The void left by the parallel port(medium.com)
medium.com
The void left by the parallel port
https://medium.com/@tltx/the-void-left-by-the-parallel-port-51eb6c919e8a#.5wytgmtir
146 comments
The best part of this is you were able to do all that without losing your chess computer.
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.
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.
Indeed. As a software guy I was sufficiently proud of my hardware effort that I neatly organised everything as a flying lead coming out of the Mephisto complete with strain relief and a tidy professional looking connector. Not as good as a mounting the connector flush somehow, but pretty good for me. It's still in my cupboard and it still worked well (as a chess computer) last time I tried it, although after 25+ years I wonder whether the EPROM is due to start shedding bits. Trying it out as a 68K dev board is more problematic - for reasons discussed in the main article - occasionally I consider having a go but these days I usually find life is too short for those sorts of things.
Great story! The rejuvenation of your EPROM sounds like a job for a Bus Pirate!
https://en.wikipedia.org/wiki/Bus_Pirate
https://en.wikipedia.org/wiki/Bus_Pirate
That's really neat, and one of those things I wish I was able to do. I would probably just have gone out and bought an Atari ST just to get my hands on an actual computer with an M68k.
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.
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.
I think back in the day it was normal for an average young embedded software dev like myself to know my way around the basics of digital hardware. Nothing unusual about it then, maybe a little different now? Not sure. As for buying an Atari ST, it would have been quite a big purchase for me at the time. I am in New Zealand, I was probably making about $NZ30K from memory, and a computer like that would have been maybe $NZ1.5K (probably at least double whatever it cost in the US). The age of ubiquitous, super cheap consumer electronics hadn't yet arrived, especially in NZ.
>Nothing unusual about it then, maybe a little different now? Not sure.
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 ..
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 ..
There is an amusing sequel to this story actually, and no harm in telling the story after all these years. The 68K product was a proprietary networking card for a private telephone exchange type product made by Philips. After developing the product in NZ a hardware guy and I were sent to the Netherlands for final testing and further integration prior to manufacture. The Dutch engineers were very well trained and competent, but used to hugely elaborate heavy process and the more free-wheeling type of development we were used to was definitely foreign territory. Rumours that the crazy guy from New Zealand had developed the telephone switch software in his chess computer (i.e. now that I've explained the story, false rumours) preceded our arrival.
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.
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.
Hahaaha as someone from Eindhoven, where Philips did and still does most of its R&D, this is frighteningly recognizable.
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.
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.
We were working for the Telecommunications and Data Systems division in Hilversum. A tiny division by Philips standards, but huge relative to our lab in NZ.
Sure, but I bet the culture at Philips was similar :) thanks for the anecdotes! :)
Yes of course the Hilversum operation was no doubt a mini version of the huge R&D operations in Eindhoven. I did enjoy the company of the Dutch engineers. I think my phonetic Dutch pronunciation amused them. I think :)
Hrmm, small world I work for a small company in NZ that used to be part of the post office, telecom and now we're privately owned. We repair Telco equipment. I am sure one of our PABX guys would be familiar with the Philips PABX. I am on the transmission team so it's not really something I would have seen. We still have a fots and rn64 though!
Huge numbers of locally developed Philips small business exchanges were sold in the 1980s. They were pretty simple and robust, I wouldn't be surprised if there were still some in use today.
The tinkering void left by the parallel port is pretty much filled by microcontroller-based systems-on-a-chip that are smaller than the plastic casing of a parallel connector.
Progress giveth, progress taketh away.
Progress giveth, progress taketh away.
Plus, in that timeframe, FPGAs have become much cheaper and more powerful, providing tinkerers a step up from bitbanging.
Bitbanging was part of the fun. That's kinda the point most are making here.
Bitbanging hasn't gone away. If you want to write assembler on an 8-bit micro, you can do it on a $4 dev board. That board can run on AA batteries and be embedded into other projects. If you want to spin your own boards, you can get 10cm*10cm boards from China for less than a dollar.
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.
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.
Indeed:
> 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
> 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
There's still a niche for interactive hackable systems that's not really filled.
Doesn't a Raspberry Pi fill this void? Cheap, interactive GUI, and a GPIO header exposed right on the PCB.
You mean, like an Arduino?
An arduino is not interactive the way a personal computer is.
What kind of interactivity do you miss?
Plugging it in USB and using like a GPIO is there. Two way communication is there.
Plugging it in USB and using like a GPIO is there. Two way communication is there.
The ability to poke at hardware from the command prompt and easy integration of text or graphical user interface. The difference is between "my computer has a port" and "this external device has a port."
So, you mean using it like a GPIO? It's there. All it requires is loading a GPIO firmware.
Huh, so what's a good and featureful GPIO firmware? I did some searching, but it's a little hard to search for.
"Arduino as GPIO" on google leads to this:
https://github.com/BLavery/virtual-GPIO
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[1]. 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.
[1] 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.
https://github.com/BLavery/virtual-GPIO
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[1]. 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.
[1] 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.
Oh, that's a nicer one than the others I found. I see that sort of thing as being useful in situations where the PC is required anyway, like a lot of automated lab setups. You need the PC for data acquisition and analysis, and it's nice if you can control the rest of the equipment from the same program. I've used Measurement Computing's digital IO and data acquisition boards for that sort of thing.
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.
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.
There was something about typing out commands on a keyboard and sending them to a 7-segment LED array that you wired up yourself, that isn't really comparable to an Arduino.
So don't use an Arduino if that makes it too easy. Get yerself an FTDI USB-to-parallel module (http://www.ftdichip.com/Products/Modules/DevelopmentModules....) and set it to bit-bang mode, and away you go.
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.
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.
> USB-to-parallel module
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.
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.
> At least they only bricked the knockoffs.
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.
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.
As opposed to disabling the knockoffs and genuine chips.
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 ;)
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 ;)
Nah, what you said made sense, I initially read it the way you meant it, but it is ambiguous enough to read either way.
Or that the joystick ports on the Atari 400/800 were actually bidirectional and you could get a speech synth chip at radio shack and wire it up that way...
I used the bidirectional ports on the Atari 800 and C64 to cross compile for C64 because The Atari Macro Assembler was much better than anything on the C64 at the time :P
Another common use for those in the days before every modem had an auto-answer mode was to hook up a "ring detector". The ring detector would send a 5v pulse into the joystick port when the phone rang, then the BBS or terminal software would issue the necessary commands to tell the modem to answer.
My MBED has a USB port so I can use a keyboard on it. Or a ethernet.
So many to choose from
https://developer.mbed.org/platforms/
So many to choose from
https://developer.mbed.org/platforms/
This. My recent encounter in this space was a Nordic NRF51822 BLE chip bought as a 3$ breakout board from Aliexpress, wiring it via STM32 and compiling it using GCC and MBED ...and skipping over the expensive official compiler.
The future is mobile!
The future is mobile!
Props to innovating a solution. But since this is SNES related ...
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'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.
Byuu, if you wrote a book on all the SNES hacking and development you (and others) have done, I'd definitely buy it and read it. Thank you for all of your work.
I've always wanted to write a book that contained every last minutiae about the hardware titled, "Everything you never wanted to know about the SNES, thus you didn't bother to ask."
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 >_<
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 >_<
Take notes so you don't have to remember it all.
The original Super Wild Card can actually play DSP games if you have a DSP cart inserted. It's the only enhancement chip that will work with pass-through on the SWC. 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. ;) I've contemplated getting an sd2snes but my 32Mb SWC (original model, pre DX) is still working great after all these years and runs probably over 95% of available games. 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. I'll probably end up getting one when more chips are supported.
I must say that your SNES<>PC interface sounds great. Do you have a website with more information?
I must say that your SNES<>PC interface sounds great. Do you have a website with more information?
Oh awesome, so the original SWC supported DSP pass-through as well? Thought that was a SWC DX2 feature only (the 'Rolls Royce of SNES copiers.') Super UFO actually had a NEC uPD DIP socket you could connect to its mainboard for DSP-1 support.
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 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.
That is alla amazing, and very impressive. Thanks for doing it all, and sharing.
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.
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.
I always thought it should be called USRT when strictly synchronous, but indeed, everyone else called it USART, so I called it the "USART controller"
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.)
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.)
> I always thought it should be called USRT when strictly synchronous, but indeed, everyone else called it USART, so I called it the "USART controller"
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.
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 found out about the CNC thing recently while trying to get a hobbyist CNC machine set up. My immediate reaction was "Parallel ports? What is this, 1985?" Turns out, there isn't really any getting around it. It's parallel port or GTFO.
This is how I also learned that dirt-cheap PC motherboards still have parallel ports built in. The higher-end ones generally don't.
This is how I also learned that dirt-cheap PC motherboards still have parallel ports built in. The higher-end ones generally don't.
If I recall from (maybe?) the linuxCNC forums, it's also pretty crucial to ensure your motherboard has a suitable chipset if you want to do soft-steppers.
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 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)
It's not quite GTFO, but you do have to spend a lot more than the $15 it costs for an opto isolated parallel port to stepper interface board. My celeron j1900 does about 20k steps/second with low jitter on LinuxCNC
My recently purchased ASRock Z97 Extreme4 has a Serial port header...
I am here thinking what sort of thing I should build and hook up to it, just because I can
I am here thinking what sort of thing I should build and hook up to it, just because I can
Yeah, I was surprised to find out a serial connector in my brand new (2015) motherboard. The previous motherboard I had didn't have headers for serial although there probably was one or more hidden on the board.
You could plug in a VT10x or a similar dumb terminal in your brand new PC :)
You could plug in a VT10x or a similar dumb terminal in your brand new PC :)
You can get a PCIe bus parallel card on Amazon for about $10 or $15. I've got one I use for programming an older FPGA board.
Just FYI, you can now get chinese knock-offs of the USB programmer for about the same price off eBay. They're faster than the parallel cable, and they work extremely well.
Oh, yes. The great Xilinx Parallel Cable III. Still works a treat!
Get a smooth stepper. The Ethernet one works great. I too ran into the issue with parallel ports, and basically, they aren't worth it. The timing is bad, and on most computers I've encountered, there's enough noise on the port that eventually it messes up a project at some critical part and convinces you that parallel ports suck. Better to have a board designed for specific pulse timing than counting on the average CPU to be consistent.
And don't forget about the venerable FTDI FT232R chip which has the very useful "Bit Bang" mode http://www.ftdichip.com/Support/Documents/AppNotes/AN_232R-0...
I use those FT232R puppies a lot for all kinds of things that the old PP was good for, programming FPGA's, testing out a new chip or circuit before going to MCU etc. It is very simple and inexpensive, and much faster than the PP was.
Fuck FTDI.
https://www.google.com/?q=ftdi+brick
https://www.google.com/?q=ftdi+brick
It's absolutely baffling. This kind of practice is never okay, be it bricking the device(that is borderline not-okay) or injecting garbage data. I, as a consumer, don't care about your IP, I care about the goods which I buy legally, using open platforms(i.e. eBay). If the manufacturer wishes to combat IP infringement, it may do so freely by doing legal action against counterfeit chip manufacturers, but affecting a device that I bought(perhaps unknowingly) is just rude.
Oh my goodness, quite a reaction storm!
I was aware of the counterfeit issue bit I am surprised at the intensity of the reactions. As a software author I can certainly sympathize with motivation of FTDI but I also can understand the frustrations being voiced. I guess I have been lucky and not had to deal with this issue.
Changing the subject a bit, it would be great if there was a standard for gpio on all pc's.
They apologized for that and pulled the update.
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.
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.
Then they decided to break it again (albeit without bricking it):
http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips...
http://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips...
Instead of bricking fake chips, the latest FTDI drivers
will inject garbage data into a circuit.Fool me once, shame on you. Fool me twice, shame on me.
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.
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 percentage is that?
I couldn't tell you, and I apologize for being idiomatic. I found 3 out of the 30 or so chips they make with a cursory glance. So at least 10%?
What I can tell you however is it's a "Typical Application" in a few of their products (FT245R, UM232R, MM232R)[1], FTDI comes up in trusted computing chip vendor discussions[2], and they go so far as to provide reference designs [3] 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 [4].
[1] http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_...
[2] http://www.eetimes.com/document.asp?doc_id=1251578 & https://www.bertin-it.com/brochure/WP-BadUSB_an-unpatchable-...
[3] http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_...
[4] http://www.ftdichip.com/Products/ICs/FT245BM.htm
What I can tell you however is it's a "Typical Application" in a few of their products (FT245R, UM232R, MM232R)[1], FTDI comes up in trusted computing chip vendor discussions[2], and they go so far as to provide reference designs [3] 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 [4].
[1] http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_...
[2] http://www.eetimes.com/document.asp?doc_id=1251578 & https://www.bertin-it.com/brochure/WP-BadUSB_an-unpatchable-...
[3] http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_...
[4] http://www.ftdichip.com/Products/ICs/FT245BM.htm
I wonder if the counterfeit chips has this mode or not.
I remember this: the counterfeit does, and it works better, because the cloners followed the data sheet and not the errata. http://www.eevblog.com/forum/microcontrollers/ftdi-gate-2-0/...
"Venerable" oh gods, I should go check my beard for grey hairs. I used one of those when it was the cool new thing.
This reminds me of junior high and high school, making PC peripherals that used the parallel port based on schematics I found on the internet. It was a lot of fun.
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.
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.
I made a little toy resistor ladder digital to analogue convertor. I used this with NO$GB Emulator for authentically horrible sound, but you could buy commercial product - COVOX Speech Thing - so it was supported by a few commercial games too.
http://www.epanorama.net/circuits/dacs.html
It's a really simple circuit, and pushing stuff out the parallel port was also really easy.
http://www.epanorama.net/circuits/dacs.html
It's a really simple circuit, and pushing stuff out the parallel port was also really easy.
What we really need to bring back is the BeBox Geekport: http://www.hardwarebook.info/GeekPort
This gets me wondering: how close is this to, say, the Raspberry Pi GPIO connector? Could someone make a Pi-to-GeekPort converter? Would that even be practical for anything?
The Raspberry pi has 26 pins (not all of which are IO), and the geekport has 37 (again, not all of which are IO, but still has more IO ports than the Pi). This means that a full converter would require some intelligent circuitry to multiplex the PI's GPIOs. The bigger problem is that the geek port has some 12V pins, and analog pins, neither of which the Pi supports. Again, this can be solved with some circuitry in the converter.
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.
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.
Could use the Beaglebone Black, it's has more than enough GPIO pins and has dedicated coprocessors for bitbanging, which improves throughput and latency.
http://kilobaser.com/blog/2014-07-15-beaglebone-black-gpios
http://hackaday.com/2014/06/22/an-introduction-to-the-beagle...
My favourite use of the Beaglebone Black so far is as the core of Bela:
https://www.kickstarter.com/projects/423153472/bela-an-embed...
http://kilobaser.com/blog/2014-07-15-beaglebone-black-gpios
http://hackaday.com/2014/06/22/an-introduction-to-the-beagle...
My favourite use of the Beaglebone Black so far is as the core of Bela:
https://www.kickstarter.com/projects/423153472/bela-an-embed...
Think with the BBB you have to be super careful with those GPIO pins (more so than the RPi apparently) - have heard of people having fried their Beagle as a result of a tiny mistake.
The GPIO pins on the BBB are 3.3V tolerant, but not 5V tolerant like the Arduino. RPis GPIO has the same power constraints as the BBB (3.3V tolerant, but not 5V tolerant).
It's fairly straightforward to check if you're going to need a level shifter, takes seconds to check voltage with a multimeter.
It's fairly straightforward to check if you're going to need a level shifter, takes seconds to check voltage with a multimeter.
Only the first two RPi models (A and B) have 26 pins. The later ones (A+, B+, 2B, Zero, 3B) have 40 pins.
You can buy a USB to GPIO (general purpose IO) adapter for under $15. Here is an example: [1]
[1] https://www.adafruit.com/products/2264
[1] https://www.adafruit.com/products/2264
National Instruments make some nice little IO cards that can provide GPIO and analog functions.
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...
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...
The NI stuff, in my opinion, is an over engineered mess, designed to force you into using LabView and really don't work with anything except their proprietary windows driver architecture.
Well, that rings true for a lot of my experience with NI, but my recommendation was based on writing a linux driver for one of the NI digital IO cards in a university class. I figured if we could do it in that class, maybe they're not all that bad?
So... I also used PCI based NI (Digital/Analog I/O) cards in the past (around the year ~2000), which then were supported by "comedi" (open source linux data acquisition drivers).
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.
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.
Or just bring back the BeBox. :)
(Still got mine.)
(Still got mine.)
I think this article explains pretty well why we don't need a parallel port anymore. Rather than outfitting every computer with a complicated and slow port we can have faster, smaller, and more flexible solutions using extra processors in our devices. While I appreciate the ability to control so many IO lines directly I just don't really see the use case anymore and this comes from someone who went down the whole design a new CNC controller because the old one used parallel. No-one ever designs new hardware anymore and bemoans the lack of parallel port that would make their job easier. The void is only legacy hardware that is difficult to use these days.
>> No-one ever designs new hardware anymore and bemoans the lack of parallel port that would make their job easier.
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.
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.
Like I said, I understand the pain of interfacing with legacy hardware but I thought his solution demonstrated perfectly why we don't need a parallel port any more. I didn't mean to imply that OP was complaining about the lack of a parallel port and I enjoyed his post very much.
Two issues you are completely ignoring are "barrier to entry" and "PITA factor".
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.
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.
Kirrent said "new hardware", the one in the article is 20-ish years old.
So why do those "cheap USB to parallel port converters" only work with printers?
Timing mostly. These kinds of devices are using the parallel port to "bitbang" everything. Because of that they need rather precise control of timing in order for things to happen when they expect. The USB devices usually just let you send a stream of bytes and they go out without much control over how fast they change.
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...
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...
I used a Geckodrive controller to connect via USB to the interface I needed to drive three stepper motors (and speed control for the drill motor) for the CNC mill I built. Works natively with Mach3.
The timing is then offloaded to the microcontroller (in this case, the Geckodrive).
http://www.geckodrive.com/geckodrive-step-motor-drives/g540....
The timing is then offloaded to the microcontroller (in this case, the Geckodrive).
http://www.geckodrive.com/geckodrive-step-motor-drives/g540....
That Geckodrive product appears to connect via a standard parallel port. I don't believe Geckodrive has a USB breakout board. You're possibly using the SmoothStepper from Warp9, the KFLOP board from Dynomotion, or one of a couple of Chinese products of widely varying quality.
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.
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.
> having it on a PC with an operating system that can interrupt the fast timing loops
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.
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.
Its more than that, most of the things that utilize the parallel port talked to the IO ports directly for the bit banging. The USB->parallel ones hide the parallel interface behind the windows/etc parallel port driver so that provides an additional roadblock for the old software which otherwise might work.
Another reason a long time ago was that you could control the built-in port's I/O lines directly by writing to a legacy IO port with a single assembly instruction. Any code written that way would not work with the USB adapters.
[deleted]
They have ieee1284 printer-port protocol baked into them, so you do an OUT transaction of several bytes and the adapter does the per-byte handshaking. The old parallel ports were just a collection of gpio lines (originally some input-only and some output-only, later some turned bidirectional) connected to some io addresses.
because USB is serial, and parallel is parallel.
So every bytes has to be sent in parallel after you made sure you signal correctly they are ready the direction of communication...
So, it makes a lot of trouble.
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)...
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)...
What about just installing a parallel port on your computer? http://www.amazon.com/StarTech-com-Express-Profile-Parallel-...
And miss all the fun hacking a custom solution? ;-)
At least USB also works on a laptop, which is easier to put next to the console in the living room.
At least USB also works on a laptop, which is easier to put next to the console in the living room.
That will likely suffer from the same drawbacks as 'installing' a parallel port via USB. You still lack the timing precision required to bitbang out many of these protocols.
Shouldn't the PCIe bus fix that problem?
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.
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.
I think the timing problems are caused by the USB protocol. A PCI parallel port shouldn't suffer from those problems. (I think they were originally connected over the ISA bus, with the ISA controller connected to the PCI bus once that was introduced.)
USB latency is generally 0.25ms. PCI-Express latency is around 250ns. That's three orders of magnitude lower. I'm not sure how you can say that this will suffer from the same problem.
I'd wager the device hanging off the PCIe bus looks very little like a traditional parallel port to the CPU. Notice the modes supported by the device don't mention 'RAW', and a number of reviews bitch about ECP not working.
Just because it is on pcie doesn't mean it isn't just emulating the most frequently used parts of a parallel port.
Just because it is on pcie doesn't mean it isn't just emulating the most frequently used parts of a parallel port.
I have successfully used a StarTech PCIe parallel port adapter card to interface with a stepper motor controller board, and I'm able to run CNC machining operations from LinuxCNC. It works fine in EPP mode (communicating bi-directionally).
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?
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?
By 'RAW', I mean being able to drive the port by poking at 0x378 in a highly controlled manner. (Not terribly uncommon when the hardware in the article was originally released)
This has been my experience when trying to interface with some legacy LPT stuff, much of the software of the era is basically hard coded to do that and won't play well with (or sometimes even recognise) the PCIe add on ports. YMMV, clearly.
0x378 is probably routed to the onboard LPT by the BIOS.
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.
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.
My first PC had the parallel and serial ports connected to an isa card instead of the motherboard, I don't immediately see why a pci version would be any different.
This product may be shit, but the concept is sound. There is a direct compatibility line from pcie all the way back to isa, so it is in theory possible to build pcie peripherals that will work in dos provided your bios supports this.
For obscure things like this its cheaper to chain more common components together through an intermediate protocol. So your PCIe adapter may well be an on-board PCIe USB host -> parallel port controller, done with off the shelf ICs. This prevents the need for a custom ASIC which is unlikely to be economical here.
This is sometimes the case, but the most popular cards on the market are indeed single chip ASIC solutions.
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.
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.
I swear, Startech sells just about anything ports related.
I fondly remember a university project where we made an mp3 player - hardware based around an Intermetall (MAS) chip and the software to drive it. This was late 90's and the run of the mill 486 struggled to play 256kbps mp3's. I designed an interface around a PAL chip that received nibbles from the parallel port and serially sent them to the decoder chip. The program to parse the mp3 and bit-bang the parallel port I wrote in Turbo Pascal, and it actually did an amazing job, up to 320kbps mp3 could be played. Fun fact: the PAL originally couldn't quite keep up, so I had to increase the supply voltage (as well as the clock voltage level) and attach a heatsink to it!
This is a cool hack, but I think the article would benefit from a deeper explanation of why "USB to serial" worked and "USB to parallel" would not.
>> "USB to serial" worked
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.
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.
CH340 has no practical Mac support last I tried. Try CP2102, works great and cheap too.
Oh boy - looks like the same kinds of problems that happened when Microsoft started enforcing driver signing. https://tzapu.com/making-ch340-ch341-serial-adapters-work-un...
How difficult would it be to write a driver for these adapters from scratch?
How difficult would it be to write a driver for these adapters from scratch?
Signed drivers for OSX do exist now: http://blog.sengotta.net/signed-mac-os-driver-for-winchiphea...
But...I'll check out CP2102.
But...I'll check out CP2102.
USB to serial worked because he could do larger transfers of data to the AVR which would then do low latency byte by byte writes to the device when polled.
Here comes a mostly true simplification.
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.
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.
I remember a tidbit that shows the nature of the problem. Was an old standard bus interface (forget which) You have huge edge connectors with 32 bits of address, 32 bits of data, control lines, interrupt lines, power etc. Later two unused pins were repurposed as a balanced bi-directional serial bus. Which could move data faster than the normal memory bus.
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.
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.
One of the most intriguing uses of a parallel port i have seen was back in the early days of digital sat coding.
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.
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.
I think you are referring to a “Season 7” interface by which a PC could emulate a smart card for pay TV encryption.
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).
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).
The parallel port was really neat. I once connected my furnace to a PC, to track when the thermostats were opening the hot-water valves.
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.
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'm having the exact same problem with my Atari Jaguar, modified to use BJL (Behind Jaggy Lines), which is a replacement ROM chip that lets you upload games directly to the Jaguar's RAM using a Parallel cable plugged into the second controller port. New PCs don't have a Parallel port and the USB adaptors don't work :(
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.
http://jaguar.linkovitch.me.uk.s3.mytilde.co.uk/bjl/about.ht...
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.
http://jaguar.linkovitch.me.uk.s3.mytilde.co.uk/bjl/about.ht...
One of the coolest class projects I worked on in school back in the mid 90's was a compiler for TTL_PAPERS, which was a hardware-assisted low-latency interconnect between PCs used for barrier synchronization. It was also correspondingly low bandwidth, but for the cases where synchronization was your bottleneck, it was hard to beat it.
More info from the inventor (Hank Dietz) here: http://aggregate.org/TechPub/ICPP95/icpp95.html
More info from the inventor (Hank Dietz) here: http://aggregate.org/TechPub/ICPP95/icpp95.html
i love stories like this.
kudos to the author for taking it all the way to the finish line.
kudos to the author for taking it all the way to the finish line.
I miss the 9-pin joystick ports more than the parallel ports. I hooked a photocell to the paddle pins on one and had a huge amount of fun. I remember Be had a huge port on the BeBox for hacking.
It was called the geek port. I never had one but read a ton about them back in the late 90s. I was a true BeOS fanboy back then and tried my hardest to run it as my primary OS. I usually ended up back in Windows 2k sadly.
Ah, the pre-USB interfaces. The most fun I had was figuring out how to read the input from an old shipping scale which had serial port output. That powered my keg monitoring server, which I eventually wrote mobile apps for. It was the best side project I've worked on!
Now add a SD card slot and you could load all games you ever owned from it without a computer.
I have a rather faded memory of using a parallel port to transfer files between our old 386 computer and the shiny, new, Pentium that replaced it ... much faster than using floppy disks and this was before everything came with an ethernet port!
> I have a rather faded memory of using a parallel port to transfer files
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.
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.
Whoever is interested in buying one: https://aisler.net/tltx/swc_usb/swc_usb
[deleted]
Man we were proud when we soldered our own Covox DACs for the LPT; Our MODs sure sounded awesome on those :)
And I didn't know DOSBox has an emulation for those, nice!
And I didn't know DOSBox has an emulation for those, nice!
I thought this was going to be about the space where a parallel port used to be on the back of your computer. Was I disappointed.
I feel like PCI and ISA have left holes as well. PCI/e is a fiendishly difficult protocol
I'm really bummed at how quickly perfectly working and valid technologies just get discarded when the new hot stuff comes out .. take, for example, SCSI. SCSI was ubiquitous in computing, its everywhere. I have a 19" case full of perfectly working drives.
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 ..
Meh.
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 ..
Meh.
> USB-SCSI? Nope. Its just been discarded like yesterdays cheese.
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.
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.
Ebay has dozens of them, although the prices are outrageous. I even see the adaptec usb->scsi converter I had a few years ago. The problem with them is that there compatibility seems pretty limited, especially if you try to attach an old scanner, tape drive, etc.
Definitely an interesting story, and I'm loving the other ones that come up in this comment thread.
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.
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.
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).