Search the Community

Showing results for tags 'vintage computing'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Frontpage, Forum Information and General LEGO Discussion
    • Guest Section - PLEASE READ BEFORE YOU REGISTER!
    • New Member Section - PLEASE READ BEFORE STARTING!
    • Frontpage News
    • Forum Information and Help
    • General LEGO Discussion
  • Themes
    • LEGO Licensed
    • LEGO Star Wars
    • LEGO Historic Themes
    • LEGO Action and Adventure Themes
    • LEGO Pirates
    • LEGO Sci-Fi
    • LEGO Town
    • LEGO Train Tech
    • LEGO Technic, Mindstorms, Model Team and Scale Modeling
    • LEGO Action Figures
    • Special LEGO Themes
  • Special Interests
    • The Military Section
    • Minifig Customisation Workshop
    • Digital LEGO: Tools, Techniques, and Projects
    • Brick Flicks & Comics
    • LEGO Mafia and Role-Play Games
    • LEGO Media and Gaming
  • Eurobricks Community
    • Hello! My name is...
    • LEGO Events and User Groups
    • Buy, Sell, Trade and Finds
    • Community
    • Culture & Multimedia

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


What is favorite LEGO theme? (we need this info to prevent spam)


Which LEGO set did you recently purchase or build?


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Country


Special Tags 1


Special Tags 2


Special Tags 3


Special Tags 4


Special Tags 5


Special Tags 6


Country flag

Found 4 results

  1. 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
  2. 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
  3. Dear All, strongly motivated by Evan Koblentz’ (@evank) “9750 LEGO Interface A hacking challenge” announced here on EB (https://www.eurobricks.com/forum/index.php?/forums/topic/195711-a-challenge-lego-9750-interface-a-hacking/), I wandered into the Atari ST world, looking at the ST’s hard- and software for the first time in my life – never had the chance to play or work with one of these beauties back then. Found three of them in “the basement” of my research institution’s labs, and one of them worked flawlessly (the other two need a little attention, as they throw bombs when booting up). Executive summary As already briefly “announced” in the referenced challenge thread: I managed to get the Atari’s “a-bit-special” 8-bit parallel port (it is fully bi-directional, but has only two control lines, strobe, STR#, and BUSY) with the help of just one (ancient) 74LS273 TTL chip, some resistors, and a 5V power supply, to operate the 9750 LEGO Interface A from 1986/7. This is a brief write-up of how I found out how the I/O hardware protocol of the Atari ST works, when using GFA BASIC 3.0 as programming language (1988). GFA program(s) and interface schematic are here: https://bricksafe.com/pages/Toastie/atari-st-and-9750. Video to follow, I am running a little short of time at the moment. Here we go, another long vintage LEGO story … According to the three challenge rules, Evan posted in the above referenced thread, namely Use any computer and any programming language you like, as long as it was for sale in 1992 or earlier (as the next-generation 9751 / Interface B debuted in 1993.) Don't use any add-on hardware that was not available back then. A breadboard is fine; an Arduino is unacceptable. It's okay to run emulators if you do not have original machines, but you can't use any additional features that did not exist back then. You can use Windows 1.0 or 2.0, but not 3.1 libraries, etc. I became very happy after reading that, as an Atari ST qualifies as a legit computer system in this challenge! My ST is from 1987 - and it features a parallel port - which gave me hopes that I can probably get this >68000 CPU loaded 32-bit power machine< (running at 8 MHz CPU clock speed with 1Mbyte of RAM available!) to controlling the 9750 LEGO Interface A. As Arduinos and the like are not allowed for interfacing, nor using any hard/software produced after 1992, I was dreaming of TTL world, as I did when I was more than 35 years younger. What did I have at my disposal for coming up with an Atari interface (that also met the three rules of the challenge)? An Atari 1040 ST(FM) (1987) with parallel and serial port GFA BASIC 3.0 (1988) with access to serial, parallel, and MIDI ports A good number of TTL chips saved from being trashed; they all date back from the 1980’s Soldering gear, an oscilloscope, multi-meter, bread board, resisitors, LED's … I began initial programming using the ST’s serial port. After all, I first had to learn GFA BASIC, and how GEM works, and so on, and so on. Never used an Atari before June 2023. I more or less “copied” (well typed in) my working DOS QuickBasic routines controlling 9750 on an IBM XT (https://bricksafe.com/pages/Toastie/lego-interface-a---9750---9771---tclogo/program-files-) into GFA BASIC – with – “some” limited success. The thing is, the Atari’s serial port has I/O buffers; the IBM XT has not. When garbage accumulates in these buffers, my Arduino “protocol” is seriously screwed up. This “protocol” does this: Send a byte to the Arduino over serial (RS232) or UBS and then immediately listen to the reply. After conversion to parallel on the Arduino, the sent byte sets the 6 outputs of 9750; the Arduino replies back the output states of 9750 in addition to the two sensor input states. This is the protocol (send and immediately receive one byte) TLG used on the IBM XT with the LEGO 9771 interface card as well, and (I believe) on all other LEGO endorsed platforms also. It turned out that the two GFA BASIC functions "boolean=OUT?(port,byte)" and "boolean=INP?(port)", which are replying the status of the ports as FALSE=busy or TRUE=available, did not really work as expected using the serial port (AUX: or “1” in GFA BASIC). In a hardwired “client/server” setting (client=Atari, server=Arduino), it is all about initialization. Once that is done, nothing much can disturb the communication other than programming errors. In other words: Whatever garbage is in the serial out buffer upon startup: just dump that. Then do the “LEGO style initialization process”: OUT 1,bin0010101; var=INP(1); IF var AND bin0011111=bin0010101 then hardware is present and works. And that worked very well on the Atari; 9750 was controllable with an Atari ST via its serial port with the help of an Arduino Nano as serial2parallel converter. SUCCESS!!! BUT, BUT, BUT: CHALLENGE RULE #2 says: Don't use any add-on hardware that was not available back then. A breadboard is fine; an Arduino is unacceptable. !BUSTED! Well, back to the drawing board. Atari forums and other websites note: The parallel (LST: or “0” in GFA BASIC) port of an ST is somewhat “special”: It lacks some control lines most printer ("Centronics") ports and parallel printers featured back in the days, such as an acknowledge (ACK) line, among others. The ST’s parallel port has (only) a “strobe” (STR#) and “busy” (BUSY) control line, the eight bit D0-D7 lines, and ground. That was good enough for most 1980’s printers, so in essence all was fine … Much more importantly, you can write to AND read from the parallel port using ALL 8 DATA BITS! WOW! As there is no reason to read the 8 bits from a printer, these Atari folks had certainly something else in mind than just printing from the parallel port. Third: Data copied to the parallel port are “transient” of nature, as the Atari operating system uses the 8 in/outputs for other purposes as well, according to Atari forums. And the internet tells you: Fast parallel data exchange via the Atari parallel port possible, using special cables, protocols, hardware, and software. What to do with that rather confusing information? Not much. Well, what did help me, was getting hold of the Atari ST PCB schematics, breaking out my good old Tektronix oscilloscope, solder/crimp a 25 sub-D connector style parallel cable (using only 11 lines: STR#, D0-D7, BUSY, GND), run GFA test programs, and poke around a bit with the two oscilloscope probes ... It quickly turned out that the Atari sends out data over the parallel port when using the GFA BASIC “OUT 0,byte” command only when BUSY=LOW. That is fully in line with the early Centronics “compliance mode” protocol: Check the BUSY=LOW condition, when that is/becomes true, put data on the data bus, assert a HIGH,LOW,HIGH) strobe (STR#) pulse of some microseconds length (Atari: 100 us), on the negative STR# slope, data are clocked into the printer, which in turn asserts BUSY=H, and when ready again, asserts an ACK LOW/HIGH/LOW pulse and then pulls BUSY to LOW again. The Atari however is lacking the ACK line; if BUSY is HIGH (=device not ready, see below though! This changes later to: BUSY=HIGH=external device ready for providing data and BUSY=LOW=external device ready for accepting data), it waits some 30 seconds and tries again before eventually timing out. The schematics of the Atari ST reveal that it’s parallel port is operated bi-directionally by the Yamaha YM2149 “sound chip” – but that chip it is much more than that: It features, among other things, two 8-bit wide I/O ports, one of which is used for the Atari parallel port; STR# is provided by one line of the osecond YM2149 I/O port, BUSY is connected to input “I0” of the Atari’s 68901 multifunctional peripheral chip. Note that the BUSY line is literally “bolted” to +5V via a 1kOhm resistor – pulling it LOW (< 0.8V!) needs a solid TTL LOW signal. All lines of the two I/O ports of YM2149 are internally pulled-up HIGH; according to the YM2149 datasheet with 60kOhm minimum resistance – here a grounded 4.7kOhm resistor should be OK to get below 0.8V = TTL LOW – 2.2kOhm should be on the safe side. Next step: Testing GFA BASIC simple input/output testing routines and record changes in the STR# and BUSY lines. BUSY was clamped to LOW and repeated OUT(0,byte) write data attempts in a simple for-next loop were performed: Worked fine. The oscilloscope trace of the STR# line is depicted schematically in panel A), top trace, in the figure below. All seems to be in line with the Centronics protocol. Check! Performed INP(0) read data attempts with the same setup – but nothing happened! Program froze up immediately, no break (CTRL+ALT+SHIFT) was possible. However, simply removing the LOW clamp from BUSY and letting it “float” (well, see schematic above, it is pulled-up via 1kOhm to +5V = HIGH) reanimated the program >instantaneously< and the upper trace in panel B) was recorded when repeatedly reading the data lines with INP(0). Check! But then … … I thought “strange” … when does the presumably negative slope trigger on the STR# line for OUT (according to the Centronics protocol) “transition” to a positive slope trigger for INP? It did not make much sense. Google was also not helpful, even after hours of searching. Which left me with: Trial and error. I love trial and error. At some point, I arbitrarily connected STR# and BUSY – did not work either, program froze again up. When trying repeated OUT commands that is. As said: Deep in trial and error territory I was. However: In retrospect, this could of course not have work but revealed the following: When turning the computer on, loading GFA BASIC, running the program, the first OUT command worked, a second did not. The oscilloscope showed: Initially (STR# + BUSY) = L. And then OUT works??? What??? This means, that a >positive< slope of STR# is supposed to clocking the data into the external device! Not the negative slope, as the Centronics protocol suggests. After the first OUT command, (STR# + BUSY) = H, so a second OUT cannot work. But an INP should – and did! After that step, (STR# + BUSY) = L again, and another OUT works etc. This also means that INP reads data on a >negative< STR# slope. The trace on the oscilloscope obtained with repeated OUT/INP loops are depicted in panel C) in the figure below. At that point, the “rules” for operating a dumb device (dumb=providing/having no control lines) >bi-directionally< using the Atari’s parallel port became rather clear: STR# + BUSY = LOW on initial OUT/INP sequence. This is straight forward: Gather the status of BUSY using OUT?(0); if FALSE then BUSY is H; if so, do one byte=INP(0) and simply dump returned byte; now BUSY=L and “endless” repeated OUT/INP sequences can be done: As the OUT data are “lost” on the parallel I/O lines at some point (according to the Atari forums after a few ms), and at latest, when reading the lines with INP, they need to be latched on the >positive< slope of STR#, see above. TLG used transparent 8 bit D-FF TTL latches with tristate outputs (74LS373) on their 9771 card. This fancy approach is not possible here, as there is are no dedicated IORead# and IOWrite# lines available, there is only “one” line (STR#=BUSY) for clocking data in and reading them out. For that purpose 74LS273 is a perfect match: 8 non-transparent D-FF TTL latches, having always logical defined outputs (L or H); all logical levels at the 8 D inputs are latched with a positive TTL slope at the CLK input and immediately show up on the 8 Q outputs. A negative slope at CLK does nothing, so when reading data with INP(0), nothing happens to the 8 Q (output) states of 74LS273. As all this is securely happening “behind” an I/O chip (YM2149) and not directly on the CPU’s data bus, and as we know that there are 60kOhm pull-up resistors on each parallel port data line, we can use a dirty trick to feed-back the Q output states of 74LS273 to its D input lines via 2.2kOhm resistors: In output mode, YM2149 easily drives the D inputs of 74LS273 to H/L, even when the corresponding Q outputs are L/H; the 2.2kOhm resistors prevent any harm: The maximum current flowing, when D=H and Q=L is 5V/2.2kOhm = 2.2mA. Each output of 74LS273 as well as each output of YM2149 easily sink/source that current (BTW, 10kOhm feedback resistors don’t work, as the voltage on the D line does not drop to or below 0.8V when Q is L. The YM2149 does not know what to do with such a voltage; it simply says it is still H, as tested). This approach of using resistors within the 8 data lines between an external device that can read and write and the Atari’s parallel port as security measure is widely known in corresponding websites and forums, see for example here: http://info-coach.fr/atari/hardware/interfaces.php#if_parallel. Finally: The two sensor lines of 9750 are routed to the D inputs 6+7 of 74LS273; on each OUT/INP sequence, the corresponding Q6+Q7 data become available to the program running on the Atari: The OUT command clocks the data in, the INP function reads them in (in addition to D0 to D5). And that’s it. Here is the schematic for the “interface” (= one 74LS273 + 8 x 2.2kOhm resistors + 5V power supply, which is not that much of an “interface” …). +5V power may be obtained from the Atari main board (this is a bit on the invasive side) or from any generic +5V power supply. Shown in the schematic is a stone-old 7805 regulator, which can be fed with DC power from +7 up-to +25V, +12V recommended. The LED’s are purely optional; with them you don’t need to connect the 9750 interface A but will have the same light show ;). The 1uF/10kOhm RC combo on the RES# input of 74LS273 ensures that it does not arbitrarily “flip flop” during power up. The very old TTL “trick”, I know. Also optional – upon initializing the parallel port, all is fine. In that case, just connect RES# to +5V. And here is the tidy, very organized and (or better but ...) working breadboard version of the Atari parallel I/O interface for controlling LEGO Interface A. As far as I know such a thing does not exist - correct me if I am wrong though!!! More on programs I am using for controlling 9750 per key clicks or per “user programs” in subsequent posts in this thread. All the best, Thorsten
  4. Dear All, after I was sleeping two days over opening a thread on "an idea", I am just doing it: This thread is intended to be a (Mindful) Pub to discuss ideas/projects/wild thinking/just memories/the good ol'days/8 bit/crazy16bit/express printers printing NCC1701/PDP10/11 ... and mostly 8bit computers - controlling LEGO 4.5V/9V/12V/RC/PF/ and yes: PUp devices. Whatever comes to mind. 8bit computers are OLD. Very old. As in: You may think the chemist down the road is old, but that's just peanuts to the age of 8bit computers. We are talking true retro here. C64, Dragon 32, Oric-1, BBC Micro, ZX's, Amstrad CPCs and so on and so forth. I don't know why, but it just never "left" me. When I was 23 years old, my wife (I was studying - well - chemistry) allowed me to buy a Sinclair ZX Spectrum. And it all began. Games never ever interested me (other than cracking the "copy protection" using the disassembled machine code) - it was the hardware. And changing/adding things. Controlling periphery. I graduated with a degree in chemistry though - and all figured out is "true homebrew". It was the world of TTL, CMOS, and ECL ... and the world of 16k x 1bit chips being expensive. Just imagine: The 16k ZX Spectrum I had was ready to be upgraded to 48k. There was also a factory version of the 48k Spectrum. To make that one as cheap as possible, Sinclair used defective 64k x 1bit chips: These chips are organized in 2 banks of 32k. Upon final testing manufacturers as TI and others sold chips with one defective bank to other companies as "32k" chips. Can you believe that? Yes of course. It makes total sense! But today? Never ever. Now, the idea for this thread is: Can we control ancient or even current LEGO electronics with 8bit computers? I am working on: Let a ZX Spectrum talk to an RCX brick. Why? Because. Nothing else. It has remotely to do with LEGO bricks being around since the 1960s - and still clutching - and LEGO electronics officially appearing and disappearing even faster than fashion trends do. You may think: So what. He has the ZX IF1 featuring an RS232 port. Well. The ZX speaks (hardwired = bolted in) 1 start, 8 data, no parity, 1 stop bit. The RCX speaks (again: Hardwired into the UART) 1 start, 8 data, odd parity, 1 stop bit (Challenge 1: Parity change). And then: The LEGO IR serial tower cranks out and sucks in bytes with no protocol at blistering 2400 Baud. The ZX IF1 can't handle that: After receiving 1 byte is pulls down the CTS -> RTS line - allowing one more byte and then think about how to store that (Challenge 2: HW protocol - the tower is totally dumb). Possible solution: Arduino as translator. We'll see. This thread will not be heavily populated, I believe. And it will take time. We are talking 1980s. There are some folks here on EB though who may have something to say ... or maybe not. @dr_spock suggested the title of this thread @Duq repairs old washing machines @zephyr1934 knows how to print NCC1701 on endless paper @UltraViolet likes when an EB topic is derailed because of 8bit computing ... This is it. Don't expect a viral thread. I am old. The cool thing though is: Posting here after ... let's say a year or so of silence will not get the moderators mad, as it is designed to be a repository All the best, Thorsten P.S.: Just for those who were born 2000(+) : k stands for kilo. A 16k x 1 RAM is a chip that holds 16384 bit (0/1). You needed 8 to get 16kByte RAM. Today, a 16G x 8bit DDR3 DIMM module, which holds about 1 million times more bytes, sells for about the same price as 16kByte cost in 1982. In other words: 1 bit then was 1.000.000 times more expensive than 1 bit is now, 40 years later.