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 :)