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....