Minus4w

I've been updating minus4w to allow better debugging, so now I can scroll the disassembly view around and have the current PC update the window as needed. This makes it easier to follow code and debug. I should have done this ages ago, but as usual I couldn't be bothered. Still, its a good change and with the symbol table output by SNasm, it makes for a pretty good devkit. The only thing missing now is a watch window. Theres not a lot of space for that, so I may not add it... but I could toggle the watch window with the memory dump....

Im not sure who else would use this as most folk dont really use SNasm and Minus4 for development, so I dont know when I do a new relase....

Theres a couple of other changes I think I'll make later to allow a bit more ease of use, but these are minor compared to these, but it's all good!

6502'ing...

I was doing my demo for the demo-comp, and I came across an instruction my debugger didn't know about. It was a simple omission but got me thinking about undocumented opcodes and memory in general. Minus4 nukes memory to 0 before starting up, but this is hardly ever correct, Yape uses a $ff,$ff,$00,$00 pattern which is much closer to the real thing. But in actual fact, each Plus/4 is totally different. I have one here that hardly wipes memory at all. In fact, I can switch the machine off/on and still have the program completly in memory. I used this a lot when growing up to get around the "no software reset" hacks software houses used to put in, and it let me hack them quite a bit more than I should have been able to.

I was also looking for ways to get more bang for my buck in my demo, and looked at the XAA opcode. This is listed on various sites as a normal 6502 undocumented op, but doesn't appear to work on the Plus/4 - or mine at least. Yape also doesnt use it, so I started to wonder what the plus/4 does have. I use lax in XeO3 to help speed up my sprite routine, and that appears to be working fine, but I may be treading on thin ice as it were, as you never know when you cross the line.

Still, I guess as long as you try these out on a real machine, it shouldn't be too bad....

Plus4 ROM disassmebly

After a post by Luca on Plus/4 world about clearing the screen via the kernal, I thought I'd have a quick poke around inside my kernal disassembly to see what it does. So I've spent an hour or so comenting my disassembly and how the screen clear stuff actually works. Its pretty simple really, and more or less loops around the current text window size clearing lines at a time. So, its not great, but its far from terrible. The "normal" kernal way of clearing a screen is to set the cursor to the top left and use Chrout to print each character. This doesn't, it hits the screen directly.
This also answers my question as to whether the kernal can move/relocate the main character map screen. The answer is no. This is because located at $d802 and $d81b you'll find a screen line lookup table, with the address of every line on the screen. and $0c00 is encoded into this table. Pitty.

Here's the main parts for anyone interested....

; *************************************************
;
; Clear screen with colour $10
;
; *************************************************
LD87E   LDA   #$10          ; Colour to clear screen to (black)
        STA   $053B         ; Set current character colour
        LDA   #$04
        STA   $0541

; *************************************************
;
; Esc-n  SCNCLR
;
; *************************************************
LD888:
        JSR   LDE70         ; Set full screen window
LD88B   JSR   LD89A         ; Set the cursor HOME
LD88E   JSR   LD8AA         ; Set screen pointers

; *************************************************
;
; Actual Screen Clear
;
; *************************************************
ClearScreen:
LD891:
        JSR   LDAF7         ; Clear the current line the cursor is on
        CPX   $07E5         ; At window lower edge?
        INX                 ; move cursor down a line
        BCC   LD88E         ; if not done, clear more


; *************************************************
;
; Set cursor HOME (set to top/left of current window)
;
; *************************************************
LD89A   LDX   $07E6         ; Get window TOP
        STX   $CD           ; set cursor Y
        STX   $C4           ; cursor input row
LD8A1   LDY   $07E7         ; Get window LEFT
        STY   $CA           ; Set cursor X
        STY   $C5           ; Set cursor input X

LD8A8   LDX   $CD                  ; get cursor Y
LD8AA   LDA   ScreenAddressLO,x    ; look up screen xply table (LO)
        STA   $C8                  ; store current screen address (low)
        LDA   ScreenAddressHI,x    ; look up screen xply table (HI)
        STA   $C9                  ; store current screen address (HI)

LD8B4   LDA   $C8          ; get current screen address LO
        STA   $EA          ; store in current editor COLOUR address LO
        LDA   $C9          ; now get the screen HI
        AND   #$03         ; and work out the HI addrews
        ORA   #$08         ; of the colour screen
        STA   $EB          ; and store in the editor colour address HI
        RTS    




; *************************************************
;
; Clear the current line the cursor is on.
; (within the left/right window range)
;
; *************************************************
LDAF7   LDY   $07E7         ; Get window LEFT edge
        JSR   LDF4A         ; ???
LDAFD   JSR   LD8AA         ; Setup screen addresses
        DEY    
LDB01   INY    
        LDA   #$20          ; fill character address with spaces ($20)
        STA   ($C8),y
        LDA   $053B         ; get current colour attribute
        STA   ($EA),y       ; and store in colour address
        CPY   $07E8         ; right edge yet?
        BNE   LDB01         ; if not loop
        RTS    


; *************************************************
; Set window bottom and right
; *************************************************
LDE67   STA   $07E5          ; Set current screen window bottom 
        STX   $07E8          ; Set current screen window right
        JMP   LDE80

; *************************************************
; Reset current text window back to full screen
; (0,0) to (39,24)
; *************************************************
LDE70   LDA   #$18           ; Set window bottom to 24
        LDX   #$27           ; Set window right to 39
        JSR   LDE67          ; set bottom and right variables
        LDA   #$00           ; Set window top to 0
        TAX                  ; set window left to 0

; *************************************************
; Set window top and left
; *************************************************
LDE7A   STA   $07E6          ; Set current screen window top
        STX   $07E7          ; Set current screen window left


; *************************************************
; Clear screen line wrap table
; *************************************************
LDE80   LDA   #$00
        LDX   #$04
LDE84   STA   $07ED,x
        DEX    
        BNE   LDE84
        RTS    

Let there be finger!!

Well, almost there. The big bandage came off today, so I can now see how its healing, and its pretty good. This means I dont feel too bad typing now, so I'll probably start debugging XeO3 over the weekend again. Because its over the joint, I still cantr bend that finger - not until I take those paper strips off, but I can get by okay as long as i can use 2 hands (mostly). Oh well.... Im off on holiday just now as I can't really do anything productive at work, but the suns out, the kids are off - so we can have a little R+R at least.

(Oh...and I know it doesn't LOOK bad now... but try and imagine pulling back the folds along the cut and almost seeing bone! Wish I'd gotten a picture of that! )

Slice and Dice!

Well, no sooner have I picked up XeO3 again, and Im forced to put it back down again! I was out giving the grass its first cut of the year, and managed to slice a rather large and impressively deep cut in my finger. So after a quick(ish) visit to the E.R., I'm now reduced to typing one handed, and thats no fun at all!

For those that haven't seen it yet, the new GTA 4 trailer is our for 360+ps3, check it out HERE

XeO3: in for a qucikie....

Just a quick note really... I have verified that its the sprite system thats killing things by basically knocking it out and running the game without sprites. The game can then work as normal and does the full cycle of frontend->game->frontend->game->etc. This is good and bad news. This means I dont have to hunt everywhere, so thats good. But it also means I have to debug the most complex bit of code in the whole game. And because theres so much changed from the old engine, I can't use SSafe to do a DIFF - oh well....

BTW...this is a debugging technique that newbies often miss, when something wrong and you simply dont know what it is, comment out huge sections of code until its working as expected, and then start putting them back in one at a time. It should become clear then at least where to START looking! Sometimes its not in the obvious place, or even the block you commented out, but it gives you that valuable starting point.

XeO3: I'mmmmmmmmmmmmm.............BAAAaaack!

Well, after a long break, I'm back and trying to get things swinging again. But needless to say, I screwed up yet again and left the game in a terrible state. There's at least 2 very serious bugs causing crashes and corruption through out the game that I need to track down before I even get started with new stuff.

I've managed to sort the 1st one out which was the turret and mine animations were going nuts! It turns out that a huge chunk of code had been deleted (I assume by accident!), and the only way I managed to find it was by doing a DIFF using source safe (a source control program).

Source control is great - even for use at home when your the only programmer. They are normally used for large teams and manage source merging and storage, but for a single programmer they give valuable check points where you can roll back to if all else fails. This is how I caught this bug; I simply checked the current version on disk, to the current version that was checked into SourceSafe - and a huge block of code had vanished. A simple copy+paste from SSafe to CodeWright, and its fixed.

The next bugs probably going to be a lot harder as Im sure its to do with the new sprite cache....

Edit: Oh! and I've been told Im not allowed to do any demos until I've finished XeO3....bummer :)

limiTED: Hard core fun!

I've been having great fun making some real hardcore demos for a new demo comp - my 1st demo comp in fact! limiTED was started and managed by Luca and has 3 catagorys: 64bytes, 128bytes and 1k. 64 bytes is about as hardcore as you get and is pretty hard to even start a program properly never mind do anything constructive, while 128 bytes you can just about do something nice. 1k is quite a lot, so your back into real demos which have to look nice as well as do something. The demos have to be anonymous for now so I cant say much more except its getting me back into 6502 fun land! So much so I hope to start back on XeO3 real soon... as soon as I've run out of demos to try and enter. I've never been much for doing cool demos, I've always been able to optimise and do stuff, but never come up with wierd shit that works well in a demo. So if I manage to do something, I'll be interested to see if everyone else thinks they're pooh or not.

Plodding on....

I'm still slowly progressing with wiring up the prototype, and I thought I was getting on well until I decided to finish one of them off - just to see how much more I had to do, and it turns out; LOADS! Oh well.... Onwards and upwards and all that.

I've been coding up a demo for Luca's new competition, and Im struggling a bit to fit it in. The original size was supposed to be 64 bytes(!) so I started working on that only to find out they had increased it to 128! DOH! Oh well.... Its nothing special, but I do prefer these smaller demos to the larger ones as you dont have to do very much, and it doesnt have to look too pretty.

I've also been speaking to Luca about the level2 on XeO3, so I may pick that up again soon. But once again, I've left it in a horrible state! Its got a pretty serious bug in there somewhere (probably the new sprite cache) which causes the whole thing o slowly get corrupted and crash. Bugger.

The wiring begins!

Nothing much new, except I've started the long boring process of wiring up my prototype. I've been dreading this as its going to be really dull, and take AGES! I've decided that rather than wire up one at a time, I'll do them all at once, this means I'll get the correct connection from the schematic, and then wire that wire 5 times. It should save going back and forth all the time so it'll be quicker, but even more boring! Oh well....