Jump to content

PI Zero IEC Device


rje
 Share

Recommended Posts

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.

Edited by rje
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

  • Super Administrators
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. 

  • Like 2
Link to comment
Share on other sites

Posted (edited)
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.

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

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.

 

Edited by BruceMcF
Link to comment
Share on other sites

  • Super Administrators
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. 

Link to comment
Share on other sites

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.

 

  • Like 1
Link to comment
Share on other sites

  • Super Administrators
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. 

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...
Posted (edited)

I've thought about this very generally, and figured that to a large degree, data can be buffered in RAM on the storage device until transmission is done.  Since the X16's RAM footprint is small, a Pi buffer might remove any potential flash lag.

***

Quote

A multi-tasking multi-user operating system such as Linux is not suitable for this task.

^ Given.

So I wrote a simple one-wire noiseless no-ack ("SOWNONO") protocol between two Pi Zeros, in C, using WiringPi, on Raspbian.  It looks like I can get a whopping 500 bits per second. 

In theory, then, plain old C with wiringPi and no ACK can get me 62 bytes per second.  No optimizations, no special nothing, and of course once they go out of sync it's disaster.

But it was fun to write and is a start.

***

I think if I revisit my simple talker, I'll define a frame and add an ACK.  I've seen a Michael Steil video where communication can slowly drift out of sync over dozens of bits...

But I'm also thinking about using my Arduinos -- I've got a Nano and a Mega 2560.

Edited by rje
Link to comment
Share on other sites

  • Super Administrators
On 4/11/2022 at 12:51 PM, rje said:

I think if I revisit my simple talker, I'll define a frame and add an ACK.  I've seen a Michael Steil video where communication can slowly drift out of sync over dozens of bits...

That's why single-wire-per-direction protocols like RS-232 have a start and stop bit. The longer duration acts as a sync marker to keep the two UARTS lined up. 

I'm still inclined to do something SPI over the User port. The Pi does hardware SPI just fine, and the only limiting factor there should be how fast we can bit-bang the port on the Commander side. (Which should be pretty fast if we have a bit shifter available.)

  • Like 2
Link to comment
Share on other sites

Posted (edited)
On 4/11/2022 at 7:04 PM, TomXP411 said:

The Pi does hardware SPI just fine, and the only limiting factor there should be how fast we can bit-bang the port on the Commander side. (Which should be pretty fast if we have a bit shifter available.)

Ok, that sounds useful.  I've done I2C but not SPI, so I'll start reading.

There's also the UART (pins 8 and 10 / GPIO 14 and 15).

 

Edited by rje
Link to comment
Share on other sites

On 4/11/2022 at 8:04 PM, TomXP411 said:

That's why single-wire-per-direction protocols like RS-232 have a start and stop bit. The longer duration acts as a sync marker to keep the two UARTS lined up. 

I'm still inclined to do something SPI over the User port. The Pi does hardware SPI just fine, and the only limiting factor there should be how fast we can bit-bang the port on the Commander side. (Which should be pretty fast if we have a bit shifter available.)

If we have access to the serial shift register lines, it can be used as MISO. If PB0 is used as the master SCLK, connected through to the serial shift register clock line so it can clock the input in, PB1 as MOSI, and PB2 to however high you want to allocate as SPI_SELECT, you can:

SPI_LSB:
   LDX #7
   LDA UPORT_PB
   ORA #%00000001
   AND #%11111101
   TAY
-   TYA
   LSR DATA
   BCC +
   ORA #%00000010
+  STA UPORT_PB
   DEC UPORT_PB
   INC UPORT_PB
   DEX
   BPL -
... with the MISO byte available in the Serial Shift Register data register when the process is finished, and with an accelerated loop when MOSI is "don't care", which can therefore be #0:

   LDX #7
   LDA PORTB
   ORA #%00000001
   AND #%11111101
-  STA UPORT_PB
   DEC UPORT_PB
   INC UPORT_PB
   DEX
   BPL -
 

Link to comment
Share on other sites

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