Atari L'Atari - A 1040 ST from 1987 controlling LEGO Interface A

[Toastie]

Dear All,

strongly motivated by Evan Koblentz’ (@evank) “9750 LEGO Interface A hacking challenge” announced here on EB (https://www.eurobricks.com/forum/index.php?/forums/topic/195711-a-challenge-lego-9750-interface-a-hacking/), I wandered into the Atari ST world, looking at the ST’s hard- and software for the first time in my life – never had the chance to play or work with one of these beauties back then. Found three of them in “the basement” of my research institution’s labs, and one of them worked flawlessly (the other two need a little attention, as they throw bombs when booting up).

Executive summary

As already briefly “announced” in the referenced challenge thread: I managed to get the Atari’s “a-bit-special” 8-bit parallel port (it is fully bi-directional, but has only two control lines, strobe, STR#, and BUSY) with the help of just one (ancient) 74LS273 TTL chip, some resistors, and a 5V power supply, to operate the 9750 LEGO Interface A from 1986/7. This is a brief write-up of how I found out how the I/O hardware protocol of the Atari ST works, when using GFA BASIC 3.0 as programming language (1988). GFA program(s) and interface schematic are here: https://bricksafe.com/pages/Toastie/atari-st-and-9750. Video to follow, I am running a little short of time at the moment.

 

Here we go, another long vintage LEGO story …

According to the three challenge rules, Evan posted in the above referenced thread, namely

1. Use any computer and any programming language you like, as long as it was for sale in 1992 or earlier (as the next-generation 9751 / Interface B debuted in 1993.)
2. Don't use any add-on hardware that was not available back then. A breadboard is fine; an Arduino is unacceptable.
3. It's okay to run emulators if you do not have original machines, but you can't use any additional features that did not exist back then. You can use Windows 1.0 or 2.0, but not 3.1 libraries, etc.

I became very happy after reading that, as an Atari ST qualifies as a legit computer system in this challenge! My ST is from 1987 - and it features a parallel port - which gave me hopes that I can probably get this >68000 CPU loaded 32-bit power machine< (running at 8 MHz CPU clock speed with 1Mbyte of RAM available!) to controlling the 9750 LEGO Interface A. As Arduinos and the like are not allowed for interfacing, nor using any hard/software produced after 1992, I was dreaming of TTL world, as I did when I was more than 35 years younger.

Spoiler

A bit of background:

In early June of this year, I brought the working ST home (wife was - again - not amused, was the same thing when bringing home the IBM XT I found in the basement as well, including an IBM color monitor). As usual, I opened it up, gave everything a good clean (all plastic pieces including each key cap; the main board, power supply, and floppy drive) and then checked again: All good. And as it was with the IBM: How to get programs in there and running? Well, GoTeks are your friends. I wanted to keep the Atari’s floppy drive where it was, and the GoTek as external drive. And no harsh drilling, cutting and breaking into the original ST configuration. Which means: GoTek connected to the ST via the external floppy drive terminal. Per default, the ST still wants to boot from the internal floppy drive. There is however a configurable (by cutting a PCB trace and soldering a bridge, called “W2” in the schematic/on the PCB) means of making the external drive the boot drive (A) and the internal floppy drive B. Well I used a switch to be able to change that configuration – you need to flip the switch before booting though, otherwise the ST is confused about it’s drives. With that little addition (requires only to drill one 8 mm into the plastic housing, nothing else), Atari software repositories were in total reach!

Next thing to decide on: Which programming language? I am a very basic person. With even more basic programming skills. Google told me, Atari BASIC kinda sucked. It also told me, GFA BASIC actually rocked. Well, downloaded GFA BASIC 3.6 (interpreter version), the GFA BASIC 3.0 manual, and – boom – it is a totally cool programming language! Bit-manipulation, interrupt programming, >and< all the – to me – well known commands, functions, and behavior. key$=INKEY$ - does it get any better? And yes, although GFA BASIC is meant to be a structured language (no line numbering), it allows “GOTO label” jumps. I cannot care less about people not liking this. Yes, may work without. So what. It works well with.

What about access to the parallel port? All there: “LST:” or simply “0”. The serial port is “AUX:” or “1” and the keyboard is “2” (and more, MIDI port etc.). Which in turn meant to find out, how GFA BASIC operates these ports, particularly serial and parallel. Why serial at all? Because I have made a little serial2parallel Arduino Nano adapter for general purpose use; works flawlessly on any serial (RS232) or (DOS COM) USB port. Used the latter to operate 9750 from my Win11 laptop + DOSBox-X for QuickBasic programming purposes, as shown here:  https://www.eurobricks.com/forum/index.php?/forums/topic/192941-lego-interface-a-97509771-–-lego-technic-control-1-tc1-referenceideas-thread/. Now back to the Atari ST:

 

What did I have at my disposal for coming up with an Atari interface (that also met the three rules of the challenge)?

1. An Atari 1040 ST(FM) (1987) with parallel and serial port
2. GFA BASIC 3.0 (1988) with access to serial, parallel, and MIDI ports
3. A good number of TTL chips saved from being trashed; they all date back from the 1980’s
4. Soldering gear, an oscilloscope, multi-meter, bread board, resisitors, LED's …

I began initial programming using the ST’s serial port. After all, I first had to learn GFA BASIC, and how GEM works, and so on, and so on. Never used an Atari before June 2023. I more or less “copied” (well typed in) my working DOS QuickBasic routines controlling 9750 on an IBM XT (https://bricksafe.com/pages/Toastie/lego-interface-a---9750---9771---tclogo/program-files-) into GFA BASIC – with – “some” limited success. The thing is, the Atari’s serial port has I/O buffers; the IBM XT has not. When garbage accumulates in these buffers, my Arduino “protocol” is seriously screwed up. This “protocol” does this: Send a byte to the Arduino over serial (RS232) or UBS and then immediately listen to the reply. After conversion to parallel on the Arduino, the sent byte sets the 6 outputs of 9750; the Arduino replies back the output states of 9750 in addition to the two sensor input states. This is the protocol (send and immediately receive one byte) TLG used on the IBM XT with the LEGO 9771 interface card as well, and (I believe) on all other LEGO endorsed platforms also.

It turned out that the two GFA BASIC functions "boolean=OUT?(port,byte)" and "boolean=INP?(port)", which are replying the status of the ports as FALSE=busy or TRUE=available, did not really work as expected using the serial port (AUX: or “1” in GFA BASIC). In a hardwired “client/server” setting (client=Atari, server=Arduino), it is all about initialization. Once that is done, nothing much can disturb the communication other than programming errors. In other words: Whatever garbage is in the serial out buffer upon startup: just dump that. Then do the “LEGO style initialization process”: OUT 1,bin0010101; var=INP(1); IF var AND bin0011111=bin0010101 then hardware is present and works. And that worked very well on the Atari; 9750 was controllable with an Atari ST via its serial port with the help of an Arduino Nano as serial2parallel converter. SUCCESS!!!

BUT, BUT, BUT: CHALLENGE RULE #2 says:

Don't use any add-on hardware that was not available back then. A breadboard is fine; an Arduino is unacceptable.

!BUSTED!

Well, back to the drawing board. Atari forums and other websites note: The parallel (LST: or “0” in GFA BASIC) port of an ST is somewhat “special”:

1. It lacks some control lines most printer ("Centronics") ports and parallel printers featured back in the days, such as an acknowledge (ACK) line, among others. The ST’s parallel port has (only) a “strobe” (STR#) and “busy” (BUSY) control line, the eight bit D0-D7 lines, and ground. That was good enough for most 1980’s printers, so in essence all was fine …
2. Much more importantly, you can write to AND read from the parallel port using ALL 8 DATA BITS! WOW! As there is no reason to read the 8 bits from a printer, these Atari folks had certainly something else in mind than just printing from the parallel port.
3. Third: Data copied to the parallel port are “transient” of nature, as the Atari operating system uses the 8 in/outputs for other purposes as well, according to Atari forums. And the internet tells you: Fast parallel data exchange via the Atari parallel port possible, using special cables, protocols, hardware, and software. What to do with that rather confusing information? Not much.

Well, what did help me, was getting hold of the Atari ST PCB schematics, breaking out my good old Tektronix oscilloscope, solder/crimp a 25 sub-D connector style parallel cable (using only 11 lines: STR#, D0-D7, BUSY, GND), run GFA test programs, and poke around a bit with the two oscilloscope probes ...

It quickly turned out that the Atari sends out data over the parallel port when using the GFA BASIC “OUT 0,byte” command only when BUSY=LOW. That is fully in line with the early Centronics “compliance mode” protocol:

1. Check the BUSY=LOW condition, when that is/becomes true,
2. put data on the data bus,
3. assert a HIGH,LOW,HIGH) strobe (STR#) pulse of some microseconds length (Atari: 100 us),
4. on the negative STR# slope, data are clocked into the printer, which in turn
5. asserts BUSY=H, and when ready again,
6. asserts an ACK LOW/HIGH/LOW pulse and then pulls BUSY to LOW again.

The Atari however is lacking the ACK line; if BUSY is HIGH (=device not ready, see below though! This changes later to: BUSY=HIGH=external device ready for providing data and BUSY=LOW=external device ready for accepting data), it waits some 30 seconds and tries again before eventually timing out. The schematics of the Atari ST reveal that it’s parallel port is operated bi-directionally by the Yamaha YM2149 “sound chip” – but that chip it is much more than that: It features, among other things, two 8-bit wide I/O ports, one of which is used for the Atari parallel port; STR# is provided by one line of the osecond YM2149 I/O port, BUSY is connected to input “I0” of the Atari’s 68901 multifunctional peripheral chip. Note that the BUSY line is literally “bolted” to +5V via a 1kOhm resistor – pulling it LOW (< 0.8V!) needs a solid TTL LOW signal. All lines of the two I/O ports of YM2149 are internally pulled-up HIGH; according to the YM2149 datasheet with 60kOhm minimum resistance – here a grounded 4.7kOhm resistor should be OK to get below 0.8V = TTL LOW – 2.2kOhm should be on the safe side.

 

Next step: Testing GFA BASIC simple input/output testing routines and record changes in the STR# and BUSY lines.

1. BUSY was clamped to LOW and repeated OUT(0,byte) write data attempts in a simple for-next loop were performed: Worked fine. The oscilloscope trace of the STR# line is depicted schematically in panel A), top trace, in the figure below. All seems to be in line with the Centronics protocol. Check!
2. Performed INP(0) read data attempts with the same setup – but nothing happened! Program froze up immediately, no break (CTRL+ALT+SHIFT) was possible. However, simply removing the LOW clamp from BUSY and letting it “float” (well, see schematic above, it is pulled-up via 1kOhm to +5V = HIGH) reanimated the program >instantaneously< and the upper trace in panel B) was recorded when repeatedly reading the data lines with INP(0). Check!

But then …

… I thought “strange” … when does the presumably negative slope trigger on the STR# line for OUT (according to the Centronics protocol) “transition” to a positive slope trigger for INP? It did not make much sense. Google was also not helpful, even after hours of searching. Which left me with: Trial and error. I love trial and error. At some point, I arbitrarily connected STR# and BUSY – did not work either, program froze again up. When trying repeated OUT commands that is. As said: Deep in trial and error territory I was. However: In retrospect, this could of course not have work but revealed the following: When turning the computer on, loading GFA BASIC, running  the program, the first OUT command worked, a second did not. The oscilloscope showed: Initially (STR# + BUSY) = L. And then OUT works??? What??? This means, that a >positive< slope of STR# is supposed to clocking the data into the external device! Not the negative slope, as the Centronics protocol suggests. After the first OUT command, (STR# + BUSY) = H, so a second OUT cannot work. But an INP should – and did! After that step, (STR# + BUSY) = L again, and another OUT works etc. This also means that INP reads data on a >negative< STR# slope. The trace on the oscilloscope obtained with repeated OUT/INP loops are depicted in panel C) in the figure below.

 

At that point, the “rules” for operating a dumb device (dumb=providing/having no control lines) >bi-directionally< using the Atari’s parallel port became rather clear:

1. STR# + BUSY = LOW on initial OUT/INP sequence. This is straight forward: Gather the status of BUSY using OUT?(0); if FALSE then BUSY is H; if so, do one byte=INP(0) and simply dump returned byte; now BUSY=L and “endless” repeated OUT/INP sequences can be done:
   
    
2. As the OUT data are “lost” on the parallel I/O lines at some point (according to the Atari forums after a few ms), and at latest, when reading the lines with INP, they need to be latched on the >positive< slope of STR#, see above. TLG used transparent 8 bit D-FF TTL latches with tristate outputs (74LS373) on their 9771 card. This fancy approach is not possible here, as there is are no dedicated IORead# and IOWrite# lines available, there is only “one” line (STR#=BUSY) for clocking data in and reading them out.
    
3. For that purpose 74LS273 is a perfect match: 8 non-transparent D-FF TTL latches, having always logical defined outputs (L or H); all logical levels at the 8 D inputs are latched with a positive TTL slope at the CLK input and immediately show up on the 8 Q outputs. A negative slope at CLK does nothing, so when reading data with INP(0), nothing happens to the 8 Q (output) states of 74LS273.
    
4. As all this is securely happening “behind” an I/O chip (YM2149) and not directly on the CPU’s data bus, and as we know that there are 60kOhm pull-up resistors on each parallel port data line, we can use a dirty trick to feed-back the Q output states of 74LS273 to its D input lines via 2.2kOhm resistors: In output mode, YM2149 easily drives the D inputs of 74LS273 to H/L, even when the corresponding Q outputs are L/H; the 2.2kOhm resistors prevent any harm: The maximum current flowing, when D=H and Q=L is 5V/2.2kOhm = 2.2mA. Each output of 74LS273 as well as each output of YM2149 easily sink/source that current (BTW, 10kOhm feedback resistors don’t work, as the voltage on the D line does not drop to or below 0.8V when Q is L. The YM2149 does not know what to do with such a voltage; it simply says it is still H, as tested). This approach of using resistors within the 8 data lines between an external device that can read and write and the Atari’s parallel port as security measure is widely known in corresponding websites and forums, see for example here: http://info-coach.fr/atari/hardware/interfaces.php#if_parallel.
    
5. Finally: The two sensor lines of 9750 are routed to the D inputs 6+7 of 74LS273; on each OUT/INP sequence, the corresponding Q6+Q7 data become available to the program running on the Atari: The OUT command clocks the data in, the INP function reads them in (in addition to D0 to D5).

And that’s it. Here is the schematic for the “interface” (= one 74LS273 + 8 x 2.2kOhm resistors + 5V power supply, which is not that much of an “interface” …).

+5V power may be obtained from the Atari main board (this is a bit on the invasive side) or from any generic +5V power supply. Shown in the schematic is a stone-old 7805 regulator, which can be fed with DC power from +7 up-to +25V, +12V recommended. The LED’s are purely optional; with them you don’t need to connect the 9750 interface A but will have the same light show ;). The 1uF/10kOhm RC combo on the RES# input of 74LS273 ensures that it does not arbitrarily “flip flop” during power up. The very old TTL “trick”, I know. Also optional – upon initializing the parallel port, all is fine. In that case, just connect RES# to +5V.

And here is the tidy, very organized and (or better but ...) working breadboard version of the Atari parallel I/O interface for controlling LEGO Interface A. As far as I know such a thing does not exist - correct me if I am wrong though!!!

More on programs I am using for controlling 9750 per key clicks or per “user programs” in subsequent posts in this thread.

All the best,

Thorsten

Edited August 26, 2023 by Toastie
Using the English language ... remotely correctly

[evank]

Congratulations, @Toastie, you win. :) Your prize is bragging rights!

I updated my page at https://www.brickhacks.com/2.php.

Edited August 26, 2023 by evank

[Toastie]

19 hours ago, evank said:

Your prize is bragging rights!

@evank Thank you!

That is much more than I hoped for!

This challenge is really motivating. I sure hope there will be more entries. @alexGS has many ideas/proposals - and I am sure - solutions. And surely others as well.

And thank you very much for setting this up, and foremost, documenting any progress in this regard on your website.

All the best,
Thorsten

Edited August 26, 2023 by Toastie

[evank]

I want to see somebody make it work on an 800, or a TRS-80. 

[Toastie]

21 hours ago, evank said:

an 800, or a TRS-80

I believe it is helpful for the challenge to get a notch more specific ;) Googling "800" does tell you a lot of interesting things - OK, we are in an Atari thread - so this yields "Atari 800" () but also Atari 800 XL ... which to choose from?

The TRS-80 also comes in a rather interesting variety - do you have a specific system in mind?

Altair ... 8800 I guess, right? There are so many versions ...

Do you own (or have access to) any of these?

Best,
Thorsten

[evank]

800/800XL are both valid, in my opinion.

I don't have a specific trash-80 in mind. I guess just one of the consumer systems, not one of the business systems.

Altair would be a stretch, or maybe it would be easier, who knows ... the people I know who are into S-100 can make them do cool things that I don't always understand.

I used to have access to all of these and a lot more, when I was in charge of a computer museum here in NJ. I left that organization in 2019. I'm still friends with some of the members, but I no longer have easy access.

[Toastie]

@evankChecked about prices - these 8 bit beauties sell for high prices, so I am out of the game (apart from the Speccy, of course).

Also checked with the Atari Gurus on their forum - they said, nothing is wrong with the circuit I posted above.

I'll make a little perfboard version of the Atari interface just to have the two (Arduino and 74LS273) ready to go. Need the breadboard for other stuff.

Best,
Thorsten

[Toastie]

From breadboard to perfboard

I just finished cleaning up the mess around 74LS273 on that breadboard - by putting it on a perfboard and do some soldering. The Atari 9750 parallel interface (left) has now a similar shape as my serial 9750 interface (right), I tried to (very, very) remotely give it an Atari-ish shape:

 

As Atari (ST) cases appear to age nicely over the decades (the ST I am using was born in 1987, at least the PCB says so) - others call it yellow/ing, same thing that happens to mostly white LEGO pieces - I thus chose tan bricks and plates to sort of match that  The top cover is pure 999 Gold - these are tiles from the MK Flying Dutchman stand I did not find any use for, as my FD is plowing through LEGO water up here in the attic .

These are the parts used - and yes, I did some cutting, otherwise a snug fit of the board, so that the cables (to 9750's port and to the Atari's parallel port) can be securely attached/detached, is tough to achieve at this scale:

Left: Interface partly assembled.

Right: The light attachment is for trying things out, which don't need 9750. I did not include the two input/sensor LEDs, as it was already a pain in the butt to get the 6 output LEDs in there. Furthermore, the inputs of the interface require TTL voltage levels, so that e.g. the TC light sensor won't function at all.

Left: Front view [power is 7-25V DC, 9V, 10V, and 12V LEGO DC power supplies work well; 11 ribbon flat cable (STR#, D0-D7, GND, BUSY) that goes to the 25 pin parallel port of the Atari].

Right: Back view (either the LED attachment is plugged in or the 20 ribbon cable that comes with 9750)

The interface with LED attachment:

Some very short video showing the interface in action to follow.

Best regards,
Thorsten

Edited September 1, 2023 by Toastie

[dr_spock]

Excellent work. 

How do you get the holes for the LEDs to line up so nicely?

[Toastie]

Thank you very much!

1 hour ago, dr_spock said:

How do you get the holes for the LEDs to line up so nicely?

The 1x tiles have anti-studs with an indent slightly smaller than 1.5 mm. I use these as a guide for a 1.5 mm drill (on my drill press) to drill "pilot" holes. Turning the tile around, I try to scratch mark the position of the hole in between two pilot holes with a sharp wood piercer(?), once it looks OK, I pierce a little more, then take that mark as pilot for the 1.5 mm drill again. Last step is widening the 1.5 mm holes with a 3 mm drill (for the 3 mm LEDs). The drills (for metal) have never seen metal, only ABS and wood.

[BTW: The drills in that box are really sharp; I thoroughly checked that by (OK, sort of accidentally, but still idiotically) drilling into my left index finger using the 8.5 mm drill. Yes, sharp the thing was. But: A small piece of wipe paper, some duct tape and a bottle of beer ensured that I could proceed with my project ]

Best,
Thorsten

     

[Toastie]

On 9/1/2023 at 3:09 PM, Toastie said:

Some very short video showing the interface in action to follow.

That'll take some more time than originally planned - yesterday I fried 2 of the 8 IO ports of the Ataris's Yamaha sound+I/O chip: "Thou shall not" ... connect a ribbon cable the other way around to the outputs of a parallel port driven by a 40 pin I/O chip". Particularly when there are additional shorts caused by sloppy soldering 

But: The financial department here (=my wife ) cleared the acquisition of a rather cheap desoldering station as well as the purchase of 2 used but functional Yamaha chips ... 

Will try (very hard) to get back to #8bitisbetter behavior, for example: "Thou shall not hot-plug on ancient computers"

Best,
Thorsten

[Toastie]

Success!

Desoldered the faulty 40 pin Yamaha chip, soldered in a 40 pin socket, popped on the working chip - and - works

Spoiler

 

Should you ever have to desolder such a big one from a double-sided PCB: Just follow every step, Adrian is suggesting:

The hot air trick really does it ...

 

So on to the video ... I suck at taking videos, though.

Best,
Thorsten

 

[Lego Tom]

On 9/2/2023 at 4:44 PM, Toastie said:

That'll take some more time than originally planned - yesterday I fried 2 of the 8 IO ports of the Ataris's Yamaha sound+I/O chip: "Thou shall not" ... connect a ribbon cable the other way around to the outputs of a parallel port driven by a 40 pin I/O chip". Particularly when there are additional shorts caused by sloppy soldering 

But: The financial department here (=my wife ) cleared the acquisition of a rather cheap desoldering station as well as the purchase of 2 used but functional Yamaha chips ... 

Will try (very hard) to get back to #8bitisbetter behavior, for example: "Thou shall not hot-plug on ancient computers"

Best,
Thorsten

LOL - many of my tools were acquired to remedy 'emergency' situations. It's akin to a lady needing new shoes to match the new dress she just bought.

[evank]

On 9/2/2023 at 4:44 PM, Toastie said:

acquisition of a rather cheap desoldering station

Last winter, I asked Hanukah Harry / Solstice Sam ... aka my wife ... for a vacuum desoldering station. They obliged! It's a pleasure to use vs. wicks or hand-powered solder suckers. Let the tip heat up, apply to your solder joint, squeeze the trigger. WOMP! The solder magically disappears. I love it.

[Toastie]

5 hours ago, evank said:

I love it.

I do as well - and I wonder how I could live for so many decades without ...

When it comes to desoldering 40-footers (or any chippy, particularly the 16 pin 4164 RAMs), Adrian's heat gun trick + the nifty curved toy (made one from 2mm dia garden wire) does it for me.

Best,
Thorsten 

[evank]

This is the one I have: https://www.amazon.com/Hakko-FR-301-Desoldering-Tool/dp/B07BKSLLG9/