LEGO Interface A (9750/9771) – LEGO Technic Control 1 (TC1) reference/ideas thread

[Toastie]

This thread is about one of the first attempts of TLG wandering into the world of electronic control using actuators and sensors in connection with a computer. Whoever wants to contribute, feel free to dump it in here. Should there exist already a similar thread on EB, moderators please let me know, merge, or delete this thread!

Here are absolutely wonderful references to already elaborate documentations and solutions for the operation of "TC1 world 4.5V machinery":

1. Apple II operating 9750 and much more: http://lukazi.blogspot.com/2014/07/lego-legos-first-programmable-product.html
2. Reengineering procedure and functionality of 9771 (in German); schematic of LEGO Interface 1 ISA bus card 9771:
   http://www.elektronik-kompendium.de/forum/forum_entry.php?id=212705&page=0&category=all&order=last_answer
3. Details on the operation of 9750 with “semi-modern” computers using the parallel port along with Windows-based executables:
   https://lgauge.com/article.php?article=technic/articles/LEGOInterfaceA
4. On the Internet Archive:
   https://archive.org/details/vintagelegorobotics (TC1 and ControlLab)
   https://archive.org/details/@magicratandbarefootgirl (TC1 and ControlLab)
5. And finally a tutorial style written 300+ page wonderful book about the PC hardware, beginning with the architecture of an IBM PC upto the Pentium CPU level, including the ISA bus organization and its signal timing:
   http://vtda.org/books/Computing/Hardware/ISASystemArchitectureThirdEd_TomShanleyDonAnderson.pdf

(Please add more to this list - I have already lost track here ...)

Introduction

In the 1991 LEGO (dacta) book “Technic Control 1 Resources Guide” (TC1RG), the introduction reads:

“Welcome to the world of Technic Control 1 (TC1) Technology! With TC1, students from middle school through high school can work in a hands-on problem solving environment to understand better the role of computers in today's technology.”

The LEGO hardware was released about 5 years earlier. As I am constantly confused with the names as well as set/item numbers TLG is using and as these LEGO Technic Control 1 sets were mostly designed for educational in-class activities (LEGO dacta) and identical “normal LEGO” and “LEGO dacta” items have different item numbers, I am using the names and numbers found in the TC1RG:

#9750 = “Interface Box”

#9771 = “MSDOS Interface Card”

Operation of 9771

This first post discusses the MSDOS Interface Card, as I still don’t own the Interface Box – should be on its way though. The Interface Box, as per references above, features 6 x 2 TMP3055 (TMOS power field effect transistors, 60V, 12 A each ... TLG didn't mess around these days) equipped drivers for digital = on/off operation of 4.5V motors and lights, as well as two op amp driven amplifiers for digitalization (on/off) of sensor signals, touch and light. There is no A/D converter present, all states of the box are of binary nature.

The MSDOS Interface Card is an ISA bus data exchange card, which allows to write to 6 latched outputs (on/off) and/or read from two latched inputs (on/off), connected to the Interface Box with a 20wire ribbon cable. The latched information is accessible via the ISA bus IOR/IOW request, respecting DMA priority. Address decoding is done with a simple TTL logic gate assembly; data in- and output is via two 8-bit transparent D flip-flop latches. This assembly is briefly described here.

The schematic was already published in 2014 (as noted by @BrickTronic , thanks again!!!) – I just did not find that one. I guess the bizarre naming was confusing Google as well … I just finished reading the entire thread (about 70 entries) on the 2014 www.elektronik.kompendium forum page (referenced above) – and I am very happy that I can fully confirm the findings from more than 8 years ago (oh man)

1. Yes, the card address is 925 (0x39D) with the bridge installed (default) and 926 (0x39E) without.
2. Yes, one can use QBasic to control the card, however, at low speed. There is actually a scanned original LEGO program listing in the thread!

It always feels - hmmm - weird to having successfully reinvented something. On the other hand, I discovered this way that I can still comprehend simple TTL logic – I did that more regularly 40 years ago as my hobby (yup nerd throughout my entire life)

I also learned that in 2014, one individual from Holland, who earlier found many of the 9771 cards abandoned in the school he was working then, still had one card in 2014 he obviously did not want to sell. He helped a lot with tracing the board and thus for Frank’s final success of reproducing the 9771; Frank only had photographs of the card. Hidden traces were giving him headaches … Now call it a coincidence – a box with 9771 in it, arrived two weeks ago from Holland at our house – and yes, name sounds very familiar … Oh my the world is really small …

Most importantly I basically just paid the postage for that package plus a >modest< amount of money. This individual is still responding to EB PMs - it is simply wonderful.

So you may ask, why creating this thread at all then? For one, the elektronik.kompendium forum is in German (yes, I have heard about Google translator). Second I had a “hard time” (OK, it was fun) to find the relevant information on 9771 in the over thread 70 entries there. But most importantly: Maybe others have more information/references on "TC1 world" they may want to share here.

Here is the schematic, my version that is. Frank’s 2014 version focuses (naturally) on card reproduction, mine on understanding the logic of the device, as I don’t need to make one:

The schematic

I am aware that many of you guys know how it works (duh); this is more for documentation purposes (for me).

I am using this notation: X# means X = L to be true. X[n:m] means from X=n all the way down to X=m. X[n] = single number. X = address, output, input line, or other signal line. ISA_A[ ] = ISA address bus; ISA_D[ ] = ISA data bus, LIA, LIA[ ] = LEGO Interface A bus.

74LS373 8-bit transparent latches: These are eight D-type flip-flop (FF) latches. The FF outputs are each connected internally to a non-inverting TTL driver with output Q, which can be in three states: L, H, high-impedance or tristate. The latter simply means that the driver is “not present” on the bus at all, so it does not affect anything happening there.

• C input: When input C = H, all 8 FF outputs mirror the logic level present at the D inputs in parallel. When C goes L (on the neg. slope), all logic levels on the D inputs are latched and then remain constant on the FF outputs until C = H again. (As a side note: 74LS374 are not transparent; they sample the D input only upon a positive slope occurring at the CLK input).
• OC# input: When OC# = H, then the TTL drivers connected internally to the D FF are in tristate. The D FF still do their work though. When OC# = L, the Q outputs have the logic level of the latched D FF information, either L or H.

IC_5 (74LS373)
OC# is hardwired to GND = L; thus the Q outputs have always a defined logic level, L or H. Q[6:1] are directly connected to the 6 input lines of the 9750 interface box. When the correct address is present on the lines ISA_A[9:0] AND ISA_AEN = L (the PC’s DMA controller is not using the A or D bus) AND IOW# = L (CPU signals an IO write request), the C input on IC_5 = H. This means that the logic level of the 8 ISA_D[7:0] data bus lines are mirrored to the corresponding Q outputs and thus the 9750 box via the LIA bus. When IOW# = H, C goes L and the 8 data bits from the ISA bus are latched and remain present on the Q outputs: 9750 turns on/off the corresponding drivers in the box and thus lamps or motors.

Note: The outputs Q[5:4] are not used at all (nc), nor are the inputs D[5:4].

IC_4 (74LS373)
OC# is not hardwired to GND, it is directly connected to the C input. In essence, the outputs of IC_4 are only in a logical defined state (L/H) when an IOR# request is issued by the CPU: When the address is correct, ISA_A[9:0] AND ISA_AEN = L AND IOR# = L, then OC# and C go from H to L. Which means that the two inputs D[5:4] of IC_4, which are connected to the two output lines of 9750, are both latched and become visible on the ISA data bus. Furthermore, as the remaining 6 D inputs D[8:7, 4:1] of IC_4 are connected to the corresponding outputs Q[8:7, 4:1] of IC_5, the current input settings on the 9750 box (status of the box drivers = motor, lamps) are also present on the ISA data bus. The CPU thus reads the status of all 8 active 9750 lines (2 inputs, 6 outputs).

IC_1 (74LS30, 8-input NAND), IC_2 (74LS27, 3x 3-input NOR), IC_3 (74LS86, 4x 2-input exclusive OR)
These three ICs are wired as a logic network to a) decode the address bus ISA_A[9:0], check for DMA access on the ISA_A/D bus, and detect the IOW#/IOR# request of the CPU. Although the I/O address range of an 8088 CPU is 64k (&0000 to &FFFF; the memory address range is 1M, &00000 to &FFFFF), only 10 address lines are decoded by the 9771 card. This should be taken into consideration when doing super fancy programming in the upper IO address range of the 8088 CPU, as the card will not only respond to its default addresses (&39D, &39E), but also to all addresses with a non-zero A[15:A10] signature, regardless what this signature is (all L for &39D/&39E). On the ZX Spectrum this really was a nightmare, as IO address decoding was restricted to only a few internally well encoded addresses.

Specific address decoding

The card address is mainly determined by IC_1, the 8 input NAND gate. ISA_A[9:7, 4:2] are directly connected to the inputs of IC_1. The output of this gate will only = L when all inputs = H. ISA_A[6:5] are connected to IC_2b (NOR), which means that the output of IC_2b only = H, when all inputs = L. This results in: The output of IC1 will only = L, when ISA_A[9:7] = H and  [6:5] = L and [4:2] = H and the remaining third input of IC_2b is also = L. This input is “prepared” by IC_3a+b (XOR):

• Case 1: Bridge is installed. This pulls the inputs of IC3_a[2] and IC_3b[4] = L. XOR requires the inputs to be of opposite logical level to become H. The output of IC3_a is directly connected to one input of IC1, thus needs to be H for correct address detection; as IC3_a[1] is connected to ISA_A[0], it needs to be H. The output of IC_3b is connected to the remaining input of IC_2b (NOR). As all NOR inputs need to be L for output = H, the input IC_3b[5] = ISA_A[1] thus needs to be H for correct address detection. This all results in ISA_A[A9:A0] = H H H L L H H H L H = 1110011101 = &39D = 925 for correct address detection, i.e. the output of NAND gate IC1 = L.
• Case 2: Bridge is removed. This pulls the inputs of IC3_a[2] and IC_3b[4] = H. With the same logic as above, this results in 1110011110 = &39E = 926.

Further handling of ISA_IOW# and ISA_IOR# is done by IC_2[a,c] (3 input NOR gates). The outputs are only = H when all inputs are L. IC_2[a]: Output of IC_1 = correct address = L and ISA_AEN = L and ISA_IOR# = L (valid CPU IO read request). IC_2[c]: Output of IC_1 = correct address = L and ISA_AEN = L and ISA_IOW# = L (CPU IO write request). The two remaining gates IC_3[c,d] are wired as inverters to match the OC# and C input logic of the 74LS373 latches.

And that’s basically it. Lots of words for nothing much.

There must be many errors in the text above – I’ll try to wipe them out, so frequent edits may occur. Once again this is for documentation purposes only. Once I finished such a project, I forget almost everything about it within days.

By the way, on another note :D - During the annual PTChem lab cleaning frenzy this surfaced:

As no one had interest in these mostly TTL chips, as well as CPUs, memory chips and other stuff – I "rescued" them from being trashed. The hardest part was to organize them in some sort of way. What helped me in doing that was this book, I purchased in 1979, one year after it was published; it organizes the more than 2200 TTL-, DTL-, ECL-, CMOS-chips (among some others) listed, into the categories:

G = gates, F = flip-flops, M = multiplexers/demutiplexers, Mf = mono-flops, Z = counters (guess why ;).

Among the "Gs" is even a 74LS133 – a 13 input NAND gate. I’ve never heard before of such a TTL chip – it makes perfect sense for address decoding :D

 

Yes, I am happy

Next: As I don’t want to fry the 9771 card, I am planning to hook up a TTL driver (74LS06 or so) to the outputs of 9771 and illuminate some LED’s using QBasic. Will report here.

 

Best regards,

Thorsten

Edited August 6, 2023 by Toastie
Wrong D4/5 lines on IC5a

[Toastie]

@alexGS

Hi Alex,

this was your question in the VC thread:

"I am wondering whether the 9771 card logic (which I had found previously at the other link) could be interfaced to a PCMCIA slot as found on old laptops?
Would the LEGO software then ‘talk to’ port 925 and would those signals appear at the PCMCIA connector?" 

As already mentioned, don't know yet, but this something to investigate!

Now, I assume that you want to use original TC1 software, right? The COM/EXE files that is? Or do you want to operate 9750 from an old laptop, using e.g. QBasic or the like? In that case, an Arduino would certainly do the trick: Feed the data from your program to a serial port of the laptop, hook that port up to a serial2TTL converter ($3) attached to the Arduino RX/TX, which in turn converts the data to 6+2 out+in digital ports connected to 9750.

Again, if you want to run original TC1 software, this won't work, of course.

So let's dive into the nitty-gritty of PCMCIA ...

Best,
Thorsten 

 

[Toastie]

@alexGS

Hi Alex,

it appears as if direct PCMCIA usage (1 to 1) to drive a logic that is similar to 9771 may be rather difficult. But maybe others know better.

What I found though is a digital I/O PCMCIA card, that may actually work. A Google search "PIOD24" should get you to a couple of vendors, that may have the card in stock:

https://www.artisantg.com/TestMeasurement/99727-1/Acces-PIOD24-PCMCIA-24-Bit-Digital-I-O-Card

https://accesio.com/product/piod24/

From the online documentation (the manual is quite elaborate) I believe to understand that you can configure that card with some flexibility (responding to specific address/address ranges). It runs on DOS, Win3.x, Win95 etc. (16/32 bit) machines. It is also total overkill, but everything that goes into such a slot is total overkill in comparison to 9771 . The description tab says:

"Once the PCMCIA Card and Socket Services recognizes the PIOD24 card it will then appear to your application software like a card on the internal ISA bus."

There is a memory resident program that does all the synching between PCMCIA and ISA behavior. The output of that card is apparently a 8255 PIO and 3 programmable counters. The PIO does exactly what the 373's do in 9771: You load data into one of the three 8 bit output ports - or you read from them. The output data are latched as well; once clocked into the PIO, the outputs hold this information until the next write access - heck, this is how I/O chips work, you know all that.

These cards maybe expensive though - the pages look like as if they do business with (old) industrial type hardware users, but I don't know. You need to call for a quote ...

Best regards,
Thorsten

[Toastie]

Just one more reference that I did not find when I started this thread - it appears as if this thread becomes obsolete.

On the other hand, the information is so widely spread out (as far as I am concerned) - there are movies on the WayBack Machine, links on diverse websites not related to LEGO at all ... maybe this thread may serve as a LEGO related "link repository" ... 

This is from the Louisville Hackerspace website: https://wiki.lvl1.org/Lego_Interactive_Interface-A_Driven_via_Arduino with many references.

 

By the way, 9750 arrived from Holland today. And yes, it works with TCLogo as well as QBasic programs I am composing on my IBM XT. Actually, I am composing them on my laptop using DosBox-X and then transfer the program files to floppy disk images, which are read by the GoTek on the XT.

Will post more here - chances are, what I post has been posted somewhere else on the net. Of course.

Nevertheless: I am very happy with 9771 and 9750 run by an IBM XT. Latest hardware is from 1987; 9750 that is. I just love this.

Best,
Thorsten

 

[Toastie]

Update: Made a "9750 Arduino Box", that allows you to run 9750 off from any modern computer - and any ancient machine with a serial port. No need to have a 9771 ISA card ...

For "modern" laptop type computers, a USB to serial adapter is needed. A USB to TTL adapter will work as well, but let's focus on "generally applicable"

For "ancient" computers, any serial port will do.

Here is the box - will post more on how to use it.

Left: Ardunio Nano clone, center on/off switch, right, serial-to-TTL adapter.

A little extra: 6+2 LEDs (2 input, 6 output) showing the in/out state of the interface. This is how it folds up in the LEGO brick enclosure.

A "modified" BB 6x8 tile used as a faceplate.

Arduino attached to faceplate.

From top left to bottom right:

Serial port of the box, connecting to any computer; parallel port connecting to the 9750 box; USB port for a) powering the box or b) programming the Arduino Nano; switch to allow programming the Nano (position "P") or let any computer control the Nano (serial to parallel data conversion).

This thing allows you to operate the Interface 1/A from 1986/7 from any modern computer, e.g., a Win11 64 bit laptop, or from an IBM XT (1983) without the 9771 LEGO ISA card.

More to come on programming ...

Best,
Thorsten

 

 

Edited January 12, 2023 by Toastie

[alexGS]

9 hours ago, Toastie said:

This thing allows you to operate the Interface 1/A from 1986/7 from any modern computer, e.g., a Win11 64 bit laptop, or from an IBM XT (1983) without the 9771 LEGO ISA card.

More to come on programming ...

 

Hello Thorsten,

It’s ironic that you post this today, just as I was replying to your new thread (relatively new anyway) which I have only just seen today while doing Google searches.

First, well done on assembling this information in one place, I think it is useful.

Second, thank you for a solid attempt at an answer to my question - which I am still struggling with :D I’ve spent about five hours today dredging through ancient PCMCIA specifications. And yes, I read all about that 24-bit IO card, which still can’t quite do the job because it can’t mix input and output bits in the same latched port (remembering that the LEGO software can only talk to one port).

To clarify, my idea was to attach the latches/address logic of 9771 to the PCMCIA slot, which appears to have all the suitable address and control lines as well as the data bus (as found on the ISA bus). Sadly, between the ISA bus and the PCMCIA, there is both a hardware layer (the Intel 82365SL) and a software layer (‘socket services’, ‘card services’) that need to cooperate. Both could be programmed to allow the access as port 925, and the PCMCIA slot is electrically and timing compatible with ISA. The configuration via card services looks like it needs this programming in the form of memory registers attached to the PCMCIA device - ie. the interface would need an EPROM, or something, to supply its configuration data. I don’t know how to make that work. http://elinux.org/Flameman/pcmcia gives a summary of the layers/device definitions.

It still seems possible. The objective is to run the original LEGO software on a slightly wider range of hardware, being laptops as well as desktops (it is generally difficult to find anything with an ISA slot, but there are more devices out there with PCMCIA and able to run DOS, such as from booting DOS off a USB drive).

I have two other left-field ideas in mind, but neither would offer the LEGO software compatibility that I would like to see.
Those left-field ideas are - the Velleman USB interface (electrically suitable, six output bits and two input bits etc.), or the use of a RaspberryPi - actually, that’s miserable with the 3.3V, so perhaps the Arduino instead, but with either of these - like the printer port idea - it seems everything has to be done from scratch. The previous Arduino solutions haven’t actually shown any use beyond turning motors on and displaying inputs - there has to be a method of actually programming it :)

I hope your Arduino implementation works out differently :p

Is it possible to read and write those bits with a single byte written/read to/from serial? And if so, could some kind of device driver (a TSR perhaps) make that available to the LEGO DOS-mode TCLOGO?
 

A possible lead on that last idea; these TSR programs written to redirect sound card access to an ISA or LPT port. I think the task we face is similar (instead of port 205h, 388h, etc. we could redirect 39Dh to the serial or parallel port, though I wonder how inputs would be handled - perhaps the program can intercept inputs as well as outputs. It’s written in assembly language that I know almost nothing about - http://github.com/JKnipperts/TNDY

 

I’m definitely interested, even though seeing holes drilled in LEGO and tubes ground off the underside of a tile has made my heart skip a beat ;) It also confused me when you said a USB-to-serial converter would be needed for a modern PC, considering the Arduino has its own micro-USB built-in. I guess all will be revealed in your next instalment.

 

Thanks again

-Alex

Edited January 12, 2023 by alexGS

[Toastie]

7 hours ago, alexGS said:

To clarify, my idea was to attach the latches/address logic of 9771 to the PCMCIA slot

Hi Alex,

thank you for your support on this thread :D it really is just a container for what is already (scrambled all over the place) out there.

Just to run into the right direction (as not in: OK, we are blasting off, tell us later to what location), from the quote above I take it that you

1. want to attach some custom hardware (latches etc., the 9771 logic) >directly< to the PCMCIA slot of a laptop or the like, correct?
2. And you do want to run the TC1 software (TC Logo) to operate 9750 (connected to your custom hardware) from that laptop, correct?
3. And c) that laptop is a DOS machine that can natively run TC Logo, correct?

Or would it be OK to run TC Logo on a "modern" laptop within a DOS emulator, such as DOSBox-X? The latter provides some flexibility with regard to interfacing with the outside world (e.g. serial and parallel ports, as per configuration) but I have no clue what it does when intercepting in/out commands.

What I am using is DOSBox-X; QBasic works flawlessly within that environment. I am using the serial port COM1, which is mapped by DOSBox-X to a real COM port (USB2Serial adapter) to communicate with the Arduino and that talks bidirectionally to 9750:

DEFSNG A-Z
SUB WriteOutputPort
 
  SELECT CASE ComMode
   
    CASE ComISA
      OUT IOAddress, IOStatus
    CASE ComSerial
      PRINT #1, CHR$(IOStatus); '";" required, otherwise cr is sent!
    CASE ComSim 'do nothing
 
  END SELECT

END SUB

INPUT$(1,1) is then reading the Arduino reply.

On the IBM, I am using direct 9771 card access via QBasic's OUT / IN

However, this is not compatible with TCLogo, of course. But maybe DOSBox-X can capture OUT / IN commands from the CPU?

I'll have to check ...

All the best,
Thorsten

[Toastie]

21 hours ago, alexGS said:

Is it possible to read and write those bits with a single byte written/read to/from serial?

Hi Alex,

well, I guess so. What I am doing on the Arduino side is totally simple; it depends a bit on the board type. I used a Uno R3 to test the waters. Then migrated to a Nano (all clones), as this board still has enough I/O ports to solder to. Instead of using the digital pin in/out declarations, I am using port manipulation; first define the input/output ports of the available bits of the 8-bit wide ports:

  DDRD = DDRD | B11111100;                    // This is safe: It sets pins 2 to 7 as outputs
                                              // without changing the mode of pins 0 & 1 
  //     pins    XXX21098                     // Ports 5-7 (pins 13-15) not usable on Nano
  //     port B  XX543210                     // 
  DDRB = B00001100;                           // Ports B0/B1 and B3-B7 = inputs (B5-7 not usable)

And then something like:

PORTD = FromQB << 2;

which writes 6 bits in parallel to the output pins. Input works alike.

The protocol is straight forward: When a (serial) byte is received from the host computer and that one is <= B00111111 (0x3F), the Arduino copies that as output change to register D. When a serial byte received is > 0x3F, the Arduino treats that as host read request and reads port D (output) and B (input), assembles a byte that is 1:1 with what 9771 does, and sends this one byte out the serial port (Port B is also configured to have two outputs driving the input status LEDs on the front panel).

21 hours ago, alexGS said:

I’m definitely interested, even though seeing holes drilled in LEGO and tubes ground off the underside of a tile has made my heart skip a beat ;)

Ha! That was a BlueBricks 6x8 tile. However: TLG does not make what I need, so out with the powertools :D I find it quite versatile to build electronics used for LEGO stuff using LEGO bricks and plates - and as PCBs don't follow the stud rules, who is gonna be "made to fit"? 

22 hours ago, alexGS said:

It also confused me when you said a USB-to-serial converter would be needed for a modern PC, considering the Arduino has its own micro-USB built-in.

True. But there is a caveat. I initially thought, an Arduino hooked up via its USB port to a host computer may act like a COM port. It does not: DOSBox-X says that there is no serial port available. Device manager is also not listing a COM port but rather the USB chip on the Arduino. When you plug in a Serial2TTL or USB2TTL adapter into the USB port, it is listed as COM port in device manager. And DOSBox-X recognizes it readily as such. Main difference is: USB2TTL adapters work for computers with USB port; when using a Serial2TTL converter attached to the Arduino, all computers can talk to the Aduino, provided they have a serial or USB port (the latter then needs a USB2Serial adapter. That's all.

With a USB2TTL adapter, the Arduino can be powered from the USB 5V/GND lines. This is not possible with the Serial2TTL adapter.

So it all depends, I guess.

Summary: 1 byte transferred to the Arduino = parallel change of all outputs; 1 byte read request to the Arduino = response of 1 byte with the status of all ports (6 out, 2 in).

Best wishes,
Thorsten 

[alexGS]

On 1/12/2023 at 9:05 PM, Toastie said:

Just to run into the right direction (as not in: OK, we are blasting off, tell us later to what location), from the quote above I take it that you

1. want to attach some custom hardware (latches etc., the 9771 logic) >directly< to the PCMCIA slot of a laptop or the like, correct?
2. And you do want to run the TC1 software (TC Logo) to operate 9750 (connected to your custom hardware) from that laptop, correct?
3. And c) that laptop is a DOS machine that can natively run TC Logo, correct?

Thanks, Thorsten!

1. yes, 2. yes, and 3. yes -

It is relatively easy to find a 1994-2004 laptop (or desktop) that can boot into DOS (a bootable USB drive can be made with Rufus). TCLOGO is a small .COM that seems to run easily in DOS with trivial memory requirement, but not in DosBox when I tried it; “out of space” was the message I saw. I imagine some kind of stack for its own variables.

Most laptops of suitable age have parallel and serial ports as well, so I am happy to entertain all options; I just thought that the PCMCIA slot was closest to the original ISA bus used by the 9771 card; and this seems to be the way we might achieve I/O at port 925 without any additional software tricks. But we’d have to get past Card Services (the evil gatekeeper who will deny our logic!)

Your data sent to/from the Arduino, being a single set of eight bits for outputs and inputs, seems to be more promising for original software compatibility than the parallel port cable I’ve made; that requires the use of three separate ports, one for outputs, one for inputs, and one for power output; this would be difficult to forward/translate to port 925.

In summary, I like your serial port output via Arduino translation, the hardware is easier to make than my PCMCIA idea, compatible with a wide range of machines. Thank you for explaining the need for the USB-TTL adapter, I have one lying around, and an Arduino Nano for that matter, so I shall now try to make your circuit :)
 

Now imagine if we could redirect that serial I/O, so that the TC-LOGO program can use it. This was what I was thinking a TSR program could do (like the soundcard example above) but I was worried how it would redirect inputs as well as outputs.

I’ve just had a better idea for a logically-simpler solution. How about using a tool like Ghidra to diassemble the TC-LOGO program (quite small, only 34KB!) and look for where port 925 is used (39Dh) and change it to… 3F8h? The COM1 address :)

Since the 9771 card has a jumper to change the I/O address, I guessed there must be a way to change the address used by the DOS version of TC-LOGO, but it is undocumented and I can’t find it by poking around so far. Imagine if it was simply a /p926 command switch…!

It feels like there are many potential ways to solve this problem, I look forward to trying Ghidra tomorrow. I don’t know if it can make an edit and reassemble…

Cheers

-Alex

Edited January 13, 2023 by alexGS

[Toastie]

12 hours ago, alexGS said:

but not in DosBox when I tried it; “out of space” was the message I saw.

Hi Alex,

that is weird. I just tried it last night: No problems whatsoever, TCLOGO just sends any I/O commands (like "talkto "A) into nowhere of course; other than that it works fine:

However, I am using DOSBox-X (https://dosbox-x.com/), the later 2022 version that is, not DOSBox. Just saw a minute ago that there is a new version that I will install right away.

There are so many options using the ports in DOSBox-X - I simply haven't looked into details yet.

QBasic1.1 and QuickBasic4.5 run flawlessly in DOSBox-X, including the serial port mapping DOS COMportX = WindowsCOMportY, USB2Serial adapters are fine. Note that the adapter has to be plugged in >before< DOSBox-X starts - it won't be recognized at all when you plug it in when DOSBox-X already runs. Also, you need to tell DOSBox-X in the config file, which COM port your adapter is providing:

serial1 = directserial realport:COM8

This then becomes COM1 in QBasic.

If you want my QBasic program and/or the Arduino sketch, please let me know. The QBasic program runs on my IBM XT with either 9771 or the serial port + Nano attached to 9750. Here's a screenshot:

You can either turn on/off the individual outputs (T), or use "press and hold" (P) for individual outputs or use motor commands like "AFBRCS" for motor A forward, B reverse, C stop (in any order); CFASAS will simply run motor C forward and A stops. "BS" ;) will not any harm, but just stops motor B with the others unaffected. The motor commands are going out as one byte to the Arduino, and that one selects all the outputs to 8750 in parallel as said. This way, motors turn on/off at the exact same time without any lag. In each loop of the QBasic program scanning the keyboard, the inputs of 9750 are read as well. 

The COM modes are ISA (9771), SERial, and SIMulation, the latter to try out things :D. Pressíng "X" just iterates through these three. Pressing spacebar tries to make contact ... The program runs without modifications on the XT and Win11 laptop, so it should run under Win98 and the like as well. On the XT, both modes initialize correctly, when having 9771 installed and a serial card + Arduino. On my laptop, only serial and sim modes work (of course).

Best wishes,
Thorsten

Edited January 13, 2023 by Toastie

[alexGS]

Hello Thorsten,
Thank you for the notes about your Arduino sketch and application - which I will need eventually ;) I haven't got that far yet.
Today I tried Ghidra as promised - it was a dead-end though, as that clever decompiler simply isn't set up to handle old DOS .COM executables with no headers and unknown development language, etc.
More convincing was the Reko decompiler, which seemed to spit out believable assembly language, but better still is the DOSBox-X debugger - because with that, you know the assembly code shown is the assembly code that's actually running, rather than some 'best guess'.

As you said, DOSBox-X works fine with TCLOGO.COM and if only I knew how to use the Debugger properly, I think I could get somewhere.
I prepared it by typing the TCLOGO command 'talkto "a onfor 1', and then in the debugger, I typed 'log 100000' to log the next 100,000 CPU cycles to a text file... then I clicked back in the TCLOGO window and hammered the Enter key... response was extremely slow (execution was slowed right down) so hopefully I got there in time.

Looking in the text file (which is 256MB in size... whoops), I seemed to find the smoking gun in the first few lines... mov dx,[9345]            ds:[9345]=039D
I think that's trying to tell me that location 9345 (?) contains hex 039D, which is of course equivalent to decimal 925...
After this line, the EDX register contains 039D for the next few dozen instructions. I would love to upload screenshots, but I can't because I can only upload 0.02MB here.

A little further down, it seems 9343 also contains 039D - I don't know why it would be in two places, but a search of the text document confirms that it is consistently in both places.
How does it get there? and how can it be changed (to 03F8)? These are the questions to answer...

-Alex

Edited January 14, 2023 by alexGS

[Toastie]

1 hour ago, alexGS said:

but I can't because I can only upload 0.02MB here.

Hi Alex,

with regard to the file size for images: You need to simply link from an image hosting service such as flickr or the like. I am using BrickShelf, but that is a) vintage and b) does not accept any new accounts anymore since long. However, when I copy a link to an image on BrickShelf into a post here on EB, it thinks a second and then the image pops up. Max. image size is 1000 x something; as far as I am experiencing, the EB software automatically scales an image to <=1024 x something. When you double-click on the image, you can scale it further down. Well, that is what I do ;)

Would love to see a bit more on that disassembled code! Back in the days, I was the nerd, who always got games from my fellow chemistry students for the ZX Spectrum - which were copy protected. As my brain has a failure with regard to gaming (that section seems to be replaced with either simply air - or with cells that find it cool to tinker with machine code protecting copying a game ...), it was my task to figure out the protection by disassembling files. That was rather simple in most cases, nothing compared to what you are trying.

I also thought that a command line switch for TCLOGO is not really necessary: In the example BASIC program in the 9771 user instructions booklet, page 76, what they do is 

P=925
OUT P,21
IF (INP(P) AND 63) = 21 THEN OUT P,0 ELSE ERC=4

So they just write bin10101 (dec 21) to the address of the 9771 card, then read back the (latched) status of the 8 bits of 9771, mask the upper three bits in case something is e.g. on the 2 input lines already, and check for the result, which should of course yield dec 21. If not, the error code 4 is further evaluated later as "no card present".

Now all you have to do is running this code for P=925 and then 926 (or wherever address lets say a home brew card is sitting on) and then you know whether there is a card or not. The user would not have to deal with this at all. In other documents of the TC1 literature, it is mentioned that 925 and 926 are hardware selectable, in case you want to run two 9750's off from two 9771 cards. Software wise, it is straight forward to figure out the configuration of the computer: None, one, or two, depending on the hardware setting only.

At least, I guess this could be the case.

Best,
Thorsten

 

Edited January 14, 2023 by Toastie

[alexGS]

Thanks. It seems like a long time ago that I had to host images somewhere else - must be 20 years since I used imageshack.us. I don’t use any such sites these days; it would be easier to post a YouTube video. Maybe a Google Drive link would work. Links inevitably get broken anyway, and we are probably creating this for when someone else searches for it in 10+ years’ time..!

The TC-LOGO software for Apple II allows selection of the slot number where the 9767 card is installed. I just expected the PC version would offer the same, in case you could run the same software twice with two cards installed. But I see what you mean - it’s more likely that it auto-configures just one card.

Anyway, continuing with DOSBox-X Debugger, I need to find how the port address gets into memory (at two different offsets) when the program runs. This is a relatively simple program; there’s no protected mode memory paging, etc. But I still feel frustrated at not knowing where numbers come from.

I’ve realised that the number in square brackets is an offset, rather than an absolute address.

I’m hoping some other assembly-language line places the 39D value into those memory locations that are then used again and again whenever the port output is updated.

I shall try again tomorrow, this time with debug ‘on’ as soon as the program starts. Hopefully I can step through the lines that run first, one by one, and recognise what happens with those memory locations. Otherwise, they must be part of some data area loaded when the program is loaded (I barely know how programs work). My qualification was electronics, not computer science…

-Alex

Edited January 14, 2023 by alexGS

[alexGS]

Quick recap in case anyone else reading this thread has lost track of what’s happening; there has been a change of plans since the start:

1. Thorsten has made the Interface A run off a serial port, via an Arduino to translate serial to parallel. This has wider compatibility than a re-creation of the 9771 card (even if the latter were on a PCMCIA or PCI bus as I was considering).

2. I’m trying to modify the LEGO TC-LOGO software to use the serial port (3F8) instead of the LEGO interface card (39D). It is a small DOS program written in assembly language, but I don’t know what I’m doing. I’ve used the DOSBox-X debugger to find the port address being used when the program runs, and now I need to find where it is first loaded into RAM so that I can change it.

3. If this modification works, I hope both solutions 1. and 2. can work together to program the Interface A using Logo without needing an ISA-slot-equipped PC and the 9771 interface card (or replica).

-Alex

Edited January 14, 2023 by alexGS

[Toastie]

2 hours ago, alexGS said:

Links inevitably get broken anyway, and we are probably creating this for when someone else searches for it in 10+ years’ time..!

Alex,

thank you very much for the recap (!) - I myself get sometimes lost, when thinking about why and how to and so on!

And you are right: This is meant to be for future searches - far in the future - so eventually it should go on the WebArchive/WayBack Machine, I believe.

There is one more thing that gives me headaches: Let's say, outputs work through the serial port. That seems to be in reach. What seems to be more difficult, though, is to (continuously) monitor the inputs, as TCLOGO does with "listento <port>", right? With such a (dumb) ISA card as 7991, you simply have to look at the content of the 8-bit data bus, when address + IOR + AEN are set. I thus believe you would have to catch the IOR (AEN) as well, and use that as a "trigger" so that e.g. an Arduino puts the 8-bits out the serial port, which has to finds it way into the PC ... I may be totally wrong though.

Best,
Thorsten   

[2GodBDGlory]

I don't have much to add to the technical side of this conversation, but for hosting images, the typical place people use on here is called Bricksafe, which is something of a successor to Brickshelf, and fairly easy to use.

[Toastie]

6 hours ago, 2GodBDGlory said:

the typical place people use on here is called Bricksafe

Good call - I guess I'll take that route ...

Thanks a lot,

Thorsten

[alexGS]

Yes!  Tears of joy...

I am very happy right now - I have the TC-LOGO program working with the parallel port - for outputs and for inputs!

It turned out that the port number came from three places in memory. A little sleuthing in the assembly language showed me that the first occurrence is used for inputs, and the second for outputs! (I couldn't be certain of the third use, but probably for testing of the port).

This is a true blessing for the use of the parallel port, since the six output bits can go to 378h (decimal 888) and the two input bits can come from 379h (decimal 889).

The use of the parallel port has already been demonstrated by Tom at LGauge, but he used bits 4-5. TC-LOGO of course expects bits 6-7, so the cable needs a modification, and ideally bit 7 needs to be inverted due to the way the parallel port works.

More to come, I will make a video and a diagram showing the cable requirement.

 

I do apologise for the change of approach, which I will address in the next reply.

[alexGS]

17 hours ago, Toastie said:

There is one more thing that gives me headaches: Let's say, outputs work through the serial port. That seems to be in reach. What seems to be more difficult, though, is to (continuously) monitor the inputs, as TCLOGO does with "listento <port>", right? With such a (dumb) ISA card as 7991, you simply have to look at the content of the 8-bit data bus, when address + IOR + AEN are set. I thus believe you would have to catch the IOR (AEN) as well, and use that as a "trigger" so that e.g. an Arduino puts the 8-bits out the serial port, which has to finds it way into the PC ... I may be totally wrong though. 

Hello Thorsten,

I managed to substitute 3F8h for the address and immediately generated serial errors in the DOSBox debugger window - I think that's a good sign. Would you like to give it some testing please?... I will put the modified TCLOGO_S.COM into a DropBox soon. EDIT: I've put it into Bricksafe, I'm impressed that it accepts files of all types :) see below.

I wondered if your Arduino program would run in a loop, continuously updating the serial port ('polling' the inputs) at the same time as it updates the outputs? I guess I expected that the Arduino would be the 'bus master' (so to speak) and the PC would put output values at 3F8 for the Arduino to collect, plus read the values that the Arduino places there. This expectation probably shows my complete lack of understanding of how serial communications work :) 

I was wondering how Setpower would function; would the Arduino update the values regularly enough for the PWM to operate, or would there be a 'Nyquist sampling error' (aliasing) where some of the cycles are lost?

 

I like the use of the parallel port for three reasons;

- The values stay 'latched', so that it works in the same way as the "dumb" ISA card :) This means it keeps up with Setpower - PWM works just as intended.

- The cable is cheap to make. It needs a 20-pin header, a ribbon cable, a D25 solder plug (a little fiddly), one 4.7k resistor, and a BC547 transistor.

- Five of my laptops and two of my desktops have a parallel port (none has an ISA slot).

 

I realise that many readers will not have a parallel port, but there is a fair range of desktop and laptop PCs until about 2004 that were so-equipped. For example I have a Dell OptiPlex GX280 (Pentium 4, with parallel port) that runs Windows XP, but I can boot it into DOS from a USB drive. It doesn't hold much appeal as a retro PC, to be honest, since it can't run Windows 98, but it is highly functional for this kind of thing and probably very cheap to find, if they haven't all been thrown away by now.

-Alex

17 hours ago, 2GodBDGlory said:

I don't have much to add to the technical side of this conversation, but for hosting images, the typical place people use on here is called Bricksafe, which is something of a successor to Brickshelf, and fairly easy to use.

Thanks for your advice - I will try to get something set up there shortly :) EDIT: I now have, what an excellent service! Cheers for that, it made it easy...

Edited January 15, 2023 by alexGS

[alexGS]

I have set up (very roughly) at https://bricksafe.com/pages/alexGSofNZ/interface-a-tc-logo

You can download the modified TCLOGO_P.COM (outputs to port 378 and inputs from 379; i.e. printer port LPT1 in most configurations) - https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TCLOGO_P.COM
TCLOGO_S (outputs to port 3F8, COM1, not tested yet) - https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TCLOGO_S.COM

This is the Turtle page included with the original TC-LOGO: https://bricksafe.com/files/alexGSofNZ/interface-a-tc-logo/TURTLE.LWR

The parallel port cable I use is the same as Tom's (https://lgauge.com/article.php?article=technic/articles/LEGOInterfaceA) except for a small change to the inputs:
Pin 18 from Interface A goes to Pin 10 of the DB25 plug
Pin 19 - Ground - Pin 25 of the DB25 (as before)
Pin 20 - goes to a 4.7kOhm resistor, then to the middle leg of a BC547 NPN transistor.

The left leg of the transistor (collector) goes to Pin 11 of the DB25 plug
The right leg of the transistor (emitter) goes to Pin 25 of the DB25 plug (ground, as used above)

This inverts the signal for input bit 7 - and it works correctly, because the parallel port has an internal pull-up.

Photo - please note that pins 12 and 13 of the D25 are NOT used - it looks like they are connected but those are pins 24 and 25 underneath

 

Tomorrow I shall draw a diagram...
 

Other files in that folder include the use of the DOSBox-X debugger, a sample dump of the code executed by the CPU, and the online hex editor I used to change the port addresses.
The order of the addresses is important, since one is the input and one is the output (I don't know what the third is used for but probably for testing the port).

-Alex

Edited January 15, 2023 by alexGS

[Toastie]

 

7 hours ago, alexGS said:

Yes!  Tears of joy...

I am very happy right now - I have the TC-LOGO program working with the parallel port - for outputs and for inputs!

Hi Alex,

CONGRATULATIONS!!! This is so cool - I shall try all this early next week!!! Oh man, what a blast.

So you are running this on middle-aged PCs/Laptops with parallel port, right? And under DOS, correct? All the DOSBox-X things you did were for debugging and testing, right?

There is another thing: I have never looked into the PWM mode, as I did not see that happening on the 9771 PC ISA card - does the ISA bus drive the PWM? I.e., is there a swift change in the output data lines on the ISA bus for PWM? Very interesting! I don't understand how PWM works using 9771 (or the parallel port - 9771 is actually a super cheap parallel port. This is what IBM said about their parallel port (which is residing in my XT, so I can try your modified TCLOGO on that machine as well!!! So cool).

 

Need to check all this out!!! 

7 hours ago, alexGS said:

I'm impressed that it accepts files of all types :) see below.

Oh, that was it then - I guess I have to migrate as well! Thanks for the tip @2GodBDGlory and for that "all files" bit, Alex.

So much fun here!!!

Will be back soon.

Best wishes,
Thorsten

 

[alexGS]

1 hour ago, Toastie said:

 

Hi Alex,

CONGRATULATIONS!!! This is so cool - I shall try all this early next week!!! Oh man, what a blast.

Hello Thorsten,

Thank you for sharing in the enthusiasm, I really appreciate it :)

Yes, I am using one of my vintage (1994) laptops for this, a Compaq Contura Aero 4/33c (486SX33, passive-matrix colour 640x480 7.8” display - it’s a little one!) I have three of these. Running native DOS (after exiting from Windows 3.1) and running on a 28-yr-old battery, too (for 2hrs+)

However, I have also tested it on my Toshiba laptop from around 2000 (running Windows 98) and my 2004 Dell Optiplex GX280 Windows XP desktop PC booted to DOS via a USB drive. All these machines have LPT1 ports, the newer ones are EPP/ECP but it doesn’t matter for this purpose. (For technical interest, the bidirectional capability of EPP/ECP requires data to be clocked through - and that is not practical to achieve with the LEGO software. Hence we use Status pins for input; port 379h).

The LEGO software generates the PWM! It turns the parallel port outputs on and off fast enough for the motor to be effectively slowed without terrible loss of torque or horrid whining - so the PWM frequency must be several thousand Hz at least. I will check it with my oscilloscope tomorrow.

This is the advantage of a tight assembly language loop (about ten CPU instructions between writes; that CPU is running at 33MHz so it’s hardly stressed…), an OS with few other overheads, and an output port that is latched without other translations or processes. 

It might look antiquated with the CGA display (and it is), but even by modern standards, this software is pretty fast - much faster than Python on a RaspberryPi can control its outputs, for example, just because of all the intervening layers in the modern OS environment (Raspbian Linux). I find Python can miss inputs even at 10Hz… needs to be interrupt-driven.

And yes, I carried out the debugging/disassembly with DOSBox-X on a modern i7/Windows 10 PC, just for the convenience of downloading/installing, generating a 250MB dump of CPU instructions, etc. With even more patience, I’m sure this could have been achieved with old equipment, as debuggers and hex editors are nothing new.

The story is not over, as I’d love to see a USB-compatible serial solution running from DOSBox-X. That will open this to a wider audience of tinkerers.

As it stands, hopefully most people with an Interface A also have access to a parallel-port and DOS-capable PC, now that it doesn’t need to have an ISA slot and a special card made up.

There are two other small catches to be aware of - Thinkpads are usually configured with LPT1 not at 378h but at some other similar address (that will be easy to adjust), and there is a slightly more serious problem that some laptop parallel ports may not supply enough current to turn on all the interface outputs together. I had trouble with the Compaq using a later Interface A (with flat-top LEDs) which worked fine on the newer Toshiba. It may be necessary to add another 5V power supply into the cable for some combinations of equipment.

Tomorrow I shall test this properly with actual Logo code for my ‘Dacta arm’. There will be a video :)

-Alex

Edited January 15, 2023 by alexGS

[Toastie]

54 minutes ago, alexGS said:

The LEGO software generates the PWM! It turns the parallel port outputs on and off fast enough for the motor to be effectively slowed without terrible loss of torque or horrid whining - so the PWM frequency must be several thousand Hz at least.

Wow - how cool is this. And yes, the olden days were better (for nerds like me of course).

I looked (all last night) around - there are USB2GPIO boards (well, e.g. all the FT232R based boards in bitbang mode http://www.ftdichip.com/Support/Documents/AppNotes/AN_232R-01_Bit_Bang_Mode_Available_For_FT232R_and_Ft245R.pdf) but I simply can't imagine how to get the IN/OUT "ISA bus signals" regardless of address from DOSBox-X bidirectionally to the USB port into the FT board without telling DOSBox-X that is the parallel port I want to use. 

I was entertaining the idea of trying a USB2parallel adapter. However, I believe I saw a comment somewhere (lost track in the 20+ browser tabs I had open :D ) that bidirectional USB2parallel ports don't work with DOSBox-X ... but others said they do. I don't have one, otherwise I would have tried. It needs to show up as parallel port or at least as IEE1284 device in device manager, which apparently some of these adapters do. Then I'd point DOSBox-X in the config file to that adapter:

[parallel]
# parallel1: parallel1-9 -- set type of device connected to the parallel (LPT) port.
#              Can be:
#                 reallpt (direct parallel port passthrough),
#                 file (records data to a file or passes it to a device),
#                 printer (virtual dot-matrix printer, see [printer] section)

And the use your modified TCLOGO version. Do you think that could work?

 

Well, I shall bring out my Toshiba Satellite 4090 - that one features a parallel port

Which makes me wonder ... it all works flawlessly with the parallel port. Back in the days, virtually all PCs had parallel ports - at least most of them, I believe? So had TLG used the 0x378/9 addresses in TCLOGO, made a custom parallel cable with the addition of 1 resistor and 1 transistor - 9771 (PC) as well as 9767 (Apple) would have become obsolete, right?

I am super excited about all this!!!

Best wishes,
Thorsten

[alexGS]

Hello Thorsten,

I haven’t quoted, in an effort to save space :)

Just quickly - you don’t need a bidirectional parallel port for this - ALL parallel ports have a set of status inputs (from the printer) and we just use two of those (379h). As I noted above; it isn’t practical for us to use bidirectional data in 378h, because of the need to clock the data through.

Sorry to say that most USB-to-parallel adapters will not work for this, for the simple reason that they don’t actually emulate an LPT port. I have tried one and it simply adds a USB ‘port’ for a Windows printer driver to use. It does not add a 378h port to the Device Manager.

But if, somehow, you DO get one to add a 378h port to a Windows machine, then yes, absolutely the software and hardware will work with it.

Now - the last point - something I’ve considered carefully in the last few days - “why didn’t LEGO do this” :)

Firstly, the Interface A was designed to work with the BBC Micro’s User Port (the ribbon cable for that machine has the same plug both ends wired straight-through). The user port is practically identical to the Printer Port also available on the same machine. A related challenge therefore; make the BBC software run on the Acorn Electron, which has only the printer port?

The C64 cable connected to the C64’s User Port - printers were usually attached to the serial port on a C64. Not always, but usually - all Commodore-branded printers anyway.

Likewise, Apple-branded printers were usually serial (except an early dot-matrix offering between 1982-1984 which was parallel; later dot-matrix ImageWriter I/II were serial). The Apple II family, except for the IIc and IIGS, relied on added-in cards for most I/O - disk drives, the serial printer; I don’t think a parallel port was standard or typical, so the 9767 card was a necessary addition.

So on these three machines that didn’t use the printer port to attach the Interface A, it would have still been possible to use the printer in a typical classroom scenario of students printing out their code, perhaps to annotate/explain while other students used the same computer…

You see where I am going with this? If LEGO had commandeered the PC’s parallel port for connecting the Interface A, they would have created a classroom situation where the printer could not have been used easily, at least not without hot-swapping cables, which is hardly to be encouraged.

It was probably intended that the simple 9771 card would be cheaper than an additional printer port card; although marketing doesn’t always turn out how the designers plan it :)

Anyway, it does feel like LEGO may have started with the DOS TC-LOGO software working with a printer port, considering they allowed for the different read/write addresses - if it was designed for the 9771 card only, I don’t think they would have made that allowance in the code.

At the time of Interface A development, printer ports were not bidirectional, i.e. could not be read from and written to at the same address. The status lines that we are using have been in the specification since the 1960s.

Just my thoughts… I have to get some sleep.

I also just realised I could use an Amiga with the same cable, its parallel port and AmigaBASIC, which would be kinda cute, if nothing else :) or even its software PC emulator! Never an intended platform, I’ve already had my Amiga 1200 emulating a Mac and operating Control Lab/Interface B through its serial port… the Amiga is that ‘jack of all trades’ with brilliance widely ignored ;)

Edited January 15, 2023 by alexGS

[Toastie]

Hi Alex,

5 hours ago, alexGS said:

Just quickly - you don’t need a bidirectional parallel port for this - ALL parallel ports have a set of status inputs (from the printer) and we just use two of those (379h). As I noted above; it isn’t practical for us to use bidirectional data in 378h, because of the need to clock the data through.

Sorry to say that most USB-to-parallel adapters will not work for this, for the simple reason that they don’t actually emulate an LPT port. I have tried one and it simply adds a USB ‘port’ for a Windows printer driver to use. It does not add a 378h port to the Device Manager. 

finally - I believe I got this. Thank you so much for taking the pain and writing this up! It is a very steep learning curve for me.

And your reasoning about TLG >not< using the parallel port makes absolutely sense! I wonder what TLG was charging back in the days for the ISA card

I am looking forward to what happens next ...

Thanks again, I truly enjoy all this.

Best wishes,
Thorsten

Edited January 15, 2023 by Toastie