Led Scrolly

I've been playing with electronics stuff again. Just before stopping for the Christmas break, Russ was moaning that I still hadn't finished my big scrolly message board, so I thought I'd have a crack at making a real life board using some some printable solder mask I got a while back. It took me a while to get things right (and I had to go and buy a cheap disposable Iron for it too), and the nerve to break out the chemical solution for the copper board, but once all that was done, I mananed to get a reasonable 1st attempt at a board.

It's taken a little bit of time to get it all working, as I'd made a right hash of some of it, so I had to cut some tracks and solder in wires to bypass mistakes. However, its working now, so in theory, I could now think about sending off to get real boards made!

I still need to work on the master PIC side, along with the PC comms. The idea is I'd use a TCP/IP or UDP interface (perhaps even wireless) and allow simple bitmaps to be sent. The mastr pic would then send this to the correct module.

I do have the basics working just not the PC comms side. The image on the right is the finished (one sided) PCB, and as you can see it still has quite a few jumpre wires. I dont want to make double sided boards at home, way too hard. If I ever get my milling machine, then I might give that a go - in fact I simply expect that to work.

Still, its nice seeing the actual PCB in all its glory, and I may end up making a board that can hold 3 modules just to see what it looks like!

One thing I would say, is that with the software Im using just now, it really doesn't route very well, and I do end up putting a lot in by hand. It could just be because this is a cheap bit of software.... I dont know.

XeO3: Late again....

Well, what would this project be if I actually managed to do something on time...*sigh* Oh well. Family and a stinking cold have knocked me around a bit and I'm no further forward, so I;m simply unsure as to when I'll manage to finish it now. I had hoped that I'd have loads of free time over Christmas and new year, but as it turns out, my wife is working, so I'm looking after the kids. Oh well...

That said, rest assured that we are still doing this 1 level test and it is coming soon; just not as soon as I had hoped for. On the plus side, Luca has been making some scripting doc's which you can find on the main page, so that when it IS released, you'll be able to make your own level if you wish.

If you happen to read MicroMart, you'll notice Shawn's 5th year there has ended, and still no XeO3 in sight - sorry dude. Lets hope I get a little free time soon, and we can finish this and progress onto the main event...

Edit: Oh, and I've also decided things are a little too easy on the test level, which leads me to think that the baddies should shoot at you - as well as the turrets. So I'll probably add that after the demo level is done.

XeO3: Damn....

Damn, damn....damn..............damn.

Running out of time; so much for getting a level done by Christmas! I have done a little more on it, so its not totally dead in the water. I'm also now on holiday so I hope to be able to do even more. However....a couple of things still left to do.

1) Finish the paths - I HATE doing paths.
2) Update the weapons system so that it has a power bar and it downgrades as you play. This idea is still a work in progress, so it'll be interesting to see exactly how it'll work in practice. I suspect it'll need some tweeking as we go.
3) Strip out all unused baddies for the demo.

And thats about it. So not a lot, but a lot to do in a couple of days. It may be I have to aim for NewYear, and not Christmas - but I'm not giving up just yet.

XeO3: Path debugging.

Almost there. My 1st pass of the Path Fast Forward is just about done, but it doesn't seem to quite match up. My timing appears to be out by a quite a few script cycles as paths are coming on too early. If you remember a while back I was talking a bit about my script engine, and each instruction was 0 or 1 cycles. Well I've built some code to skip over instructions and process PAUSE's by subtracting them from the number of pixels I have to scroll.

Anyway, while it appears to be roughly correct, its not perfect. If I skip $10 macro blocks (=384 pixels) then sprites are simply coming on too early. That said, its realy nice to be able to skip forwards like this.

There is a downside though. If you stop the scrolling, the FastForward will try and find the next one that starts it again (as you can't advance in pixels while the screen is paused). BUT if you stop the scroll and dont start it again, then keep the master path going with an infinite loop (using a pause and goto), then the FastForward will lockup as it never finds a restart. However, as long as this is know, it should be okay.....

Commands like PAUSE/NOP are the fastforward's bread and butter, since it simply subtracts the pause count from the number of pixels to move (1 PAUSE/NOP = 1 pixel scrolled). But for some reason they aren't matching up properly - yet.

XeO3: More debugging stuff.

Well, not DEBUGGING as such, but stuff to help making paths that little bit simpler. The current problem I have with creating new paths is that I have to scroll through the whole level to see the path I'm doing. This means everytime I make a minor change, it takes a few seconds good seconds to get to the point where the path is even before I see the alteration. This is a pain.

So, I've decided to add some code to try and fast forward the level before the game starts which means I should be able to design the paths where the are supposed to be, without having to use YAPE's warp feature to get there.

For the scroll this is pretty simple; draw tiles until I'm there. But for the path script its a little harder. I need to have a dummy process where I look at the command and process its cycle count, but dont process the path. Basiclly run the master path in TURBO mode too. This means when the screen fades on, there won't be baddies there, but all the counters and locations will be right.

Well, thats the theory...


On a little side not, I was thinking that now I have the SuperCPU drawing a software character map into a bitmap, theres nothing stopping me drawing lines right over the top of it all - or even polygons! Because I don't have ANY character problems, I can use the screen like the bitmap it is and possibly draw R-Type style lasers with lines that bounce around the screen, or perhaps draw a 3D baddie; although that might look very odd....

SuperCPU: Scrolling...

I've managed to get Level 1 of XeO3 scrolling on the SuperCPU using my software character map - well, a test anyway as the map is still 8bit, but that would be a simple change. What this now means is I can now load up and convert the sprites into a BITMAP system, and then see how many I can draw!

The other thing I was thinking was, why am I sticking to the normal 40x21 layout? Why now 21x40? Storing the screen in columns makes sprite drawing much easier and would fit a lot better with the internals of the sprite system.

One thing that "may" now break is the optimised sprite render as I no longer know if a space has been printed. I guess I could carry on as normal using a character system since I now have no limit on the characters available, but Im not sure. My gut tells me that in the long run, it would be slower, still that "space" optimisation is very cool and speeds things up hugely....

Watching the scrolling go its a little dishartening as it looks just like a normal C64 version. But I know its far cooler as being a bitmap I can now have 3 colours per tile AND since its a software charactermap I can animate ANY tiles I want and have the whole screen move without batting an eye!

SuperCPU: Now we're getting somewhere!

After the disappointment of last night, I realised this morning that I dont need to copy the whole screen - just 21 lines of it! Knocking off 4 lines saves a fair bit, particually since I dont have to generate them either! So what this now gives me, is the whole bitmap printed from scratch and copied well in just over the lower/top boarder (when I start on the 1st line of the panel).

It also means the RAW copy can take place inside the boarder area, meaning theres no longer any problem with rendering to an offscreen buffer and blitting down.

So next thing to do tonight is to get the XeO3 scroll working again! This should be pretty easy, as its now still just a character map, albeit a 16 bit one!

I'm also pretty confident that I can get my multiplexor happening along with the BLIT well inside the boarder area, which means I would already have 16 sprites, and now just need to add loads of software ones and see what the affects like. I could also now burn sprites on the player so he could be super hi-res IF I manage to get lots of software sprites on screen. I think I could get 30+ running around....but only time will tell.

Oh...and the more I do of this, the more I realise I'm gonna need a debugger of somesort, which might mean I need to update my C64 emulator to do 65816/superCPU. Im not sure it would be able to run at full speed (because of how its written), but machines are getting faster all the time so I guess it would catch up!

SuperCPU: Damn that 1Mhz memory...

Okay.... It wasn't quite setup right. For those that haven't played with a SuperCPU, they have to do sime jiggery-pokery to write into the C64's RAM (So the VIC can see it), and I hadn't enabled that correctly. This means the block transfer of a bitmap takes AAAAAAAAAAGGGGGGGGGGGGGEEEEEEEEEEESSSSSSSSSSSS!!!!!!!!!! :(

If I trigger it at the panel in XeO3 (21 lines down) it "just" finishes before the screen starts again (well, almost).

The screen "building" (aka the software character map) "IS" very very fast is is practicle... but the copy into 1Mhz memory is horrible.

However.... Because I can use FAST memory for building up the screen and drawing lots of sprites, it should still work. It just means that I need to set everything up and take the huge hit for the bitmap copy..

As a reminder what this gives is a virtually unlimited character supply (no longer 256), Fantastic colours via the bitmap colour ram+Normal character RAM, AND as many software sprites as I can render in the time! No more are sprites limited by the number of characters I want to lose in the 256 bank.

As I side note.... I "did" finally get MetalDust to see what games on the SuperCPU were like, and I wasn't THAT impressed. Music aside (which Im not a fan of), I think it just looks like a polised C64 game rather than something you KNOW is done on a SuperCPU. If you look at games like Driller when they are run through the SCPU, its OBVIOUS that you have an enhanced machine, its SOOOOOOO much better. Metal Dust is just "nice", except it takes AGES to load, and basically scrolls a bitmap....

Id rather have quick loading (so not too much data), and try and fill the screen with sprites (hard+soft) to make it LOOK like a SCPU game. I know colour clash would make it seem a little "non-C64-ish", but I think allowing you to fill the screen more would just be nicer.

65816: Cool bitmap stuff...

Yeah, I know I know.... I should be doing XeO3, but the lure of 65816 code is too much just now! :)

Anyway... After doing my block transfer code for copying a bitmap, I started wondering how expensive it would be to physically draw the screen everyframe from a tileset. This then got me thinking about making a software character map. If you could do a 16bit character map, you could extend the characters available, and even do some pretend hardware flipping! So I did some basic code (no visuals yet) to see how bad it was, and was pretty pleased. It worked out about 1.5 to x2 the raw block copy. Not bad at all! After playing with the hardware FLIP (on Y) idea, it came out to about x2 to x2.5 which is still pretty good, and actually BETTER than my current character screen copy! (code shown below)

     ldx #8000-8
BlitLoop2
     lda    $9000+1000    ; get character
     dec    BlitLoop2+1
     dec    BlitLoop2+1
     and    #$3ff
     asl
     asl
     asl
     tay                  ; X=Character address
 
     lda    $8000,y       ; copy character
     sta    $4000,x
     lda    $8002,y
     sta    $4002,x
     lda    $8004,y
     sta    $4004,x
     lda    $8006,y
     sta    $4006,x
     txa
     sbc    #7   ; -8 coz carry is clear
     tax
     bpl    BlitLoop2

Imagine it.... a character map screen that has proper bitmap colouring, a colour screen that is double buffered, and around 1024 (at least) characters. Very cool. On top of all that, your software sprites DONT steal any of them, and DONT have to draw into chars before going on screen.

Then I started thinking... On the 65816 Direct page is moveable.... So why not point it at the bitmap screen. This could save 2 cycles per STA - a LOT when dealing with a bitmap. The results are amazing to say the least!! Believe it or not, its now about the SAME time as the raw block transfer instruction!!! How amazing is that!! (basic code below)

DoChar     macro 
     lda    charScr+\0  ; get character
     and    #$3ff
     asl
     asl
     asl
     tay     ; X=Character address
     lda    $8000,y   ; copy character
     sta    $00+\1
     lda    $8002,y
     sta    $02+\1
     lda    $8004,y
     sta    $04+\1
     lda    $8006,y
     sta    $06+\1
     endm
 
     ; Actual loop....
   
     phd
     lda #31
     sta LoopCounter+1
     lda #$4000
     tcd
     ldx #0
BlitLoop:
     DoChar    0,0
     DoChar    2,(8*1)
     DoChar    4,(8*2)
     DoChar    6,(8*3)
     DoChar    8,(8*4)
     ;
     ; etc...
     ;
     DoChar    60,(8*30)
     DoChar    62,(8*31)
   
     txa
     clc
     adc    #64
     tax
 
     tdc
     clc
     adc    #$100
     tcd
         
     dec    LoopCounter+1

LoopCounter:
     lda    #$0101
     beq    AllDone 
     jmp    BlitLoop
AllDone:
     ; 8 more DoChar's to finish off....

So I can now not ONLY copy a bitmap, but create a whole screen in realtime from a 16bit charactermap. This means you can do all the old tricks of animating a couple of characters and the whole screen could change (as I do for my turrets in XeO3), and if you really wanted you could draw huge character style sprites/baddies again.

I need to verify all this by actually drawing a screen (probably get the XeO3 scrolling going), but it looks really REALLY cool.....

Play.com: How the mighty have fallen....

For those that don't know, Play.com are a fairly sucessful on-line DVD shop. They have reciently branched out into electricals and games but while doing so have sacrificed what made them great...

I just tried to order a Hi Def DVD player from them only to have my account suspended. I then recieved an email telling me to phone customer support to verify who I was. Now.... if I was a new user, OR had changed my details in the past - hell - YEAR! then I could understand this. I had added a new delivery address, but these items "for security reasons" were being shipped to my home/billing address. On top of that, they emailed the email address they've held for the past several years to ask for verification.

This comes on top of increasilly poor service. Now, Im a DVD fan - a HUGE DVD fan, so I notice this more than most. But in the days of "next day delivery" or at the most a couple of days, a couple weeks is bad. And thats what play now deliver on a regular basis. My current record is 4 weeks, I now NEVER recieve an order from play quicker than 2 weeks.

And to top all this off, our local Asda has started beating them on price - HUGELY! The new Shrek the 3rd movie on play is around £12.99, while Asda have it for £8.88! This is happening more and more, so much so that I found the only reason to order from play, was the fact I could do it easily, and then they pull this.

Not only that, but when you buy a pre-release, you could usually assume you would get it on the day of the release. NOPE! They've screwed that as well. I ordered Call of Duty 4 months before it came out, yet I had to wait several days after launch to finally recieve it, when I could have walked into a shop on the friday and get it for exactly the same price.

Now only did they ask for verification, they actually suspended my account. Bastards the lot of them. Everything on play can be bought else where, usually at the same price or sometimes now cheaper. It didn't used to be this way.

.................So much for internet shopping being cheaper,quicker and easier - to hell with them.

(rant over)

65816: More coding goodness....

I finally managed to get a stable framework now (more or less), complete with interrupts. I did have to go looking for some answers though as I was getting nowhere fast! Turns out when the 65816 is in native (16bit) mode, its IRQ vectors move to $FFEE and $FFEA. Oh well, live and learn (again). When I did this on the SNES I would have done that the 1st couple of days then forgotten about it!

Anyway, now that its running the real problems with block transfer routines show themselves; you can't interrupt them! Yup, on most CPU's the next interrupt happens at the end of the last instruction - EVEN if that instruction takes seconds to complete! So, looks like I'd need a loop around a few of these, or not use it at all!

I guess for the final BLIT, as long as I knew it wasn't going to interfere I could use it, but it does look like the best/safest way is simply to use lda/sta instructions, Oh well.

SuperCPU: Wowza!

You know the more I toy with this machine, the more I'm blown away by it. Now that I have a reasonably stable assembler I can see just what its capable of.

For example, a full BITMAP copy using the block transfer instruction runs in at around 56 scan lines (7 characters high), while a transfer to NON vic memory runs in at around 40 scan lines (5 chars high). Thats fast, really fast! Normally, this would take over a frame to do. It means that software sprites AND bitmap scrolling is easily possible, and it would be interesting to take over the XeO3 sprite routine and apply it to a bitmap screen.

I suspect you could do a parallax bitmap scroll in the same way I did a character one, but by using a bitmap screen you would get access to many more colours.

If you ran the game in 2 frames (same as XeO3), you would have a phenominal ammount of CPU time to burn, and could probably fill the screen with software sprites!

All that said, I am still having problems using the SuperCPU to its fullest as I can't seem to access the higher banks without it locking up (using the block transfer instruction).

For those interested, I've been using THIS PAGE as my 65816 refrence. Although I do have an old 65816 cycle sheet from my SNES days somewhere....


You know, the more I think about it, the more I think that 16Mb of RAM and sprite caches would be amazing! I need to do a new SuperCPU demo :)

65816: Aaaaaaaannnnnnnddddd we're done..........

Well, I appear to have now finished 65816 support. I had some nasty little bugglets that were messing with my REP/SEP commands which is exactly the reason I couldn't swap in/out of it easily! Basically, even in 16bit mode, Rep/Sep are 8bit commands, but it was saving 16bit immediate values, which meant it would then hit a $00 (brk) as the next instuction.

So, this is pretty cool, as I'm now done with the core supprt for 65816 and 65c02. It still needs heavy testing, but looks like its mostly there.

While I was at it, I also fixed a couple of other instructions in normal 6502 mode that were broken ( jmp($1234), and lax $00,y). So that helps me anyway for XeO3.

So all I need to do now is release this version and then back onto paths for xeo3!
(have I mentioned just how much I HATE doing paths???)

65816: Problems....

Okay....I was a bit peeved that I released the latest SNASM with only partial 65816 support, so I've decided to finish it off. While doing this, I've hooked up my SuperCPU again along with my fab new Heavy Duty PSU.

I'm pleased to say my MMC64 and Ethernet still work on the super CPU, so downloading is a doddle. You know...I was halfway through this post, moaning that nothing was working, and then I noticed a REALLY stupid mistake, and now all is well....

So now I have a full 65816 - 16bit program running!! COOOOOOL!

Slight problems still exist however....If I'm in 16bit mode, I cant go into 16bit mode. (yes you read that right). Its a bit strange. As its not that big, I've done a HEX dump on the code and it all lookgs fine!

*sigh*........What the hells wrong now.......

New Release!!!!

I have just done my first new release of Minus4 in about 2-3 years!! Yes all these new features I keep going on about are have now been released into the wild. So if you head on over to THE MINUS4 HOMEPAGE you'll be able to download new versions of Minus4w, Minus4wsrc and the new Snasm.

The new Snasm also has a lot of 65816 assmbler support in it, but mre importantly outputs symbols for Minus4's built in debugger.

If theres any cool features you can think of, let me know.... Minus4 has moved from being the best emulator (now easily beaten by YAPE) to being the best for development - by far!

XeO3 is being developed using SNASM as the assembler, and Minus4 as the debugger. Yape provides more realistic playback, and the uploader provides real hardware downloading! All I really need to do is finish the remote debugger and we'd have a full devkit!!

XeO3: Profiled!

I'll get into this in a bit, but I just wanted to show the basic XeO3 profile. As expected sprite drawing is coming out on top with the HUGE spike inside ZeroBlock which is the bit that draws sprites when they are over an empty character. This is the fastest path through the sprite system.

The 2 big peaks to the right are the screen copy used for scrolling (but also wipes the display). Theres 2 seprate peaks as its double buffered and it flips from one to the other.

This is pretty good as it means code is taking its time in the areas expected; as is usually the case for 8bit stuff. However, I'll start looking at things like collision and zeropage next. Theres something funny happening in zeropage that I'll need to track down, it looks like something it over writing a couple of bytes of unallocated memory down there.

Oh...The reason I was able to pick this bit out is that I've impemented the ZOOM feature. So now all you do is click and drag over an area of interest and then click ZOOM. I'll need to change the Execute buffer as when you zoom in to byte level, it only counts the OPCODE bytes as being used. This means you get a peak, 0, peak, 0,0 peak etc. as the paramaters aren't tagged. All I need is a 256 byte table of how big each opcode is then fill in each location of an instruction.

Minus4: More on profiling....

You know, the one thing I really like about machines getting bigger and better, is that it lets you be lazy. In Minus4 I could do special functions to hunt quickly for symbols as quickly as possibly, arranging it all in a nice binary tree, while at the same time maintaining a 2D linked list so that I can find the symbol closest to an address.

Or.... being lazy and having a big machine....I can create a 256K table of symbol pointers.

I like lazy. Code is easy, and I can get onto what matters.

So I've only a couple of bits left of the Minus4 profiler. One is a ZOOM function; which it does actually do just now but I need a user interface, and the second is a symbol look up so that the addresses make sense to a developer. The blurb above means I can do the symbol lookup REALLY easily, so that will just leave the zoom and scroll bit (to let you view around the window area easily).

Then I can get back onto XeO3 and rearrange memory to be more efficiant.

Minus4: Profiling other games!!

Now this gets really cool.... I was busy flicking though other peoples demos and games and its amazing what a basic profiler does. In Elite, you can clearly see where the linedraw (I assume) is called as theres a huge spike in the Execute map, while in Monty on the Run shown in this new image, you can clearly see that monty is rotated in Zeropage!!

72 bytes appear to be set aside for the monty graphic in zero page, and as you run about it goes up and down in time. Really cool.

It also shows up some odd patterns, for example in one of Luca's demos, it looks like he's using ZeroPage oddly as something is reading through zeropage overtime, and the read bar runs up smoothly through memory.

On XeO3, you can clearly see where both the sprites and scroll occur in memory, AND you can tell when its drawing tiles as theres a noticable spike every few frames.

The thing a static image can't get over, is that fact that becasue its in realtime, you see spikes as they happen - and where! Really neat.

Great fun this :)

Minus4: Profiling.

I've added the basics to the profiling kit and its really interesting to see memory access at work. With machines being so fast these days I can afford to put in profile access for everything without worrying about it, which is pretty neat in itself. So I can currently profile read, write and execute all seperatly (or accumulate them for a combine profile).

The REALLY cool thing is that I can watch the profile in real time!! When selected a new window pops open and you can sit and watch any area of memory and see what the access is like. This is very very cool, and a tool I wish I had in my day to day development! The piccy on the right shows the profile in action and the bars bump up and down over time as the system hits memory differently. I have a reset option so that I can averate the profile over a little bit of time and clear it. This gives some really cool feed back.

What I really need to do now is allow symbol lookups so you can see where time is being spent. This shouldn't be too hard but will prove to be amazingly cool! I still have most of the editor functions to add, but even now I can see that vast areas of ZeroPage (which is shown) are virtually unused!

Of course, a huge spike does not mean that you HAVE to put something in zero page, as things like my frame sync variable gets hit thousands of times a second, but can be slow as its the end of a frame!But for the most part, if theres a spike in memory access, thats a good variable to move to ZeroPage if you can.

Plus4: The expansion port...

Oh.... and as a little side note.... I was wondering.... The big problem with the plus4 is that theres no female edge connectors that now FIT the plus4. Sure we can make cards that plug into the machine, but we can't do THROUGH connectors. So I was wondering, why not make a new standard?

We could do a convertor that goes in the current port, but then expands into a new size; a new width that there ARE connectors for. Then we make the cards fit the new size - say the PC ISA card size, as these are big enough and easy to get (or something like that). This way you can add through connectors and allow cards to be connected together.

This means all we need is one card to plug into the expansion, and from then on we make stuff for the NEW port.

Other machines like the Spectrum and C64 can have through ports - like the MMC64 which still allows the retroreplay to be plugged in. That would be cool.

Minus4: An old friend....

While getting a little bored of doing paths (MAN! I hate doing paths...) I decided to take a break from that and add some basic profiling under Minus4. This was suggested a while back by TNT in his Paradriod blog, so I'd thought I'd take the plung now and see if I can't save some zero page memory; or at least shuffle it around so I get better use out of it. I currently have around 50 bytes of zero page left but I'm fairly sure some of it really doesn't have to be there.

Anyway, while browsing the source I had a look at the last release of Minus4 and what's been added since, and theres actually quite a bit. I'm sure I posted this a while back, but here it is again.

V2.6
----
1)   Debugger now loads symbols (-p "symbol.sym" on the command line). SNASM format.
2)   Source now builds under VS2005
3)   Updated Debugger to allow disassembly view movement. 
     Page up/down, line up/down now moves disassembly view
     SHIFT+Page up/down, line up/down now moves memory dump view
4)   Dump of most of the hardware registers
5)   Added a menu switch for undocumented opcodes. They are now OFF by default....
6)   Added a scrollable BAR to the disassembly view to allow the placement of breakpoints and nicer navigation
7)   New debugger keys:
            Cursor Up/Down              Move user bar
            Page   Up/Down              page disassembly up/down
    Shift + Cursor Up/Down              Move memory dump up/down a line
    Shift + Page   Up/Down              page memory dump up/down
            B                           Set Break point at current user bar address
    Shift + B                           Set Break point at address/symbol
            Enter                       Step a single instruction. If JSR/Branch then follow if need be.
            Space                       Place a breakpoint after current instruction and RUN.
            Cursor Right                If user bar is on a JSR/JMP, then read address and set window address to that.
            Cursor Left                 If CursorRight has been used, then pop last address off and reset window.
            M                           Set Memory window address
            G                           Set Disassembly window address
8)   Basic Profiling

With profiling being added I think its probably time to release this one so others can make use of it. I dont really use Minus4 for running games anymore, Yape has long since taken that crown, but I do use it for debugging as the built in debugger is much nicer to use (although I do now wish I'd opened up a new window for it so I could have a bigger area). Anyway... With the profiling about to be added, I think its now a nice enough release that others may like to use it for development, so once Im done with profiling, you can play with it for yourself.

My assembler (SNasm) outputs the symbol file format needed for Minus4 although I'll try to workout what the format was so you can use others and convert if you need to.

XeO3: Scripting....

As you may have noticed from Luca's blog, we've decided to not only release a demo, but the script for level 1, and a way to build it.

So... what does this mean? Well, it basically gives you a chance to get a taste and see whats coming in the full release. This means you can start to build your own paths, and do your own level. I suspect we'll see a couple of new 1 file demos with other peoples scripts, and who knows..... some folk might hack it a little more and try and extend it; although that would be a little tricky and Id wait for the full release.

Anyway, I'll try and post some stuff about the scripting, the limitations and what you'll be able to do with it soon.

XeO3: Demo

I've been doing more waves for the demo level and I'm now halfway, although it suddenly occured to me last night that I do still have code to do. I've not done the weapon energy bar yet! If you've watched the video you'll notice your shields take up both bars, but the plan is now that the one on the right will be your weapon power and it'll slowly drain over time. This means you HAVE to go in and collect coins to buy more power. IF you manage to get a load of coins before say the final 1/4 has gone, then you get a power up.

It'll be interesting to hear what you all think of this mechanic when you play it, as we both feel its whats going to make the game fun/difficult/annoying. Most games you can stand back and blast away, but with this one you have to get in there to pick up coins which means you will always be in danger!

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.

XeO3: Demo level progression.

I'm slowly progressing with the alien waves for the demo level and I think it's going okay. If I play without wanting to power up, you can more or less run through without getting hit (so far). But if I get greedy and want all the coins, then it starts to get tricky; which is the idea.

I've mapped out about one third of the level, although I've extended the start a little to make the introduction a little simpler - mainly so theres no backgrounds while you get used to moving around.

I also fixed the 2nd bug in my list from yesterday, where the collision radius wasn't being used.

So.... the demo is progressing slowly. Slow but steady! which is of course better than it has been; stopped and dead.

XeO3: Demo level....

I managed to get Luca to send the test level again, so I've now put that in and have started making new alien wave's. Heres the current plan for the demo.

1. Have the front end as is
2. Only have 1 weapon type but allow you to power it up.
3. Have the full weapon power up/down sequence


4. Only a couple of baddie types.
5. fix all current bugs before release.

Speaking of bugs, I've found another couple.

1. If you shoot a "group" of sprites too quickly, its possible to get multiple pickups. A group is only supposed to leave 1 item.
2. The baddie radius isn't used! This means all baddies have a fixed bullet collision area
3. If you collect a weapon pickup you appear to lose a bullet.
4. 2 character wide bullets don't always appear to hit baddies.

I've fixed the 1st and I'm about to fix the radius one, but I'll fix the rest later. I want to try and get some paths going.

XeO3: Demo level

I've been hunting around trying to find the demo level Luca built, and unable to find it, I went back to Luca's web page to see what it looked like. I was somewhat shocked to discover that he actually made it just over a YEAR ago!! So much for 2007 being the year of XeO3! I've done even less this year than last year! bugger.

XeO3: Here we go again.....

I've not done nearly as much as I'd hoped on XeO3 this year. I was convinced THIS was going to be it's year. A few things got in the way, my new found electronics hobby - which should still prove interesting to others once I start to finish things, and the fact I HATE makeing levels. Always have. Hate it! Hate it! Hate it!

But I think at the VERY least, I need to get the test level done so we can at least make some progress. For those that don't know, the plan is it make a 1 level demo with simple graphics but the game playing. This lets us (Luca and I) test the game mechanics out and at the same time, make sure we're not aiming to high (or low) on the difficulty side.

So...... to this end, I've decided to try and force myself to produce a new 1 level playable demo, and to release it AT THE VERY LATEST for Christmas. I really hope it'll be WAY sooner than that (a couple of weeks would be better), but Christmas at the latest.

Then once I get some feedback from everyone that's played it, we can both start to try and put the final game together.

..........well, thats the theory. So hands up if you believe one word of it?

Dundee "smart" city.

This is a funny one.... Dundee has been named as one of the smartest citys on the planet by some of the worlds leading experts. (HERE). I find this really funny coz it names as one of the reasons the ever growing computer games comunity there, which by definition makes me really smart - and if thats not enough to make you laugh, then nothing is.

The other odd thing is that it seems to try and suggest it was planned.

"It said the city had "continued to transform a former shipbuilding community that suffered severe economic shocks into a national powerhouse and leader in game design and sciences"."

Now.... I find it odd - being one of the founders of this "game design" comunity, that they think it a planned thing since anyone actually IN computer games, knows it was simply because DMA brought in heaps of folk, who then splintered off and formed their own companies. Now, Dundee does have a huge number of games companies per head of population, but non of this is because of the planning of Dundee City Council.

However, all that aside it's good to see I guess as it might help to upgrade peoples opinion of Dundee and let them consider it a place to live. We struggle a lot to hire folk, and lots of folk dont want to move here because its got a bad name, so I guess in that respect its good; funny....but good.

Im still here!!!!

I know....its been a while. I'm still actually recovering from my trip believe it or not. I got back just over a week ago and I'm still not sleeping as well as I was, and this means I have no energy at night to do anything else....bit of a bugger really. I am start to think about things again though, and hope to get stuck in soon, although Im not sure if that'll be XeO3 or my MMC add on - time will tell.

Of course...I didnt make a diagram of the MMC thing, so now I have to reverse engineer what I've already done! doh!!

Mode DMA videos and pictures.

So, another day... another stack of pictures and videos uploaded to my flickr and YouTube accounts. I'm starting to run dry now, most of the video I have has been uploaded, and although I do still have a stack of level building graphics for games, I have very little "pictures" left. Which is good I guess, as it means folk can now see everything.

Anyways...back to XeO3. I think I'm gonna have to bite the bullet and put some code in the level loading when done, however it will mean I lose my 1k I've been holding onto in an attempt to keep the character sprite system, but it just appears theres no real space left for them. I need to add code to draw them, spawn them and move them - not to mention the actual graphics themselves.... Luca's gonna kill me....

XeO3: Possible solutions....

While I was talking to Luca last night, I thought of a possible solution to our background animations. The problem is that its code driven, and then tables that drive them which allows cycling frames of animation to be played. This however isn't good for every level as on level 2 (for example) Luca would like to change the sequence and even speed of animations. To this end, I think it might be possible to move the animation code into the level data, and if I do that it would get loaded with each level. Its unusual to load code in this way, and I've never needed to do it, but it might work fine here.

I'll give it a try soon and I hope this will allow Luca to allow do the animations the way he wants.....

Unseen Tanktics video.

This little gem was never used, much to my frustration at the time. When it was made I tried for months to get it included in some Animation festivals as it really was right up there with the likes of Pixar at the time. Created by John Harrison its a great little video.

Anyway - enjoy!

DMA Design stuff....

I've been trying to look out some Uniracers pictures for an upcoming article, and while doing so I've been admiring all the old images I have from those times. The idea originally was to use my DMA Website to show them all, but its just taking too long to put together, I just don't have the time at the moment. Theres also WAAAAAY too much to put up. So, what I thought I'd do is start uploading them to Flickr! That way everyone gets to see them now, AND I don't have to worry about bandwidth costs etc.

I have hit a slight snag however.... I logged out of my flickr account, and now can't log back in! Oh well.... I've emailed the support team so I hope to get it resolved soon. In the meantime, you can see the images I have already uploaded here: www.flickr.com/photos/mikedailly/

I have also decided to upload all the DMA Videos I've been holding back to my youtube account. Im not sure what the longest video you can post there is, but I have some toppers!

Xeo3: Taking stock...

So, Ive been cleaning my desk a little and getting things back in a usable state, and while doing this I reconnected my Plus/4 and had a quick play of XeO3 using my new Joystick adapter. It nice being able to use a normal joystick, but it feels a little un-plus/4-ish for some reason.

While playing I spotted another bug this time in the new weapons system. Once I've powered up enough to get larger and faster bullets I dont always seem to be able to shoot turrets/mines. This must be due to the extra character hitting the turret and not detecting it properly, so I'll have to look into that next.

I need to copy the latest source from the laptop onto my main machine at some point so I can carry on. I think I'm actually fairly close to doing a beta release with a test level so we can staty to guage difficulty for everyone. After all this time it would be nice to let you guys have a play with it.

Blood Money

So Ive been looking at the code to Blood Money whilst I've been writing this post-mortem, and its not quite the work of art I thought it was; which I guess is no surprise. I was only 19 at the time and I hope I've improved a lot since then! However one thing I did get totally wrong was the way the paths were created.

In XeO3 I have 10 paths, one for each baddie and another which acts as the master path. This is how I remembered I'd done Blood Money, but it turns out I was wrong. In Blood Money, I'd a special format for the master path, one that didn't look at all like the rest of the system.

Path_Address:
Sc0:
 db  End_of_Screen
 db 5|Sprite,$58,100,14|Sig,<path2,>path2,<Header2,>Header2
 db 7|Sprite,$58,100,14|Sig,<path2,>path2,<Header2,>Header2
 db 9|Sprite,$58,100,14|Sig,<path2,>path2,<Header2,>Header2
 db 10|Sprite,$58,150,3|Sig,<path1,>path1,<Header2,>Header2
 db 11|Sprite,$58,100,14|Sig,<path2,>path2,<Header2,>Header2
 db 12|Sprite,$58,150,3|Sig,<path1,>path1,<Header2,>Header2
 db 14|Sprite,$58,150,3|Sig,<path1,>path1,<Header2,>Header2
 db 16|Sprite,$58,150,3|Sig,<path1,>path1,<Header2,>Header2
 db 18|Gun,$27,17,Player2 | Gup
 db 24|Gun,$27,1,player1 | Gdown
 db 35|Sprite,$58,150,14|Sig,<path4,>path4,<Header4,>Header4
 db 35|Sprite,$58+24,150,14|Sig,<path4,>path4,<Header5,>Header5
 db 35|Sprite,$58,150+21,14|Sig,<path4,>path4,<Header6,>Header6
 db 35|Sprite,$58+24,150+21,14|Sig,<path4,>path4,<Header7,>Header7

This is the 1st screen from Level 1(I think) on Blood Money, and its pretty ugly. The 1st byte is the character to start the sprite on followed by the X,Y, Path and object header. It was also able to spawn turrets and character sprites but still - it was pretty nasty.

In XeO3 I use the path engine as the master path, that way I can use loops and pause whenever I need to, and then use standard StartSprite commands. I did a couple of Shoot-em-ups for mobile phones, and I used the XeO3 way then, so I must have just gotten confused. Still I guess its good to know that I do still improve, even with the most basic of game.

Post-Mortems

I've gotten really carried away with the idea of doing an 8-bit (or retro) post-mortem site, I think theres still lots to be learnt from hearing what others did in the past, and it might even inspire others to do more in the future! Who knows! I've also registered post-mortems.com although it just points here just now.

So to this end, I've started doing a Blood Money post-mortem, although unlike modern ones its not really a what went right or what went wrong document, but more a what did I do and why presentation. I do give public presentations every now and then so speaking through this on my own at home is gonna be really weird. I might see if anyone at work wants to listen to it just so I can get an audience and someone to speak at!

These things usually last an hour, but I think I'll be lucky if its lasts 15-20 min, but thats probably okay.

Another oddity is that your used to getting some questions, but at home you won't get any! The more I think about it the more I really want to have someone -anyone! to speak at.

.............Anyone able to travel to Dundee? :)

RETROspective...

Russ sent me a link to an interesting talk (HERE) about a PSone game where he talks about how he did the physics in the game. Now, this struck me as a great idea, doing post-mortems on old retro games like Blood Money or Shadow of the Beast (I did the PC Engine one) or whatever would be really interesting for lots of folk. I wonder how possible this kind of thing would be; I guess you wouldn't need to hire a hall or anything, but do a powerpoint thing and talk through it, and then post it somewhere. This could be pretty cool to start building up these for people to watch. YouTube (or google video) would work really well for these.

What do you think? A site that has post-mortems of various retro games? I don't know about you guys, but I'd love to see some of them.

Drobo!!!

So, I'm thinking about some mass storage device so I can store my DVD's and music in a single easy to store location and theres a couple of really cool little devices out there now. One of which is DROBO which is a new hard disk system which seems to overcome most of RAID's limitations. Its a little pricy, but since its dynamically upgradeable, its well worth the cash. If you watch the video, you can see just how amazing it is; very cool indeed.

Now...if you use one of these you still need a PC, but there are a few answers to that too. I have a little linksys unit that that takes USB2 drives and then puts them onto the network, which means anything can see it. Theres also a cool little media server available for this little unit which might spell the end of the PC altogether!

Cool toys, if a little expensive.

Oh, and I have finally recovered, but we have a close family wedding this weekend, so Ive had no time to do anything. Hopfully after that, i can get back to doing more interesting things.

Jetlag boy....

Yep, I've come up with a new super hero: Jetlag boy!!

As you may have guessed, I'm still too jet lagged to do anything, I was fine for most of today, and then once my bum hit the seat, my eye's closed and then it was 2 hours later! doh!

I was at the new Edinburgh International Games Festival today as I was taking part in a panel on getting into games. I've done this the last 3 years now and its pretty good fun even if its not very busy. I also went to have a look at the Dare to be Digial entry's which were on display and open to the public this year, and as usualy, they look pretty good for 10 weeks work. Some were of a very high standard, and some were struggling, which is normal. 10 weeks is a very short timeframe to do what they are trying, so they all do well getting anything done at all!

Anyway, I hope to be back to fighting ways as I'm back to work properly tomorrow, and then back to doing stuff at night as well; I hope.

I've been thinking more and more about making XeO3 a pretend cartridge game (that is, a self booting MMC/SD game). So that when you buy an MMC card reader, you also get XeO3 for it. This makes life interesting as theres no disk involved, and I have fast storage available.....but.... another part of me doesn't like that because not everyone plays on a real plus/4 which shrinks the market somewhat.

But, even if I do a normal version, I can still see me doing a special MMC version as well - for the C64 too, as it's just cool :)

SigGraph 2007, Day 5....

So, almost done.... Just a couple of hours left really, and then off to the shops. The show goes onto 6pm tonight, but theres nothing I really want to see after 3:30, so I'm gonna go do some last minute shopping.

Im in a Spore demo just nowm and it does look very polished, but at the end of the day, it does just look like a populous (or god sim) game. So for all their bluster they haven't really added much "game" stuff.

The problem with being at a graphics confrence, is I now want to go home and write raytracers and model some stuff in lightwave! Oh well.....Im sure this urge won't last.

SigGraph 2007, Day 4....

So, day 4..... one more to go. I now remember why we were itching to get home last year; its hard going. Until you've actually done something like this, you don't realise how hard it is to sit in a dark room for 5 days straight sitting listening to folk waffle on. Still, theres some good stuff being said, and I hope we get a chance to use some of it when we get back. Russ has been doing XeO3 stuff while sitting listening, but I find it pretty hard to code on the laptop, particually doing paths - which is what I have to do next.

I guess I could start to flesh out the front end a little and do the high scores and saving to disk etc., but I'd rather start doing the gameplay beta and start to get feedback on difficulty. I think thats the next big step for us - something playable and getting some feedback on how hard people think it is, that would help make the final one that bit better.

Still, I find it hard to think about this stuff while listening to guys go on about high end rendering on PC's and in movies. Oh well....I'll be back home on Saturday, so I can carry on with my own projects rather than vegging out over here.

The only good thing about being here is occasionally getting to shopping mall's.... but you dont really get a chance to do that very often.

SigGraph 2007, Day 2....

Well, after a really boring day yesterday with nothing of real interest, todays a little better so far - although not by much. Most of today's work has been shown in the past and they aren't really going into detail about things, but theres supposed to be an interesting paper tomorrow about taking photographs and making 3D models from them, so that could be good.

However, I hope things are about to pick up as the next talk is from the guys that did the need for speed and how they modeled the world there.... So could be good...

Later that day.... Mmm.. Not bad at all. Nothing new or ground breaking but was nicely presented.

SigGraph 2007, Day 1....

Started off with a raytraching course this morning, not quite as good as I thought it would be, and with 5 others here as well, not a lot of choice for skipping out into another one. oh well. This afternoon should be better as I'm going to a DirectX 10 course and the guys from Crysis are talking about stuff; and hopefully showing some video!

The Conference center is huge again, and it feels like you have to walk miles between talks, but it does mean you can stuff your face and walk it off!! :)

Arrived in San Diego

We've arrived after a fairly long trip of 15 hours, but we here safe and sound. Hotel seems nice, and we're not too far away from anything so could be fun! Trip was pretty good (as much as it could be!), the plane was reasonably empty so we had space to sreach out and the seats were actually far enough away for me to open the laptop!

Which brings me to XeO3. I managed to get the weapon upgrade more or less in, which means I can now kill a baddie group and pick up a new weapon. So really its just paths to be able to use them properly. The biggest problem with the pick ups is that I can't leave them on screen as I might need the sprite for baddies. This means I have to get it off screen quickly; kinda like the coins.

I'm not sure the 2 char bullets are working right either, they seem to hit things and do no damage sometimes.... I'll have to try and check that out... Working on a plane can be hard going though, its hard to concentrate 8 hours into a flight... Oh well, at least I got something done!

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