Jump to content

pi2iec (was: piMultIEC)


Recommended Posts

We know that it is possible to emulate a 1541 with a Raspberry Pi, and that's an awesome project. Emulation is being worked on for 1571 & 1581 as well (or is already available, I can't tell for sure). It may support other formats, and that's great. But I have an idea...

What about a device that doesn't try to emulate exact pieces of hardware, but just provides mass storage on some device number, not unlike CMD or other brand of Commodore hard drive. Say it is device 11. It can load, save, do all the normal things you'd expect to be able to do with a disk drive, along with useful extensions to seek into files, and even create a sort of REL file that would be backed by a SQLite database instead of being traditional block based. It could provide typical REL compatibility and some sort of extended functionality to do more, like access records by a magic file name that could be loaded and saved. In fact, that's how I'd imagine "plain old PRG/SEQ/etc" files would be stored in the system.

And what if that device also responded on device 4 to provide access to a printer connected on that Raspberry Pi?

Device 6 I believe was the number used by the 1520 plotter. Maybe one could access a plotter the same way (not that I see a lot of people with plotters). Alternatively, it could emulate the plotter and render it to the printer.

Device 5 is typically another printer as far as I know. What if that device gave you access to the Raspberry Pi's HDMI display via IEC? It would not be *fast* but could be useful for text debug output. It doesn't have to send full 1920 x 1080 bitmaps, though I suppose it could. It'd be slow, but possible. Control codes could be used to define a virtual size of text mode or bitmap mode.

Device 7 could be the same as device 5, but it would use the HDMI display for rendering vector graphics. Effectively a video plotter.

I believe the Raspberry Pi would have more than enough power to do all these things if it wasn't trying to spend all its time being a cycle exact 1541.

Being serial IEC based, it could be used with a VIC 20, C64, C16, Plus/4, C128, or even the upcoming MEGA65 and of course Commander X16. It would not be blazing fast, but it's intended to provide access to slow memory constrained devices anyway, so I don't see that as a huge deficit in most scenarios.

How crazy is this? What should be discarded as stupid? What didn't I think of in the list above?

Edited by Scott Robison
  • Like 4
Link to comment
Share on other sites

It's actually not a bad idea. Really, it would be a perfect job for the new Pi Zero 2, which is plenty powerful enough to achieve this functionality using Raspberry Pi OS Lite and some shell scripts. If you made a simple circuit board to plug the Pi02 into then you could have it fit into one of those standard hobby boxes with circuit board front/back panels (like the Colour Maximite 2). Stick an IEC port for the input from a Commodore machine and then outputs for USB, Parallel Port (whatever type(s) for vintage and current dot matrix printers), and perhaps an SD card slot on the front using one of those ribbon cable extender things, and a power switch.

Functionally, I think it might be faster to have all of the input from the C= machine be written directly to files and then make use of listener scripts on the Pi that act upon the discovery of new files. For instance, "printing" to device 5 would put the new.pdf file in /var/c5/ and the script would automatically copy it to /var/c5/[DATE]-###.pdf and then display it on the HDMI screen. Printing to device 8 would do the same, but then send it to the configured printer rather than the screen (though it could be set up to email it, view it, upload it to a web server, whatever).

Lots of possibilities there and none of it would require much processing power. Could probably do it with an original Pi Zero.

 

  • Like 2
Link to comment
Share on other sites

I was thinking a bare metal approach rather than a full OS, but otherwise I agree with the "everything is a file" approach.

It could also support networking (slow but potentially really helpful on something like Commander X16 that would work with an existing CBM 8 bit standard.

It could also provide a build server or other similar type of processing. Edit text on your 8-bit system, save it to the device, kicks off a script to assemble/compile/whatever, then you can load the generated PRG file.

  • Like 1
Link to comment
Share on other sites

The build server is a neat idea. Program on the retro machine in a retro IDE, but pass off the compilation work to the "mainframe". Funny how that workflow is still in use today, yet it is decidedly retro nonetheless.

Internet pass through over IEC might be slow, but there's nothing stopping you from using the userport like other networking cards for C64/128.

Maybe it would make sense as to build the whole thing as a funky, huge userport cartridge. That would have the benefit of allowing one to use the cartridge slot for normal cart software or something like the Final Cartridge III or the like, unlike the Ultimate II cart. It would also look awesome, like a Neo Geo arcade cart with ports.

Edited by Tatwi
  • Like 1
Link to comment
Share on other sites

On 11/18/2021 at 8:10 PM, Tatwi said:

The build server is a neat idea. Program on the retro machine in a retro IDE, but pass off the compilation work to the "mainframe". Funny how that workflow is still in use today, yet it is decidedly retro nonetheless.

Internet pass through over IEC might be slow, but there's nothing stopping you from using the userport like other networking cards for C64/128.

Maybe it would make sense as to build the whole thing as a funky, huge userport cartridge. That would have the benefit of allowing one to use the cartridge slot for normal cart software or something like the Final Cartridge III or the like, unlike the Ultimate II cart. It would also look awesome, like a Neo Geo arcade cart with ports.

The reason I was thinking IEC is that that is the common port on all the machines listed above. I think Commander X16 is supposed to have one, but no user port per se (though the hardware isn't 100% settled yet). C16 doesn't have a user port, and I happen to have a C16. MEGA65 doesn't have a user port either (though it does have other interesting ports in lieu of networking, like it's own ethernet). I know there are differences with the various user ports on some machines that do have them. David described in his last video the effort it took to get the SNES controllers working on Plus/4 because it wasn't compatible.

In theory, an IEC device could work with all those computers, perhaps needing a little tweaking of the timing like the 1541 did vs 1540 when C64 was released.

I agree that IEC would not be as fast as other solutions, but I expect it could be a very affordable option for people still hanging onto their old machines but maybe don't have the resources to pay for multiple bits of hardware to bring their retro computers into the 21st century.
 

Link to comment
Share on other sites

  • Super Administrators
On 11/17/2021 at 9:13 PM, Scott Robison said:

We know that it is possible to emulate a 1541 with a Raspberry Pi, and that's an awesome project. Emulation is being worked on for 1571 & 1581 as well (or is already available, I can't tell for sure). It may support other formats, and that's great. But I have an idea...

What about a device that doesn't try to emulate exact pieces of hardware, but just provides mass storage on some device number, not unlike CMD or other brand of Commodore hard drive. Say it is device 11. It can load, save, do all the normal things you'd expect to be able to do with a disk drive, along with useful extensions to seek into files, and even create a sort of REL file that would be backed by a SQLite database instead of being traditional block based. It could provide typical REL compatibility and some sort of extended functionality to do more, like access records by a magic file name that could be loaded and saved. In fact, that's how I'd imagine "plain old PRG/SEQ/etc" files would be stored in the system.

And what if that device also responded on device 4 to provide access to a printer connected on that Raspberry Pi?

Device 6 I believe was the number used by the 1520 plotter. Maybe one could access a plotter the same way (not that I see a lot of people with plotters). Alternatively, it could emulate the plotter and render it to the printer.

Device 5 is typically another printer as far as I know. What if that device gave you access to the Raspberry Pi's HDMI display via IEC? It would not be *fast* but could be useful for text debug output. It doesn't have to send full 1920 x 1080 bitmaps, though I suppose it could. It'd be slow, but possible. Control codes could be used to define a virtual size of text mode or bitmap mode.

Device 7 could be the same as device 5, but it would use the HDMI display for rendering vector graphics. Effectively a video plotter.

I believe the Raspberry Pi would have more than enough power to do all these things if it wasn't trying to spend all its time being a cycle exact 1541.

Being serial IEC based, it could be used with a VIC 20, C64, C16, Plus/4, C128, or even the upcoming MEGA65 and of course Commander X16. It would not be blazing fast, but it's intended to provide access to slow memory constrained devices anyway, so I don't see that as a huge deficit in most scenarios.

How crazy is this? What should be discarded as stupid? What didn't I think of in the list above?

You're basically just re-hashing the User Port device I've been looking into. My system would have provided UARTs, network connectivity, and even a second screen for the Commander. I put it on the back burner for now, but it's certainly possible to do the same thing through the IEC port, rather than the User port. After all, they're both basically the same thing: just pins connected to the VIAs. The only difference is that the IEC port only has 3 data lines connected straight through to the VIA, where the User port has something like 12.

I don't see any reason not to build something this... the only catch is you'd need to run under a bare metal OS to drive the GPIO pins reliably enough and fast enough to be useful. 

  • Like 2
Link to comment
Share on other sites

On 11/19/2021 at 12:05 AM, TomXP411 said:

You're basically just re-hashing the User Port device I've been looking into. My system would have provided UARTs, network connectivity, and even a second screen for the Commander. I put it on the back burner for now, but it's certainly possible to do the same thing through the IEC port, rather than the User port. After all, they're both basically the same thing: just pins connected to the VIAs. The only difference is that the IEC port only has 3 data lines connected straight through to the VIA, where the User port has something like 12.

I don't see any reason not to build something this... the only catch is you'd need to run under a bare metal OS to drive the GPIO pins reliably enough and fast enough to be useful. 

Right, there are other approaches that are "better" in multiple ways. The unique parts of this are repurposing the serial IEC bus for some tasks it's never been used for previously (as far as I know) and having a single smart device behave as multiple individual devices.

I concur on the need for a bare metal system for this. Serial IEC timing is precise. But it could also implement something like burst mode or fast loaders for accelerated IO. Out of the metaphorical box it should Just Work(TM) with any system with a working serial IEC, allowing BASIC and the kernal to open channels, write, read, and close, load, verify, and save. Disk drive, printers, and plotter functionality could just emulate the command, control, and data interfaces so that it is immediately useful without a need for custom programming on each system. A networking interface could emulate RS232 at that same level. The system could also provide access to other devices. I've already discussed HDMI output. It could allow reading from a USB keyboard, or a camera at a low bandwidth, digital audio input via a mic. And it could have a meta device (sorry Zuckerberg) that allows for command and control of the overall puMultIEC.

But being a bare metal system, it couldn't use all the good features of a general Raspberry Pi OS. It could provide it's own API for adding new modules to the system. It could work on a RPi zero, of course, and I'd want to make it work on a broad range of hardware, but my goal would be a multi core with all the typical RPi ports. Just add IEC ports and custom bare metal software for the most flexible smart device with multiple personalities even seen on a Commodore inspired 8 bit system. One core dedicated to IEC communication. The other cores handling more device specific stuff.

Edited by Scott Robison
  • Like 1
Link to comment
Share on other sites

  • Super Administrators
On 11/19/2021 at 4:39 AM, Scott Robison said:

Right, there are other approaches that are "better" in multiple ways. The unique parts of this are repurposing the serial IEC bus for some tasks it's never been used for previously (as far as I know) and having a single smart device behave as multiple individual devices.

I concur on the need for a bare metal system for this. Serial IEC timing is precise. But it could also implement something like burst mode or fast loaders for accelerated IO. Out of the metaphorical box it should Just Work(TM) with any system with a working serial IEC, allowing BASIC and the kernal to open channels, write, read, and close, load, verify, and save. Disk drive, printers, and plotter functionality could just emulate the command, control, and data interfaces so that it is immediately useful without a need for custom programming on each system. A networking interface could emulate RS232 at that same level. The system could also provide access to other devices. I've already discussed HDMI output. It could allow reading from a USB keyboard, or a camera at a low bandwidth, digital audio input via a mic. And it could have a meta device (sorry Zuckerberg) that allows for command and control of the overall puMultIEC.

But being a bare metal system, it couldn't use all the good features of a general Raspberry Pi OS. It could provide it's own API for adding new modules to the system. It could work on a RPi zero, of course, and I'd want to make it work on a broad range of hardware, but my goal would be a multi core with all the typical RPi ports. Just add IEC ports and custom bare metal software for the most flexible smart device with multiple personalities even seen on a Commodore inspired 8 bit system. One core dedicated to IEC communication. The other cores handling more device specific stuff.

So my current thought process is to write assembly or low-level C routines on a Pi Pico or Arduino device, then connect that to software on a Pi or PC via USB. It would cost a few more $$, since you'd need the microcontroller, but then you get the best of both worlds: low level communication via the IEC or User port, and the advanced features a real OS can bring you: TCP/IP transfer, second screen, file storage, and even access to serial devices via the Pi's UART or USB serial devices.

In fact, some people are even using the Teensy (an Arduino like board) to run on the C64's expansion port, communicating directly with the system at 2Mhz. So building an IEC/USB bridge and then connecting to a server on  a Linux or Windows box should be very possible. 

 

  • Like 3
Link to comment
Share on other sites

On 11/18/2021 at 10:41 PM, Scott Robison said:

The reason I was thinking IEC is that that is the common port on all the machines listed above... I agree that IEC would not be as fast as other solutions, but I expect it could be a very affordable option for people still hanging onto their old machines but maybe don't have the resources to pay for multiple bits of hardware to bring their retro computers into the 21st century.

You make some excellent points. I agree with you completely! Simplicity, functionality, compatibility, and affordability, at the cost of some speed is well worth the trade off.

Again, even if it was "as simple" as a Linux machine that turns data into files and then does stuff with the files, it could be immensely useful. Could a 3D printer be considered a plotter? If the computer can generate the data to make a valid STL file, then in this scenario it sure could be! I think one's imagination would be the real limit here. With a Buildroot based setup the boot time would be a couple of seconds and it while still have full networking and GPIO support. It would also have like 40+ years worth of scripting and data parsing software to leverage. People poopoo Linux/BSD/*nix solutions in the retro community, but it's good stuff, truly a living fossil; *nix terminal is just as retro as CP/M!

  • Like 1
Link to comment
Share on other sites

On 11/19/2021 at 4:28 PM, TomXP411 said:

So my current thought process is to write assembly or low-level C routines on a Pi Pico or Arduino device, then connect that to software on a Pi or PC via USB.

That's not a bad idea at all. My main reason for focusing on the pi is that I can already acquire a serial IEC IO board for a pi, as used in pi1541. Then "all" I have to do is replace the software layer. Instead of cycle exact emulation of a 1541 or other drive, I only have to worry about timing that conforms to the IEC standard (slower for C64, faster for VIC20). And of course all the magic that exposes a mass storage device or printer or plotter or screen or networking or whatever your imagination can come up with.

But perhaps such things already exist for Pi Pico or Arduino? Or maybe we just use some sort of jumpers to hand wire a connection between the two?

Regardless, I think if it is possible to do it with the same hardware that already works for pi1541, then that is a strong proof of concept for other things. And it is something we could be developing now and testing with existent hardware, and it would likely be ready whenever X16 is available.

Maybe I need to go create a repo and start putting some real design together instead of only talking about it here. 🙂

  • Like 1
Link to comment
Share on other sites

On 11/19/2021 at 8:40 PM, Tatwi said:

You make some excellent points. I agree with you completely! Simplicity, functionality, compatibility, and affordability, at the cost of some speed is well worth the trade off.

Again, even if it was "as simple" as a Linux machine that turns data into files and then does stuff with the files, it could be immensely useful. Could a 3D printer be considered a plotter? If the computer can generate the data to make a valid STL file, then in this scenario it sure could be! I think one's imagination would be the real limit here. With a Buildroot based setup the boot time would be a couple of seconds and it while still have full networking and GPIO support. It would also have like 40+ years worth of scripting and data parsing software to leverage. People poopoo Linux/BSD/*nix solutions in the retro community, but it's good stuff, truly a living fossil; *nix terminal is just as retro as CP/M!

3D printer? Heck yeah! Whatever can be thought of is probably possible. Sure, it's not the C64 or C128 or {fill in the blank} doing the heavy lifting, but these computers are very senior citizens, of a sort. They deserve to be used and useful as much as possible. Attaching a piMultIEC (or whatever better name comes up) to a 8-bit computer is just giving them an assisted living senior community in which to enjoy their golden years. 🙂

Edit: Oops, forgot to say I have nothing against Linux or BSD. I run BSD, I work on Linux at the office, I like Windows. None of them is perfect. But I also like RPi and Arduino and full "heavy" OSes and bare metal systems. They all have their place.

Edited by Scott Robison
Link to comment
Share on other sites

  • Super Administrators
On 11/19/2021 at 8:06 PM, Scott Robison said:

That's not a bad idea at all. My main reason for focusing on the pi is that I can already acquire a serial IEC IO board for a pi, as used in pi1541. Then "all" I have to do is replace the software layer. Instead of cycle exact emulation of a 1541 or other drive, I only have to worry about timing that conforms to the IEC standard (slower for C64, faster for VIC20). And of course all the magic that exposes a mass storage device or printer or plotter or screen or networking or whatever your imagination can come up with.

But perhaps such things already exist for Pi Pico or Arduino? Or maybe we just use some sort of jumpers to hand wire a connection between the two?

Regardless, I think if it is possible to do it with the same hardware that already works for pi1541, then that is a strong proof of concept for other things. And it is something we could be developing now and testing with existent hardware, and it would likely be ready whenever X16 is available.

Maybe I need to go create a repo and start putting some real design together instead of only talking about it here. 🙂

The Pi 1541 Hat is basically just a level shifter. If you use a 5v Arduino or one that's 5v tolerant one, then you're gold. Otherwise, you can pick up a small level shifter board or pick up a shield with level shifters integrated. 

Obviously, the Pi hat is simpler, physically, but I'm thinking about all the features we don't get with bare metal OS... although those features are being expanded all the time, so maybe I'm worried about nothing. 

  • Like 1
Link to comment
Share on other sites

On 11/20/2021 at 1:35 AM, TomXP411 said:

The Pi 1541 Hat is basically just a level shifter. If you use a 5v Arduino or one that's 5v tolerant one, then you're gold. Otherwise, you can pick up a small level shifter board or pick up a shield with level shifters integrated. 

Obviously, the Pi hat is simpler, physically, but I'm thinking about all the features we don't get with bare metal OS... although those features are being expanded all the time, so maybe I'm worried about nothing. 

Good points. I am thinking "simple" to be sure. The BMC64 project uses the circle bare metal library to good effect, and there are a lot of C++ classes (https://github.com/rsta2/circle/blob/master/doc/classes.txt) and add-on libraries (https://github.com/rsta2/circle/blob/master/addon/README) available. I think we can do both. Use the RPi with the pi1541 hat for built in things, plus an ability to pass through to other machines for when RPi isn't quite enough.

But I'm not opposed to an Arduino solution either, I just worry that it won't be able to keep up with the IEC timing *and* go over yet another remote connection for some things (like loading a file, maybe).

Computer <-> piMultIEC (with option for some hand off to a bigger system) is in general a shorter path than Computer <-> Arduino <-> ModernComputer (with option to do anything it dang well pleases at that point)

Link to comment
Share on other sites

On 11/18/2021 at 10:10 PM, Tatwi said:

The build server is a neat idea. Program on the retro machine in a retro IDE, but pass off the compilation work to the "mainframe". Funny how that workflow is still in use today, yet it is decidedly retro nonetheless.

Internet pass through over IEC might be slow, but there's nothing stopping you from using the userport like other networking cards for C64/128.

Maybe it would make sense as to build the whole thing as a funky, huge userport cartridge. That would have the benefit of allowing one to use the cartridge slot for normal cart software or something like the Final Cartridge III or the like, unlike the Ultimate II cart. It would also look awesome, like a Neo Geo arcade cart with ports.

The User Port of the X16 will surely be different from the User Port of the C64 ... but then again, so are the VIC20 and the Pet's.

C64 (Bottom|Top):
A|1:  GND|GND
B|2: /FLAG2|+5V
C|3: PB0|/RESET
D|4: PB1|CNT1
E|5: PB2|SP1
F|6: PB3|CNT2
H|7:PB4| SP2
J|8: PB5|/PC2
K|9: PB6|ATN
L|10: PB7|9VAC(+)
M|11: PA2|9VAC(-)
N|12: GND|GND

VIC20 (Bottom|Top):
A|1:  GND|GND
B|2: CB1|+5V
C|3: PB0|/RESET
D|4: PB1|JOY0
E|5: PB2|JOY1
F|6: PB3|JOY2
H|7:PB4| LightPen
J|8: PB5|CassetteSwitch
K|9: PB6|ATN
L|10: PB7|9VAC(+)
M|11: CB2|9VAC(-)
N|12: GND|GND

PET (Bottom|Top):
A|1:  GND|GND
B|2: CA1|Video
C|3: PA0|/SRQ IN
D|4: PA1|/EOI
E|5: PA2|DIAG
F|6: PA3|#2CASSREAD
H|7:PA4| CASSWRITE
J|8: PA5|#1CASSREAD
K|9: PA6|VERT DRIVE
L|10: PA7|HORIZ DRIVE
M|11: CB2|GRAPHIC
N|12: GND|GND

To date, the X16 User Port is on the block pin header, organized for accepting an in-case Parallel Port to ribbon cable connector, including, AFAIR, all of Port A (PA0-PA7 and the CA1, CA2 handshake lines) and IIRC, five of the Port B GPIO (PB0-PB4).

So it seems you could have a board customized to the specific machine, with a User Port connector and a pass through on a card edge on the back that brings out the lines that do not go to the User Box, and a block pin header that lines up with the CX16 block pin header but DNC inappropriate lines from that system's User Port.

Then the IEC on the same box gives two advantages: you can send a command on the command channel which specifies which lines in the block pin header are "live" for that particular system, and you have a side-channel you can use to communicate with the User Box without interfering with the main half-duplex parallel port connection for higher speed data transfer.

 

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

In some ways this reminds me of what geoLaser did. The C64 had just enough power to compose the PostScript code to be sent to the printer, and then the printer itself was responsible for turning that into a 300dpi raster on the printed page.

In these days of GDI printers that don't have that kind of computing horsepower because it's expected that the PC will take care of that, then offloading the rasterizing to a Raspberry Pi seems perfectly reasonable.

Technically, a page of US letter paper, edge to edge, at 300dpi, is 'only' 1051875 bytes in monochrome, which would easily fit in the available memory of a 2MB X16. But the dual hardships of USB and multiple incompatible manufacturer-specific GDI printer control protocols mean that it just isn't feasible to do it from the X16 itself.

  • Like 2
Link to comment
Share on other sites

On 11/20/2021 at 5:00 PM, kelli217 said:

In some ways this reminds me of what geoLaser did. The C64 had just enough power to compose the PostScript code to be sent to the printer, and then the printer itself was responsible for turning that into a 300dpi raster on the printed page.

In these days of GDI printers that don't have that kind of computing horsepower because it's expected that the PC will take care of that, then offloading the rasterizing to a Raspberry Pi seems perfectly reasonable.

Technically, a page of US letter paper, edge to edge, at 300dpi, is 'only' 1051875 bytes in monochrome, which would easily fit in the available memory of a 2MB X16. But the dual hardships of USB and multiple incompatible manufacturer-specific GDI printer control protocols mean that it just isn't feasible to do it from the X16 itself.

I can imagine an EPP parallel port device on the input side and USB on the printer output side with a Raspberry Pi inside. It seems like it would be straightforward to set up old school printer compatibility modes, oldschool plotter compatibility modes, and Ghostscript mode ... kind of the reverse of the Parallel Port / USB adapters I see for running an old fashioned printer off of computer with a USB port. Indeed, I more than half expect it's already been done by somebody.

Edit: ... like Retroprinter.

Edited by BruceMcF
  • Like 2
Link to comment
Share on other sites

  • Super Administrators
On 11/21/2021 at 4:12 PM, Scott Robison said:

I called this project piMultIEC for lack of anything better. I'm open to suggestions for a better name, but I have been thinking of a few ideas:

I like Pi2IEC. Since this would basically be the Pi version of the SD2IEC, but with some added benefits.

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

On 11/22/2021 at 12:25 AM, TomXP411 said:

I like Pi2IEC. Since this would basically be the Pi version of the SD2IEC, but with some added benefits.

I surfed around the YouTube "net" over the past week, and it struck me how like the SD2IEC this project is, except using a Pi.

 

Edited by rje
  • Like 2
Link to comment
Share on other sites

  • Scott Robison changed the title to pi2iec (was: piMultIEC)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use