Direct SD card access (SPI) on a 6502..

[orac81]

One interesting idea I saw on old XT PCs was a bit-wiggling interface for using an SD card as an HD drive via the printer port, using only resistors, diodes, transistors and caps, no external "helper" processor. I think the SD card can be accessed this way with a slow processor, whereas usb needs 16mhz+ processor for a bit wiggling i/f to work. There are threads on vcfed and vogons, here are some links:

https://www.vogons.org/viewtopic.php?t=62716
https://www.vogons.org/download/file.php?id=53412

quote.. "the Nilquader Driver needs only ~1,5k RAM and implents SPI in Software on LPT." This design uses SD card adapters with the voltage level adapter build in, which makes the circuit very simple.

If this was possible to adapt for a 1/2/4 Mhz 6502 via a 6522 VIA it would be of general interest for many 6502 based machines. You would think if a 4.7Mhz 8088 can do it, a 4Mhz 6502 could do it too.


Has anyone tried or done this? Any thoughts welcome..

[Orangeman96]

Sorry; I guess I am not seeing the application for what you are pointing at. -OGM

[srowe]

If this was possible to adapt for a 1/2/4 Mhz 6502 via a 6522 VIA it would be of general interest for many 6502 based machines. You would think if a 4.7Mhz 8088 can do it, a 4Mhz 6502 could do it too.

The code required to access the hardware is probably simple (the I2C code I wrote was less than 500 bytes). To actually read data from an SD card you're going to need code to read FAT partitions, that's going to be a lot more complex and require significant space (including zero page). You'll also have to patch the KERNAL to be able to access the device. Given you can build an SD2IEC for a handful of dollars, I don't see the appeal.

[brain]

To answer the OP, it for sure is possible.

Most SD cards are OK being clocked slower than maximum, so you're OK there.

The 6522 is a great place to start, but I'd skip trying to use the build in shift register. It seems like it would be a nice HW solution, but SPI is bidirectional, and the 6522 is not. With some clever programming and the ability to switch the shift register IO pin to connect to the SPI MISO (DI) or MOSI (DO) pins on the SD card, you might be able to make it work (I'm doubtful, but there's some smart folks out here), but I'd highly recommend you just use standard IO on the 6522 pins exposed on the user port.

I think a simple SPI protocol can be implemented in 1.5kB easy, but as @srowe notes, FAT can suck up a lot of code space. if portability is not absolutely required, you could layout the SD card as a 65535 track, 65536 sector disk, and then just implement the CBM BAM stuff. It'd still be non trivial code, but you could steal from the 1541 DOS if desired, and you can skip all of the IEC code, the command switch IRQ stuff, and verify and such.

If portability is required, FAT is your best bet, but it's gonna take 32kB at the end of the day to write all of that and then the FAT<->CBM conversion, as it's gonna be must of the sd2iec firmware, minus the IEC code.

From a HW point of view, connecting the SD card to the user port would require 6 resistors (3 each of 1800 and 3300) and optionally 2 additional IO lines (Write Protect and Card Presence) each with a 10K to 5V. The rest is just SW

If you wanted to pursue, I'd highly recommend hooking the SPI lines (CLOCK, DO, DI) to an arduino's SPI lines initially, for testing. That way, you can instrument and debug the low level SPI code with less hair pulling. If the arduino has 2 SPI ports, you could use one for your interface and the other for an actual SD card, with a passthru on the Arduino, simply passing the data it receives from the 6522 lines to the other SPI port, and vice versa. When done, remove the arduino.

[orac81]

Thanks for the feedback, some interesting ideas! I should say that I wasn't yet at the point of doing this yet on a Vic, but it was an idea i saw when i had an 8086 laptop with broken hd i/f some time back, its a simple way of making a hard disk that would port between machines.

Yes I was aware that there would be an overhead for DOS beyond the 1k or so for raw i/o. If you do try to make real dos, FAT16 (32mb) maybe a better choice than FAT32, make that the first patition on the sd, then the rest fat32, or whatever.

There are simple approaches that could be done in little ram, for example prepare a FAT32 part with lots of files in a subdir with non fragmented blocks, called FILE001.. FILE999, all at fixed positions, fixed offsets, say 64k per file. When a file is opened for write, the code steps through to find the first unused one, creates a header with cbm name, file size, start, type etc, then the bytes are written as the chars are sent until close.

For reading, scan through each file (simple offset step) looking for matching name. for dirs, much the same. Use a separate util (cbm or pc) to pack/unpack d64 images or prg files from/to this system.

There you go, a simple dos in probably 2k or so!
This could be portable to any 6502 with a via/cia, it would be cheap for pets where a sd2ieee costs about £100.

Another idea: pc partition table allow an offset at the start, you could have 64k of 6502 code at a fixed location with (say) code in 256 byte pages that can be switched around for different tasks. That way you might run a real dos using very little ram. With sd reading is fast, no delay for head/track movements, you can load as fast as you can shuffle the bits.

Bootstrapping is admittedly a problem, The driver could be loaded off tape/disk, or even a bootstrap put in the kernal cassette save or rs232 area of rom.

I do want to dig out some sd card holders and try to make something on vero at some point..

[Mike]

I was about to point you to 6502.org, but seeing you already had posted an equivocal inquiry over there and already got some answers there, too, then so be it. An application for that on the VIC-20 would imply - as the posters before me have pointed out already - quite some extra work to not only access the SD card's contents with a FAT file system, but also make the SD card be accessible from the VIC-20 in a way comparable to CBM DOS, i.e. mimicking at least most central aspects of file handling (directory, file access, delete, rename, etc.) to work like CBM DOS does.

Without the FAT file system, data exchange with PCs, i.e. 'filling' the SD file from the PC side becomes somewhat impractical; without use of the mass storage as if it was a CBM DOS like drive, programs would need to be specially rewritten to use that SD card adapter, each of those rewrites in a one-off fashion. As a result, one would not be better off than with the other already existing SD drive solutions. It would likely be much slower though, as now the 6502 in the VIC-20 has to do all the housekeeping for drive access and file system.

It is not an alien concept on the 8-bit CBM computers to delegate the processing power for media access and file system management to intelligent drives with an own CPU. That is what the contemporary drives (1541, etc.) were designed with in mind, that is what SD2IEC drives utilize today, and which could be leveraged up to the point of transfer rates to and from SD cards in excess of 100 KB/s - if the IEC bus in-between was eliminated.

[orac81]

I was about to point you to 6502.org, but seeing you already had posted an equivocal inquiry over there and already got some answers there, too, then so be it. An application for that on the VIC-20 would imply - as the posters before me have pointed out already - quite some extra work to not only access the SD card's contents with a FAT file system, but also make the SD card be accessible from the VIC-20 in a way comparable to CBM DOS, i.e. mimicking at least most central aspects of file handling (directory, file access, delete, rename, etc.) to work like CBM DOS does.

Without the FAT file system, data exchange with PCs, i.e. 'filling' the SD file from the PC side becomes somewhat impractical; without use of the mass storage as if it was a CBM DOS like drive, programs would need to be specially rewritten to use that SD card adapter, each of those rewrites in a one-off fashion. As a result, one would not be better off than with the other already existing SD drive solutions. It would likely be much slower though, as now the 6502 in the VIC-20 has to do all the housekeeping for drive access and file system.

It is not an alien concept on the 8-bit CBM computers to delegate the processing power for media access and file system management to intelligent drives with an own CPU. That is what the contemporary drives (1541, etc.) were designed with in mind, that is what SD2IEC drives utilize today, and which could be leveraged up to the point of transfer rates to and from SD cards in excess of 100 KB/s - if the IEC bus in-between was eliminated.

Ok some fair points, the sd2iec saves implementing a dos and is definitely simpler to use.
However you don't need a dos that has to shuffle 256 byte blocks and mess around with a BAM, the big size and speed of the sd can free you from that. (see my above post)

True, You can use a full 8bit input from a 6522 with an external atmega or other helper cpu for a very high speed, but then you have the same bootstrap problem.
Dont forget the SD2IEC only gives 1541 speed, without loading turboloaders into ram, (problem for seq file access), even with turbo they only get about the same speed as my idea.

As far as i can see, some of the tapuino/sd2iec devices only work fully on c64, partly on vics/+4, not at all on pets or other 6502s..

[Mike]

You might want to read these two threads, "Banked RAM cart" and "Ultimem or Final Expansion?", to see what I actually am talking about.

[brain]

As far as i can see, some of the tapuino/sd2iec devices only work fully on c64, partly on vics/+4, not at all on pets or other 6502s..

They should work perfectly on VIC and 264 series, as well as 128/128D/DCR and SX. If you want PET, I think there is PetSD for that (same idea, just IEEE 488), but for other non CBM 6502s, sd2iec will not work.

Jim

[orac81]

Thanks for that, yes I can see devices like the uIEC are the best/ easiest way to replace a 1541, particularly for a c64 where they support many turbo protocols. Some of the other devices ("tapecart" etc) are sold as c64 only although there is probably a way to make them work for the vic20 or pet.

Information regarding vic20/+4/pet turbo compatibility is often absent from the readme/help dox, but i can see a list of turbo protocols supported so for loading you just need a turbo loader that supports one of those. Most of these devices are very c64 centric, centering on exact 1541 compatibility for the c64 demo/game scene.

Good support for turbo seq file access is harder to find, as it was back in the day.

Really what i was thinking about originally in this thread was a little sd card holder mounted in a user port +cover (i have a few hundred of these!) that would run on either my pet, vic or 64, with a little device driver loaded off tape, as an experimental project. I have all the components.

That was the way the early apple2 computers did disk drives, directly with the 6502, which somehow seems more satisfying than modern helper cpus to me, although with failing 1541/c2n's such devices are becoming essential.

Back a decade or so i made my own user port to pc cable, with my own software, which i used to transfer all my cbm floppys to a Toshiba libretto micro laptop. It used 4 bit+handshake, and was very fast. I also have the cable that allows a pc with lpt port to emulate a 1541.

Anyway thanks again for the ideas and links.

[Wilson]

Thanks for that, yes I can see devices like the uIEC are the best/ easiest way to replace a 1541, particularly for a c64 where they support many turbo protocols. Some of the other devices ("tapecart" etc) are sold as c64 only although there is probably a way to make them work for the vic20 or pet.

For the C64, the uIEC/SD2IEC is severely limited in its support of specialized protocols. It's fine for many games (and many have been "fixed" to run it) but few modern demos will work. Many fastloaders make use of custom drivecode, which the SD2IEC does not emulate.

Information regarding vic20/+4/pet turbo compatibility is often absent from the readme/help dox

For most other Commodore 8-bits, there is little need for "turbo" protocols support. Most programs for these don't do anything too fancy and stick to the KERNAL's file I/O routines.

Maybe you could start with a simple SPI driver and then see what it would take to interact with the filesystem?

I agree that it's cool to do more with less. Ultimately, I'm not sure it's any more "pure" of an approach considering the SD card itself has its own powerful (by comparison) microcontroller.

[brain]

sdi2ec supports JiffyDOS, which is available on VIC, 64,128,264 series, for what it's worth.

But yes, sd2iec was always designed as a mass storage device, not a 1541 replacement, so that has to be kept in mind. It was also designed to be inexpensive, though Pi1541 can also be inexpensive and supports 1541 emulation.

[orac81]

Yes, and if you have a pi already, the 1541 "hat" is not too expensive. It depends if you are bothered with 64/1541 demo compatibility. Those modern demos/progs should really drop back to slow mode if the right hardware isnt there.

Interestingly someone pointed out this hackaday project:

https://hackaday.io/project/5789-65c02- ... -interface

which is pretty much what i was suggesting. Implements FAT16 in about 2k which isnt bad.

[Wilson]

Those modern demos/progs should really drop back to slow mode if the right hardware isnt there.

In many modern demos, and even some older ones, the effects, graphics, and music are streamed from disk as the demo plays. By the time song A finishes, for example, effect B has to be loaded and ready.

Also, a lot of work has been invested in loaders. Although there are more off-the-shelf options than there used to be, there are plenty of novel and interesting things to do in that space. It is very much part of the demo.

And even in less timing constrained demos, there are usually too many concerns with timings, interrupts, and zeropage-usage to reliably drop in a replacement loader.

Interestingly someone pointed out this hackaday project:

https://hackaday.io/project/5789-65c02- ... -interface

which is pretty much what i was suggesting. Implements FAT16 in about 2k which isnt bad.

Nice!

[orac81]

Some interesting points/code I was discussing at 6502.org:

http://forum.6502.org/viewtopic.php?f=4&t=8260

See this thread for hints to get it as fast as possible, even with bit banging: http://forum.6502.org/viewtopic.php?f=4 ... st&start=0

Now reading that thread i find this interesting titbit:

Hello.
Without extra hardware, is this the fastest possible VIA SD card read setup?
This reads a byte from a SD card in 46/38 cycles (non-ZP/ZP):

Code: Select all

    
    lda VIA_PORTA 
    asl
    ora VIA_PORTA 
    asl
    ora VIA_PORTA
    asl
    ora VIA_PORTA
    asl
    ora VIA_PORTA
    asl
    ora VIA_PORTA
    asl
    ora VIA_PORTA
    asl
    ora VIA_PORTA

gfoot helped me out over on my Bad Apple thread in programming with this setup:

I have the SD card data MISO data out pin connected to bit 0 of VIA Port A.
There is nothing else hooked up to that port.
That port is setup to clock on read and the clock pin of the SD card is hooked up to CA2 on the VIA.
The other SD card pins are connected to Port B.
Is this the fastest SD card read possible out of a VIA alone?
I think it could be?

Given that;
I'm also interested in the smallest hardware change that would improve the SD read speed?
If the VIA lived in zero page that would reduce the cycles to 38, but what else can be done?

......

I put the SD card in READ_MULTI_BLOCK mode.
When in this mode every pulse on the clock puts a bit on MISO.
With VIA PORT A setup to pulse CA2 on reads every read of the port puts a bit in bit 0 of the port.

I didnt know that mode was available, i could have used that VIA mode in my earlier projects!

Anyway if that is true, maybe this alternative code could be used:

Code: Select all

sdread256:
    ldx #127 
    ldy #0
loop:
    cpx VIA_PORTA  ; input on VIA bit 7
    asl
    cpx VIA_PORTA
    asl
    cpx VIA_PORTA
    asl
    cpx VIA_PORTA
    asl
    cpx VIA_PORTA
    asl
    cpx VIA_PORTA
    asl
    cpx VIA_PORTA
    asl
    cpx VIA_PORTA
    asl
    eor #255
    sta (destptr),y
    iny
    bne loop  ; approx 60 cycles/loop
    rts

(making a complete untested subroutine. no initialisation, may need other code in the loop.)

Its a tiny bit slower, but the other 7 VIA lines are free to be used. At 60ish cycles per loop, with a 1mhz 6502 thats reading the sd card at 16k bytes per second, which isn't too shabby.