IEC Mass-Storage device

Chat about anything CX16 related that doesn't fit elsewhere
TomXP411
Posts: 1785
Joined: Tue May 19, 2020 8:49 pm

IEC Mass-Storage device

Post by TomXP411 »



53 minutes ago, rje said:




Here's an ATMega solution: https://github.com/fachat/XD2031



Or, perhaps what Tom was alluding to: https://github.com/Larswad/sd2iec_mega2560



I have a Mega 2560 and a Nano as well, so that's fine, they're just not as familiar to me.



 



The Arduino IS probably better; for one thing, the voltage levels are more compatible.



 



There's also https://www.insentricity.com/a.cl/208/C64PiVideo.



Oh, I'm stuck on the Pi because 



(1) I "know" it better than other little platforms and

(2) I have some lying around but also

(3) The Pi Zero is just so cheap and

(4) I get stuck on things.



Yes, I was thinking of the sd2iec_mega2560 version - although I would not implement it on a Mega. I would use a Teensy 3.5, due to the built in SD reader and smaller footprint. 



Actually, you should be able to do it on a Pi, using a bare metal coding solution like Circle. Just don't expect to do this in Raspbian. Pi 1541 was developed as a bare metal program specifically because Linux doesn't have the timing resolution needed to work in this situation.

Most of the code should also work, although you may need to deal with the timer - I don't know what the Pi uses for a timer, but you need some pretty tight precision if you're going to use a serial connection. A parallel connection would actually be simpler to code,  since you just need to set the data pins and strobe the clock pin. 

I also have RunCPM running on a Grand Central - which would actually be ideal. It has a lot of pins, so you can stick it on the User port and also use it as a serial and WiFI breakout, with the addition of an ESP8266 or ESP32. 

 

rje
Posts: 1263
Joined: Mon Apr 27, 2020 10:00 pm
Location: Dallas Area

IEC Mass-Storage device

Post by rje »


 


7 hours ago, TomXP411 said:




what's the point of all this? To make a faster SD2IEC? 



The SD card slot in the Commander is faster than an IEC drive can hope to be [...]



(...) You can get up to around 64KB/sec using IEC, but that seems like a lot of work for something few people will need or use. 



My use case is: complex programs.

I'll define "complex programs" as ones which use files as resources, loaded on demand.

 

Perhaps that's what the SD card is for, but I am not sure about that.  For one thing, you don't want to swap an SD card out like you would a floppy diskette; it's not intended for that kind of use -- although perhaps it's OK.  But if that puts an unreasonable amount of wear-and-tear on the connector, then that could be a problem.  I've tried googling for the MTBF on SD card connectors, but obviously I don't know what I'm looking for.

Now if the SD card is the target, then programs will be written with that device driver.  Is that what we want?  Does that cause a portability issue?  Maybe not -- I mean large programs which load in data files are by definition not very portable.  So strike portability.

If the IEC bus is the target, then programs will use the IEC protocol.  Maybe that doesn't matter (portability is not the issue).

 

I was also thinking about an RS-232 port; I was thinking how interesting it would be to write a shell-like transfer program for it, and that's when I realized that complex programs will never be written for that protocol on the X16, exactly because it's not a supported standard, and "no standard" will never be able to compete with two existing-and-supported standards.

TomXP411
Posts: 1785
Joined: Tue May 19, 2020 8:49 pm

IEC Mass-Storage device

Post by TomXP411 »



6 hours ago, rje said:




 



My use case is: complex programs.



I'll define "complex programs" as ones which use files as resources, loaded on demand.



 



Perhaps that's what the SD card is for, but I am not sure about that.  For one thing, you don't want to swap an SD card out like you would a floppy diskette; it's not intended for that kind of use -- although perhaps it's OK.  But if that puts an unreasonable amount of wear-and-tear on the connector, then that could be a problem.  I've tried googling for the MTBF on SD card connectors, but obviously I don't know what I'm looking for.



Now if the SD card is the target, then programs will be written with that device driver.  Is that what we want?  Does that cause a portability issue?  Maybe not -- I mean large programs which load in data files are by definition not very portable.  So strike portability.



If the IEC bus is the target, then programs will use the IEC protocol.  Maybe that doesn't matter (portability is not the issue).



 



I was also thinking about an RS-232 port; I was thinking how interesting it would be to write a shell-like transfer program for it, and that's when I realized that complex programs will never be written for that protocol on the X16, exactly because it's not a supported standard, and "no standard" will never be able to compete with two existing-and-supported standards.



Actually,  the SD card is made for exactly that sort of use. Remember that the SD card was originally made for digital cameras and MP3 players, and the intent was for users to pull the card out of their device and plug it into a computer to transfer data. 

However... it does seem sort of silly to sneakernet the card to a PC when the X16 should come with some sort of network device built in. We've all been saying it since the beginning, and it's still true: The Commander should have an Ethernet port, WiFi interface, or at least a hardware driven serial port. 

Anyway... the IEC port is intended to support Commodore peripherals. That means a 1MHz clock speed. THAT means 600 characters per second. So you won't be using that for complex programs using the default on-board software. 

 

rje
Posts: 1263
Joined: Mon Apr 27, 2020 10:00 pm
Location: Dallas Area

IEC Mass-Storage device

Post by rje »


Yes, yes, and yes.  I don't disagree on any particular point up there.

I wonder what Dave's been thinking re I/O. 

With the IEC port at crawly 1541 speeds, there may be an effort (post release?) for fastloader support, or a KERNAL update to implement the 1581-era burst mode (1500 characters per second, perhaps).

 

 

kelli217
Posts: 535
Joined: Sun Jul 05, 2020 11:27 pm

IEC Mass-Storage device

Post by kelli217 »


Let me see if I can restate the premise.

You want to be able to transfer information to and from this machine, but you're worried that repeated insert/eject cycles are going to wear out the SD card slot, plus the slot is inconveniently placed. You would use something like an SD2IEC but the IEC bus is too slow for the kind of file quantities that the SD card makes possible and that the 2MB version of the machine makes useful. You also don't think connectivity via serial would be a popular option, given the existence of the SD and IEC standards on the system.

Do I have that about right?

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

IEC Mass-Storage device

Post by BruceMcF »


The thing about load time for a "complex program" if the SD stays in the system is that if you are loading a complex program to the SD card, then it's a one-off. I am more than a little skeptical about there being a lot of 4MB programs for the CX16, but the issue is that if, optimistically, the bit banged serial port is 19200Kbps, that's 2,400KBps, and a 4MB program is like half an hour. Even for a one time process, that's a bit more than a "make a cup of coffee" wait time. An EPP transfer is more like 24KBps (with a routine with a timeout countdown on /ACK), so a 4MB program would be more like 3 minutes.

If complex programs are more in the range of 128K-256K, then if the bit banged serial is (optimistically) 19200kbps, that's more like 1-2 minutes to load a file onto the SD card, and more like a sip of coffee wait time for an EPP transfer.

If you are going to sneakernet the SD card, an SD card extension cable totally eliminates the worry about the SD card wearing out, though I'd not so much worry about that as want to have the SD card more easily accessible.


On 3/19/2021 at 9:20 AM, rje said:




I was also thinking about an RS-232 port; I was thinking how interesting it would be to write a shell-like transfer program for it, and that's when I realized that complex programs will never be written for that protocol on the X16, exactly because it's not a supported standard, and "no standard" will never be able to compete with two existing-and-supported standards.



Except if (1) the bit-banged serial on the User port is a Kernel device, like bit-banged serial on the C64 User port, and (2) an RS-232C card has a Kernel API driver written for it that works the same way, then it would be an existing standard.

 

Ed Minchau
Posts: 503
Joined: Sat Jul 11, 2020 3:30 pm

IEC Mass-Storage device

Post by Ed Minchau »



On 3/18/2021 at 7:20 PM, rje said:




 



My use case is: complex programs.



I'll define "complex programs" as ones which use files as resources, loaded on demand.



 



My video demo used 15947 files. Every 1/20 second, it loads a PCM audio clip, tile data, and a palette from the file system to VERA (the two extra files are a tile map and the default palette). It's all loaded on demand, triggered by VSYNC.

The whole thing is over 67 Mb. The only way to avoid sneakernet with something like that is if the SD card has an on-board wifi. Luckily such cards exist, if one wants to write the protocol. 

 

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

IEC Mass-Storage device

Post by BruceMcF »



5 hours ago, Ed Minchau said:




My video demo used 15947 files. Every 1/20 second, it loads a PCM audio clip, tile data, and a palette from the file system to VERA (the two extra files are a tile map and the default palette). It's all loaded on demand, triggered by VSYNC.



The whole thing is over 67 Mb. The only way to avoid sneakernet with something like that is if the SD card has an on-board wifi.



20-50 minutes is indeed something only a certain segment would have the patience and ability to plan ahead and do something else while it is finishing. But I do reckon that if I sneakernet everything above 10MB that I have an interested in getting loaded up into the CX16, doing that doesn't seem like it would be a very regular occurrance.

rje
Posts: 1263
Joined: Mon Apr 27, 2020 10:00 pm
Location: Dallas Area

IEC Mass-Storage device

Post by rje »



12 hours ago, BruceMcF said:




I am more than a little skeptical about there being a lot of 4MB programs for the CX16 [...]



If you are going to sneakernet the SD card, an SD card extension cable totally eliminates the worry about the SD card wearing out, though I'd not so much worry about that as want to have the SD card more easily accessible.



Except if (1) the bit-banged serial on the User port is a Kernel device, like bit-banged serial on the C64 User port, and (2) an RS-232C card has a Kernel API driver written for it that works the same way, then it would be an existing standard.



You made three good points.

(1) I don't know about 4MB either.  However, games that use a map will seek to fill available space within reason.  I have 5mb of data I *could* put in map files.  I chose to limit it to 260K.  I might pare that down further, or go the (1a) route.

(1a) Slow performance OR extraordinary file sizes would suggest breaking a map up into multiple files, or doing seek()s on an open stream.

(2) Yes to the extension cable.

(3) Yes to a KERNAL driver for serial on the user port / RS-232C.

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

IEC Mass-Storage device

Post by BruceMcF »



12 hours ago, rje said:




(1a) Slow performance OR extraordinary file sizes would suggest breaking a map up into multiple files, or doing seek()s on an open stream.



I would expect that the SD drive will be used by programs that rely on accessing files, and the SD drive will be fast enough that speed of access will rarely be the bottleneck ... the speed issue is how fast can a larger file or set of files be loaded onto an SD drive one time.

It would likely be convenient enough to give people an option on which device number they use, but if they elect to use their old 1541 on the IEC port and it makes for long pauses in game, that is really on them.

That's not where I see any advantage from an IEC mass storage device.

Where there is an advantage would be, for example, if there is a microcontroller that hosts USB being used to support a USB flash drive, or USB to WIFi bridge, or whatever ... and it talks to the CX16 over a bespoke User Port parallel port A interface, using the VIA parallel port handshake modes to transfer a page of data at time time ... IOW, you have the microcontroller, you have the read and write routines so they are fast enough to keep up with the VIA using the hardware handshake on the VIA side, you do your "RDY ACK" handshakes a page at a time and rely on the hardware handshake to just pump data through 256 bytes at a time.

That's where you get your really nice User Port data transfer rates ... READPG1: LDA portA : STA (target),Y : INY : BNE READPG1 ... as an inner loop, with the ACK / RDY overhead happening once every 256 bytes, so you might hope for around 16-20 clocks per byte, which is getting up into the 400KB/s-500KB/s, or 3 minutes or less for that 67MB demo.

Now, while I can see EPP parallel port routines getting more than "single project lifetime" support, because of the retro appeal of accessing existing old dusty PC parallel port devices and bringing them up on the CX16, something like this benefits a lot from being an all-in-one solution.

So also having an IEC port to plug into the CX16 IEC plug (or terminal of the IEC daisychain) as "Device #14" would allow the microcontroller to store the utilities and/or drivers to install the support for User port parallel port access to the board and serve them over the IEC port ... making it LOAD"*",14 plug and play.

Post Reply