Fast IEC + SD2IEC?

[rje 193]

I've watched the brainstorming on serial communications, and it occurs to me that some of this is a solved problem: namely, SD2IEC, and some sort of fastloader, perhaps in one of our ROM banks.

The "sunk" hardware cost is the price of the SD2IEC.  Call it $70.

That's the price point to beat, isn't it?

 

[Lorin Millsap 171]

I've watched the brainstorming on serial communications, and it occurs to me that some of this is a solved problem: namely, SD2IEC, and some sort of fastloader, perhaps in one of our ROM banks.
The "sunk" hardware cost is the price of the SD2IEC.  Call it $70.
That's the price point to beat, isn't it?
 

Not needed as there is an integrated SD card which is orders of magnitude faster than SD2IEC. No sense in implementing a fast loader for legacy devices when firstly it can be done in software for the cases that need it, which realistically will be rarely.


Sent from my iPhone using Tapatalk

[rje 193]

41 minutes ago, Lorin Millsap said:

Not needed as there is an integrated SD card which is orders of magnitude faster than SD2IEC. No sense in implementing a fast loader for legacy devices when firstly it can be done in software for the cases that need it, which realistically will be rarely.

Agreed.  Now I seem to recall that the SD card is on the VERA board, which would be inconvenient.  So I hope you mean there's an external SD card slot?

[Lorin Millsap 171]

Agreed.  Now I seem to recall that the SD card is on the VERA board, which would be inconvenient.  So I hope you mean there's an external SD card slot?

The VERA card is exposed to the back of the machine. You just stick the card in. No worries.


Sent from my iPhone using Tapatalk

[m00dawg 104]

Ah maybe I misinterpreted, I thought you were saying the IEC bus could be a good way to enable getting data to/from the X16 and, say a PC?

[rje 193]

Just now, Lorin Millsap said:

The VERA card is exposed to the back of the machine. You just stick the card in. No worries.

Thank you again!

[rje 193]

Just now, m00dawg said:

Ah maybe I misinterpreted, I thought you were saying the IEC bus could be a good way to enable getting data to/from the X16 and, say a PC?

I don't know if it's a GOOD way (LOL!) but it is a solved problem.

[m00dawg 104]

Just now, rje said:

I don't know if it's a GOOD way (LOL!) but it is a solved problem.

Is it though? There's not yet a serial solution available, though given all the things discussed, I'm sure there will be one. I was thinking you were suggesting using the IEC bus as one of the solutions since it already exists. The idea seems to be, given the SD card is at the back of the computer, that one won't be removing it from the X16 all that often. But for active development, that could happen _a ton_ and likewise for sharing content made (you know like tracker files, demos, etc.) one will have to yank the card.

I have to do this all the time with my 3D print farm and it's a pain (as an aside, I do it this way because OctoPrint isn't as reliable for me as just printing right from the printers and it really sucks to ruin a customer print because Octo print disconnected from the printer, or the Pi just stopped working, etc.). So having a way to copy stuff back and forth without having to remove the SD card all the time is something that I think would have very high value.

[rje 193]

44 minutes ago, m00dawg said:

I was thinking you were suggesting using the IEC bus as one of the solutions since it already exists. 

Yes.

And yes, I think a "bit-banging RS232 protocol" is *somewhere* in the mix.  Although I don't think my Mac can do RS232...?

Quote

... for active development [inserting and removing the SD card] could happen _a ton_ and likewise for sharing content made (you know like tracker files, demos, etc.) one will have to yank the card.

Yes.  When I develop stuff, I'm moving SD cards around quite a bit, because I'd have to get it off my Mac and onto the X16, and vice versa.

Another solution is perhaps a Wi-Fi SD Card...

Edited January 14 by rje

[rje 193]

Oooooooh.... how about SD2IEC with a Wifi SD card?   

[TomXP411 304]

3 hours ago, rje said:

Oooooooh.... how about SD2IEC with a Wifi SD card?   

Why? The user port will be the same speed, since it's all software controlled. So you might as well just bit shift through the User port and run an external ESP32.

 

[rje 193]

1 hour ago, TomXP411 said:

Why? The user port will be the same speed, since it's all software controlled. So you might as well just bit shift through the User port and run an external ESP32.

Why use a Wifi SD card?  I might be wrong, but it sounds like it grants the X16 a file system that's network-accessible.  

Imagine the fun, there.  One of my Rpi Zero W's can monitor the SD card's file system, proxying requests to the web in an astonishingly slow -- but fun -- fashion.  Network access, through a proxy, with none of the dangers.  Holy crap, my Traveller game won't need to store the galactic map -- it's all on the web, and now I know how to get at the web from the X16.  That's a game changer.

More practically, it avoids the physical swap cycle of transferring files to and from the X16 via the SD card.

Plus -- and yes, this is a plus -- then people like me won't have to make all the mistakes of learning to properly shift bits.  I would use up a lot of aspirin.  Although I guess I know ROL and ROR... but still.  It's not that I don't find designing hardware and writing assembly language sexy -- I'm a big enough nerd to like it.  It's just that I'm no good at it.  There.  I said it.  In my hobby hours, I'd rather write Perl than assembly.  And I'm friggin' good at it, too... Perl ain't just a text mangler and process controller... it can pack binary records like no one's business.  It's just not C-fast and is a memory hog.  That's what you get when C and Awk have a love child.

 

 

But yes, I have no problems with other hardware solutions.

In fact, I prefer MANY options, so that I can pick my price point based on my need of the moment.  I also mused on the venerable IEC (with an appropriate bursty mode), as well as the slightly less venerable I2C.

Edited January 15 by rje

[BruceMcF 237]

If it's to communicate with a PC, I don't understand the "SD2" part ... a USB to parallel converter plus a parallel to IEC cable would do. That would come out to a long way less than $70.

And if it's to sneaker net to the PC, then a second SD card slot on an expansion card could be done that was substantially cheaper than an SD2IEC.

[TomXP411 304]

4 hours ago, rje said:

Why use a Wifi SD card?  I might be wrong, but it sounds like it grants the X16 a file system that's network-accessible.  

Imagine the fun, there.  One of my Rpi Zero W's can monitor the SD card's file system, proxying requests to the web in an astonishingly slow -- but fun -- fashion.  Network access, through a proxy, with none of the dangers.  Holy crap, my Traveller game won't need to store the galactic map -- it's all on the web, and now I know how to get at the web from the X16.  That's a game changer

Why use an IEC based device at all? If the SD card can act as a file server (which I doubt), then you can just install one in the Commander. And if it can't... the SD2IEC is always going to be slower than either the internal port or a parallel connected device.

 

 

[TomXP411 304]

11 hours ago, Lorin Millsap said:

Not needed as there is an integrated SD card which is orders of magnitude faster than SD2IEC. No sense in implementing a fast loader for legacy devices when firstly it can be done in software for the cases that need it, which realistically will be rarely.

It's not, really. The FAT32 driver is hampered by running on the 6502, and it shows. I did some testing today, and raw file reads from SD run at around 9KB/s. That's much slower than what the hardware should be capable of, so I'm going to assume it's just due to the sheer amount of code needed to read a file stream from a FAT32 volume.

I have clocked my SD2IEC at 6KB/s - and that's connected to a 1MHz Commodore 64. Running an SD2IEC at 8MHz, instead of 1MHz, you could expect speeds of 40-50Mhz. I'm not sure existing SD2IEC devices could actually do this, since they're based on slower AVR microcontrollers, but a device with a faster ARM chip, like the Teensy 3.5, is certainly capable of those kinds of speeds. 

 

Edited January 15 by TomXP411

[Fnord42 36]

14 hours ago, m00dawg said:

The idea seems to be, given the SD card is at the back of the computer, that one won't be removing it from the X16 all that often. But for active development, that could happen _a ton_ and likewise for sharing content made (you know like tracker files, demos, etc.) one will have to yank the card.

It should not be too hard to build an extension cable using two of those sd-to-microsd adapters that everybody has a ton of and some ribbon cable, I guess. That way, you can at least have the card at a more accessible location.

Of course, any solution that eliminates the need for physically handling storage media would be much preferable to this.

[Lorin Millsap 171]

It’s not like it’s large or heavy. Just reach back and pop it out.


Sent from my iPhone using Tapatalk

[Fnord42 36]

Maybe it's just one of those things that you imagine to be terribly annoying, but then get used to quickly. But apparently it seems to be an issue for some people.
However, it will be fun to see (and/or make) the wlan-based solutions that will inevitably turn up sooner or later.

[rje 193]

Swapping SD cards is not really the same as swapping floppies.  I mean, the human side of the action is the same, but SD cards seem less happy about it.  Maybe it depends on the quality of the SD card, but it seems less happy than cartridge swapping, which I assume is designed around heavy plug-unplug use.  SD cards are designed to stay where they're put, with a minimum of swappage.

 

 

Edited January 15 by rje

[Lorin Millsap 171]

Swapping SD cards is not really the same as swapping floppies.  I mean, the human side of the action is the same, but SD cards seem less happy about it.  Maybe it depends on the quality of the SD card, but it seems less happy than cartridge swapping, which I assume is designed around heavy plug-unplug use.  SD cards are designed to stay where they're put, with a minimum of swappage.
 
 

Valid point to a large degree. Less of an issue here if the system always closes its files, but I can see wear being an issue. To minimize swapping you will have serial. And if you do all your testing in the emulator you will not need to swap cards as much.


Sent from my iPhone using Tapatalk

[Fnord42 36]

Good point. The only thing where this might be problematic is developing (for) external hardware. Is there an API in the emulator that allows us to simulate external hardware (like expansion cards and/or hardware on the user port)?  If not, is it planned to add it at some point? Or are there arguments against it? (Except developer time, which is of course always short. I guess this feature would be relatively far down on the priorities list, at least until the hardware is more or less finished.)

[m00dawg 104]

Expansion hardware is a great point. I still think between all the options discussed across the forums that one of them will stick So I have to imagine we'll have some sort of file copy solution - other than Sneaker Net. I'm just not sure which one. I would imagine the simplest one will be the first one that works (and that sounds like some sort of user port solution is my guess - or perhaps the IEC port).

I think I'd be less bothered by SD cards if they weren't so small and were more purpose made for frequent insertion and removal. Something between an SD card and 3.5" would have been nice, with slots intentionally made for the purpose. Micro-SDs are even worse - I've lost several already behind my desk and that's where they're staying.

I have to swap SD cards between devices several times a week and it ends up being a pretty big annoyance for me and they definitely do wear (both the SD cards and the readers) if you swap cards a lot.

[rje 193]

YES on using the emulator!  That's a very good point.   (And yeah, it's also a good point that when we're working with hardware expansion we probably won't have the emulator to rely on).

But!  Yes, I think avoiding the SD swap two-step dance is important, and that's why we have serial transfer of one sort or another.  And it doesn't have to be "fast".  It can be the X16 waving little flags manually at my Mac and I'd be fine (*).

(*) exaggeration

 

Edited January 15 by rje

[TomXP411 304]

4 hours ago, rje said:

But!  Yes, I think avoiding the SD swap two-step dance is important, and that's why we have serial transfer of one sort or another.  And it doesn't have to be "fast".  It can be the X16 waving little flags manually at my Mac and I'd be fine (*).

There are already solutions for the C64 that load data into RAM over the User port. It would be trivial to implement a similar solution on the Commander. 

And, again, don't forget that I've already put together a basic spec for communicating in parallel over the User port. All we need to do is implement that in code (which we can't reliably do until we have hardware.) 

Edited January 16 by TomXP411

[Lorin Millsap 171]

Again to all the people discussing serial over the user port. RS232 serial is already planned. The routines just have to be written and the vectors are there.


Sent from my iPhone using Tapatalk