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):


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!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for the reply!


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.



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!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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 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?

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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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

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.



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.

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.

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

(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

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

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

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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):



... 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.