Come and get it!!

I've now added the C64 frame work (and sample app) to the downloads links on the right, scroll down a bit and you can't miss it!

So to recap what I've given you to play with in the framework....

Initialisation, mainloop and interrupts all setup and ready to go.

Production quality multiplexor

Three seprate switchable sorts.

Simple collision detection system

General sprite animation system.

Game based keyboard and joystick routines.

Simple player control framework.

Lightning fast 8x8bit multiply routine.

Simple random number routine.

Built in MMC64 FAT16 file loader.

Simple example platform engine showing the framework in action.

And there you go. As a little aside, the example also has a byterun decompression routine built in that you can use as well. Its all very simple really, but if you have any questions (or find any bugs) feel free to bug me about it.

Hope its of use to you and gets you going on your next great game!

MMC64 loader finished

I've now completed V1.0 of the loader complete with PRG file loading. Its shot up a little to about 900 bytes but it's now functionally complete. The only thing missing (which isn't vital just now) is error checking on initialisation. Its not important because if youve done a game thats supposed to load from an MMC card and its not there, then you have bigger problems! I've just ordered a retro replay so I can check all is well with that too (okay, okay...Coz it's cool...)

So tomorrow night I'll try and knock up a new downloads page somewhere and get all this up for you lot to play with. I'm not sure what I'll work on next but I like the idea of using the MMC card loader in the C64 version of XeO3.

I also want to do a proper Super CPU version of the loader so I can start playing more with that. I'd love to see how many software sprites I can pile on a bitmap screen, and I'd love to try that Lemmings idea too...

MMC64 cleanup

I'm putting the finishing touches to the MMC64 loader and making it work with more files. I've also shrunk it down a fairly sizable amount, with the code shrinking from 1,236 bytes down to 828 bytes (sofar) and the data block has shrunk from 624 to 568. While doing this I've optimised the load a bit so that the bulk of the file gets loaded directly into the destination rather than going via a sector buffer, which should make it twice as fast - in theory.

I'm pruning down all the "nice" bits and making it a bit more hard core C64 only - something I'll reverse when I do a SCPU version in the future. So for example while file sizes can be a full 32bits, we know a stock C64 will be less then 64k, so only work in that size.

That said I've tweaked quite a bit of it so it is a little bit more robust, but it will be likely to fall over if you use it wrongly, which isn't a problem as its not designed for a file browser, but a game that KNOWS what its loading. I've also decided to ignore long filenames, because again a game doesn't care! In fact, chances are you're filenames will be something like L1\1.PRG or LEVEL1\DATA.PRG. But this for a game is fine.

I haven't done a directory search yet and I might not for the 1st release as that'll put the size up again, still we're now sitting at 1,396 bytes total for code and data which is pretty good indeed. So for now you'll either put the game directory in the ROOT or specify something like GAMES\XEO3\LEVEL1\MAP.DAT. I have also yet to do PRG loading, so that it gets the 1st 2 bytes and loads it into the correct address - that will complicate things a little, but it should be okay.

I should also say I expect SAVING to come in later versions as well as its not hard to save to these things, so high score tables or editors can make use of the storage medium as well - which will also be pretty handy. Also...I do not disable interrupts, so technically speaking, you could be playing music, scrolling the screen or whatever while you load things. Also means the SCPU while taking time to load a meg of data can play music and display a loading bar or something!

So... only a little more to do for a 1st version, then I'll knock up antoher web page and post everything for whoever wants it.

Success!

I've now managed to load a file from the MMC64 given a full path+filename! Very cool indeed. It's a shame that you can't page in a ROM that has this functionality built into it. My plan of doing a Plus/4 MMC card was to have a built in ROM with lots of extra features built in like the Kernal, that way adding loading to a game would ultimately be very cheap and you wouldn't need to add all this code.

Still... thats a future thing, for now I need to test this code and load up lots of other files and make sure it all works. Im pretty sure it won't be terribly fast either as its pretty noddy code, however keep it simple and get it working - THEN speed it up and make it impossible to read.

The code is sitting at 1,860 bytes long (1,236 code and 624 data) so it would be nice to shrink this too. If the code can fit inside 1k that would be perfect I think. RAW loading is pretty simple, but including path searching and other features will push up the code space a little.

Anyway... all this aside, it's now working and is pretty cool. As a side note it should now be possible to load large files for my SCPU work; very neat.

MMC64 Progression...

I've progressed quicker than I figured I would and have almost got files loading from it. It also supports directorys and will load a file from a full path+filename (just about). It only uses 8.3 filenames so far, but I suspect it will get expanded to do more in the future.

It takes arond 2k to add this although 600 bytes of it is data and a sector buffer. I suspect this will shrink a little once its all working properly, but to have fast access to 4Gb's of data is probably worth the extra space.

I also plan to put in a recursive directory search, allowing you to search for a game directory and then load from there. That means people won't be forced to put everything in the root directory.

I will also write a full Super CPU version allowing you to load megs directly into memory, and MUCH quick than a floppy could.

Life after floppies....

I've spent a little time trying to chat up my MMC64, but it just won't respond to my tender words, at least I wasn't having much luck until about 5 minutes ago. I was following the documentation completely - cut and paste actually - but with very little to show for it. It then occured to me that since I'm loading from it, it must already be enabled and ready to go. So I've dispensed with the full initialisation and jumped straight in with sector reading, and what do you know! It works! I'm not quite sure what would happen if you have to re-initialise the thing as I can't seem to get that going at all, but as long as the cards in and you've just loaded the main program from that, its all funky.

For a first pass, not having any error state is probably fine, after all its not like you have to swap disks (err...MMC cards) during a game or anything, and if you remove the card then its probably your own fault. Still sometime down the line doing a better fault tolerant system is desirable - but lets get the bugger working first! I still expect this to be released in V1.1 of the framework, but its good to see it shouldn't be too difficult.

I've also added a simple animation system to the framework even though I said I wouldn't. I figured you can always rip it out, and in the end the ones I write are almost exactly the same over and over again so sod it. This means theres now the multiplexor, a few sorts, basic collision, animation, joystick and keyboard input and a very simple test app - which is a good start. Actually, theres 2 test apps. The Frame work has code to bounce sprites around in a simple manner, and then theres the playformer framework which gives a little more realistic usage. Still the more the merrier.

I'll now have to do another web page to download all this rubbish, and expand my wiki page to have some simple documentation...and I mean simple...

C64 framework V1.1?

I've thought of one more thing I'd like to add, but its not a quickie by anymeans so I'll leave it till version 1.1 so that I can get this version released. After speaking about using the MMC card as a loader, I suddenly realised that it would be awesome to have a proper file loader built into the framework. That way these no excuse as to not use it, and it'll make development MUCH simpler. Simply bung your files onto an MMC card in a folder or something, then load them - how simple would that be! It might also mean we would start getting some more games that load directly from the MMC rather than floppy/tape, which would be very cool.

I also suspect V1.2 will be when I start to add remote debugging features through RR-NET. As I've mentioned in the past I do have the beginings of a remote debugger on the Plus/4 and would like to get that onto the C64 but using the ethernet adapter rather than the user port. Although since the upload/download part is prett much GetByte()/SendByte() I can probably have both in case people don't have an RR-NET. It would be good to get a proper devkit again as I was reading about the old PDS system I used to use and starte getting a little homesick for it...

You can read about it HERE if you wish although its in spanish. HERE'S a translated version via Babelfish. It really was an amazing little system and I miss it hugely.


Oh and as a little side note, I've managed to get WWW.XEO3.COM again. I'd let this expire and some bugger pinched it which is why I went to the .ORG, but I've now got it back again so I'm happy.

Slow progress....

Well, after listening to the Scotland v Italy match on the Radio I'm wondering if I'll ever speak to luca again!! Oh well, its our own fault - as usual. We should have beat Georgia. Everyone was complaining about the refereeing, but I think it swings both ways. Never mind....We've improved loads and had a great campain - Well done Scotland! Ya done us proud!

Oh well, after that how have I been doing...... slowly. Not had a lot of chance to do much, but I hope to do some more paths tonight. I really hate doing them, but Luca (SPIT!) is still learning the script so I'll be doing these one, but I hope he can start doing some for the actual game.

I was also thinking about the MMC card stuff. I really screwed up here. By not doing a schematic first, I have no idea where all the wires are going, so now I either need to start again, or revese engineer what I had started. Im also thinking I need to do a Plus4 user port version so that I can test out code and allow SID usage. A userport card would be much easier, and if I supplied a ROM (or ROM image) then it could still boot properly.
It does mean this version wouldn't have the clockport so couldnt' do the ethernet/serial addon's. Im still trying to get a milling machine what would let me make real boards, and if this was possible then I could make the card here....Oh well... Still lots to do first.


Oh, and theres a new POLL. The results of the old one were pretty predictable with no one really interested in an external RAM expansion.

SD/MMC+Clockport Prototype

So here we go again....I've started the SD/MMC+Clockport interface. While it should be fairly simple, I've not connected a clockport before, and I need to decode the lines pretty much down to the byte this time; for both the clock port and the MMC interface. This means the board is pretty full so I won't be able to add the RAM to this test one,but if I was making a proper board, theres nothing saying I couldn't do it on that. While I couldn't see any real use for a RAM only interface, this one I can (with or without the extra RAM). Having an MMC card slot and a clockport on a card would be pretty cool, and allow all manner of C64 apps to be ported, along with allowing the +4 onto the Net - or simply better comms to the PC. But best of all really is that anything that someone makes for the C64's Clockport, would be usable on the Plus4 (with a little relocation - something +4 guys are pretty good at!).

Of course, if I added some RAM (128k,256k or 512k extra) it would mean that any clockport applications (like a TCP/IP stack or game) could make use of it, since you'd know everyone else running it would have the extra RAM as well. The only thing that worries me is the physical size of the interface. The C64 one is full of surface mount stuff - professionally done, but I guess this wouldn't be....

Oh well... first things first - lets get a working prototype and then worry about the rest of it!


Edit: Oh! And the little voltage regulator at the top, was just to see if I could solder one on without making a complete hash of it!

Getting orginised.

Yup, not been doing much.... A load of chips/parts have arrived so I've spent a couple of days sorting out my parts bin into some sort of order. I got fed up with not having the chips I needed/wanted, so I'm slowly trying to buy a few of everything (common chips at least), buit this means making some space for things.

I've also managed to source some pin headers for the clockport stuff, so Im going to start wiring up a SD/MMC+Clockport interface for the Plus4 next then I can start to have some REAL fun!!

I still need to finish doing the basic directory on the MMC, but that shouldn't be a big issue, and then loading a file should simply be a matter of getting the inital cluster from the directory entry, and reading it in.

I'm kinda looking forward to playing with the clockport the most, as it could mean some cool off the shelf toys for folk. The ethernet contoller looks the most fun, and I have the UDP slave source here to try out. Could be good!!!

I'm off to SigGraph in SanDiago next friday (3rd Aug), so I'll be back on XeO3 at that point, and I hope to get some stuff done on the plane again; but as usual it depends on how close the bloody seats in front are!

MMC Success!!

And here you go!! The ROOT directory in all its glory! I'm not parsing past the end of the 1st sector, but thats okay for now. I can now plug in any card (I have 3; 32Mb, 256Mb, 2GB - all FAT16) and I can display the ROOT directory of each of them. I guess the next thing to do is load a file from it..... or I could finish displaying the root directory, and sub directorys of course. But loading a file is pretty exciting stuff :)

I dont really want to get too far into it, as the main goal is to do a Plus4 version, not a C64 one. Although the code will be identical so its not wasted work.

Another big thanks to TNT for helping be get started with this....

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.