Plus4 SD/MMC

SO, I've spent much of the day soldering away, and I've almost got the MMC part connected up. It's hard going though, and to top it all I think my soldering iron needs a new tip - again. The more I do of this, the more I wish I had that milling machine so I could just make a new board! Soldering in the sockets etc. is nothing, but stripping and soldering the wires is a nightmare!

Any-hoo, once I've done the last few wires, I'll try the code I have for reading the card and see how close I got...chances are it'll need lots of tweeking to get it working right.

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.

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.

Plus/4 External RAM expansion.

I've managed to get a proof-of-concept working; that is external RAM plugged in and working without any internal modifications at all. If I add a hardware banking register I could add up to 256 banks of 16k giving up to 4Mb RAM (although that would be a BIG stack of chips!). However, a 128,256 or 512k expansion would me much simpler. Its good to see it working, even if no one and nothing will use it!

Bearing that in mind.... I do wonder if its even worth doing any more on it as it simply wont be used! Oh well... its nice to know I was able to do it - it might be nice as a development tool though, and if I were to add an MMC card, then the extra RAM could be used as a buffer. The problem with using it as a devtool though is that the ram under it will be fried. Thats not very good, but if you were writing a program to actually USE it, then it wouldn't be a problem as you would never use the upper 32k of the machines native RAM.

Heres how I switch it on and use it....

     sei
     lda #$ff
     sta $fdda       ; Enable Upper and Lower external banks

And thats it really... The idea is that BANK 0 is always mapped to $c000-$ffff, while $8000-$bfff is user selectable via a register somewhere. And finally, heres the equations for the GAL.

 /WRITE = A15* /A14* PH2* /RW               ; WRITE Enable  (32-48k)
 /CS =    /C1LOW* A15* /A14* PH2* RW        ; Chip Select on READ access  (32-48k)
       +  A15* /A14* PH2* /RW               ; On WRITE access  (32-48k)
 /OE =    /C1LOW* A15* /A14* PH2* RW        ; Output ENable on READ access  (32-48k)

Memory Mapped LED - Phase 2!

If you remember a while back when I was doing my Plus4 LCD screen, I spent a lot of time simply mapping a BYTE into the Plus4 memory space(Blog HERE). Well, I finally found something that will assemble source files for my GAL's, so I decided to play with trying to get my RAM expansion idea working. The first thing I had to do yet again, was map a byte into memory, but this time it was FAR easier!

You can see from the pictures that theres a LOT less, and even less soldering! Fantastic! This is the one bit that really puts me off doing any hardware stuff, I really dont like soldering that much. Well, with these GAL's, a whole array of chips have collapsed into 1! Not only that, but theres a lot more pins available, so I can add even more functions, and reprogram it as need be! Brilliant!

I did know what they were able to do before, but I was unable to make them until today when I found a program called fgal.exe, which is basically a GAL assembler. Now I can simply assemble this line...

     WR = A15* A14* A13* A12* A11* A10* A9* /A8* PH2* /RW

.... and I've done all the work of those 4 other chips! Great stuff. Now I can actually try out the external 256k RAM pack idea I had, where I dont modify anything internally... could be neat if it works!

One thing that would be very cool, is a pass through connecter, but from what i hear, you dont get these edge connectors any more... pitty.

I'm thinking of saving up for a milling machine so I can cut/make my own PCB's easily, this would mean that once I design it, I can (more or less) press a button and get a prototype board out! These are pretty expensive, but I think it'll be great fun so I hope to have one by the Christmas holidays...I hope.

XeO3: Fire!!!

So here we go - I've got the basic weapons running, I can select a weapon and power level and shoot things, so all I need now is the incremental upgrades/downgrades. I've been changing the power levels Luca came up with to make a smoother increase/power level. We won't know for sure until the whole game's done, and we can see just how hard the levels should be.

XeO3: Weapons!

I've finally started to put the weapons systems in - or rather, I've run out of more interesting things to do, so I may as well put the weapons systems in. Theres nothing much there just now, I've just started putting the tables in place to control them, and now I need to think what else I need to add to them. Things like maximum repleish rate, power etc. I'll get these bits decided tonight, and then start on the actual code after that. It'll be interesting seeing the real weapons in place and gettting things powering up right, and when you get right down to it, weapons are the driving element behind the gameplay....

FEK!

And....bugger....My C128 has died on me. No idea why, just stopped powering up. FEK'in hell... Oh well...I'll probably butcher the PSU so I can use it, but I'll try and get another from ebay...bugger...NOT happy... I've NO idea why its dead, and not even sure how I could figure it out. At least it didnt take the SuperCPU with it!

I was also thinking about the sprites... Currently I store 3x3 chars and that lets me keep the sprites simple.....BUT....I "could" strip the lower 3 chars and add code to manage it. It would free up some 3.5k, but the code would be pretty complicated (like it isn't already!). I'll have to think about it, I'm not sure....

I think I'm going to finish my assembler, and then get bak onto XeO3 again.... Oh well...

65816: The power of 16bit.

I've been wondering just how much faster the SuperCPU actually is to a stock C64, and aside from the x20 jump you get from the raw clock speed, the new instructions and 16bit nature give you an even bigger boost - Alomst another x2! Heres a little example....

The scrolling in XeO3 takes a long time, every game cycle I do this:

         ldx  #39
ScrollLoop
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*00),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*01),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*02),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*03),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*04),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*05),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*06),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*07),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*08),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*09),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*10),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*11),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*12),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*13),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*14),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*15),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*16),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*17),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*18),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*19),x
         lda  BackBuffer,x
         sta  HWScreen2+$400+(40*20),x
         dex
         jpl  ScrollLoop1
         rts

This code is self-modified to address the new location of the back buffer, and I have to use a jpl (macro) since a normal branch is just out of reach, so this takes (40*21*9)+(40*7) = 7840 cycles. (this is approx as there are also page boundary crossings hidden in here.)

Now in 65816, I can do exactly the same but being 16 bit, the loop is half, and although we add a couple more cycles for LDA/STA, its still much quicker. So the loop is now (20*21*11)+(40*7) = 4900 cycles.

And now lastly, the 65816 has a block transfer instruction MVN+MVP which are like Z80's LDIR instruction, which means (BEST case) its now (20*21*7) = 2940 cycles. Now, although the block transfer would be broken up a little mode (to do lines mainly), its still only going to be around 3000. So not only is more than twice the speed as the 6502 version, but we have the new 20Mhz clock as well.

..............Bitmap blitting suddenly becomes REALLY interesting!!

Snasm: 65816

I've done most of the assembler stuff - not all, but most - to the point that I can now build simple programs. So I've built a simple 65816 program, and it appears to be falling over; and I've no idea why! These kinds of things suck coz I can't debug it at all - just try new things over and over until I get somewhere....

Heres the code....

        opt    prg
        opt    C64=START     ; Insert BASIC header, and jump to start of the code
        opt    A65816        ; Set 65816 assembler mode

 
        org $1000
START:
        longa off
        longi off
        sei
        clc            ; Set processor to 65816
        xce            ; Set 16bit processor mode 
 
        rep   #$30
        longi on
        longa on

        lda   #$0000
        sta   $20
 
Here:
        lda   $20
        ldx   #$1000
Here2:
        sta   $0400,x
        dex
        bne   Here2
 
        inc   $20
        jmp   Here   
 

If I dont put it into 16bit mode, it appears to work fine, but execute the rep #$30, and it dies.... I'm not sure why... If I didnt know better, Id say there was an interrupt going off - I wonder if the NMI's are still on....

Snasm: Addressing modes.

I've finished the last couple of new addressing modes the 65816 has, so tonight I'll start throwing in the new instructions which won't take long and then I can start having a play on the real machine and see what it can do. The idea of a fully software driven game appeals to me, as in bitmap mode you can do some pretty big sprites without losing all your background tiles.

However... A multiplex is still a great tool, and you should never discard useful tools.

SNASM: 65816...

Almost done with the addressing modes. Only 2 small ones to go, and I'll do them tomorrow.

     EOR (dp,X)
     EOR sr,S
     EOR dp
     EOR [dp]
     EOR #const
     EOR addr
     EOR >long
     EOR (dp),Y
     EOR (dp)
     EOR (sr,S),Y
     EOR dp,X
     EOR [dp],Y
     EOR addr,Y
     EOR addr,X
     EOR >long,X

So the only modes left are sr,S and (sr,S),y - neither which I've ever used but I'll put them in for completeness. This hasn't been nearly as painful as I thought it would be, 2-3 days at most. I've still to add all the extra instructions, but they're all just implied addressing (TXA etc.) and are just table modifications. MVN, MVP, PER and BRL are the only ones that need special work, and they won't take long.

Oh....I've been using THIS page as an opcode refrence - pretty good too.

XeO3: SuperCPU...

I'm just running the current version of XeO3 on the my C128 with the SuperCPU attached, and I still cant believe just how fast it is... The whole game (as it currently stands - scrolling, paths, animations, turrets) runs in around 20 scanline. Whats amazing is that XeO3 is designed to run in 2 frames so that its a nice slow paced scroller so thats basically 2 WHOLE FRAMES with nothing to do but fancy stuff!!! How cool is that!

With the turbo off, its taking about a frame - which is a lot. It just shows how much faster the Plus4 really is.

Im also really pleased with the downloader - Because it uses control lines and not timing code; it just works! AND I can switch the turbo on/off as it downloads without it doing something horrible!

The only current issue is that while everything runs, the background tiles aren't being drawn correctly - for some reason. That's a bit of a bugger...

Edit: I think part of the problem is that the C64 version has a multiplexor runing everyframe, and the sort is as well - when it doesn't have to be.

SNASM: 65816 support....

I've been adding more addressing modes during lunchtime, so now I can do full 16bit immediate mode stuff. This also means I had to put in 8/16 bit flow control using new LongA and LongI, so you can now do commands like this!

        LongA   off
        LongI   off
  
        lda  #$ff
        adc  #$55
        and  #$fe
        cmp  #$12
        eor  #$55
        ora  #$55
        sbc  #$55
        bit  #$55
 
        ldx  #$23
        cpx  #$55
        ldy  #$23
        cpy  #$55
 
 
        LongA   on
        LongI   on
 
        lda  #$ffff
        adc  #$5125
        and  #$fe34
        cmp  #$1112
        eor  #$5544
        ora  #$5555
        sbc  #$5566
        bit  #$5532
 
        ldx  #$2312
        cpx  #$5542
        ldy  #$2363
        cpy  #$5513

Great fun!! I found out from the forums on Lemon64 that I can happily run my SuperCPU on my C128 in C64 mode without fear of blowing it up, so I can probably start to test some of the output soon.

I was thinking of doing a bitmap scroller an actually blitting the bitmap on each frame - which at 20Mhz, should only take around 1/5th of a frame!! wow thats fast... I could then also do software sprites on top of that! The great thing being that the sprites would be much quicker (aside fom the 20Mhz stuff) since I dont have to copy character data around - AND you wouldn't be limited by the character set either -its a bitmap! Colour would also be possible with this as well I guess... and thats not even thinking about C64 hardware sprites yet either!

Theres surprisingly little added to the 6502, a couple of addressing modes (and I'm doing 24bit Absolute addressing just now), and a few extra instructions that take no effort at all really. So this shouldn't take that long at all to finish this....

Edit: Thinking a bit more about this....I really need to update my C64 emulator to allow 65816; development would go much quicker if I had an emulator to run it in... I'm not sure how much effort that would be, I've not looked at it in years - since I put it on the PS2/XBox really.

Paradroid!!!!

At long (long, long, long, long, long, long, long, long, long, long, LONG!) last... TNT has started a proper blog of his Paradriod update. Its basically a disassembled, updated (a lot) and then reassembled version of the original game. He's making heaps of improvements and its well worth a shot if you haven't already. You can find his blog HERE

I've decided to start the work of upgrading my assembler to be 65816 compatible (which is used in the SuperCPU) as I fancy having a little play with 20Mhz of power! I know - Im jumping around quite a bit, but that happens as I try and keep my interest going. I'll probably play with this at lunchtimes at work, so I hope it won't get in the way too much. The 65816 is very neat and I've used it a lot in the past when doing SNES work (Lemmings2), its got full 16 bit registers although you can swap them back and forth. Its also got access to a full 16Mb of RAM (which my Super CPU has!) which could make for some REALLY cool stuff - lots of space for buffers and tables here! Also Zero page becomes DirectPage and it can move!! In Lemmings2 I pointed zero page at my graphics so that the code ran faster! I'll need to look out my SNES assembler manual to see the syntax I used in that, but all in all - it should be pretty good fun!

Edit: So I've just added my first new 65816 instructions! yeeeeeeaaa!!

     inc a
     opcode [$00]
     opcode [$00],y

I'm so happy... :) This does 24bit indirect addressing through the direct page register (the new movable ZeroPage)

You know something....the THOUGHT of filling even 4Mb with C64 graphics/sound is frightning.... On the SNES I had a ROM disk system, and most of the memory was taken up with that, but here... its RAM...so you cna actually DO stuff with it - outstanding! I may have to update my C64 emulator to allow 65816 code as well...Mmmm... even simple stuff without the need to fallback to 1Mhz for custom chips would probably do - I dont think anyones done a SuperCPU emulator before....

The other thing I didn't realise is that the 65816 is also 65c02 compatable...which means I can probably add 65c02 to the assembler as well...

RetroEdit: Painting by numbers.

I got basic editing in last night, although I really do mean basic. I can paint with 2 pre-defined colours - which isn't very handy. Now I need to put all the really boring editor stuff in to allow you to select colours from a palette, swap between them, validate the system its on, and then swap between systems....I hate editors :)

(oh....then save it all)

RetroEdit: Editing...

I've almost got editing working, I can click on the bitmap and it draws a pixel into the right place. Theres still loads to do, but it shouldn't take long now. Once I get editing and saving working, i can let Luca lose on it and try it out - it should help him do later level sprites. I'm expecting great things from him once he gets a good editor, as hes already done amazing things with - well, crap editors!

XeO3: Squishing bugs!

I've had a really bugging..well...bug! for a while now in the front end; after you die and return there I seemed to be losing a layer of stars and I couldn't think what it could be! My first that was that one of the couters werent being reset and so a layer was in fact 2, but I couldn't see how that was possible. So I then though that perhaps some stars were black, and I just wasn't seeing them. This wasn't right either - although I did discover some were in fact being made black - but it was fairly even throughout all the layers. Once I fixed that I went back to hunting for the missing layer.... Turns out my first instinct was right and a counter wasn't being reset! The slowest speed only moves every other frame and was being toggled with $FF and getting checked to 0, but since I use the game data area it wasn't being cleared to 0, which meant the EOR #$FF was setting it from one zero value to another, and so it was moving at the same speed as the middle layer.

Glad I fixed that, its been bugging me for a while now....