alexGS

Hello Thorsten - nice work with proving the operation of the 1ms interrupt timer for the PWM - that explains how it works consistently across systems of different speeds. I think you will be successful in your quest to use the same approach from QuickBASIC (or QBASIC?) Thank you for your kind words about my ‘hacking’ - and for proving that the use of the port address in three places is (i) for testing the port, (ii) for outputs, and (iii) for inputs - I appreciate that. Meanwhile, I have had some difficulties with parallel port use on later laptops from the early 2000s, but since these usually have USB ports as well, I hope to try using USB to feed the (relatively hungry) 5V supply to the Interface A of the later type with the flat-top LEDs. I need to do a little more testing to check this solves the problem of not being able to activate more than two or three outputs simultaneously. The parallel port alone cannot supply enough current in this situation (it can for the earlier interfaces, or for earlier laptops). Last night I became aware of this rather-bizarre piece of new hardware: https://www.aliexpress.us/item/1005005528944178.html It has sold out already, even at the rather high price for what it is. You’ll notice that while it doesn’t have a printer port, it does expose the ISA bus - so could support a version of the LEGO 9771 card - check your post above for the typo under “PWM Signal Generation” ;) All the best -Alex

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? :)

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! :)

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.

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?

I don’t want to derail the thread, so will keep this brief - but remember the Interface A was an educational product designed in England to work with the BBC Micro first. The C64, Philips P2000, and Apple II were alternatives; all four used LEGO Lines, and the first set of teaching materials was designed around this and set 1090 (1986). The second round of teaching materials (1988) was designed around Logo and therefore only for the IBM PC/Apple II. It seems LEGO partnered with MIT after the Interface A was developed, so effectively ‘re-launched’ it with Logo and the new set 9700. However, there is also Logo-based material in the archive for set 1090. It intrigues me that set 1092 seems to have never been featured in teaching materials.

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)

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…

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

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

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 ;)

I’m enjoying this too, for obvious reasons ;) well, obvious if you’ve been reading our big thread about Interface A and TC-LOGO :D Thanks for your work on this! I have Control Lab and all generations of Mindstorms, but it will certainly be interesting to see how they came into being…

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

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

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 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...

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.

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

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

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

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

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

It’s always quite exciting when topics are discussed at the very time that I am thinking about them - i.e. within a day or two (for something that I last considered at least a year ago) :) 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? PCMCIA pin out http://www.hardwarebook.info/PCMCIA - seems to have OR, OW, and EN? And address/data of course. I’m not clear whether a system with a PCMCIA slot has an intervening ‘card services’ in BIOS that only configures ‘approved’ devices, or only enables certain address space. Or does it simply expose all the ISA signals at the PCMCIA slot? The wiring of the LEGO card would presumably configure it at a particular address - as I recall, there is a jumper to select “adress” (!) 925 or 926? The only other practical solution I can think of, to use the LEGO software on a system that doesn’t have the ISA card installed, is to somehow modify the software to redirect output to the printer port. I presume via disassembly the port address could be changed from 925 to 378h? I guess it would be very difficult to match the 9771 port characteristics in terms of output bits and input bits being at the same port address. Thanks for any insights in solving this conundrum -Alex I just realised that I have hijacked your thread in replying to Thorsten on his topic (which I landed on from a Google search). Sorry about that. I am glad you have found the software you were looking for - I shall download it too, in case I get one of those little blue cameras for my Mindstorms :) -Alex

That’s fabulous - thank you :) I will watch the complete video shortly I note that on their Macintosh LCII, the Dacta interface doesn’t fill the modest 640x480 screen properly. I guess that’s why I tend to use even older models like the Powerbook 100! I’ll try it on a Classic too… The advantage of the Windows version, which seems to have come out after that video was made (they’re showing the DOS version), is that the windows can be re-sized and multiple pages displayed at once. Again, wonderful find - thanks for sharing your viewer’s resource here! -Alex

Ah right, I understand now :) Nice work! Love the reference to 2400 baud as ‘light speed’ :D I also wondered whether a Psion Organiser could be used for controlling some of this stuff. It has a serial or a parallel port and a programming language built in. Just another piece of period 1980s tech, but small and handheld :) Cheers -Alex

Evan put it there ;) I’m guessing the software from the link you shared is the same, but maybe I should check. There’s separate versions of Control Lab for DOS and for Windows 95/98. I bought the Macintosh version and Evan put that there too for me. -Alex