Sunday, July 22, 2007

MMC Reading...

Mmmmm....It just goes to show how well the MMC64 card was made. Currently I can load a full 64k in around 15 seconds (load is a loose term here...cycle through 64k of sectors is more like).

The MMC64 can load 61k in 3 seconds....damn thats fast! I think they allow proper access to it rather than SPI mode where the CPU "clocks" the bits in. I can probably speed that up by putting a PIC on there and having BYTE access to the card. But thats a LOT of work.

If I put a byte Read/Write port in there, then got the PIC to do the bit talking, then the Plus/4 could just read/write bytes. I guess that would be a x8 speed up (ish), but it might be a bugger to do. That would be almost on par with the MMC64 though, and with the higher clockspeed of the Plus4, I might even beat it.

I swapped the DataIn line from bit 3 (0-7) to bit 7, which meant I could use the BIT instruction to read it, there by freeing up the A register. So now I have a macro to read a bit like this...

GETBIT  macro
stx port ; Clock pulse
sty port ;

asl ; Shift incoming data to make space for new bit
bit port
bmi !skip ; Bmi is reversed
ora #1
!skip
endm

This is a special ReadSector() call used when reading the actual data (does 4096 BIT reads - 512 bytes), the write is longer and far slower, but doesn't get used nearly as much. Before I moved the bit from 3 to 7, I had to LDA, then AND, then deal with memory etc.... but by using BIT I can and the AND from memory without affecting anything else. I suspect this is about as fast as it can go via the user port.

10 comments:

TNT said...

MMC64 does the parallel-serial and back conversion in slightly over one CPU cycle. Had it been exactly one cycle or less, one could use REU to read/write full sector in 512 cycles! Too bad that's not true. 65000 cycles for data transfer, double that for waiting memory card to retrieve correct sector - 0.2 seconds to read in full memory...

What about this for getbit: "stx port; sty port; cpy port; rol" and "eor #$ff" after eight bits?

TNT said...

Drop the EOR, you have inverted the input bit so compare sets carry only when bit is not set.

(I really should be hunting bugs, but I'm hitting my head against a brick wall so surfing feels nicer...)

Mike said...

MMm.... Good idea, but I just can't seem to make it work - and Im not sure why!

It could be some of the bits are unstable (even though I've set all bit BIT 7 to OUT)...but all I get is $FF (or $00 of eor'd).

Either way...Im not getting correct results...MMm...puzzler...

Mike said...

GOT IT!!

If you WRITE $FC to the port, it doesn't work (still not 100% sure why not), but if I write $7C to the port, it works fine.

Top bit is INPUT anyway, so thats fine!!

Cheers dudeeee!

TNT said...

Of course $fc is higher or same than either $7c or $fc, so carry is always set...

I use this compare method in my loader, although a bit differently. AFAIK it's the fastest way to read serial bits except "stx port; asl port; rol" which assumes that data comes in right after X sets clock high.

Mike said...

I did try shifting the port, but that screwed with the CLK+DataOut lines... so I moved the input line to 7 so I could use BIT. But this is better over all...

Cheers!

Now to do some FAT16 reading! :)

TNT said...

Make data_out input when reading. No, this doesn't work anyway as SPI clocks data from slave to master when clock goes low, not before. Too bad, it would have cut two cycles and freed one register...

You may find this interesting :)

Mike said...

Ooooo...cool :)

Ta!

TNT said...
This comment has been removed by the author.
TNT said...

12 cycles per bit, frees one index register as well which should make data store faster. Untested, but I don't see why it wouldn't work.