Fastest possible SD card Read with a 6522 VIA?

[NormalLuser]

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?

Is there an easy way to use the shift register on the VIA for data in?
I think the clock is 'backwards' from the VIA and needs to be inverted with a NAND or NOT or flipflop, is that correct?
I could use a shift register on the 8 bit port A and shift it in but what is a good way to clock that such that I actually save CPU cycles?
I'm not really caring about robustness, or saving VIA ports for other uses, just read as fast as possible with as small and simple of a hardware change as possible.

Any suggestions out there?

Thanks!

[BigDumbDinosaur]

I’d write it as...

Code: Select all

         lda #0
         ldx #8
;
loop     asl A
         ora VIA_PORTA
         dex
         bne loop

In writing I/O routines, it’s generally helpful to look at the overall picture before obsessing on how fast a particular code segment can run.  Even though my routine is slightly slower than yours, it will still outrun many SD cards, especially if your clock rate is significantly faster than 1 MHz.  At the same time, there are six instructions, versus 15, to help save some space.

That said, what is your assurance that each time you read from VIA_PORTA that valid data will be waiting?  In other words, what is handshaking your transfer from the SD card to the VIA?

[NormalLuser]

Thanks for the reply!

BigDumbDinosaur wrote:

I’d write it as...

In writing I/O routines, it’s generally helpful to look at the overall picture before obsessing on how fast a particular code segment can run.  Even though my routine is slightly slower than yours, it will still outrun many SD cards, especially if your clock rate is significantly faster than 1 MHz.  At the same time, there are six instructions, versus 15, to help save some space.

But I don't need to save space right now.
Unrolling is the least I can do to increase the SD read speed.

I can stream off the SD card a 47 FPS average, 4 color, Bad Apple video with vsync off with my current code.
That is 23,829 bytes a second streaming on average.
I'm using a class 10 SD card and my clock is 5Mhz, but with VGA halting I only get 1.4Mhz
1,119,963 cycles of my 1.4 million cycle a second CPU budget is spent just reading these bytes.
While my source is 30 FPS, the more complex frames are more bytes and take longer to render.
Some sequences are still less than the full speed I'd like. I am only doing square wave music, when I add digital I'll need even more data off that SD card.
Also, I only have 7.5k available for a read buffer and that just might not be big enough to smooth out both the video and handle audio.

Given this I think I might need a faster SD read (or to read less in the first place with a better encode) because I am streaming video data from the SD card as fast as I can now and I am already too slow for what I will want.

BigDumbDinosaur wrote:

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.
Once started the SD card will stream bits forever.
As long as you take into account a 10 byte CRC message every 512 bytes anyway.

I'm working on a better encoder/decoder that will help quite a lot by needing less bits, but with the digital audio I want to stream the math says I need to try to work this problem from both ends.

Thanks!

[BigDumbDinosaur]

NormalLuser wrote:

Once started the SD card will stream bits forever.
As long as you take into account a 10 byte CRC message every 512 bytes anyway.

Seems in this application the CRC message is superfluous.  Any way to tell the SD card to not send it?

[gfoot]

I've had a custom circuit reading SD cards by SPI using a 4MHz clock to drive shift registers, and the card was happy with that. I have heard that some cards may require a slow clock speed during initialisation, but it may vary from card to card.

It's possible to use the VIA shift register to read from SD cards, and get fast speeds (it'll clock the SPI connection at half of the PHI2 rate I think, so two cycles per bit) however it can be tricky to start and end the communication - I think once the read is in progress you'd be fine, but changing between reads and writes can require some careful bitbanging to get the clock phase right. You might be able to find some useful code in the MMFS codebase - it's an SD-card filing system for the BBC Micro. It supports several different hardware interfaces; the "Turbo" one uses the VIA's shift register.

[NormalLuser]

BigDumbDinosaur wrote:

NormalLuser wrote:

Once started the SD card will stream bits forever.
As long as you take into account a 10 byte CRC message every 512 bytes anyway.

Seems in this application the CRC message is superfluous.  Any way to tell the SD card to not send it?

I know, it would be great.
From what I gather from a couple of forum scraps is that while there is a command to turn off the CRC in the SD card spec, in the real world when you stream data off (avoiding the even larger overhead of dealing with asking for each block) the SD cards ignore that command and always sends the CRC for each block before sending the next anyway?

If there is some way to turn it off in multiblock that would be great!
But my google-fu fails to find me anything other than folks saying it just doesn't work?

[NormalLuser]

gfoot wrote:

I've had a custom circuit reading SD cards by SPI using a 4MHz clock to drive shift registers, and the card was happy with that. I have heard that some cards may require a slow clock speed during initialisation, but it may vary from card to card.

It's possible to use the VIA shift register to read from SD cards, and get fast speeds (it'll clock the SPI connection at half of the PHI2 rate I think, so two cycles per bit) however it can be tricky to start and end the communication - I think once the read is in progress you'd be fine, but changing between reads and writes can require some careful bitbanging to get the clock phase right. You might be able to find some useful code in the MMFS codebase - it's an SD-card filing system for the BBC Micro. It supports several different hardware interfaces; the "Turbo" one uses the VIA's shift register.

I want to make sure I squeeze as much out of a basic SD card to VIA connection as possible before moving on to other hardware.

Once I think I can't take that further without a whole PIC or whatever in there if I still need more speed I should probably just move to Compact Flash?
viewtopic.php?f=4&t=2877

But SD cards are way more convenient and I already have that working.

If I understand, once a full byte is in it stops shifting until you read that byte?
It would be perfect if I could get the VIA shift register reading in at half the PHI2 rate while I do other things for a few operations IE decode.
With one byte encoding it would make reads 'free' and other options unneeded.

Otherwise the setup/code you helped me with just might already be as fast as I can expect!
Thanks!

[drogon]

NormalLuser wrote:

gfoot wrote:

I've had a custom circuit reading SD cards by SPI using a 4MHz clock to drive shift registers, and the card was happy with that. I have heard that some cards may require a slow clock speed during initialisation, but it may vary from card to card.

It's possible to use the VIA shift register to read from SD cards, and get fast speeds (it'll clock the SPI connection at half of the PHI2 rate I think, so two cycles per bit) however it can be tricky to start and end the communication - I think once the read is in progress you'd be fine, but changing between reads and writes can require some careful bitbanging to get the clock phase right. You might be able to find some useful code in the MMFS codebase - it's an SD-card filing system for the BBC Micro. It supports several different hardware interfaces; the "Turbo" one uses the VIA's shift register.

I want to make sure I squeeze as much out of a basic SD card to VIA connection as possible before moving on to other hardware.

Once I think I can't take that further without a whole PIC or whatever in there if I still need more speed I should probably just move to Compact Flash?
viewtopic.php?f=4&t=2877

But SD cards are way more convenient and I already have that working.

If I understand, once a full byte is in it stops shifting until you read that byte?
It would be perfect if I could get the VIA shift register reading in at half the PHI2 rate while I do other things for a few operations IE decode.
With one byte encoding it would make reads 'free' and other options unneeded.

Otherwise the setup/code you helped me with just might already be as fast as I can expect!
Thanks!

Not really a solution for you - or at least not for the initial brief of no extra hardware, but I have had good results reading SD cards with an 8Mhz clock, but not in streaming mode, but in block at a time mode - as that suits my filing system(s). However my systems to do this involve an ATmega.

Some other thoughts - Just thoughts.... What about an SPI EEPROM? Easier to setup and read and they stream really well.

A "black box" device with SD card on one side and 8-bit + strobe & ack interface on the other side to interface to a VIA? (The black box in my world is an ATmega, but could be PIC, etc. whatever you are familiar with that has an 8-bit port with a few signals you can bit-bang).

Slow setup + Fast access - Yes, SD cards should be initialised and probed at 400Khz then you can ramp up the speed. SPI on the ATmega is max. fCPU/2, so 8Mhz on my 16Mhz systems, but can be higher, and I've never had any issues with them.

But going to the "black box" means above - that's almost like a parallel access IDE drive, or CF, etc.

A dedicated SPI engine is the way to go though - CPLD/FPGA ..

-Gordon

[plasmo]

NormalLuser wrote:

Once I think I can't take that further without a whole PIC or whatever in there if I still need more speed I should probably just move to Compact Flash?
viewtopic.php?f=4&t=2877

All my CF interfaces are bus-connected, ie, connect 6502's data bus directly to CF's data bus and drive CF's address lines directly with 6502's addresses. So you only need to worry about 3 control signals, CF_select, CF_write, and CF_read. CF_select is just address decode (not qualified with clock); CF_write is CF_select qualified with clock and write; and CF_read is CF_select qualified with clock and write_inverted. At 5MHz, you don't need to worry about wait state. The logicstic of hooking up 8 data bus, 3 addresses, reset, and 3 controls are significant, but you are rewarded with 8-bit parallel transfer, as fast as you can move data.
Bill
Edit, at 5MHz, CF data transfer is fast enough to support executing data streaming out of CF as instructions. Another word, reading a CF byte every 5MHz clock cycle

[NormalLuser]

drogon wrote:

What about an SPI EEPROM? Easier to setup and read and they stream really well.

I have thought about this. However I need 3 or 4 MegaBytes to store video and audio.
There are parallel chips that exist but with the shortage they seem to be hundreds of $$.
I can find some SPI chips but they are on the small side and other than getting rid of the CRC bytes they are not really any faster than my SD card reads since I still need to shift in serial data from them.

drogon wrote:

A "black box" device with SD card on one side and 8-bit + strobe & ack interface on the other side to interface to a VIA? (The black box in my world is an ATmega, but could be PIC, etc. whatever you are familiar with that has an 8-bit port with a few signals you can bit-bang).

Slow setup + Fast access - Yes, SD cards should be initialised and probed at 400Khz then you can ramp up the speed. SPI on the ATmega is max. fCPU/2, so 8Mhz on my 16Mhz systems, but can be higher, and I've never had any issues with them.

But going to the "black box" means above - that's almost like a parallel access IDE drive, or CF, etc.

A dedicated SPI engine is the way to go though - CPLD/FPGA ..

-Gordon

Thanks. I think before I get to complicated with the SD card if I just have to have the speed I should just go with Compact Flash. It seems to be the simple answer to the problem short term.
With CF cards on the slow way out though I'm sure soon enough SD card to 8 bit adapters will become the norm for retro storage.

[NormalLuser]

plasmo wrote:

NormalLuser wrote:

Once I think I can't take that further without a whole PIC or whatever in there if I still need more speed I should probably just move to Compact Flash?
viewtopic.php?f=4&t=2877

All my CF interfaces are bus-connected, ie, connect 6502's data bus directly to CF's data bus and drive CF's address lines directly with 6502's addresses. So you only need to worry about 3 control signals, CF_select, CF_write, and CF_read. CF_select is just address decode (not qualified with clock); CF_write is CF_select qualified with clock and write; and CF_read is CF_select qualified with clock and write_inverted. At 5MHz, you don't need to worry about wait state. The logicstic of hooking up 8 data bus, 3 addresses, reset, and 3 controls are significant, but you are rewarded with 8-bit parallel transfer, as fast as you can move data.
Bill
Edit, at 5MHz, CF data transfer is fast enough to support executing data streaming out of CF as instructions. Another word, reading a CF byte every 5MHz clock cycle

Thanks! If I can't get my encoding efficient enough I think I will go this route. And good to know it works at 5Mhz.

[Dietrich]

The fastest Code to read a SD card is, to my knowledge, this one:

Code: Select all

SPI_BIN	LDA IFR		;read byte from SPI
	AND #$04	;test SR bit
	BEQ SPI_BIN
	STA IFR		;clear SR bit
	LDA SR
	RTS

(courtesy Jörk Walke, JC ][)
It operates the SR unter PHI2 clock.
Writing to the SD card is however a different story due to the well established quirks of the 6522

Dietrich

[fachat]

With SPI EEPROMs you get the advantage to be able to use SPI mode 3. That enables you to use the VIA shift register to shift out with 4cycles/bit. For reading a single '164 shift register suffices, with its parallel output connected to a the VIA's PA or PB.
Also, transfers can happen while the CPU is doing different stuff.

SD cards are mode 0, which is not that easily done with the VIA SR, see discussion elsewhere in this forum.

Edit: here is the link to the forum post with just 2 chips extra to use the VIA SR with SD-Cards in mode 0: viewtopic.php?f=4&t=7937#p106623

[GARTHWILSON]

Dietrich wrote:

The fastest Code to read a SD card is, to my knowledge, this one:

Code: Select all

SPI_BIN	LDA IFR		;read byte from SPI
	AND #$04	;test SR bit
	BEQ SPI_BIN
	STA IFR		;clear SR bit
	LDA SR
	RTS

How about:

Code: Select all

SPI_BIN: LDA  #4
 1$:     BIT  IFR
         BEQ  1$        ; (shorter loop)
         LDA  SR        ; (This clears the IFR's SR bit.)
         RTS

[BruceRMcF]

fachat wrote:

With SPI EEPROMs you get the advantage to be able to use SPI mode 3. That enables you to use the VIA shift register to shift out with 4cycles/bit. For reading a single '164 shift register suffices, with its parallel output connected to a the VIA's PA or PB.
Also, transfers can happen while the CPU is doing different stuff.

SD cards are mode 0, which is not that easily done with the VIA SR, see discussion elsewhere in this forum.

Edit: here is the link to the forum post with just 2 chips extra to use the VIA SR with SD-Cards in mode 0: viewtopic.php?f=4&t=7937#p106623

I wonder whether one way to use the 6522 SR as a MOSI output and an SSR 74x595 as a MISO input with a 6522 and no distinct memory mapped active low selects is to connect PB1 to the /Mode0_Reset input into the NAND circuit and also to MISO_RCLK (pin12 in DIP package), and PB0 to /MISO_OE (the snippet of SPI_TRX below assumes that multiplexing of PortA happens at the caller of the SPI_TRX routine):

Code: Select all

    ... ; PB0, PB1 starts out set to 1
    ... ; DDR_A starts out SPI mode set to all input
    LDA #%00000010
    TRB PORTB ; this pulls down MISO_RCLK and resets Mode0
    INC PORTB ; this pulls up MISO_RCLK and pulls down /MISO_OE
    LDA PORTA ; read MISO SSR
    INC PORTB ; this pulls up /MISO_OE
    RTS

... remembering that the data stored at the SSR must have its bits flipped, since the 6522 SR is least significant bit first rather than most significant bit first.