PI Zero IEC Device

rje · Post by **rje** » Wed Mar 16, 2022 3:07 pm

In this thread I want to discuss writing a hunk of C code for the Raspberry Pi Zero that can talk the IEC protocol.

***

My biggest question is HOW CAN I TEST SOMETHING LIKE THAT? I have no clue.

***

I want to start by using Debian (Raspbian), for example. In other words, start simpler. Also, this way it is actually possible that I might be able to write a proof of concept, because I can program applications that talk over GPIO.

In other words, there's an actual possibility that I could write a prototype that kind-of works.

***

I suggest the Zero, just because I want to start with the least-capable Pi.

SlithyMatt · Post by **SlithyMatt** » Wed Mar 16, 2022 3:23 pm

Are you aware of this project? Scott is already well down this path:

rje · Post by **rje** » Wed Mar 16, 2022 3:27 pm

On 3/16/2022 at 10:23 AM, SlithyMatt said:

Are you aware of this project? Scott is already well down this path:

YES, I am/was aware of it, and had forgotten.

Thanks!

Scott Robison · Post by **Scott Robison** » Wed Mar 16, 2022 4:49 pm

I wish I was further down the path. Stupid jobs.

If you want to pursue it I don't object. Not that I should, just saying so.

TomXP411 · Post by **TomXP411** » Wed Mar 16, 2022 6:25 pm

On 3/16/2022 at 8:07 AM, rje said:

In this thread I want to discuss writing a hunk of C code for the Raspberry Pi Zero that can talk the IEC protocol.

***

My biggest question is HOW CAN I TEST SOMETHING LIKE THAT? I have no clue.

***

I want to start by using Debian, for example. In other words, start simpler. Also, this way it is actually possible that I might be able to write a proof of concept, because I can program applications that talk over GPIO.

In other words, there's an actual possibility that I could write a prototype that kind-of works.

***

I suggest the Zero, just because I want to start with the least-capable Pi.

I’m going to suggest downloading the SD2IEC source code first. Modifying that may be the smart route, since it already works on AVR processors. Keeping a common code base also means being able to take advantage of JiffyDOS, which is going to be essential to getting decent performance.

Remember the base 1541 protocol only manages like 600 bytes per second. Even sped up by 8X, that’s still only 4Kbytes/s. I’m thinking a storage solution should have a minimum of 16Kbytes/s, which would fill up main memory in about 2 seconds and would take 32 seconds to fill up 512K of banked RAM.

Gah! Looking at those figures, I’m thinking we should suggest an IEEE interface, similar to the PET. The SD2PET is already a thing, and it works very well. I know David has one, since his Mini PET review inspired me to get one of my own.

maybe the answer to our storage needs is an additional VIA or PIO chip on the system, coupled to an SD2PET like device.

rje · Post by **rje** » Thu Mar 17, 2022 1:11 am

On 3/16/2022 at 11:49 AM, Scott Robison said:

I wish I was further down the path. Stupid jobs.

If you want to pursue it I don't object. Not that I should, just saying so.

Ideally I would like to collaborate. I can do some things well and some things badly. If your skill set is complementary, then theoretically we should have a better chance of getting something interesting done.

And Tom has two good ideas.

On 3/16/2022 at 1:25 PM, TomXP411 said:

I’m going to suggest downloading the SD2IEC source code first. Modifying that may be the smart route, since it already works on AVR processors.

...

Looking at those figures, I’m thinking we should suggest an IEEE interface, similar to the PET. The SD2PET is already a thing, and it works very well. I know David has one, since his Mini PET review inspired me to get one of my own.

BruceMcF · Post by **BruceMcF** » Sat Mar 19, 2022 10:44 am

Note that if connected to an SD2IEC rather than to a Commodore drive, JiffyDos is more like 8KB/s ... there are overheads like sector seek in a physical drive that are not present when a microcontroller is accessing an SD card. However, that is still a bit slow.

But that is constrained by the need to support something that the C64 can support "out of the box".

Here is Pasi's "Burst Fastloader for C64" article.

After reading Pasi Ojala's discussion of the C128 burstloader mode for his C64 burstloader mod, there is no doubt in my mind that the C128 burstloader protocol could easily hit 16KB/s if connecting a CX16 and a SD2IEC type device that supports burstloader mode ... so long as the SD2IEC device connects the SRQ line to a GPIO. I'm not a hardware hand, but what I see at the official sd2iec site seems to suggest it ought to be done ... but with any device with multiple independent builders, YMMV.

Also, since the protocol is built around a receiver ACK of each bit received, working out a better implementation of the side that is the bottleneck will always increase transfer speed. AND even if the SD2IEC transfer is much faster than a 1571/1581 transfer, it will still work to connected to the 1571 or 1581.

The CX16 does have one of its hardware serial shift registers free ... only one is needed since the burstloader protocol uses regular IEC to determine who is sender and who is receiver, so its a three wire interface ... IEC data is the data line, IEC SRQ is the clock line, and IEC clock is the acknowledge line.

TomXP411 · Post by **TomXP411** » Sat Mar 19, 2022 10:10 pm

On 3/19/2022 at 3:44 AM, BruceMcF said:

Note that if connected to an SD2IEC rather than to a Commodore drive, JiffyDos is more like 8KB/s ... there are overheads like sector seek in a physical drive that are not present when a microcontroller is accessing an SD card. However, that is still a bit slow.

But that is constrained by the need to support something that the C64 can support "out of the box".

Yes, I'm seeing some benchmarks that say up to 9KB/s. I don't remember my personal tests being that fast, but it's been a while, and I'd have to go back and build some test programs and data sets to really figure that out.

Meanwhile, I'm more and more on board with the idea of a "burst mode" SD2IEC running on a Raspbery Pi Pico. Those things run less than $5, can do all the things the CX16 needs a microcontroller for, and can simplify the KERNAL by removing the need for the DOS/FAT32 code.

OTOH, it sounds like maybe the FAT32 code is mostly fine and either the FAT32 code or VERA just needs some minor bug fixing to get it across the finish line.

BruceMcF · Post by **BruceMcF** » Sat Mar 19, 2022 11:18 pm

On 3/19/2022 at 6:10 PM, TomXP411 said:

Yes, I'm seeing some benchmarks that say up to 9KB/s. I don't remember my personal tests being that fast, but it's been a while, and I'd have to go back and build some test programs and data sets to really figure that out.

Meanwhile, I'm more and more on board with the idea of a "burst mode" SD2IEC running on a Raspbery Pi Pico. Those things run less than $5, can do all the things the CX16 needs a microcontroller for, and can simplify the KERNAL by removing the need for the DOS/FAT32 code.

OTOH, it sounds like maybe the FAT32 code is mostly fine and either the FAT32 code or VERA just needs some minor bug fixing to get it across the finish line.

I don't see why a "burst mode" SD2IEC couldn't be done with the original design, as long as it's a build with the SRQ line connected properly ... but a Raspberry Pi Pico SD2IEC would likely run it more efficiently, and since it's an ACK-per-bit protocol that can run as fast as the slower side will handle, that could well speed it up to the fastest speed the hardware serial register in the W65C22 will handle. Having it available with just a firmware update to existing SD2IEC devices would be good, even if an RPi Pico version is the most appealing for a new buy.

As far as the "flaky" SD interface, if the most critical SD problem is the "SD card not recognized" problem, @Wavicle made a quite persuasive argument that since the SPI mode is quite robust, so it could well be in the SPI mode initialization process itself where a problem lies.

Given that Vera JUST has a simple single-select SPI bus master, it's hard to imagine what could be an issue with the Vera unless they placed the "slow" speed too close to the upper clock limit for the SPI-initialization sequence for some cards that are a little off in their tolerances. Unless scaling down to 380kbps magically gets more cards to be recognized, there's no much more that could be there.

One thing that is needed on an organizational level is a github pull request committee, to encourage broader participation in Kernel/DOS development and bug fixing.

TomXP411 · Post by **TomXP411** » Sun Mar 20, 2022 12:56 am

On 3/19/2022 at 4:18 PM, BruceMcF said:

One thing that is needed on an organizational level is a github pull request committee, to encourage broader participation in Kernel/DOS development and bug fixing.

Agreed. We need someone or “someones” to merge all the community PRs and to cut some new releases. Ideally, one or two people to do testing and an additional community manager for the GitHub repos. There are a lot of open requests and code changes that need to be reviewed, triaged, and QAd.