pi2iec (was: piMultIEC)

[Scott Robison]

I had ordered the two hats (one for Pi zero, another for Pi three) and the shipping information from Hong Kong said they would be here between Dec 6 and Dec 30. Imagine my surprise to receive them today, Dec 4!

[rje]

Back to your original post, in particular:

Would the pi1581 give a reasonable data transfer rate?  Assuming the x16 could do fast serial?

If so, then it seems “easier”(?) to modify the pi1541 project to include a piIEC mass-storage option that uses the 1581 fast serial?  

Makes me wonder what a nice base image size would be.  4 megabytes?  16?  Or am I off by three orders of magnitude?

Edited December 5, 2021 by rje

[Scott Robison]

If all you are looking for is mass storage, then it probably would be faster to modify pi1541 to support pi9999 (or whatever).

I want something personally that will give me more than just mass storage, though. I've not looked at the pi1541 software to figure out what it would take for it to support multiple simultaneous devices so it can be disk drive and printer and external monitor and keyboard and networking... and that will work on all the IEC based machines.

Edited December 6, 2021 by Scott Robison

[TomXP411]

On 12/5/2021 at 5:21 PM, Scott Robison said:

If all you are looking for is mass storage, then it probably would be faster to modify pi1541 to support pi9999 (or whatever).

I want something personally that will give me more than just mass storage, though. I've not looked at the pi1541 software to figure out what it would take for it to support multiple simultaneous devices so it can be disk drive and printer and external monitor and keyboard and networking... and that will work on all the IEC based machines.

I think it's fine to have the Pi1541 for those people who want true 1541 emulation. Unlike the SD2IEC, the Pi1541 actually runs a virtual 1541, which fully emulates the CPU and I/O controllers. I'd expect the Pi2IEC to skip that layer of emulation and just directly handle DOS calls.

In fact, since we have the open-source SD2IEC firmware to draw on, it would probably be simplest to port that and add the other features from there. 

Of course, the existing Pi1541 hardware would work, so I'd expect to see two Pis in identical cases on some people's desks. Quite frankly, considering how many things I hung off the IEC bus...  This Is The Way. 

(For that matter, if someone builds a MIDI port, we might add a MT32-Pi, as well. So 3 Pis hooked up to one Commander.)

 

Edited December 6, 2021 by TomXP411

[TomXP411]

I also keep forgetting to mention that since the Commander is 8x faster than a C64, it should be possible to accelerate IEC transfers by a similar amount. JiffyDOS can do 8KB/s on a C64 with SD2IEC, so implementing that on Commander at 8MHz should give us 64KB/s. (Or maybe use a FOSS fast loader, since JD is still being actively sold and is under Copyright.)

 

 

 

[Scott Robison]

On 12/7/2021 at 11:07 AM, TomXP411 said:

I also keep forgetting to mention that since the Commander is 8x faster than a C64, it should be possible to accelerate IEC transfers by a similar amount. JiffyDOS can do 8KB/s on a C64 with SD2IEC, so implementing that on Commander at 8MHz should give us 64KB/s. (Or maybe use a FOSS fast loader, since JD is still being actively sold and is under Copyright.)

It would be nice to have different speed modes supported natively by pi2iec, but first and foremost I want it to just work with the native kernal interfaces so that no custom software per platform is necessary. But as an extension, I'm all for it! Standard serial, Fast serial, Jiffy serial...

https://github.com/MEGA65/open-roms/blob/master/doc/Protocol-JiffyDOS.md was work done for the mega65 open ROM project that might prove useful.

[TomXP411]

On 12/8/2021 at 3:37 PM, Scott Robison said:

It would be nice to have different speed modes supported natively by pi2iec, but first and foremost I want it to just work with the native kernal interfaces so that no custom software per platform is necessary. But as an extension, I'm all for it! Standard serial, Fast serial, Jiffy serial...

https://github.com/MEGA65/open-roms/blob/master/doc/Protocol-JiffyDOS.md was work done for the mega65 open ROM project that might prove useful.

Fortunately, since the IEC code for Commander hasn't been written yet, we have the opportunity to decide what goes in there. 

I'm thinking that, at the very least, you should try to support 1x and 8x IEC mode. Maybe an additional DOS command would be in order, to switch modes. SD2IEC doesn't emulate the 1541, in that it doesn't run 6502 code. Instead, it supports fast loaders by accepting the drive code upload, like a real 1541 would, but then inspecting the uploaded package and selecting its own fast loader to match the uploaded code. If it receives drive code that doesn't match one of the pre-selected profiles, it returns a DOS error.

That's certainly acceptable for maintaining support with SD2IEC, but for the Commander, it might be nice to have an explicit command for switching I/O modes, something like "MS:x" for "Mode Select", where "X" is something like "1X" for standard IEC, "8X" for 8x IEC, and maybe "1J" and "8J" for 1x and 8x JiffyDOS. 

Since standard IEC is the easiest to support, 1X and 8X seem to be the place to start (although we obviously either need real hardware or a good VIA emulation to test with.)

Edited December 9, 2021 by TomXP411

[TomXP411]

Also, here's a place to get started with bare metal coding:
https://www.rpi4os.com/

and here's the SD2IEC source code. Note that it's written in ANSI C, so it might require some refactoring to work in a C++ environment.

https://www.sd2iec.de/gitweb/?p=sd2iec.git;a=summary

I guess the first steps would be to work through the bare metal tutorials and get to the point where I can boot a Pi 4 board without Linux. I have three projects in mind that could benefit from this, so I guess I should get cracking.

 

Edited December 9, 2021 by TomXP411

[TomXP411]

On 12/5/2021 at 3:27 PM, rje said:

Back to your original post, in particular:

Would the pi1581 give a reasonable data transfer rate?  Assuming the x16 could do fast serial?

If so, then it seems “easier”(?) to modify the pi1541 project to include a piIEC mass-storage option that uses the 1581 fast serial?  

Makes me wonder what a nice base image size would be.  4 megabytes?  16?  Or am I off by three orders of magnitude?

I should mention that, based on Gorak's comments on Lemon64, the Pi 3 (and especially Pi Zero) can barely keep up with proper drive emulation at 1MHz, and we want to push that to 8MHz for the Commander. This is why I suggested skipping actual drive emulation and going straight to the SD2IEC model, since that bypasses the overhead of emulating a 6502 computer on the Pi. 

 

Edited December 9, 2021 by TomXP411

[Scott Robison]

On 12/9/2021 at 12:12 PM, TomXP411 said:

I should mention that, based on Gorak's comments on Lemon64, the Pi 3 (and especially Pi Zero) can barely keep up with proper drive emulation at 1MHz, and we want to push that to 8MHz for the Commander. This is why I suggested skipping actual drive emulation and going straight to the SD2IEC model, since that bypasses the overhead of emulating a 6502 computer on the Pi. 

 

I agree, this should implement the protocol, not try to emulate a drive exactly. I don't care about disc protection schemes, just being able to load, save, read and write data as quickly as possible.

Edited December 10, 2021 by Scott Robison

[rje]

I think we have a quorum on not emulating a drive.

I also think that we can agree on SD2IEC as a place to start.   

 

Regarding pi1581 mode... I seem to think that pi1581, unlike the 1541 mode, does not run in hardware emulation mode.  Can someone confirm or deny? 

 

[Scott Robison]

I'm not 100% happy with it. Probably not even 90% happy with it. But I fear I never will be so I should just release it and move on to the next thing. At the moment it is unlisted. Since I don't have a fancy Patreon to get pre-release reviews from, I'm counting on you guys to tell me if it is particularly egregious in any way, and I'll publish it in a bit.

{old link removed}

 

Edited December 24, 2021 by Scott Robison
Invalid link

[Scott Robison]

Here is the "final" release. Changed the thumbnail based on a recommendation from @SlithyMatt on discord, and I tweaked the audio to hopefully remove a hum I couldn't hear myself.

[TomXP411]

Hey @Scott Robison

Turns out, someone beat us to the punch... there's a device that does much of what we're talking about. It's a drive emulator and network interface, named "Meatloaf."

https://github.com/idolpx/meatloaf

 

[Scott Robison]

On 5/19/2022 at 11:16 AM, TomXP411 said:

Hey @Scott Robison

Turns out, someone beat us to the punch... there's a device that does much of what we're talking about. It's a drive emulator and network interface, named "Meatloaf."

https://github.com/idolpx/meatloaf

 

Thanks for pointing it out. I'll give it a look over.

[rje]

I just read about this X16 KERNAL function, and thought it would be useful for an efficient file transfer mode:

Commodore Peripheral Bus

The X16 adds one new function for dealing with the Commodore Peripheral Bus ("IEEE"):

$FF44: MACPTR - read multiple bytes from peripheral bus

Function Name: MACPTR

Purpose: Read multiple bytes from the peripheral bus
Call address: $FF44
Communication registers: .A, .X, .Y
Preparatory routines: FILNAM, FILPAR, OPEN, CHKIN
Error returns: None
Stack requirements: ...
Registers affected: .A, .X, .Y

Description: The routine MACPTR is the multi-byte variant of the ACPTR KERNAL routine. Instead of returning a single byte in .A, it can read multiple bytes in one call and write them directly to memory.

The number of bytes to be read is passed in the .A register; a value of 0 indicates that it is up to the KERNAL to decide how many bytes to read. A pointer to where the data is supposed to be written is passed in the .X (lo) and .Y (hi) registers.

Upon return, a set .C flag indicates that the device does not support MACPTR, and the program needs to read the data byte-by-byte using the ACPTR call instead.

If MACPTR is supported, .C is clear and .X (lo) and .Y (hi) contain the number of bytes read.

Like with ACPTR, the status of the operation can be retrieved using the READST KERNAL call.

[rje]

But then, there's also this.

I2C

$FEC6: i2c_read_byte - read a byte from an I2C device
$FEC9: i2c_write_byte - write a byte to an I2C device

Function Name: i2c_read_byte

Purpose: Read a byte at a given offset from a given I2C device
Call address: $FEC6
Communication registers: .A, .X, .Y
Preparatory routines: None
Error returns: .C = 1 in case of error
Stack requirements: [?]
Registers affected: .A

Description: The routine i2c_read_byte reads a single byte at offset .Y from I2C device .X and returns the result in .A. .C is 0 if the read was successful, and 1 if no such device exists.

 

EXAMPLE:

LDX #$6F ; RTC device
LDY #$20 ; start of NVRAM inside RTC
JSR i2c_read_byte ; read first byte of NVRAM

Function Name: i2c_write_byte

Purpose: Write a byte at a given offset to a given I2C device
Call address: $FEC9
Communication registers: .A, .X, .Y
Preparatory routines: None
Error returns: .C = 1 in case of error
Stack requirements: [?]
Registers affected: .A

Description: The routine i2c_write_byte writes the byte in .A at offset .Y of I2C device .X. .C is 0 if the write was successful, and 1 if no such device exists.

EXAMPLES:

LDX #$6F ; RTC device
LDY #$20 ; start of NVRAM inside RTC
LDA #'X'
JSR i2c_write_byte ; write first byte of NVRAM

LDX #$42 ; System Management Controller
LDY #$01 ; magic location for system poweroff
LDA #$00 ; magic value for system poweroff
JSR i2c_write_byte ; power off the system

Edited May 19 by rje

[Scott Robison]

On 5/19/2022 at 3:37 PM, rje said:

But then, there's also this.

I2C

$FEC6: i2c_read_byte - read a byte from an I2C device
$FEC9: i2c_write_byte - write a byte to an I2C device

Very cool. Lots of room for various projects IMO, but it is nice having that built in.

[Scott Robison]

On 5/19/2022 at 1:07 PM, Scott Robison said:

Thanks for pointing it out. I'll give it a look over.

A very worthy project. It has the same "downside" of many other projects in that it won't be compatible with as many platforms as I'd like, which to me is the draw of pi2iec. I just need to get to work on it (one week of school left)...