Search the Community
Showing results for tags 'lego technic control'.
Found 4 results
-
Dear all, this is what I came up with recently (focus is on the lower right ...): Executive Summary In this project, a 1981 TI99/4A is connected via its speech synthesizer module to Technic Control Interface A from 1986/7 using a simple bidirectional 8-bit latch parallel port interface comprised of two 74LS373 TTL ICs from the same era No address decoding required, instead, the PCB in the synthesizer is slightly modified and all required lines (D0 – D7), LR#, LW#, WE#, GND, +5V are wired to the empty upper compartment of the synthesizer module Direct access from TI BASIC (1979; mini memory module required) or TI Extended BASIC (1981; XB module required as well as a 32k memory expansion module) The interface is in full compliance with Evan Koblentz’ challenge, announced earlier here on EB as well as on his website, see below. A preliminary video showing the TI99/4A + synthesizer module in action is here: It shows my prototype board (which is now on perfboard in the TI's synthesizer module). In action means, there is speech synthesis and parallel output to 6 LEDs and 2 TTL inputs (which go directly 1:1 to #9750). I hate taking videos, as I constantly screw up, but will try to make a somewhat decent one … EDIT: Video ^^ is on Youtube: And here is the full boring story: During a trip to the US (SoCal) in May/June this year, I “accidentally” ;) googled “TI99” … … so here we go again: Motivated by Evan’s 9750 EuroBricks hacking challenge, I tried to get my 1982 dream computer TI99/4A in touch with TLG’s LEGO Interface A (#9750), what else to do with it ;) And yes, my posts in this regard may be annoying, but so are super cars. Or Cada stuff, BuWizz problems, ++$600 sets – of course >only< to me. Here is to feeling good! The TI99/4A is “beautifully weird” and a very nicely designed system, I fell totally in love with. I have these feelings after thorough studies of corresponding circuit diagrams and inspecting the main board myself. I had no idea what the story was back in the days; I did not know why TI entered the home computer frenzy ship in 1979 with the TI99/4 and abandoned it in late 1983, when they stopped manufacturing the TI99/4A, nor that 16-bit TMS9900 processors existed, and that the TI could speak … I do know now and it is truly a breathtaking story. Also the “inner logic” of the TI99 around the CPU is almost bizarre, but when diving deeper, it really is a very cool approach, descending from the concepts of making mini computers. As said, I never had one, nor saw one in reality before early summer 2024. Evan’s challenge rules are hack computers from 1992 and earlier, that were not endorsed by TLG to operate LEGO Technic Control Interface A #9750 (endorsed were: IBM PC, Apple ][, BBC Micro, Commodore C64, Philips P2000) only use contemporary hardware components up-to 1992; only use emulators on modern machines, but with no additional features other than available up-to 1992. This 1992 threshold originates from TLG’s release of their Interface B in 1993, which changed “everything”, details are on Evan’s website (https://www.brickhacks.com/2.php) For my very own purpose, I added a 4th rule: The Interface A must be operated with the BASIC language that came with the respective computer The latter is just my personal rule, as it a) makes it much easier to write programs for operating #9750 in contrast to using assembly; b) virtually all BASIC dialects have almost identical instruction sets, particularly PEEK, POKE, and or IN(), OUT, to get access to the hardware components of the system; c) assembly, which is a way more powerful language, both in terms of code execution speed and hardware accessibility, is mostly specific to CPUs due to their different internal hardware structure, as are the accompanying assemblers, linkers, and other software. I do speak Zilog Z80 assembly, but I had a hard time getting used to Intel’s 8086/8 assembly, and for Motorola’s 68000 (used in my Atari 1040 ST and others), I simply lost it. For the 99er, with its Texas Instrument TMS9900 CPU, everything is once again largely different … and I simply don’t have the time to learn all this stuff … well not yet ;) OK, enough story telling: What is the cheapest and appropriate hardware approach (cf. challenge rule 2) for getting parallel access to the 6 output and 2 input lines of #9750 in TI BASIC? Well – none! That was it, story was over. Why? Because TI BASIC (from 1979) does not have a POKE, nor an OUT or equivalent command. You can PEEK around, but no, no POKE. Back in the days, there may have been good reasons for that … But wait, there is more (there always is) … there is TI Extended BASIC, released in 1981 as ROM cartridge. And bingo, now we’ve got CALL LOAD (address, byte), which is the equivalent to POKE address, byte … but only when you have the 32k memory extension attached as well ... or if you have the TI mini memory cartridge, which also adds CALL LOAD to your commands, but without any other needs. I was lucky enough, to purchase an original TI mini memory cartridge for €40 from a >very< nice individual living in Berlin! Thank you very much again, Daniel!!! So I was all set, original hardware wise. On to hacking … it took me a while to figure out the “inner logic” of the address decoding within the console, particularly because the TMS9900 processor is a true 16-bit CPU! When interacting with peripherals though, the 8-bit world is back, by doing … things, I still don’t understand. All I know for sure is: The TI99 uses an 8-bit wide data bus to talk to its speech synthesizer box, an add-on that came with my machine. And that CALL LOAD and CALL PEEK have direct access to this thing, i.e., its memory mapped address space: One can read data from the synthesizer at address 0x9000 and write to it at address 0x9400. So the documents say. With some further study of the circuit diagrams of the console as well as the speech module and most importantly, this website (http://www.unige.ch/medecine/nouspikel/ti99/titech.htm), which is an invaluable resource, I finally came up with these ideas: Use the speech synthesizer box as enclosure for my “TI 9750 interface” in the way, TI originally planned it: Slide-in hardware speech extensions into the upper compartment. Well, the upper compartment with that little door is empty, nor are there any sockets; in other words, TI never released anything that may slide in there. The circuit board with the synthesizer’s electronics is located in the lower compartment. I read that TI planned to extend the speech capabilities of the synthesizer with additional “speech ROM modules”, but before they actually made that happen, they found out a way more flexible approach using software … so no one wanted to book that room up there in the synthesizer, but me. As the full I/O bus including all address, data, and control lines of the TI console are fed through (and also into) the speech synthesizer’s PCB, everything is available within the synthesizer box; no reason to hack the console. When you attach the speech module to the console, the I/O bus is replicated on its other side, and more peripherals can be attached (parallel/serial interfaces, disk controllers, modems, etc. pp.). There is one exception: the +5V line is not, as the power consumption of the different additional original TI hardware extensions was simply too high for the console’s power supply. However, when you only want to power a modern 32k memory extension, just solder a wire from one side of the synthesizer PCB to the other. I did that. So, here’s the plan: Circuit diagram of some of the address decoding sections of the TI console and synthesizer module (blue boxes), and my added two 8-bit transparent D-latches (74LS373) interfacing to #9750, along with a 4 x NOR gate 74LS02 TTL chip. Note that only one NOR gate is used. Here are the console and synthesizer circuit diagrams I used for my project. The former is actually a large collection of diagrams of the TI console and some peripherals. The weird CON notation is just describing my wires going from the PCB into the upper (empty) compartment of the synthesizer module. Address decoding in the TI99/synthesizer system (useful for hacking …) The logic of the IBM PC/#9771 combo has been described before, and is summarized (again ) in the hidden section below, where the corresponding TMS9900 CPU lines are used for the description. The thing is: The TMS9900 has no IOREQ# equivalent; all I/O access is via memory mapping (which may be wrong: I simply have no clue, how this A15/CRU stuff works, and most importantly how I would invoke/apply/use it from BASIC. Furthermore, there is no RAMCS# or ROMCS# input as on the ZX computers, which is really useful on systems with unresolved address space. The TI99 is no exception in this regard – out of the box, its address space is not fully resolved, see below. With reference to the above circuit diagram, I figured out a rather simple route to make use of the present address decoding hardware in the console and synthesizer module for additional memory mapped hardware, without screwing up the system – and without using assembly. In essence, I am hacking the synthesizer module, there are no changes to the console. The minor hardware change, without compromising the functionality of the synthesizer(!) is: A cut of one trace on the synthesizer’s PCB: Remove GND from pin 3 (C input) of U3 = 3-to-8 decoder 74LS138. And then connect this pin to address line A14[A1]: Note on usage of weird notation A14[A1]: For some reason, the TI engineers back in the days decided to use a different notation for their address and data bus lines: In contrast to every other vendor, TI denotes the most significant address bit as A0, and the least significant bit as A15. This is exactly the other way around in all other computer systems known to me. The same holds true for the data bus. I am thus using the notation A15[A0], where the bracketed bit denoting what it is outside of TI universe. Here is how the address decoding for the synthesizer works in the original configuration (you can read much more about that here): The speech synthesizer chip TMS5220 has, among many other things, two inputs, RS# (L = CPU reads data from synthesizer) and WS# (L = CPU writes data to synthesizer). Both cannot be L at the same time; thus there is a dedicated read address and a write address, respectively. These signals are generated by U3 = 74LS138 (3-to-8 decoder) in the synthesizer – this chip selects only two outputs: Q2# and Q3#. No other Q# outputs are used – in other words they are free! The output enable dependencies for U3 are: A15[A0] = H; RESET# = H (which is always the case when there is no trouble). The inputs A and B (C is bolted to GND = L) select the active output Q#: Possible combinations in the original configuration are: Table 1: “-“ = not connected/no function; SBE = speech block enable; RS#: read from speech chip; WS# write to speech chip. Note, that A5 = [A10] in the non-TI world. That’s it; Q#4 – Q#7 cannot be addressed, as input C is always L. And here comes the hack: Remove input C from GND = L, and hook it up to A14[A1]. This is all and changes the output selection to: Table 2: LR# = LEGO 9750 read; LR# = LEGO 9750 write, my fancy addition of synonyms … Now we need to have a look at the address decoding inside the TI99 console; on pin 2 of the I/O port, the above mentioned SBE signal is provided, which indicates CPU wants to address/access the synthesizer module. The NAND gate U506b in the console “combines” the outputs Q4# and Q5# of U505 (74LS138 3-to-8 decoder) generating the SBE signal: When either one of the output is selected (= L), SBE = H. When none are selected (= H), SBE = L; and finally both cannot be selected. Regarding the enable inputs of U505: Q4# of U504 (again a 74LS138) needs to be selected = L and A15[A0] needs to be L. The third enable input is active H; the NAND gate U506a combines A5[A10] and DBIN in the following manner (DBIN = H indicates a read data request from the CPU): When the CPU has issued such a request, DBIN = H and thus A5[A10] needs to be L, otherwise the outputs of U505 are disabled (are all = H). When DBIN = L, A5[A10] needs to be H for a write data request. The outputs Q4# or Q5# are selected, when A3[A12] = H, A4[A11] = L, and A5[A10] = L for read and H for write, see above. Finally, for selection of Q4# = L on U504, MEMEN# (memory accesses enable) needs to be L, A0[A15] = H, A1[A14] = L, and A2[A13] = L. All this results in the following table for read/write access to my interface connecting the TI99 to #9750, preserving full access to the speech synthesizer: Table 3: X = L or H, thus the addresses are mirrored (i.e., are not fully decoded) every 4 times in the address range shown in the last column. Using this approach, we now have two (+ all mirror!) new addresses: 0x9002 for reading data from the LEGO #9750 interface and 0x9402 for writing data to the interface. As DBIN is already tied into the address decoding logic, C and OC# of the corresponding 74LS373 input latch (IC1 in the circuit diagram above) are both connected to Q6# of U3 = LR#. For the 74LS373 output latch (IC2), we need a positive signal on the C input, which is “composed” using Q7# of U3 = LW# AND WE# (write enable) from the I/O bus of the TI99. This is done with the 4 x NOR gate 74LS02 chip, but only IC3a is used. NOR gates behave as AND gates in negative logic, so LW# NOR WE# = H, that’s exactly what we need: Only when both inputs are L, the gate output is H, in all other cases L. The 74LS373s are wired as in the #9771 card for the IBM and many other simple 8-bit I/O solutions from back in the days. I used it for my ZX and Amstrad interfaces as well. Lastly, PEEKing and POKEing in TI BASIC is again a little different than for the computer systems I played with: In the address range 0x0000 – 0x7FFF (0 – 32767) it works as “everywhere”, e.g.: CALL PEEK (32767,variable). Above that address range (and the speech synthesizer’s addresses are located above 32767), one needs to subtract 0x10000 (65536) from the address you wish to PEEK/POKE: CALL LOAD (-27646,0) is equivalent to POKE 37890,0 (which is 0x9402, our write address for #9750). If we want to read data from #9750, we need address 0x9002, which is 36866; subtracting 65536 yields -28670 and thus CALL PEEK (-28670,variable) is used in TI and Extended TI BASIC programs to do that. If you like to read more about this approach, here is one source. And finally, here are some pictures: Above: Disassembled synthesizer module Above: CON lines soldered to freely accessible soldering spots. Yellow wires = D0-D7, white = WE#, yellow/white = LR#, yellow/green = LW#, whatever color (I am color blind) = A14[A1], red = +5V, black = GND. Missing: WE# - I simply forgot that line on first try and almost gave up, because nothing worked as intended. Then, when walking our dog, it just occured to me ... when you want to write data, you need to tell your chippies so ... Above: Perfbord attached to the connector, the top white connector was glued to the 12 others; this is the missing WE# line The left 10 x 2 pins attach to the Interface A with the original cable. Above: Synthesizer module. Bottom connector: Replicated I/O port of the console - this is where my 32k expansion attaches to and is also powered from. Top left: Connector for Interface A and 74LS02 trying to figure out, what's going on ... Above: Synthesizer module attached to console, with interface for #9750 extension under the hood and original LEGO cable for connecting to #9750 attached ... In summary, we can add another computer system from the 1980’s, which was not endorsed by TLG, to @evank's challenge (and https://www.brickhacks.com/2.php); The TI99/4A. All the best, Thorsten P.S.: Will try to make a video proof soon!!! Done -
Dear All, motivated by Evan’s 9750 EuroBricks hacking challenge, I tried to get my beloved Amstrad PCW 8512 (named by Amstrad's CEO Alan Sugar “Joyce”, which is the given name of his assistant) along with an SCA Systems parallel/serial interface in touch with the LEGO Interface A (#9750). It appears as if TLG never wondered into Amstrad world; they were more on the professional IBM, Apple, Acorn, Commodore, and Philips side of things. Expensive things that is; not on the el cheapo side, were I was. Here is the video proof that it works ;) I did not upload that video to YT - it is too crappy https://bricksafe.com/files/Toastie/amstrad-8512-and-9750/Amstrad 8512 LEGO 9750.mp4 To begin with: Here is my vintage compuing corner in the attic (this room also serves as my home-office) - along with the vintage LEGO stuff, which is controlled by these machines: (1) is the PBrick section (RCX, Scout, IR serial and USB tower, Sybotics with optical serial connection; the Vision Command camera setup is controlled by the Scout; Cybermaster with the RF tower below. The barely visible TC brick sorter robot is controlled by the RCX. (2) is the LEGO interface A (#9750) section; there is a 4-way switch that allows to use multiple computers for the interface: The IBM XT (A), the Toshiba Satellite 4090 (B), which is on a pull-out shelf, or any modern computer via an Arduino USB28bit parallel interface mounted right to the interface A. The 4.5V motors of the TC robot (3) below are hooked up to the Interface A; additionally, a PUp tacho motor and a Technic hub control the lateral movement - synching and programming reported here on EB. (4) is a second Interface A - this again is on a 4-way switch (located above the (D)) to be controlled either by the Amstrad PCW 8512 (C) or the ZX81 or ZX Spectrum (D) or the Atari 1040 ST or the C64 (E). The second Interface A is intended for testing and trying out things; there are 8x 4.5V lamps and 2x 4.5 motors with 2x light sensors on a 32x32 base plate. Both, the interface as well as the Atari and C64 are on pull-out shelves. So without further ado: Here we go again ... and yes, my posts in this regard may be annoying, but so are super cars. Or Cada stuff, 2++ m tall cranes, ++$600 sets – >only< to me, that is! And here is to feeling good! The Joyce [(C) in the above photograph] is one of a kind, I can tell … its design is beyond belief – in the absolutely positive sense. Made for the masses, using incredible techniques. IBM just went ballistic with regard to parts and pieces in their original PCs and then XTs (which I am madly in love with). 8000 something German Mark in 1983. And TLG was sailing along – after three more years they introduced Technic Control, and PC’s, XT’s, Apples, and so on were the prime machines targeted for that technology – in schools that is … no way to go cheap there! Now, the PCW (Personal Computer Word-processor) 8512 was not as cheap as Sinclair’s ZX computers; it cost about one quarter of what IBM charged for their PC. But: It was a fully blown word and database processing system. No built-in graphical stuff, just pure text and number crunching. The OS was CP/M 3.0 (“CP/M Plus”) – which was “the basis” of (or better copied by) Microsoft’s early versions of MSDOS. CP/M is so cool … and of course programming languages also work on the Joyce; as I wrote many times, I am a total BASIC person. Joyce came bundled with the “LocoScript” word processor and with “Mallard BASIC” for CP/M Plus, both made by Locomotive Software in the early 1980’s. The following citation is what I really like about the name of that BASIC dialect (copied from the referenced Wikipedia article): “It was also optimised for speed — it is named after the LNER Class A4 4468 Mallard locomotive, the fastest steam locomotive in the world, once again displaying the company's fondness for railway-oriented nomenclature. In fact, the Locomotive Software name came from the phrase "to run like a train" and it was this theme that was used to name Mallard BASIC — no other Locomotive Software product was named after anything railway-oriented.” And behold, Mallard BASIC is fast! Joyce came also bundled with a 9-needle dot-matrix printer, which mechanically attached seamlessly to the keyboard mimicking a type writer; there are recesses for 2 brackets in both devices. I believe though, virtually >no one< actually used that feature, as it consumes considerable space in front of the screen. Joyce’s brain is a Z80A CPU – my all-time favorite microprocessor. Why? Because back in the 1980’s, I must have referenced the German edition of Rodnay Zack’s book “Programming the Z80” a thousand times as I was fascinated by the performance boost when programming in Z80 assembly code, as compared to e.g. BASIC. All my computers I had back then (and still have today) had Z80 CPUs: Sinclair’s ZX81 and ZX Spectrum, and Amstrad’s PCW 8512 “Joyce”. On the Joyce, almost all Z80 CPU signals are exposed on the back connector along with some other lines. But there is more (there always is): Joyce features a printer port, which is (exclusively) connecting with the Amstrad/Joyce 9-needle dot matrix printer. One can of course connect custom devices to that port, but that needs intimate knowledge of the innards of the hardware. Which is not that straight forward, as Joyce features some rather powerful chips, among them an 80 pin flat pack gate array which does a lot of housekeeping tasks, the well-known NEC µPD765AC-2 floppy disc controller, and even a second microcontroller, the NEC µPD8041AH, which is a programmable peripheral interface controller. The latter features an 8bit CPU, 1kbyte ROM, 64 byte RAM, 8bit timer/counter, and 18 I/O lines, which all go to the 9-needle dot matrix printer! Nothing really easy to hack for the interfacing of Joyce with LEGO interface A, particularly with access from BASIC. Mallard BASIC does provide the command “OUT address, data byte” and the “INP(address)” function for direct Z80 I/O port access, but I would not know how to dig through the PPI controller to read and write to #9750 through the built-in printer port. Fortunately, I got hold of the SCA Systems serial/parallel extension interface for the Joyce. There are at least four such interfaces from different vendors I am aware of. Two of these are the Amstrad CPS 8256 and the SCA Systems interface. At first glance, both their PCBs look identical, but closer inspection revealed that there are differences, particularly in the address decoding section. The circuit diagram and photographs for the CPS 8256 are available on the internet, similar stuff for the SCA interface is not, as far as I know. So I had to do some PCB track tracing, at least for the address decoding. After a lot of beeping through the tracks, I came up with the partial circuit diagram below. I was very happy to learn that the TTL 74LS373 chip (8 transparent D-flip flop latches, as TLG used in their #9771 ISA card for IBM PCs) directly connected to the 8 data out lines of the Centronics port of the SCA interface! From there it went straight downhill. Above: Circuit diagram of the address decoding section and the 8-bit 74LS373 output latch interfacing to #9750. The blue box contains my additions, i.e., a second 74LS373 and a 4x NOR gate 74LS02 TTL chip. Address decoding and data read/write procedure I wanted this interface to act in exactly the same way as TLGs #9771 card behaves: Upon emitting 1) the correct address, 2) the 6 data bits for the 6 output channels of the interface A, 3) IORQ# (# = active low), and finally 4) WR#, the C line of the “output 74LS373” goes H and thus it mirrors the content on the 6 D lines connected directly to the Z80 data bus transparently to the corresponding 6 Q outputs. As there is no change on the data bus as long as WR# = L, all emitted data are securely latched, when WR# goes H again (i.e., the C input of 74LS373 goes L). No more changes of the output lines are possible until the next complete write cycle. OC# is connected to GND and thus the chip has always activated outputs, see below. Well, this is how it is done on the #9771 card. But to my surprise, I did not find any WR# line connecting to the address decoder, I found only address lines and IORQ#. At first, I was puzzled but then realized: The 74LS373 in the SCA interface is for writing only. No data are read from the 8 Centronics data lines; the two Centronics flow control lines BUSY and STROBE# are routed to the Z80DART in the SCA interface. In other words, no WR# decoding is necessary in this scenario. SCA used the 3-to-8 demultiplexer 74LS138 for Centronics port address decoding in the following manner: The output Q7# of 74LS138 goes L (= is selected) when its data input lines A(=A3), B(=A5), and C(=A6) are all H, the enable line FE1(=A7) = H, and the enable lines FE2A#(=IORQ) and FE2B#(=A4) = L. In all other cases Q7# = H. This signal needs to be inverted, and SCA used the second 2-to-4 demultiplexer in the 74LS139 TTL chip to do just that: When Q7#(74LS373) = L, Q2#(74LS139) = H. The decoded Centronics port write address is thus: A7 A6 A5 A4 A3 A2 A1 A0 H H H L H X X X ; = 0xE8 to 0xEF, as A0 – A2 are not decoded The Q2# line of 74LS139 used as simple inverter is routed to the C input of the 74LS373 8-bit latch: When the address is within 0xE8 to 0xEF, the data bus content is latched upon IORQ# = L. However: This approach does work with a Centronics printer but not for bidirectional operation of LEGO interface A: Using TLG’s TC Logo and other programming languages, you can write to the 6 outputs and read back the status of the outputs as well as the status of the two sensor inputs of #9750 at the same address. So this calls for a (very) little tinkering with the SCA circuit board and the addition of a second 74LS373 (read latch) and a 4x NOR gate 74LS02 TTL chip, see circuit diagram above. In addition, pin 6 of 74LS139 in the SCA interface needs to be bent up – there is no use for this inverter after pimping the board. Next the WR# and RD# lines (connectors 39 and 41 on the Joyce expansion port) are wired to the inputs of two NOR gates; Q7# is wired to both other inputs: When WR# and Q7# = L, the NOR gate for reading = H; when RD# and Q7# = L, the NOR gate for writing = H. The latter means that this signal can be directly connected to the C input of the 74LS373 latch for storing write data. For reading back all 8 bits with the additional 74LS373, the corresponding NOR gate output signal needs to be inverted: This signal goes to both, the C input as well as the OC# chip enable input. When OC# = L; the chip is enabled; when it is H, the outputs are in “tristate”, i.e. not visible on the data bus. All inputs remain active though. When C and OC# = H (wrong address, IORQ# is not = L, RD# is not = L) the outputs of the second 74LS373 are in tristate but the D-inputs follow (transparently) the data bus content. When C and OC# = L, data on the D inputs are immediately latched (no more changes recognized) and the outputs are activated, mirroring the D lines content very shortly before C became L for the time of the RD# signal = L (i.e., the Z80 CPU fetches the data bus content). The moment RD# goes back to H (= data are in the corresponding register of the Z80 CPU), the second 74LS373 goes again into tristate. This is in principle how it is done on the IBM XT #9771 ISA card as well. I also used a similar approach for my ZX81 and ZX Spectrum interface for #9750. It is a bit different on my Atari 1040 ST, as the printer port is handled differently on these machines. Here are some pictures of hacking the SCA Systems interface for operating LEGO Interface A with an Amstrad PCW 8512: Left: I had to cut into the SCA interface enclosure to access the built-in 74LS373 - this "channels" all 8 data bus lines as well as +5V and GND to the outside. Also the 6 Q outputs going to #9750 are available. Right: I simply soldered two 1x10 Dupont type connectors to the solder pads of the 74LS373. The wires seen are RD# and WR# from the control bus, Q7# and the new line replacing the Q2# line going to the C input of 74LS373. Left: The TTL chip on the lower right is the 74LS373 output latch I am tapping into (or better onto ;) Right: The add-on board attached to the RCA interface; the front connectors are compatible with the orginal LEGO 20 ribbon wire for the Interface A. As always: Tried to match an enclosure - the golden 1x6 tile is from the stand of my MK Flying Dutchman. 3 windshields make the side walls. Left port: Centronics - still works. Right port: RS232 - still works. Top port: LEGO Interface A - works. And finally, we can add another computer system from the 1980’s, which was not endorsed by TLG, to @evank #9750 challenge list. The chippies used are all from way before 1990. I feel good . All the best, Thorsten
-
Dear All, motivated by Evan’s 9750 EuroBricks hacking challenge, I tried to get my beloved ZX81 (Zeddy) in touch with the LEGO Interface A (#9750). It appears as if TLG never wondered into Sinclair world; they were more on the professional IBM, Apple, Acorn, Commodore, and Philips side of things. Expensive things that is, not on the el cheapo side, where I was. My Zeddy is an ISSUE ONE (as it is printed on the PCB, I am not exaggerating here!) machine from 1981 … Does the text above sounds familiar? Yes, I just c/p’d from my ZX Spectrum thread posted earlier. And yes, my posts in this regard may be annoying, but so are super cars. Or Cada stuff, 2++ m tall cranes, ++$600 sets – >only< to me, that is! And here is to feeling good! The Zeddy is one of a kind, I can tell … its design is beyond belief – in the absolutely positive sense. Made for the masses, using incredible techniques. IBM just went ballistic with regard to parts and pieces in their original PCs and then XTs (which I am madly in love with). 8000 something German Mark in 1983. And TLG was sailing along – after three more years they introduced Technic Control, and PC’s, XT’s, Apples, and so on were the prime machines targeted for that technology – in schools that is … no way to go cheap there! There was a nice ad in the back-then magazines (this one from the 1983 April issue of Sinclair Projects: So, here we go again: The Sinclair “interface” for LEGO Interface A is exactly the same as described earlier on EB for the ZX Spectrum, so there is nothing to add. The edge connector layouts of the Speccy and Zeddy are “identical” (for the Zeddy’s contact range); thus the interface for #9750 I built into the ZX Printer case along with the printer’s edge connector plug/cable are fully compatible. All that is needed is (again) CE#, RD#, and WR#; CE# is enabling reading/writing from/to the interface and includes resolving address and memory request (MREQ#). Why not I/O request (IORQ#) as for the Spectrum? Simply because standard ZX81 BASIC does not feature the OUT/IN command/function. Machine code works well using the Z80 out/in directives as well on the ZX81 of course, but I like to keep it simple; BASIC command POKE and function PEEK are my best friends. Both issue MREQ# rather than IORQ# for getting access to the data bus. The really crazy part is the address decoding, which should be compatible with the 1kByte ZX81 base unit as well as with a Zeddy having a 16k Sinclair RAM pack attached; who knows what I will program into these sheer endless rows of empty bytes … Here’s what we are dealing with: The 8kByte ROM of the ZX81 has 13 address lines A0 to A12 (0x0000 to 0x1FFF) – so Sinclair only attaches these with no further decoding of A13, A14, and A15. In other words, the ROM also responds to addresses from 0x2000 to 0x3FFF, and so on (these additional “regions” are sometimes called “shadows”). However, for one, there is the clever Ferranti ULA, which is connected directly to the Z80 CPU using all 16 address lines, and always knows what’s going on in the system. And the ULA can control the ROM and RAM access via its RAMCS# and ROMCS# outputs. It does clean up the address mess a bit but certainly not everything, as it has other, way more important things to do. If you want to dig any further, I recommend starting here: https://www.zx81keyboardadventure.com/2023/02/zxio-interface-for-zx81-part-2.html As my Zeddy does have a 16kByte RAM pack attached, which is located at 0x4000 to 0x7FFF, followed by ROM shadows 3 and 4, which are followed by 16k RAM shadow 1, all 64k addresses are in use. Furthermore, the 16kByte RAM pack does not have a RAMCS# input. I did not want to open it (again that is, needed to do it a couple of years ago to replace two 4116 memory chips); I was thus left with cleaning out ROM shadows and use corresponding addresses to read from/write to the ZX Printer interface which in turn talks to #9750. This approach has been frequently used back in the days as well of course; see for example this article also referenced in the above zx81keyboardadventure blog thread on page-1. And without further ado, here is my approach to a) free up addresses 0x2000 to 0x3FFF (the first ROM shadow) and establish 8 (memory mapped) I/O ports for – well – controlling 8 #9750 interfaces: As I am going cheap here, in the tradition of Sinclair Research Ltd., I am using only 2 TTL chips from the 1980’s (this an essential is part of @evank 's challenge!), to get 8 I/O ports (and not only one, as described in the ETI article referenced above) at the addresses 0x2000 to 0x2007, when address lines A0, A1, A2 are actually connected to the 3 channel select inputs of the 74LS138 de-multiplexer. OK, in principle only; currently I have hard-wired only one I/O port at 0x2000 (8192 dec), as all three channel select inputs of 74LS138 are connected to ground (L), which always resolves to output Y0#. Only when this chip is enabled though, otherwise Y0# is H. Taking advantage of the 3 enable inputs (FE1 needs to be H AND FE2A# needs to be L AND FE2B# needs to be L) allows appropriate address decoding when the de-multiplexed A, B, C input information (3 bits = 8 combinations = 8 I/O ports) is used to select an Y# output port. In the above configuration, A15 AND A14 AND MREQ# need to be L AND A13 needs to be H (= CPU memory access to address 0x2000), and as A-C are L = 0, Y0# then goes L. This is exactly the same approach I used for the ZX Spectrum – in other words, I can use the exact same interface described before built into the ZX Printer case. This is also in the tradition of Sinclair Research, of course; the ZX Printer works on both the ZX81 and the ZX Spectrum. Now the ROM shadow needs to get kicked out; this is done by inverting Y0#, and use one additional npn transistor as “tristate” driver: When Y0# = L, the output of IC2c is H and the transistor pulls the ROMCS# line high (ROM = not responding), when Y0# = H, the output of IC2c is L and the transistor is in “high impedance” state and the ULA can do whatever it wishes to do on the ROMCS# line. The only thing left is to route the Y0# (CE#), RD#, and WR# lines to the interface as well, as was also done for the Spectrum. And now we can add the good’ol Zeddy (Grrrrrr …) to the list of 8 bit machines operating the LEGO Interface A. At >very< low cost: Left: The Zeddy - a full-blown 8bit computer! The tape is for insulation. Soldered extra wires are for connecting to the "interface" shown on the right. This is the circuit enclosed in blue in the above schematic. Left: "Interface" mounted to the PCB. Right: Focus on the 16kByte RAM pack (me and photography, this was on purpose, of course) and the ZX Printer interface connecting to #9750. The Sinclair workspace - here, the Zeddy illuminates the 4.5V light bricks: POKE 8192,63 does it ... This is the program playing the lights as shown in this video: https://bricksafe.com/files/Toastie/zx81/ZX81 8750.mp4 All the best, Thorsten
-
Dear All, motivated by Evan's Eurobricks 9750 hacking challenge, I tried to get my beloved ZX Spectrum (Speccy) in touch with the LEGO Interface A (#9750). It appears as if TLG never wondered into Sinclair world; they were more on the professional IBM, Apple, Acorn, Commodore, and Philips side of things. Expensive things that is; not on the el cheapo side, were I was. My Spectrum is an Issue.3 machine from 1983 –Sinclair introduced the legendary ZX Spectrum in 1982 – as successor of their legendary ZX81 from 1981, which was the successor of their legendary ZX80 from, guess when, yeah 1980. And yes, I do like the Sinclair machines very much, as they taught me (a low income chemistry student) how computers work on the hardware level, at the lowest price tag possible (so I could afford these machines) and they taught me how machine language and assembly works. A very nice coincidence regarding LEGO Technic Control and computer hardware for the masses in the 1980’s is shown in the photograph below: The background is a copy of one page of the service manual of the ZX Printer, which came out in 1981. I also had one for printing endless lines of Z80 disassembly code (mostly for cracking the copy protection of video games, see “print” on the right). At the top center there is a Technic 4.5V motor (#6216), a Technic disk with 4/8 black sections (#2958) attached to the hole of an 4.5V light sensor brick (#1161); actually the latter has an IR emitter and IR sensor inside. The Interface A powers and reads these and thus the status of the disk: Black = 1/off, white = 0/on. TCLogo running on a PC samples the >change event< with 1kHz temporal resolution, has two counters, and calculates the frequency of the changes, among other things, and makes them all available to the user. Well written assembly code >is< fast … On the bottom there is the main board of the ZX Printer along with its DC motor – and a disk and the light emitting diode. The disk has transparent and reflective sections (many more as compared to the Technic disk) but the principle of operation is absolutely the same. The Ferranti ULA took care of all the above; the Spectrum (or ZX81) just had to send “make dot”. Here we go: Inside my Speccy, the address lines A5 to A7 and the I/O request (IORQ#) line of the Z80 CPU are already hooked up to provide 8 “chip enable” signals (L=enabled), that I can “freely” use. Due to the “interesting” I/O port address decoding of the Spectrum’s very own hardware (>every< even address activates something in the ULA – Ferranti’s uncommitted logic array chip. It does almost everything other than CPU/memory stuff), care has to be taken upon addressing further I/O ports. Address 1 works, 2 does not, 3 works etc. Sinclair did that for cost saving purposes of course, as the address decoding is kept to the absolute minimum. The Z80 CPU has 16 address lines, which means a lot of decoding to filter out one specific address. Now, other add-on hardware (Sinclair Interfaces 1 and 2, or one of the myriads of third party vendor products, for example) then need to tip-toe between the even addresses – and when they went cheap as well, entire address ranges are blocked as well. Back then (1986 that is) I “blocked” the address range A5 - A7 with all A0 – A4 = 1 (no even addresses!), which gave me 31 (0x1F, bin 1 1111), 0x3F, 0x5F, 0x7F, 0x9F, 0xBF, and 0xFF as I/O port addresses. My ZX Interface 1 does not use these, so they actually work, even today. I used I/O port 1 = 0x1F for 32k bank switching, 0x3F for turning an LED on and off. The latter is the port I am using here to control #9750 as well. The BASIC commands are (as usual …): OUT 63, data (data = 0 to 63 for any of the 6 channel configurations) – this turns also the front panel LED on LET i = IN 63 (which returns the status of the 6 9750 output channels as well as the 2 sensor channels – this also turns the LED off). I simply copied the LEGO #9771 ISA card approach using two 74LS373 transparent D-flip flop latched as described in detail here. This is a rather elegant way of getting instantaneous feedback on the output status using rather cheap, but electrically powerful chips (TTL drivers). I/O address decoding is done in the Spectrum’s gut as shown in lower left blue box in the schematic below, with the 3 “extra” (see below) lines RD#, WR#, CE#: How does it work? When the Z80 writes to an I/O port, it puts the corresponding address on the address bus, pulls IOREQ# low, puts the corresponding data on the data bus and then pulls WR# low. The address is decoded by 74154; the corresponding output (0 – 15) goes low, but only when the chip’s outputs are enabled, which is the case, when EN1# and EN#2 are both low. EN2# is always low as it is tied to GND, EN1# when IOREQ# is low. IC3c (NOR gate) receives the Q1# output signal on one input, WR# on the other. When both are low, C of IC5a goes high and the transparent latches follow the signal at its 8 (6 only used for #9750) D inputs which are connected to the data bus of the Speccy. During this time, the Z80 holds the data from the BASIC "OUT" command static on the data bus. Upon pulling C high again (write cycle is over), IC5b freezes-in the 8 data inputs and clocks them onto the corresponding Q outputs connected to #9750. As OC# is always low, the outputs of IC5a are always enabled. When the Z80 reads from an I/O port, essentially the same things as above happen; now the RD# line is pulled low (somewhat delayed, i.e., closer to the rising edge of IOREQ#), and data are transferred to Z80 the accumulator register. However, the outputs of IC4a, again transparent D latches, are only enabled, when the correct address + IOREQ# + RD# is active, i.e., for a very brief moment. It has to be this way, because the Q outputs of IC4a are connected to the system’s data bus and would crash it at once when RD# goes high again (read cycle done). Most of the time pin C of IC4a is high (in contrast to IC5a, where it is always low = enabled), so the Q outputs are in tristate (high impedance or simply “not there)”, but the D inputs constantly read a) the state of IC5a’s outputs and b) the two sensor lines from 9750, i.e. they are always up to date. Upon a valid read request, pin C of IC4a goes low – at the same time its outputs are enabled: #9750 status freezes-in and is clocked onto the Q outputs = Z80 data bus. I like this approach using the transparent latches very much! This is of course owing to the fact that TLG’s programs (TCLogo and the like) write the “code” 00010101 (0x15) to #9750, then read back the #9750 status (the sensor readings are stripped, as they may have changed in between OUT and IN). The remaining connections required for the interface (data lines D0 – D7, +5V, GND) are obtained from the edge connector of the Spectrum’s PCB. Although I have the corresponding bare plug, I wanted to use the ZX Printer cable and case as interface box, as an homage to Sir Clive Sinclair : For the parallel Atari and the serial PC interface (USB and/or RS232), I made brick-built cases. Initially I tried using an Intel 8255 PIO (https://en.wikipedia.org/wiki/Intel_8255) as communication hub for #9750 (= total overkill, but I had three of the PIOs) – because it is a fun chip, debuting in the mid 1970’s. I guess I got the addressing wrong; a 8255 wants to know, what to do upon powering up, default is all three 8-bit I/O ports = inputs. I could not get the configuration right – I guess the ULA was addressed as well and things totally screwed up. I shall give it a second try “later”. I thus reverted to TLG’s “2x 74LS373” design, and made a perfboard version of the circuit shown in the schematic above, which fits into the ZX Printer case. I used the original printer cable (rewired inside the plug, as the printer uses other signals then #9750, such as address lines) and made no changes to the outer appearance of the printer. There are only 12 wires available; thus the 3 extra wires from the Speccy came in handy as additional inputs to the interface. Absolutely not nice, but: works. I guess a black ribbon cable looks nicer, but right now I don’t have one. Upper two pictures: (Left) Perfboard mounted into the printer case and (right) connector to #9750 and address decoding board. The latter is simply tying together RD#, WR#, and CE# controlling the C and OC# inputs of the two 74LS373. I made this extra board so that a different approach using 74LS374 just requires exchanging them for the 373’s (they have the same pinout), which are clocking in the data upon any rising edge at their CLK input (recall that 373’s freeze in data when C = low and set their outputs accordingly; no edge trigger required, and the Q outputs follow the D inputs when C = high). 374’s thus need a slightly different address decoding using NOR gates – and thus only the additional board needs to be replaced. This board is attached with Dupont type connectors. Upper two pictures: Finished interface without (left) and with (right) metalized paper roll inserted. I need to make a cover for the soldered pins of the 20 pin flat cable connector I desoldered from an old Shimadzu mass spec in the lab; otherwise the paper may cause shorts. Almost forgot: The switch S1 in the schematic above is actually the original paper feed switch of the ZX Printer, located at the top right of the case. Sinclair used this switch upside down: The knob sits in a fitting mount on the bottom of the printer case; a plastic rod extension with a little knob at its upper end is the switch’s actuator – you are pressing the switch body onto its fixed knob – I love it. Simply ingenious. In my setup, the switch pulls the "OC#" line of IC 5a high, and thus turns it's outputs off - should something go wrong on your TC LEGO model and #9750 is not in reach. And finally here is the entire ZX Spectrum + ZX Printer interface + LEGO Interface A – the program running is the old-fashioned TLG version; but this time, the presence of #9750 and the interface is checked by asking for the answer to the ultimate question of life, the universe, and everything, which is 101010 of course: BTW: I think the LEGO Interface A “look” very nicely matches up with the ZX Spectrum and ZX Printer design; too bad TLG did not see that, back in 1986. Sinclair BASIC at its best: The program does this: https://bricksafe.com/files/Toastie/zx-spectrum-and-9750/ZX9750.m4v Best wishes, Thorsten