MMC progress...

Well, I'm slowly progressing with my MMC card reading, I've gotten sector reading working okay, and from there read the boot sector with the partition information and then onto the FAT Mast Boot Record. However, I'm struggling to get from there to the root directory. The only info I have says that I use the root FAT+ReservedSectors+FatSectorSize = DirRoot, and while this works for one card, it appears to be coincedance.

Once I can get the root directory, it should be plain sailing to load a file. Each Directory entry points to a base sector (or cluster) and from there you use the FAT to cluster hop, reading in the file. I have to confess, I thought sectors were allocated rather than clusters and that sectors were resizable. But it appears that its the number of sectors in a cluster that changes. oh well, its much the same I guess.

Once I have a file loading, I'm going to build a Plus4 interface - or add it to my MemoryCard expansion, Im not sure...I guess it would be easier to build a seprate interface, although Im having a little trouble figuring out the best way of reading the card. The only way I can figure is using 2 flipflop buffers, one for in and one for out. However, the ChipSelect on the card may help with this, I havent sat down and worked it out yet.

Speed up!!

Well, thanks to a quick bit of spotting by TNT, Its down to around 11 seconds for 64k! Around 3 scanlines a byte - well cool... Thats actually usable as it is I'd say! And although it will slow down a bit (due to saving the output to the correct place, sector selction etc...) Thats still bloody good. Anyway, heres the brainwave TNT got...

GETBIT3 macro
        stx   port         ; Clock pulse
        sty   port         ;
        cpy   port         ; if Databit is 0, then Carry clear, else set.
        rol
        endm

Very cool indeed...Branchless, and 4 cycles per bit quicker... I NEVER would have spotted that one!!

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.

MMC/SD reader....

Well, I've managed to get basic reading working, or rather the basic circuit and reading using the sample program. However, thats half the battle. I was struggling a little due to lack of proper chips, but I've managed to pick up the correct ones, so I'm back on track. I'll get the core Init/Read/Dir working, then I'll switch to the Plus/4 and see how I get on from there.

I suspect that I'll do it as an expansion card and not USER PORT plug-in though, as it allows me to download via my cable to program it - and perhaps even use my remote debugger which is partly written.

RR-Net and MMC cards

I've been playing with a cool little design for an MMC card reader on the C64, mainly so I can understand it and then try it out on the Plus/4. I've had to modify it a little as I dont have the chip he's using, but it should still work okay.

It's a user port based one so is easy to play with, but it did mean I couldn't use my download cable! Damn! However, now that I have an RR-NET, I found a cool little program called udpslave, which is exactly like my download program anyway, but over ethernet! Very neat. it also means you dont need a parallel port anymore, so I could use a laptop.

The more I look at these things the more I think it would be very cool to have on the Plus/4. Its another fairly simple addition I could add to the memory expansion I guess, as it only needs 4 bits of memory (3 out,1 in).

Its in situations like this though, that I'd KILL for a proper remote debugger! This is the reason you need to step through the actual code on the real machine...Oh well.. back to printing to the screen I guess.

Clockports, RR-Net's, SilverSurfer's.....

I just bought a RR-Net and SilverSurfer and have been playing with them a little, and I'm pretty impressed I have to say! Since both these products are modules that just "plug-in", they would work just fine on a Plus/4, and all you need is to be able to map the port into a set of hardware registers - a GAL would work just fine for that! You can do it pretty simply with a couple of other chips, but GAL's are really cheap, and make development really easy, so sod it :)

Anyways.... TNT kindly provided me with a link to the data, so I thought I'd post it here (so I dont lose it mainly...).

                  CLOCK PORT 

                   +--+--+ 
         GND       | 1| 2|   VCC (+5V) 
                   +--+--+ 
         /INT      | 3| 4|   /SPARE_CS 
                   +--+--+ 
         /RTC_CS   | 5| 6|   /PWR_BAD 
                   +--+--+ 
         /IORD     | 7| 8|   /IOWR 
                   +--+--+ 
         A3        | 9|10|   A2 
                   +--+--+ 
         A1        |11|12|   A0 
                   +--+--+ 
         D7        |13|14|   D6 
                   +--+--+ 
         D5        |15|16|   D4 
                   +--+--+ 
         D3        |17|18|   D2 
                   +--+--+ 
         D1        |19|20|   D0 
                   +--+--+ 
         GND       |21|22|   /RESET 
                   +--+--+ 
 
 
 
Connection to C64 Expansion Port 
---------------------------------
 
 
  Clock Port Signal   |   Expansion Port Signal 
----------------------------------------------------- 
            GND      <=>  GND (22 and Z, not 1 and A) 
            VCC      <=>  +5V (2 and 3) 
            /INT     <=>  /NMI 
            A0-A3    <=>  A0-A3 
            D0-D7    <=>  D0-D7 
            /RESET   <=>  /RESET 
 

This should be really easy, and although you won't get NMI's, things like RR-NET don't use them anyway, and you can always POLL the hardware instead - pretty neat. I might even try and add it to my RAM expansion, as I need to decode other stuff there anyway.

Web site....

I've just "upgraded" to the new blogger template stuff, so some of the site may not look right, but I can't spot anything wrong just now. It has however allowed me to poll's on the bar to the right, and the 1st one is the RAM expansion. Please be honest when polling because it may well cost me money down the line.

Ram Expansion - Running test

I decided to see if normal games would actually RUN with the expansion installed, so I connected the last address line needed and wrote a special uploader for it, then modified XeO3 to use the RAM expansion instead of normal RAM, and here you go! It runs fine! No difference at all!

Theres no funny read,write or timing errors - it just works! Im not sure how Graphics would work there... You would have to set the TED bit for getting data from ROM instead of RAM, and if you switched bank, it would change instantly. However, if you keep the TED data in the lower half (or possibly top 16k), then you can use most of the RAM for "data". My sprite cache for example could be huge with this!! We could have LOTS of character set data - altering it as we scrolled through the level, or have the SID/TED music loaded into there freeing up normal RAM. Lots of things you could do... Also...16K of SID music per level would be well cool...

Of course....to get SID music, I'd have to do a SID add on with the RAM!! Not impossible, particually if I just copied SOLDER's - which already works great.

Super Expansion....

I've thought about this before, and Im still tempted by it; doing a super expansion for the plus/4. One with Extra RAM, SID and MMC all built in. this would be pretty cool, to the extent that someone might even code something for it!! Having simple access to mass storage (MMC) would also let you fill the extra RAM with ease, and mean your not bound by disk loading times etc.

Still, thats a long way off happening (if ever), but it would be pretty cool I think. I wonder how many people would want one? Could be fun!

Emulators...

I was just reading TNT's paradriod page, and read a great idea there, Emulator profilers. That is, using an emulator to give readings of things like memory usage, and general speed settings. This is a wonderful idea!! Having realtime profile information, just like proper development. I'll have to add this to Minus4 soon.