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