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:
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?
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...)
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...
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!
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.
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! :)
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 :)
Ooooo...cool :)
Ta!
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.
Post a Comment