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

[alexGS]

2 hours ago, Toastie said:

I wonder what TLG was charging back in the days for the ISA card

Sorry for the small print and distracting pen-marks, but here’s the answer in the New Zealand price list for 1991… NZ$239 was roughly 1.7x the US$ at the time, so US$140.

Yep, I’ve been collecting this stuff for a long time (I was 11 when I had this posted to me) :D

Edited January 15, 2023 by alexGS

[Toastie]

24 minutes ago, alexGS said:

I was 11 when I had this posted to me

Oh my, when I was 11 years old, I was into the LEGO space theme :D - brick build that is. These very small sets, on the right ...

Thanks again, Alex! It really make(s) my day(s)!

Best regards,
Thorsten

 

 

[alexGS]

I got a bit busy this week and still haven’t made a cable diagram - will do it soon - but I have made a video to prove it works 

 

[Toastie]

9 hours ago, alexGS said:

I got a bit busy this week

Heehee - same here ... I had no doubts though

Very nice video - I could watch forever. Fast and efficient that robot arm. I mean, this is from >35 years ago ... today you need the computing power of a modern cell phone, a powerful microcontroller, and electronically controlled motors with active encoders to accomplish the same :D OK, sort of the same.

I was busy with some visits to medical sites ;) as well as with remodeling part of my attic - to give the beautiful "old stuff" more visibility, when I sit up here and deal with students not liking multiphase thermodynamics, oh well two phases - and in only one instance three. So I can always look at the "old stuff" and simply enjoy that these days were better :D

Will post some pics in the vintage computing thread on the remodeling - as it is not only about 9750 and company.

However, I have "acquired" the parts to making that PC parallel port/9750 cable. Also, I found a C64 ... no idea what the condition is. And there were 4 Ataris - 2 work, 1 throws three bombs upon trying booting into GEM and the other one plays dead. Good thing is that all his stuff must be from around my active time in 8-bit computing. There are tons of all kinds of 8-bit computing electronics as well. All secured in the electronics section of the large mass spec lab we run. I have convinced the folks that that stuff is very valuable ;) and proven it: We needed to measure the impedance of a custom 1.5 m log hexapole for ion transfer from a EUV light compartment into one of our mass specs. As the multi-meters were close to out-of lower range, I used a signal generator, oscilloscope and - this is the proof - 100pF, 1nF, and 10nF capacitors from that vault for calibration purposes; just measured the half-life of the discharge time at two points. Very old school - but my post docs actually believed in that approach ;) And also in the sheer invaluable value of all the 10 ... 30+ years old electronics stuff :D Tsss ... chemists ...

I also just read (as a very nice BL seller threw in a 12-page brochure in catalog style from 1986 summarizing "The LEGO Educational Program - Technic/Informatics - 1986/1987" on my last order) that a C64 directly connects to 9750 - all you need is a cable and LEGO Lines for the C64. And the latter is available on the archive.org ... Then found another website showing that the C64 does control 9750 nicely.

We'll see.

All the best
Thorsten

Edited January 19, 2023 by Toastie

[alexGS]

5 hours ago, Toastie said:

I also just read (as a very nice BL seller threw in a 12-page brochure in catalog style from 1986 summarizing "The LEGO Educational Program - Technic/Informatics - 1986/1987" on my last order) that a C64 directly connects to 9750 - all you need is a cable and LEGO Lines for the C64. And the latter is available on the archive.org ... Then found another website showing that the C64 does control 9750 nicely.

Indeed - couple of years ago, I used my other PC to edit the LEGO Lines program files - and the bitmap image for the screen. The copy of LEGO Lines translated from Dutch to English, at the archive, is my work :)

The only compromise is that it requires J or N entered for Yes or No respectively, since I couldn’t change the input part of the assembly code. I should have another try I guess, I understand that one of Evan’s friends is sorting that out…

[Toastie]

1 hour ago, alexGS said:

Indeed - couple of years ago, I used my other PC to edit the LEGO Lines program files - and the bitmap image for the screen. The copy of LEGO Lines translated from Dutch to English, at the archive, is my work :)

The only compromise is that it requires J or N entered for Yes or No respectively, since I couldn’t change the input part of the assembly code. I should have another try I guess, I understand that one of Evan’s friends is sorting that out…

Oh my - it is a small, small world ... thanks a million for this as well!

I'd just stick with J and N - in German it is Ja/Nein so all is good and honestly? Y and J and not that difficult to guess - and No/Nee/Nein/Nej/Nada/Njet ... are all the same. So should anyone be confused by the J, the alternative N should make the choice easy. Guess saying NO is more generally going smoothly the same way - it is always much tougher to say "yes" .

Best regards,
Thorsten

 

[alexGS]

Hehe - yes - once you try it, you’ll see the prompt says “Continue? J for Yes, N for No” ;)

At least I managed to convert all the code keywords, as it really was a bit of a challenge otherwise. I added a few of the shortcut keys I discovered to the background image, since there was no way of knowing apart from trying lots of keys… I also took the liberty of replacing ‘LEGO’ with a LEGO logo similar to the one that appears in the BBC version - complete with (R).

However the program does run quite slowly, because it highlights each line as it runs. Pressing F8 runs it without redrawing the display (‘FAST’ mode)

[Toastie]

14 hours ago, alexGS said:

Pressing F8 runs it without redrawing the display (‘FAST’ mode)

Ahh - same "trick" with the ZX81 I guess - the Z80 was mostly busy with redrawing the screen ... counting up to 100 takes half a minute or more (have to check, just got that one up and running again. In fast mode, the screen is gone, and the CPU is doing what a CPU is supposed to do; swapping registers and jumping around

Best,
Thorsten

[Toastie]

Hello @alexGS,

made the parallel cable - but it won't work with my Toshiba 4090 running DOS. TCLogo_p runs fine; it just does not set/read any bits from 9750. I will check that cable ag ain, did it twice, but I am a certified expert in screwing up the pins on any male/female connections. Must be a brain-failure when it comes to mirror images :D

Now with regard to TCLogo_s: Here the idea is, that it talks to the serial card/interface, which in turn stores the one byte data in its write buffer and then cranks it out bit by bit, correct? I can hook-up my Arduino to watch the data coming from the PC/Toshiba Laptop ... need to check, what the addresses are that both are using for the serial port.

I still can't figure out, how to possibly read back the input lines from 9750. The Arduino can do that rapidly in the program loop. However, it would a) need to be slowed down (no problem) because at 9600 baud (XT) or even higher (Toshiba) it will flood its serial write buffer in no time. That usually holds 64 bytes (and is readily expanded by hacking hardwareserial.h). And b) when TCLogo reads the serial port on the XT/Toshiba, it will read from the input buffer. Well, that is the whole idea of asynchronous communication, I believe. In other words, there is no sync between the data in the read buffer and the time TCLogo accesses that buffer. On the parallel port, this syncing is simply done by pulling down the appropriate IOW/IOR lines etc., which represent a request to write/read data. There is no such thing in serial communication, I believe, other than HW handshaking. But even that would not circumvent the usage of the serial read/write buffer(s).

And that is the reason, I am sending a one-byte "read-request" in my QBasic Program: It sends 11000000 to the Arduino (or something > 111111), which then returns exactly one byte with the I/O status of 9750. The QBasic code simply waits during the transmission delay for 1 byte showing up in the serial read buffer and reads it, which empties the buffer. The Arduino is not sending any more data, until the next read request comes. And that slows down things considerably. This represents some (very dumb and very slow) syncing approach, as the read request alone takes up 1 start, 8 data, 1 stop bit @9600 baud to crawl through the serial data line ...

Best regards,
Thorsten 

[Toastie]

On 1/23/2023 at 5:32 PM, Toastie said:

made the parallel cable - but it won't work with my Toshiba 4090 running DOS. TCLogo_p runs fine; it just does not set/read any bits from 9750. I will check that cable ag ain, did it twice, but I am a certified expert in screwing up the pins on any male/female connections. Must be a brain-failure when it comes to mirror images :D

Oh yes - I am a top expert in screwing things up! This time, all wires I actually soldered were positioned correctly on both terminals. But for some reason, I decided to just not connect 2 wires: Parallel port wires 1 and 14 to 9750 port 1 and 3. Reason? I thought I am super-smart and made a short-cut: As the 9750 output drivers should get their TTL input from the parallel port, any positive supply voltage to 9750 is not required - and the parallel port does not supply +5V VCC anyway. So - hooked up LEDs to the parallel port using 1kOhm resistors - and they all light up correctly when running Alex' TCLogo_p. Which called for another look into the 9750 schematics ... which readily showed that with no VCC supply, no signal will go anywhere as the input (and output pull-ups) optocouplers simply can't light up at all. So added one more line: 1 connected to 14 on the DB25, route through one wire to 1 and 3 on the 9750 terminal. Guess both (Control 0 and 1, corresponding to !Strobe and !Linefeed) are always log1 = high = 5V when not used, as these are inverted lines; off = high. 

In other words: If I had strictly followed the instructions @alexGS has so nicely written-up, it would have worked on the first try 

And now my 1998 Toshiba Satellite 4090 runs TCLogo_p Alex has provided flawlessly! Thank you very much again, Alex!!!

All the best,
Thorsten

[alexGS]

Hello Thorsten,

I started to write a reply, but didn’t get a chance to finish it in time - sorry about that. I wanted to make a proper diagram and a full pin-to-pin list, as so far I’ve been assuming everyone will follow Tom’s instructions, then make the modification I detailed above for the inputs.

Indeed the optocouplers must be supplied with 5V, and the combination of an early parallel port with later Interface A causes some problems in this regard; there isn’t enough power from those pins to drive more than two outputs. I’m glad it’s working for you (I think you have a ‘later’ parallel port).

While considering your other serial-data question, I stumbled across a very interesting YouTube video yesterday which may resonate with what you’re achieving with the Arduino - have you seen this?

 

Edited January 25, 2023 by alexGS

[Toastie]

45 minutes ago, alexGS said:

While considering your other serial-data question, I stumbled across a very interesting YouTube video yesterday which may resonate with what you’re achieving with the Arduino - have you seen this?

Hello Alex,

no - I have not seen that - just took a peek - that sounds totally cool!!! Will have to dive deep on this.

But even >more< exciting to me: Your TCLogo_s works flawlessly with the Arduino thingy! I mean that Arduino is just a serial to parallel "converter" of lowest level - the program is more of a joke than a "program". However, what makes me a bit happy is that I used strictly the IBM BASIC instructions for 9771 (bit masking and so on) and stayed with sending actually 0x00 (rather than any readable number or the like) for addressing chn_0 on 9750. In other words, the Arduino understands TCLogo addressing. 

So, I hooked up the Arduino box to the USB2Serial converter on my Win11 64bit laptop, fired up DOSBox_X, ran your TCLogo_s program - and IT WORKS LIKE A CHARM!

Your redirection of the original ISA card output to the serial port "COM1" arrives exactly where it is supposed to arrive, and the Arduino happily translates that to 8 parallel bit output and 9750 just does what it is told to do!

In summary: Your TCLogo_p works perfectly on 9750 inputs and outputs using a parallel port; your TCLogo_s works perfectly well on outputs using a serial port, regardless of the machine. IBM XT from 1985 or DELL laptop from 2021.

THIS IS SO UNBELIEVABLY COOL!!!

Thank you so much again for providing these TCLogo variants.

Now onto the video you found!

All the very best - and thank you for making my day!

Thorsten 

[alexGS]

Hello Thorsten,

Oh! That is interesting - I wasn’t expecting that serial data to work!

So now there’s just the problem of inputs to solve, by having the Arduino ‘poll’ the inputs and send data back to the PC?

Thank you for your work on this  it will be great to have a solution for the newer PCs as well as the DOS dinosaurs.

[Toastie]

1 hour ago, alexGS said:

So now there’s just the problem of inputs to solve, by having the Arduino ‘poll’ the inputs and send data back to the PC?

Hello Alex,

yes! As far as I am aware. And this is on one hand totally easy: Just hack in such a request, and then listen to the port. However, in machine code, these additional instructions may cause terrible things. Absolute jumps will go berserk and so on :D.

Nevertheless: Here is a brief summary of all results reported in this thread so far:

TCLogo: That requires 9771 (or clone) to listen to address 925 (926) = 0x39D (0x39E) and then act on these I/O ports = full write/read access to 9750.

TCLogo_p: This is @alexGS' modified DOS com file 1: Original TCLogo I/O is redirected to a true parallel port responding on 0x378 (out) / 0x379 (in). This is taken care of by TCLogo_p and should run on any "medium-vintage" PC or laptop having a parallel port - and that is the real beauty of it: You can take such a laptop to a "show" or equivalent happening and bring 1986/7/8 4.5V computer controlled LEGO into action, as Alex has nicely demonstrated.

TCLogo_s: This is Alex' modified DOS com file 2: Original TCLogo O (so far no I) is redirected to a true OR virtual COM port. So far, I got it to work with TCLogo running within DOSBox_x, USB2Serial adapter declared in the DOSBox_x startup file, connected with a 1:1 serial cable to an Arduino nano equipped with a Serial2TTL adapter, simply listening to what comes in on the serial port: 0x00 = 9750 output 0, 0x01 = output 1 ... and mapping that to 6 outputs/2 inputs using register programming. So far, it did not work on my Toshiba 4090, nor on the IBM XT, BUT I am pretty sure that these 2 beauties want handshake lines to be properly connected; I am just wiring RX, TX, GND. Today that is totally OK (XON/XOFF, and a gazillion of mega Hertz) but back then it was not. Need to make appropriate cables and will report back :D.

All the very best and here is to Alex:

Thorsten

P.S.: Yes, LEGO bricks from 1986 clutch nicely with LEGO bricks from 2023. But LEGO software from 1986 does that as well!!!

Edited January 25, 2023 by Toastie

[Toastie]

3 hours ago, alexGS said:

YouTube video yesterday which may resonate with what you’re achieving with the Arduino - have you seen this?

Well, as said, I did not - this is superb, breathtaking work, YouTube user atkelar has done!!!

However, the goals are different, I believe. What he is doing is using 9750 as "simple" (it is simple :D) motor driver. The Arduino Mega does it all. And that's fantastic, but not the goal here, I believe. The whole communication/control is elevated to the Mega. Interrupts for the sensors etc. Totally cool!

But the goal "here" ;) is mimicking a vintage computer running original/hacked TCLogo on a (semi) modern machine. And that is rather "different": atkelar transferres 9750 control completely to the Mega. With a >superb< program and approach. You (and now I :D) want to use it essentially to act as a serial2parallel I/O gateway (with no brain), and have TCLogo in control. Is this correct?

All the best,
Thorsten

 

[alexGS]

58 minutes ago, Toastie said:

However, the goals are different, I believe. What he is doing is using 9750 as "simple" (it is simple :D) motor driver. The Arduino Mega does it all. And that's fantastic, but not the goal here, I believe. The whole communication/control is elevated to the Mega. Interrupts for the sensors etc. Totally cool!

…

You (and now I :D) want to use it essentially to act as a serial2parallel I/O gateway (with no brain), and have TCLogo in control. Is this correct?

Yes, exactly right.

Using the original software allows us to ‘play along’ with all the original LEGO teaching material available on the Archive.

For us the Arduino is just serving as an interface that works with a more modern PC. I hoped perhaps the use of interrupts for inputs might give some inspiration for how you might code the Arduino to catch the inputs - I haven’t really got my head around it all! :)

Edited January 26, 2023 by alexGS

[Toastie]

@alexGS, @evank,

I am reporting a major update on the usage of TCLogo and LEGO Interface A (9750) without having an ISA card or a semi-vintage computer equipped with (real) parallel port available.

It (almost) all (output as before but also input) works with a USB2Serial adapter on any modern computer - e.g. my Dell Precision 7530 running Win11/64bit and DOSBox-X.

So why is this a major update? Well, it may very well be that I am again behind (as so often in this thread) but I simply did not find any reference out there ... please let me know if this is (again) incorrect

Most importantly, all credit goes to @alexGS(!), as he has created, by literally working on the machine code level (see above), to make 2 new versions of TCLogo (see links in his post above). In these two new versions, Alex redirected the I/O access of the original LEGO TCLogo program, which directly addresses the LEGO 9771 ISA card at 0x39D (or 0x39E, address jumper removed):

1. TCLogo_p: Redirection to I/O addresses of the PC (default) parallel adapter: ports 0x378 for motor/light output and 0x379 for sensor input. This allows you to run TCLogo without the 9771 card; instead, a true hardware parallel port is required. 
2. TCLogo_s: Redirection to I/O address of the PC (default) async (= serial) adapter: port 0x3F8 for output and input. In this case, either a true hardware RS232 port OR, and this is the thing, a USB2Serial adapter enables full bidirectional  access to 9750. And thus modern computers are back in the game.

Hardware requirements:

1. TCLogo_p: A custom parallel port (DB25) to LEGO interface 9750 (20 pin) cable, see Alex's instructions above.
2. TCLogo_s: Either a true RS232 serial port  - OR - (1) a USB2Serial adapter, as the software required (DOSBox-X, see below) wants to detect a COM port upon startup; (2) a serial 1:1 cable; (3) a Serial2TTL adapter; (4) any suitable microcontroller board - I am using an Arduino Nano clone - for bidirectional serial-to-parallel data conversion, as LEGO Interface 9750 handles 8-bit parallel data only.

Software requirements:

1. Any "true" DOS computer (DOS, Win 98 and the like) will run TCLogo, TCLogo_p, TCLogo_s.
2. Modern computers lacking "true" serial or parallel hardware ports need to run a DOS emulator. DOSBox-X is easily installed and runs TCLogo flawlessly. It just needs the virtual com port (e.g. COM1) to real com port mapping (the COM port the USB2Serial adapter is occupying) declared either in the DOSBox-X config file or typed in as a direct command within DOSBox-X.

Some very low level observations when running TCLogo either on my IBM XT (1985) w/ 9771 ISA card attached to Interface A or a Toshiba 4090 (1998) with parallel cable attached to Interface A; the latter runs TCLogo orders of magnitude faster than the XT :

1. I did break out my vintage Tektronics oscilloscope and did measurements on the pins going into Interface A, when changing the TCLogo "setpower" level from 1 to 6 (0 = off, 7 = on); here shown for Interface A's "output 0":
   
   These data imply that the minimum time for TCLogo to issue a write command is 1 msec. A "full output duty cycle frame" (green box) is 8 msec long. The corresponding motor on/off PWM times and the resulting duty cycle is shown in the table.
2. By coincidence, the timer resolution in TCLogo is 1 msec.
3. TCLogo counts sensor level changes, even if not asked to do so, with 1 msec resolution. Data available to the user at all times.
4. The last time between two sensor changes is available with the "frequency" command, in msec.

This strongly suggests that within TCLogo, there is a 1 msec timer interrupt routine, which:

• updates output 0-5 settings (PWM, even when all outputs are on power level 0/7, as TCLogo does not know, when a user or a program will change the power level)
• reads the inputs with the same temporal resolution, as the user can call "listento" along with "sensor?" at input line 6/7 anytime.

Without timer interrupt handling of the I/O ports (and counter etc. housekeeping), both PWM intervals as well as accurate sensor change detection would be depending on time other TCLogo code needs to perform - which is not the case: When setting the power level of any (or all or some) of the outputs of 9750 to PWM (1 - 6), every ms the outputs are updated - even if there is no change in power data.

I thus modified my Arduino serial to parallel program for my (very slow) QBasic application: Each time, TCLogo_s sends out a byte, the Arduino sets the outputs accordingly AND immediately replies with a full 8-bit serial data package (status of 9750 outputs and inputs).

And did a little sniffing on the serial port: The very moment, TCLogo(_p) is starting up (just showing the welcome screen, nothing else), it cranks out 1msec updates on the serial port. The Arduino listens and does nothing else than sending back the current output/input status. TCLogo happily reads these data and upon issuing a "listento 6" followed by "show sensor?" in direct mode, TCLogo shows the correct status of input 6. Also, "setpower" works - almost - flawlessly. The thing is, that a 10 bit serial message (1 start, 8 data, no parity, 1 stop bit) takes at least 1.04 ms to transmit at 9600 baud. However, TCLogo cranks the data out and asks for replies at exactly 1 msec repetition time. So every 16 (have to check further) bytes arriving, there is a little glitch (1 msec) and then all is well again for the next 16 bytes.

I simply cannot figure out how to use >9600 baud rates using this combination. It is not DOSBox-X: The config file accepts much higher baud rates. Also, when running QBasic within DOSBox-X, I can change the baud rates up-to 38400 with a little hack to the serial port settings (divider register of the virtual UART). Nor is the Arduino; that one easily manages Mbit rates. The thing is: The moment, TCLogo starts up, only 9600 baud works. This is strange and needs further investigation.

BUT: For now, the "every 16 byte glitch" is more than tolerable. As TCLogo does not ask for or provides data faster than 1 msec/byte, a modern computer can thus operate the LEGO Interface A (9750) via a USB port!

The syncing that I was discussing above as "very tough to accomplish" using async communication - is just >garbage<, as syncing is automaticlly provided by the exact 1 kHz (1 msec) rate of data "clocking" the Arduino synchronously with TCLogo timing.

Conclusion:

If the baud rate can be increased to 19200 or higher, TCLogo will work without any problems on modern computers.

All the best,
Thorsten 

Edited January 30, 2023 by Toastie

[Toastie]

Update #2 - and success 

For some reason, DOSBox-X always starts-up with 9600 Baud, regardless of config settings - at least this is what I am experiencing. Need to get on GitHub and ask the developers about it - and most probably they will tell me, I should not use DOSBox-X, when I don't know what I am doing 

And then I remembered DEBUG.COM/EXE ... It allows you to do many things, assembling, de-assembling, and so on. And: You can simply do I/O requests to all addresses that come to mind. A quick look into the IBM Async Adapter Manual:

Running DEBUG and then typing the output command "O 3FB" (1111111011) addresses the line control register. The data to be sent for changing the baud rate are shown in this table:

We want access to the divisor latch, which is essentially providing the baud rate from the base frequency (1.8432 MHz crystal on the async card), so the data to be sent with 3FB are 10000011 (0x83): Access DLAB, 8 data bits.

The first DEBUG command is thus: O 3FB 83. Now the divisor needs to be sent: The lower significant byte (LSB) is sent to address 3F8, the most significant byte to address 3F9. The divisor we want (baud rate = 19200) is calculated as per IBM manual:

Divisor = 1.8432E6/16/19200 = 6; LSB = 6, MSB = 0

The second command to be sent is thus: O 3F8 6 and the third O 3F9 0.

Then the line control register is set to "normal" RX/TX operation: O 3FB 3

And this works: Run DOSBox-X, run DEBUG, type in the 4 lines (or use input redirection from a file, e.g. DEBUG < 19200BD.TXT), then run TCLogo_s.

As 19200 baud is not at all supported on the original IBM XT, the processor used for the simulation needs to be at least a Pentium. Going to even more powerful processors does not help, as they screw up the correct simulated interrupt timing (1 ms).

Conclusion: No more glitches as observed at 9600 baud (see above).

Last thing(s) to do: Clean up Arduino code and that's it :D - 9750 operated running TCLogo_s off from a USB port of any modern computer. And compose a reasonable summary here, with all the things required.

BTW: Did I mention, that I love 8/16 bit computers? If not: I do.

All the best,
Thorsten 

Edited January 31, 2023 by Toastie

[Mikdun]

I'm not gonna use it, but have to say: great work! 

 

PS: 

7 hours ago, Toastie said:

The second command to be sent is thus: O 3F8 6 and the third O 3F8 0.

The third command shoud be O 3F9 0, right?

[Toastie]

1 hour ago, Mikdun said:

The third command shoud be O 3F9 0, right?

Absolutely! Thanks for noticing - changed it accordingly!

Best wishes,
Thorsten

[alexGS]

Hello Thorsten - you’ve done extremely well, I’m impressed by your work in checking the timing. I’m sure that 1ms timer resolution isn’t a coincidence ;)

I wonder how those baud rate instructions can be added in to the TCLOGO program. Are you confident we can add assembly-language instructions, or should we just start it by a .BAT file instead? :)

[2GodBDGlory]

Wow, I finally looked up the sets that you're working with here, and was surprised at how ancient it was! I didn't realize there was any programmable stuff for the 4.5V system!

[Toastie]

1 hour ago, 2GodBDGlory said:

I didn't realize there was any programmable stuff for the 4.5V system!

Same here!

Spoiler

For some reason in late 2020/early 2021 I had the idea of looking (again) into my ZX Spectrum I got in 1985. I heavily tinkered with it back then, but still found my "documentation" for all the changes (2 x 32k bank switching, some I/O ports wired to the outside world etc.). It was dead though, as I knew, but you never know ;) ... then found out that vintage computing is something that apparently many, many people are interested in (there are zero in my local universe). They put their stuff on the internet. People literally make custom ULA chips from back then with new hardware ... and that got my Spectrum back to life. Strongly encouraged by all the available old hardware (4164k memory chips etc. pp.), I did the same thing with my ZX81 from 1983. Both are alive again. Then I had the wild idea of letting my ZXSpectrum control all the 16 trains on my LEGO layout, RC, PF, BLE controlled - with a little help from a tiny ESP32Vroom board. Worked. There are a couple of threads on that here on EB. And then I learned about the folks putting all sorts of "ancient" stuff (software, hardware descriptions, instructions, programs ... onto the Waybay Machine. And only at that point, I realized that there was a programmable 4.5V LEGO Technic/Dacta system, which became available to customers in Germany in late 1986. Coincidentally, I found a dead IBM XT with CGA color monitor in otherwise reasonable condition in a storage room of my research group at the university. Nobody was even remotely interested in that thing. Guess what: I was. Totally dead is always good, as you need to begin at Zero. And for IBM PCs, the website "minus zero degrees" is a gold mine. My wife was really happy  when I hauled it out of our car ... A couple of weeks later, that IBM was happily crunching numbers again. Which in turn called for a ISA card (9771) that a PC back then needed to interface with the (4.5V) LEGO Interface A. And EB user alexGS shared all his very deep knowledge on vintage LEGO stuff here. His plan was to run the original LEGO software (TCLogo and the like) on computers that don't have ISA slots anymore ... and I tried to just talk to 9750 with a QBasic program and a very simple serial2parallel "translator" (Arduino Nano) - because then I can use any modern computer with USB ports to control 9750, provided there is a virtual DOS machine that allows accessing the USB port - and DOSBox-X is such a simulator. However, QBasic is way too slow to do PWM on the outputs - and this is, what TCLogo does, even on an 1986 IBM XT: 1 kHz modulated PWM on the 6 outputs along with 1 kHz sampling of the two inputs of 9750. And now we are trying to pull it all together: Controlling the first (electronically) programmable LEGO system from more than 35 years ago with 2023 computers - although ISA slots are gone, parallel ports are gone, and 64kByte of memory are not considered as being "very large" anymore ).

Thank you for your comment and interest!

All the best,
Thorsten

[Toastie]

Thank you for your nice words - but this all builds on your changes to the TCLogo code and your many other insights into PC/LEGO hardware!

15 hours ago, alexGS said:

I wonder how those baud rate instructions can be added in to the TCLOGO program. Are you confident we can add assembly-language instructions, or should we just start it by a .BAT file instead?

I am doing more measurements - time is a little issue at the moment, though.

Well, timing as well ;) I shall take more screenshots of my scope, here's the text version:

At 9600 baud, the DOSBox-X DOS simulation runs rock solid. One 1 msec interrupt of TCLogo_s is exactly 1.04 ms long on the Arduino parallel outputs. As it should be, even on a serial hardware port: TCLogo drops the current PWM motor data byte into the 1-byte serial output "buffer" and continues on with other TCLogo stuff. This goes blistering fast. The serial adapter then recognizes that byte (oops, data coming in :D) and slowly cranks it out according to its settings, 1 start, 8 data, 1 stop bit = 10 bit. At 9600 bit/s this results in 104 usec/bit and 1.04 ms per 10 bit packet. And then the next packet can be transferred. As the 8250 UARTs in IBM PCs have no serial input/output buffers (https://en.wikipedia.org/wiki/16550_UART#The_16550_FIFO), the next byte to be transferred has to wait ;) This time lag will add-up and at latest (no overhead) after 0.04 x 24 = 1 msec there will be a hiccup.

Interestingly, exactly this behavior is replicated in DOSBox-X. A hiccup occurs every 24 ms, as per measurement. Which makes me believe, DOSBox-X simulates a 8520 UART for the serial port. You can choose a Pentium processor - but I believe the serial port behavior remains identical.

At 19200 baud, which is not recommended at all for 8250 UARTs - in fact my IBM XT says NO to everything above 9600 baud - things become a little "weird" in DOSBox-X. The hiccups are gone, as they should (!), but now the simulation timing becomes critical. That was not the case at 9600 baud; everything up to the 486/66MHz CPU does not alter the timing. Going faster makes the pulses >longer< - with still no hiccups. With 19200 baud I have to select a pretty fast processor - not too fast and not too slow - I believe because the simulation of the serial port and the CPU are not well-matched anymore. And I need to watch the oscilloscope to choose wisely :D. There is also some (minor) jitter, as I believe the simulation goes nuts - assuming a 8250 UART with no buffer running at 19200 baud - and having a Pentium throwing in data at a rate of 1 msec.  

Maybe we should not overdo it and test the waters with real LEGO models. How bad is the hiccup affecting the performance of the robot? How accurate does it need to be? If it is not 1 msec time slice anymore, does it matter? This could be a very cool school/university project.

Citing the above referenced Wikipedia article:

"Replacement of the factory-installed 8250 UART was a common upgrade for owners of IBM PC, XT, and compatible computers when high-speed modems became available. Above 9600 baud, owners discovered that the serial ports of the computers were not able to handle a continuous flow of data without losing characters. Exchange of the 8250 (having only a one-byte received data buffer) with a 16550, and occasionally patching or setting system software to be aware of the FIFO feature of the new chip, improved the reliability and stability of high-speed connections."

With regard to the baud rate hard-coding into TCLogo: My assembler hardcore time was in the mid-late 1980s for the Z80 processor in my ZXSpectrum. 8086/88 was not in my universe, nor do I know anything about memory allocation in DOS. In the Speccy, all things began at address 0x0000 :D = the ROM, we hooked extensively as it saves a lot of assembler code ;). I believe in DOS, this is different? Question is: Does the TCLogo code (or any DOS code) have absolute addressing? Not the interrupts/hardware access, just within the program. I doubt it, but what do I know. In that case though, things will get messy, as any additional code inserted would possibly screw up absolute addressing.

So I suggest (for now) going with the debug patch in a BAT file. And we should maybe do more research into other DOS simulators handling the serial port differently. Maybe simulating a 16550 or other chips natively handling 19200 baud, as this is all we need to break the 1.04 msec sound barrier.

What do you think?

All the best,
Thorsten

PS.: Just found this: https://www.tek-tips.com/viewthread.cfm?qid=73071. It is exactly what we are talking about here - however this is for slow QBasic - per byte (and not 1 msec byte hammering). Works with QBasic within DOSBox-X (per byte) - and look at the end of this thread ... it is all out there. I like the "you don't need assembler" bit very much; OUT address, value in QBasic is exactly the same as O address value in DEBUG ...

 

Edited January 31, 2023 by Toastie

[Toastie]

9 hours ago, 2GodBDGlory said:

I didn't realize there was any programmable stuff for the 4.5V system!

Sorry for bringing this up again. I surely have a (n updated) copy of your wonderful Technic History book. It is a repository I never want to miss.

As far as I am concerned, 9750 (and dependencies) runs under the LEGO Technic as well as LEGO Dacta program.

All the best,
Thorsten

Edited January 31, 2023 by Toastie