Then I worked out a simple serial bit twiddling scheme to exchange bytes a bit at a time and coded it up in C as a kind of software serial port. On the PC side I ended up with something that looked just like a simple terminal that happened to talk out the printer port. On the Mephisto side, I replaced the 64K byte EPROM with a 128K byte EPROM. I changed the cold boot vector to point at "my" 64K, which first checked to see if the printer port was hooked up. If it was hooked up, then the CPU stayed in "my" area and ran a monitor I had coded up for the occasion. If it wasn't hooked up it vectored back to the original boot code and the chess computer worked as well as it ever did. I layered a loader on top of everything and enjoyed loading simple cross compiled C programs on my new 68K computer, (complete with 16K RAM).
Now I was young and dumb at the time, and I had decided for some reason to jokingly call the simple bit bashing communication protocol I'd invented to talk to my chess computer "V.69" (The V series protocols - eg V.24 = RS-232 in the USA were big at the time). A V.69 port had actually made it into the final schematics for our board. It was just 5 logic level pins (two inputs two outputs plus ground) - and in production it would not have any impact - but it was possible to solder a 5 pin header onto the pins, and hook it up to a PC running the same terminal software previously discussed - If such a PC was connected my embedded code would emit diagnostic information.
We had many meetings during our visit, with the typically gruff non-nonsense Dutch engineers and their huge vats of extraordinarily strong coffee. One of them was with "the Standards guy" who wanted to audit compliance to all possible standards - I was able to spectate mainly as it was hardware stuff. But suddenly he was pointing at the V.69 connector, clearly labelled as such. We'd forgotten all about it. Us> "Oh well, arrrgh, yes. It's a diagnostic port - for the lab only - no impact on production - the header is just omitted." Him> "But what is this V.69 standard?". Us (hopefully)> "Well, it's just a 5v serial diagnostics standard". Him> "Okay, yes I've heard of it". So as is often the case, the need to save face saved the day.
The scary part is that most departments in Philips still prefer heavy processes over progress. I, for one, didn't last more than 6 weeks there.
I miss those days as well. It's a lot easier to repurpose things made out of through-hole mounted 7400 series logic than all the custom surface mounted stuff you see today.
On the flip side, though, back then to make your own boards you had to shell out thousands of dollars for the software and more thousands for a prototype run.
It does make me wonder what made you go all of this instead of doing that? It obviously wasn't just your need to program on an M68k. I think you are more of a hardware genius than you want to let on. Either that or you are just good at everything.
Like you, I cut my teeth in the 80's .. never trust a coder with a screwdriver, amiright .. but it seems that a rejuvenation of this ethos is upon us, with the Arduino and Maker crowd producing plenty of young developers who know how to burn their fingers ..
Progress giveth, progress taketh away.
Edit: Or get something from a different vendor, since as mentioned below, FTDI now has a track record of punishing their legit customers for the existence of knockoff chips.
Those have awful latency so bitbanging is less efficient.
> FTDI now has a track record of punishing their legit customers for the existence of knockoff chips.
At least they only bricked the knockoffs.
Prolific simply disabled support for their older, widely counterfeited PL2303HXA chips in Windows 8+. The same driver binary loaded under W7 still supports them.
As opposed to what? Making them burst into flames in the hope of burning the person's house down? Bricking is pretty much the worst thing you can do.
Sorry for the confusion. I noticed that English speakers place "only" before the verb in such sentences and I'm monkeying them even though it doesn't make sense to me either ;)
So many to choose from
Plugging it in USB and using like a GPIO is there. Two way communication is there.
Looks like it's become the "mainstream" implementation since last time I looked.
Honestly, I don't see much gain in using something like this in "production". After you hack something together, carrying a PC around with it isn't comfortable.
It may be useful for prototyping, but the arduino IDE is pretty good by itself. I have never actually needed a GPIO firmware. But it's there.
 In my 3D printer, that I really couldn't get away with it, I plugged a rPI with a wifi module so it can stay far away. I have a project where I will need a PCIe bus, this one bothers me.
Having a separate microcontroller has its uses too, of course. Like you said, it certainly packages smaller. Plus, you can get much more reliable timing. I'm currently helping a friend with an antenna rotator project, and that requires some brains right at the motor/encoder unit. For that I've written some software to reliably send control data packets back and forth, which is necessary but adds quite a bit of complexity.
We are living in a golden age of hardware hacking. Modern computers aren't particularly amiable to bare-metal programming, but we have truly incredible microcontrollers available at very low cost. We also have excellent gratis and libre toolchains for microcontroller development.
Once you have a little experience working with microcontrollers, you realise the incredible possibilities available to us today. The ZX Spectrums and C64s we loved haven't gone away, they've just turned into tiny chips that cost less than a newspaper.
> I made a PCB that fits into a standard D-Sub 25 connector housing with a micro USB port where the cable usually comes out
The future is mobile!
This is how I also learned that dirt-cheap PC motherboards still have parallel ports built in. The higher-end ones generally don't.
I think the reason is that some boards have various non-maskable system interrupts that will play hell with your timing if you get the wrong board.
grbl or similar (Machinekit on a beaglebone) seem like reasonable alternatives for motion control, but I'd prefer the flexibility that having a full PC gives you...just without needing a whole PC (and probably needing a few PCI parallel expanders to handle all teh other GPIO you need)
I am here thinking what sort of thing I should build and hook up to it, just because I can
You could plug in a VT10x or a similar dumb terminal in your brand new PC :)
When they did so, do you think they came to terms with why that line of reasoning was wrong and should be given a second chance or were their reactions purely reactionary?
A huge percentage of their chips are used specifically for software integrity validation (aka 'security dongle') - that has to warp their threat modeling.
Instead of bricking fake chips, the latest FTDI drivers
will inject garbage data into a circuit.
Whenever I see a board that uses an FTDI replacement chip, I smile. And I see a lot more of these as time goes on.
What I can tell you however is it's a "Typical Application" in a few of their products (FT245R, UM232R, MM232R), FTDI comes up in trusted computing chip vendor discussions, and they go so far as to provide reference designs  which is enough to infer it's non-trivial.
While I don't have any love lost for them, they do have a USB-to-Parallel chip which could have saved the author a lot of work .
 http://www.eetimes.com/document.asp?doc_id=1251578 & https://www.bertin-it.com/brochure/WP-BadUSB_an-unpatchable-...
Also worth checking out are MCC's USB data acquisition devices, which have open source drivers and provide digital IO and high speed differential analog inputs: http://www.mccdaq.com/usb-data-acquisition/USB-1208FS-LS-140...
On the other hand, I recently got a few USB based I/O boxes from NI where no documentation on the USB protocol (or, god forbid, even open source drivers) exist.
Using this converter would require the software running on the PI to be aware the intelligent circutry and either have driver support for it, or operate at a low enough throughput to bitbang in userspace.
My favourite use of the Beaglebone Black so far is as the core of Bela:
It's fairly straightforward to check if you're going to need a level shifter, takes seconds to check voltage with a multimeter.
(Still got mine.)
I remember building a link cable for my TI-89, NES and SNES controller adapters, a programming cable for a radio shack universal remote, AVR programmers, and other things.
It's a really simple circuit, and pushing stuff out the parallel port was also really easy.
Did you even skim the article? Not only did he identify a painpoint (whether or not you feel it, he did), but he wrote a solution, took the PCB to production, and open sourced the whole thing. That's the exact opposite of most of the tech articles which sit around and complain about the lack of solution.
Hey OP, way to go man. Setup a Patreon, and I'll throw a tenner your way just to see what you come up with next. Like AvE, mikeselectricstuff, SpritesMods, you're a "do-er" and I'm sure whatever you do will be mighty interesting.
I can control a bunch of LPT-attached LEDs with two lines of shell script or bitbang SPI/1W/whatever with a screenful of C. No reason to design one-off PCBs and make those external devices "smarter" than they need to be.
There's apparently some people making usb devices for things like Mach3 and they have some links to them: http://www.cncrouterparts.com/my-computer-doesnt-have-a-para...
The timing is then offloaded to the microcontroller (in this case, the Geckodrive).
Once upon a time, the upper end of the market used expensive dedicated hardware for CNC motion control. The low end of the market used commodity PCs ruining the signals out the parallel port.
Nowadays, the high end of the market is using PCs to do complex motion control (with computer vision etc) and the low end is using variants of Arduino boards with firmware like GRBL. With GRBL, the G-code itself is fed out the USB in a serial stream and the hardware does the motion calculations. Having the motion control in dedicated hardware is much nicer than having it on a PC with an operating system that can interrupt the fast timing loops and as hobby electronics gets more capable, you're going to see this set up more and more.
I wonder if this is also the case for old lab equipment that keep running one some dusty DOS box because replacing the equipment is expensive and time consuming.
USB is still one of the biggest mistake of computer hardware where a supposed simplicity for the user comes at the price of an clumsy complex unsecure spaghetti layer of abstractions in order to prevent small hardware makers to compete.
A bus should not care of the class of the device on the bus. A simple handshaking protocol with a simple fixed size identifier handled by something like IANA could be enough.
It could also be just declarative avoiding bad surprises (well I still don't understand why my computer sees 3 USB keyboard at bootup and what my devices can do). You have 1 device on the bus, you load explicitly the driver, avoiding functionalities you don't wish to work.
USB is hardly auditable, while a multi input oscilloscope is enough to see what happens on a // bus and debug analyze...
The certification process is a pain. The HW manufacturers do what they want and patch the protocol in ways that are wtf. And just look at the dozens of cable to convince yourself the U in USB is not for Universal anymore, but rather Unconsistent.
USB is almost DRM by obfuscation for the profit of shitty hardware manufacturers.
Long live to USB-C, long live to the future of computer where obsolescence is programmed every 5 years, while some electronic have a life expectancy of decades (industry, aeronautic, medical systems, expensive labs systems, weapon systems, traffic signalisation, nuclear/energy equipment)...
I would assume the reason why usb converters do not work would be due to the fact that usb uses a host controlled polling system, resulting in discrete timing that can only be as precise as the bus speed.
Just because it is on pcie doesn't mean it isn't just emulating the most frequently used parts of a parallel port.
The parallel port is actually very cool. You can take a high-end Linux machine and add the parallel port as a low latency GPIO interface with 25 pins. It can be used to control LEDs, motors, etc, and can also be used to receive sensor data, etc.
What is 'RAW' mode? I think you are referring to a legacy TCP/IP network printing protocol also known as "Port 9100." I'm not sure that's relevant to parallel ports?
However, I wouldn't be surprised if those PCI cards used the same IO port protocol, only at some different address assigned in the standard way with PCI BARs.
Also, don't forget that small FPGAs like those from Lattice Semi are very cheap these days and find a lot of use specifically in obscure IO interfacing tasks.
At least USB also works on a laptop, which is easier to put next to the console in the living room.
Somewhat. The combination of vendors sunsetting older chipsets (Prolific HX), and their reaction to counterfeit chips makes the USB-to-Serial world a huge pain in the ass.
I'm hopeful the CH340 chipset eases the pain of supporting non-tech end users with these things.
How difficult would it be to write a driver for these adapters from scratch?
But...I'll check out CP2102.
Printers speak an extremely low level protocol of "Once the printer ready pin indicates the printer is ready, load up one byte of data across 8 pins, smack a pulse out that says yo here is another valid byte, wait a bit, then repeat until you run out of data in the buffer to print". This is actually not too far from how parallel port hardware and port driver OS software worked. In practice the hardware ends up as something like 10 general purpose TTL IO ports, in fact in the REALLY old days our NON-integrated parallel printer ports used actual 8 bit latches like you'd see on memory busses from S-100 cards and stuff. Not the abstract concept of a latch but an actual TTL DIP chip like a 74LS373 or whatever printers use (I don't remember inverting or not or whatever) Newer hardware is way more complicated and "automated" and "buffered" but at some level the original PC compatible API locked down how low level it had to be and you have to be able to at least pretend you're GPIO to be "IBM PC Compatible". Standards being a great idea there are of course at least four SPP, EPP, and some others that spec'ed slightly more advanced but whatever.
So the high level protocol PLUS industry monopoly compatibility meant if you sell it as "IBM PC compatible" its gotta be able to speak at a 10+ pins of general purpose IO level.
The USB replacements do something different and appear to be printers and can no longer implement general purpose IO they implement "print a character" at the USB level not bit fiddling. I've not written a USB driver for a printer (on either side) so I'm a little fuzzy but what I've heard second hand is the USB level lives at an abstraction of "here's a packets worth of UTF-8 stream"
Note that there were weird situations for RS-232 serial where you'd synthesize signals by weird pulsing of DTR leads or CTS or whatever that can be pretty well messed up by transitioning to a USB implementation of "heres a bit stream".
I guess another way to look at it, is its easier to maintain compatibility across hardware generations for a single stream of bits so serial has it easy, whereas parallel was always a mismatch of high level byte transfer vs GPIO in the same system. The USB emulators only mass market making a printer work, not concerned about providing 10 or so pins of GPIO.
There is other fun... to a first approximation (aka its untrue) no one implemented multipoint networks on parallel ports. So latency was approximately zilch and much hardware hacking relied on that. USB of course is shared and totally non-deterministic and just maintains a long term average bandwidth. So trying to synthesize a beautiful sine wave works fine on actual hardware, not so well over a jittery USB. Its very much like the technical challenge of output sound to a local sound card vs stream VOIP across the public internet, which is really hard.
That the problem with the parallel port in a nutshell. Parallel port uses single ended ttl logic to move data. USB port or Ethernet uses a balanced twisted pair, with an impedance matched driver and it's faster.
It was a crude PCB, some wires, and a old IBM PC.
The PCB was shaped such that it fit the receivers card reader, along it was 4 lanes going from the contact pads to the other end that protruded from the reader, from there went 4 wires that was poked into specific holes in the parallel port, and then a program was fired up on the PC that did the decoding.
One side was a PCB the shape of a SmartCard, only slightly longer. The part protruding from the satellite receiver/TV decoder had a single 74hc driver on it (I think an open collector driver of some sorts to handle the half duplex, bidirectional, data pin of the smartcard interface).
My house has hot-water heating (as opposed to electric or hot air). I would occasionally observe the furnace coming on for a few seconds, then shutting down. I suspected a malfunction. So I connected the 24 v. valves that control the flow of hot water to the radiators, to relays. Each relay opened/closed a pin on the parallel port. I wrote a program to record the status of the parallel port.
I was able to determine that the furnace was coming on at the very end of a heat cycle, just when the room had reached temperature. The furnace would kick in just before the room stopped asking for heat. So it was OK after all.
I've been working with people over the years on an SNES<>PC interface. Idea being, you could dump SNES games from the cartridge port to the PC. Or you could upload hardware diagnostic/test programs (for emulator development) from the PC to the SNES, and then read back the results to the PC for analysis. Or just do crazy stuff like linking multiple SNES units together, support netplay on real hardware, download an unlimited amount of game level content, mix in audio from the PC via SNES commands, etc.
Here's the history: http://i.imgur.com/ucxVbJa.jpg
We started with the SNES controller port and used bit-banging code to a MAX232N, and connected the other serial end to a PC serial<>USB adapter. This worked out to around ~4KiB/s that we could transfer.
After that, I moved to a TTL-232R-5V cable, and spliced it directly to an SNES controller. Same speed, but a lot less bulky.
The speed killer was having to bit-bang everything. The SNES has DRAM refresh cycles that stall out the CPU for a short duration on every scanline, so that greatly impedes the maximum baud rate you can bit-bang at.
Then I found out about the Teensy, which has a synchronous UART mode. Just connect another line that you strobe when new data is available on your pin. They have software drivers that simulate USB serial UART, so you just compile that in and flash it onto the chip. This got us up to around ~30KiB/s, but that was still rather slow.
Finally, we moved on to targeting the expansion port on the bottom of the SNES. It exposes the entire 8-bit data bus. And so we connected that to an FT232H board, which has built-in 1024-byte smoothing buffers in each direction. From the SNES' perspective, it's just like a parallel port. From the PC's side, it's just like a virtual COM port. This lets us hit ~160KiB/s in both directions, and that's with code to verify data is available/can be sent from both ends of the connection on every single byte transferred either way.
The device itself is actually USB high-speed, so we could max out the SNES' 2.68MiB/s transfer rate, but we would lose the ability to ensure data or buffer space was available during DMA transfers, so it wasn't as reliable to do that.
Moving on to the Super Wild Card ... that thing is just a relic. It's unable to dump games that use the SA-1 coprocessor (Mario RPG, Kirby Super Star, etc), or memory map controllers (Star Ocean, Tengai Makyou Zero, etc), making it quite limited.
The device we've built can dump games over a USB interface. Takes about ~20 seconds a game, and can dump absolutely every game in the library. And the dumper is written in pure C/C++. About 200 lines of code to support every possible cartridge type.
When it comes to playing games, the SWC can't play anything with any coprocessors (all the aforementioned games; plus DSP games like Super Mario Kart, Pilotwings, Top Gear 3000, etc) [well, some of these copiers supported DSP-1 pass-through, not sure if the original SWC supported that or not]. On this front, the sd2snes is a vastly superior solution. You can put the entire SNES game collection onto a micro SD card, and run anything the SWC can, plus the DSP games as well.
All the same, even if it's not the optimal solution, I still give props to the author of this hack. It's definitely cool to restore these old copiers, if just for the novelty factor. I'm reminded of a guy who built his own SWC DX2 CD-ROM drive interface for loading games, because the CD drives are much less common.
I must say that your SNES<>PC interface sounds great. Do you have a website with more information?
The chips that could never work with that design would be the SA-1, SuperFX, S-DD1, SPC7110, MCC, and ICD2 (Supe Game Boy.) These coprocessors sit between the SNES bus and the ROM/RAM, but copiers can only sit between the cartridge and the bus, so you won't be able to substitute the game mask ROMs inside the cart.
> sd2snes doesn't actually support that many enhancement chips yet so I don't it's worth the investment over what I've already got.
It does all the firmware-based ones we dumped except for the ST011/ST018 (two Japanese chess games.) So that's DSP-1/1B/2/3/4, ST010, Cx4. But so far, nothing does SA-1, SuperFX, S-DD1, SPC7110. I think the sd2snes could do the latter two, but so far it does not. ikari has been working on either SA-1 or SuperFX, but I don't think it's panned out thus far. Those two are more complex individually than the entirety of an NES.
I'm not sure if it does OBC1 or not. Nobody seems to care either way about poor Metal Combat ;)
> Of course the sd2snes is a superior solution but we didn't have that 20 odd years ago when the SNES was still in its prime.
Undoubtedly. I would have killed for a parallel port copier back in '04. I spent about 5-6 years developing an emulator using a Super UFO 8.3j that I paid $250 for in '01. Every time I assembled a new hardware test, I had to run this old DOS tool to generate a valid Super UFO copier header, split the game into 1MiB chunks to fit on a series of 1-4 floppy disks. Then I had to load each floppy onto the UFO, run the test, power cycle the UFO, put another floppy in, go through the menu to copy the save RAM back to the disk, then copy that file back to the PC for analysis. It took me about 10-20 minutes (floppy disks are slow) per hardware test. And I must have done over a thousand of them.
If I weren't poor back then, I'm sure I would have tried to purchase a parallel-port copier.
The problem is that it's been so long since I've had to work extensively on the emulation core, that I'm starting to forget a lot of this stuff as well >_<
A super-picky note from the embedded developer corner: a serial port with a clock signal is not asynchronous, so the "A" in UART becomes wrong.
Peripherals capable of doing both, which are common on modern microcontrollers, are often called USARTs, which of course means universal synchronous/asynchronous receiver/transmitter. Other names for more fancy capabilities are also common.
For instance, this is the code I use to emulate it (also includes pin connection list in the comments): https://gitlab.com/higan/higan/blob/master/higan/sfc/control...
(Seems silly to emulate this device, but it allows for testing and debugging the code you want to run on real hardware.)
Because the chips that do synchronous serial IME also do asynchronous, hence USART. Which makes sense: asynchronous is a far more widely accepted and used protocol, so one chip-placement covers connecting to those devices as well.
I've been considering trying to build something using my Raspberry Pi or get into Arduinos to try and fix it, but I'm not really capable with hardware stuff.
But can I, for the life of me, find a modern SCSI adapter with ease these days - say, USB-SCSI? Nope. Its just been discarded like yesterdays cheese.
Same goes for the Parallel port. What used to be a perfectly cromulant means of wiring up some I/O for quick hacking has now been supplanted by a drawer full of Bus Pirates ..
It's for that reason I've kept around the oddities like the Castlewood Orb USB-SCSI cable and the Iomega JAZ cables. A couple of years ago I used the Orb's USB-SCSI with an external power supply to fire up an old drive and check the contents. Sometimes you just need it. Keep an eye (in the USA) on http://www.shopgoodwill.com/ sometimes these things turn up.
More info from the inventor (Hank Dietz) here: http://aggregate.org/TechPub/ICPP95/icpp95.html
kudos to the author for taking it all the way to the finish line.
Indeed. It was called "Laplink" though that was a trademark (https://en.wikipedia.org/wiki/LapLink_cable). In addition to the Laplink brand software there was Interlink which Microsoft bundled with Win95 iirc, FastLynx (FastLink? my memory is also fuzzy), and a bunch of shareware/freeware from the era (I remember simtel).
I was a field service engineer in the early 90's and carried around a six-headed parallel/serial null modem cable just for this. I also got my hands on a few of those (awful) Xircom Parallel-Ethernet adapters some time later and those were just the thing for ruining an entire day getting some awful old machine backed up onto Novell NetWare.
And I didn't know DOSBox has an emulation for those, nice!
But I have to say the article name is a little overbearing. USB serves the same purpose parallel ports originally did plus more. Yes, devices designed for the parallel port might have trouble playing with modern hardware, but you're just as likely if not more to have drivers that don't run on modern operating systems and are closed source so you can't do anything about it.