Was Bird Strike ever fixed?

[iainfm]

Hi,

The Andrew Frigaard masterpiece was a favourite of mine when I was young (no, really). Yes, there's little replay value in it. Yes, the enemy AI is...basic. Yes, there's no variety between levels (other than enemy design). Perhaps it was the cheerful music, or an irrational dislike of pigeons. I don't know, but I would regularly play it until it crashed.

The crash I'm referring to is the gradual screen corruption starting at wave 13 (irrespective of how you get there, it would seem). First a stray enemy bomb would get stuck above the clouds, then the clouds would begin to part (I originally thought a hidden message was going to be revealed), then the pigeon sprites would corrupt, then your own shots, and the game would eventually throw in the towel as wave 23 loaded.

I originally thought the problem might be due to the score overflowing sprite areas, but the locations affected are far apart. And as I've proved today, it doesn't matter how you get to level 13 - either by racking up pigeon bonuses or by destroying aircraft - or how long you take to get there, the fault occurs.

Reason I ask that curiosity has gotten the better of me, and as a result I now have (with the help of WFDis and beebdis.exe) a beebasm-compatible source file that assembles to give a binary that byte-for-byte matches the orginal.

So.... If it's not already been done... Can we fix it?

[lurkio]

Can we fix it?

Not sure if you're asking for help..? If you are, then do you want to share your disassembly so that those with the skills to do so might be able to have a go at finding the bug..?

[iainfm]

Can we fix it?

Not sure if you're asking for help..? If you are, then do you want to share your disassembly so that those with the skills to do so might be able to have a go at finding the bug..?

Yep, planning to do that - just really wanted to find out first if it's already been done and therefore whether I'm trying to re-invent (repair?) the wheel

[chrisn]

There was some previous discussion here, from when we found the bug during a high score challenge round. I started disassembling the code at the time, to figure out why it crashes but didn't get very far.

[iainfm]

There was some previous discussion here, from when we found the bug during a high score challenge round. I started disassembling the code at the time, to figure out why it crashes but didn't get very far.

Thanks for that. Yeah, I remember playing Spectipede until it crashed as well

Not sure what the best way forward for this is. I can either post the source here with various annotations I've made or start a new thread (maybe in the programming section). The other option is to put it on github or somewhere so people can make their own branches that can (in theory; I don't really understand github ) be merged back together when improvements are made.

[chrisn]

I think sharing the code on GitHub would be good next step, and we can use this thread to discuss. I'm sure I or others here can help you get started with GitHub.

[iainfm]

Ok, I've uploaded what I've done so far to Github: https://github.com/iainfm/BirdStrike

I've had a trawl through it to start to try to make some sense of it - I've renamed default variables to something useful where I could, added some comments here and there, and made a start at figuring out what the main game loop does.

Instructions are in the readme, but to elaborate a little:

Bird Strike initially chains "BIRD" (via !BOOT) which resets page to &3000 and chains "BirdSk1". BirdSk1 has some hidden code at the end of it, where the loading music comes from - &3500, specifically.

BirdSk2 (the 6502 binary) then gets loaded at &1200 and called from &1300.

There's something in the code at &1300 that loads a couple of things from the memory space that BirdSk1 occupies. If BirdSk1 wasn't loaded, the call to &1300 will fail. I'm not sure if this is a copy or tamper-protection thing or what.

Either way, it can be defeated by simply calling &1E00 instead of &1300, which is where the code at &1300 banches to after it's done whatever it does.

So, once you've assembled your code and transferred it to a beeb of some flavour you simply do the following:

PAGE=&3000
*LOAD <filename> 1200
CALL &1E00

Happy pigeon-bothering

[iainfm]

A bit of progress today, but mainly only eliminating a few things it might be, and I've updated some of the source code to replace EQUBs with their equivalent strings for readability.

My plan today was to compare the areas of memory containing sprites before and after the memory corruption, to see what was being scribbled over it. This didn't lead to a single bit out of place, so I compared the program memory (&1200-&2FFF) of a beebem glitching after 20-odd waves with one that just had the program code *LOADed.

Aaand, there were surprisingly few differences - life count, various coordinates, that kind of thing. I've summarised what I've found and stuck that in the github repo as well. There does appear to be a bit of self-modifying code here and there; some RTS's get changed to other things on the fly it would seem.

So, the problem lies elsewhere. My next port of call is going to be to look at the soft-defined characters area, I think, in case it's using that for the minor sprites/scenery.

Edit: Nothing there, and copying page 0 from a fresh load to a corrupt machine still exhibits the glitching (albeit resets the wave number etc). Curiouser and curiouser...

[iainfm]

The other 'discovery' today is that if you die after the graphics become corrupt, and start a new game, the glitches are still there and you can play the game until level 23.

I guess that means whatever is overwriting memory is reset on a game load, and it overwrites the memory in exactly the same way (the glitches appear to be the same as from a hard reset/fresh load of the game).

[lurkio]

This is great work!

I wonder if it would help others if you uploaded two BeebEm savestates, one from well before the game starts glitching, and the other from just after the first glitch?

[iainfm]

This is great work!

I wonder if it would help others if you uploaded two BeebEm savestates, one from well before the game starts glitching, and the other from just after the first glitch?

Excellent idea! I'll do that. I've also got a save state from well into the corruption (level 20 I think) and one post-crash. I'll stick those up too.

Edit: And done! Five save states added ranging from the game freshly loaded to the very last plane before it dies on its erse!

[dominicbeesley]

I can recommend the b-em trace feature for this kind of thing in not sure if there's a similar thing in beebem

[iainfm]

I can recommend the b-em trace feature for this kind of thing in not sure if there's a similar thing in beebem

Great, are you able to give an example of its use please? I had a play with the b-em debugger, but once I restart execution (with 'c') I can't figure out how to stop it again. Even closing the debugger window closes the whole emulator.

Beebem has got a debugger as well, which has been really useful so far. Only problem is beebem runs like a dog when the debugger is open.

[dominicbeesley]

The debugger in b-em is a bit touchy about its window!

If you press c then everything runs until the next breakpoint, or you can select Debug->Break from the main screen's menu. The console window used for the debugger stays open - you mustn't close it as it will exit the whole program! (I keep meaning to see if there's a way to fix this). Also beware that alt-tabbing between the debugger and the main window can get the main window stuck in full screen, pressing alt a few times unsticks it!

Confusingly Debug->Break doesn't do anything until the debugger has been activated (it should really be disabled?)

To get a trace type "trace d:\temp\temp.txt" (or whatever filename) and then "c" to continue until the moment of interest has passed then Debug->break to get back to the debugger then "trace" with no parameters to stop tracing. The file will be HUGE if you leave it running for too long so you will want to either hit Debug->Break pretty close to the time where things go pear shaped or use break points etc. B-em will run very slowly while the trace is going but that is usually a good thing!

(Sorry if this isn't clear, or I'm teaching to suck eggs, let me know if you want more details - I'm tired now and probably not making much sense)

D

[iainfm]

Hi,

Thanks for this - makes sense now!

I've given it a go, but I'm not getting a trace file created...and no trace option is shown when I do a help in the debugger window.

I'm on 2.2 - is there a later version I need?

Edit: Ignore - I've found a later version

[scarybeasts]

This is great work!

I wonder if it would help others if you uploaded two BeebEm savestates, one from well before the game starts glitching, and the other from just after the first glitch?

This might be the sort of bug where you need to catch it "in the act".
beebjit has the start of "time travel debugging" which may or may not help. It can capture an emulation run to a very small file (kind of like an quasi-infinite series of save state files) and then very quickly replay state to a chosen number of cycles. This can be used to zero in on the exact moment things go wrong. Longer term, I'll add a command to "go back in time" directly in the debugger.

I'm happy to go in to more detail if it sounds like it might be useful to debug this case, or other cases.


Cheers
Chris

[iainfm]

Ooft, 113Mb trace file from about a 3 second execution! That's some bedtime reading right there

@chris - I'll take a look at beebjit. Part of the problem is that I don't know exactly when things go wrong. All I can say is everything appears normal right up until the end of level 12. The first graphical glitch happens as level 13 prepares. However, due to the fact that level 23 begins to load, then crashes the game completely, I suspect the fault is occurring during the level load routine.

Of course, it could be the cause happens at the end of the previous level, and it only manifests when the load level code executes against what is then bad data...

[dominicbeesley]

Yes the traces are long but a good text editor (Notepad++, sublime text) should be able to handle them - then it's a case of searching for likely looking sequences in the trace file and working backwards. Judicious use of breakw in the debugger might help to catch it in the act if you can work out a memory location that shouldn't be getting written to.

[lurkio]

This might be the sort of bug where you need to catch it "in the act". beebjit has the start of "time travel debugging" which may or may not help. It can capture an emulation run to a very small file (kind of like an quasi-infinite series of save state files) and then very quickly replay state to a chosen number of cycles.

That sounds like it might be very useful!

But even if I had the skills to do any sort of serious debugging of machine code (which I don't, really), the problem for me personally is that I don't currently have a good way of running beebjit. For my sins, I'm on macOS Mojave. Perhaps I need a 64-bit Windows VM? (At the mo I only have a 32-bit Win VM install.) Or maybe I have to run 64-bit Windows in BootCamp..?

(Btw, I think I noticed recently that in your beebjit Github repo there were references to "ARM"..? Intriguing! What's that all about..? Is it to do with the ARM copro?)

[iainfm]

Ok, I have beebjit 0.9.4 installed. Any advice on how to do the debugger thing? If a linux build is preferable, I can boot to that (Ubuntu 20.04 I think).

(@lurkio, beebjit is compiled in linux, so you might be able to build it on the mac...which is unix-y at its heart).

I think my ideal debugging capability at the moment would be some way of logging every memory write, with the ability to filter specific ones (or ranges) out as I find out what they are. Not sure if that's possible or not? That way I could figure out which part of memory is being corrupted and try to work backwards from that.

[lurkio]

(@lurkio, beebjit is compiled in linux, so you might be able to build it on the mac...which is unix-y at its heart).

When I asked a while ago, I was given the impression that it probably wasn't possible to compile beebjit on macOS. But maybe things have changed since then..? I don't know.

[iainfm]

When I asked a while ago, I was given the impression that it probably wasn't possible to compile beebjit on macOS. But maybe things have changed since then..? I don't know.

I don't know much about macs, and hate them with a passion but I have one in my possession at the moment. It's on...the one before Big Sur, so I'll fire it up and see what errors make generates.

Edit: Yeah it throws errors and says it's not got a mac build yet, so I guess that's that!

[scarybeasts]

(Btw, I think I noticed recently that in your beebjit Github repo there were references to "ARM"..? Intriguing! What's that all about..? Is it to do with the ARM copro?)

The ARM references are about the start of JIT mode on 64-bit ARM processors. So, when complete, you'll be able to run a very fast beeb emulation on your Raspberry Pis! Also, it'll be interesting to see how fast Apple's new M1 processor really is....


Cheers
Chris

[scarybeasts]

Ok, I have beebjit 0.9.4 installed. Any advice on how to do the debugger thing? If a linux build is preferable, I can boot to that (Ubuntu 20.04 I think).

Yes, it's best under Linux for now. Runs OK on Windows but I don't put out builds too often. I'll polish up the ports once all of the core emulator is done.

(@lurkio, beebjit is compiled in linux, so you might be able to build it on the mac...which is unix-y at its heart).

I think my ideal debugging capability at the moment would be some way of logging every memory write, with the ability to filter specific ones (or ranges) out as I find out what they are. Not sure if that's possible or not? That way I could figure out which part of memory is being corrupted and try to work backwards from that.

beebjit can break on writes to a range of memory, but doesn't yet have easy logging of writes to a range.
I'd also put "b2" on your shopping list of emulators. It's one of the more modern ones, and is still maintained. I've used it's trace facility before but can't remember what filtering it has.

If I was taking a swing at this, one way to tackle it would be to trap a known-bad write. Those holes smashed in to the clouds look like they're at static memory addresses? I'd run the game (capturing state in beebjit with -capture), then replay with a memory write breakpoint on the cloud hole. When it gets punched, I'd have a look at what punched it, then replay "back in time", working out the sequence of things leading to that write.

IIRC I found a tricky sprite corruption bug in Camelot using a similar approach.


Cheers
Chris

[iainfm]

Thanks for all that - I'll have a look

If I was taking a swing at this, one way to tackle it would be to trap a known-bad write. Those holes smashed in to the clouds look like they're at static memory addresses? I'd run the game (capturing state in beebjit with -capture), then replay with a memory write breakpoint on the cloud hole. When it gets punched, I'd have a look at what punched it, then replay "back in time", working out the sequence of things leading to that write.

That's the weird thing. I know where the cloud sprites (and others) are stored. But if you look at the memory addresses of an uncorrupted beebem and a corrupt one, those memory addresses match exactly. Unless beebem is lying to me (and I don't think it is; I can manually corrupt the clouds/pigeons/etc by writing over their sprite areas in its debugger).

What's more, when the game ends (all lives lost) after the corruption begins, the game's high-score page is in mode 7. Starting a new game changes back to mode 2 (so all the graphics need to be redrawn from the (pristine, remember) sprite area. But - the holes in the clouds etc are still there!

Starting another game gives you another 23 levels until ultimate game crash, so it's not an additive corruption - the exact same corruption happens each run through (it would seem).

I've done more extensive memory comparisons (eg game code &1200-&2FFF, page zero, and a few others), but yet to actually find something that doesn't match a freshly-launched game.

I'm beginning to think it's something around byte/wrch/evnt vectors, but that's only a hunch at the moment.

[scarybeasts]

Thanks for all that - I'll have a look

If I was taking a swing at this, one way to tackle it would be to trap a known-bad write. Those holes smashed in to the clouds look like they're at static memory addresses? I'd run the game (capturing state in beebjit with -capture), then replay with a memory write breakpoint on the cloud hole. When it gets punched, I'd have a look at what punched it, then replay "back in time", working out the sequence of things leading to that write.

That's the weird thing. I know where the cloud sprites (and others) are stored. But if you look at the memory addresses of an uncorrupted beebem and a corrupt one, those memory addresses match exactly. Unless beebem is lying to me (and I don't think it is; I can manually corrupt the clouds/pigeons/etc by writing over their sprite areas in its debugger).

Interesting! I wasn't very clear, but I was assuming the clouds don't move on-screen and suggesting watching the screen memory address where the corruption appears.


Cheers
Chris

[billcarr2005]

I've managed to trace a crash, but on level 35!
I used the "don't die" cheat, changing &2238 to &60

The problem on this crash seems to be at &29E0

Code: Select all

29E0 LDA (82),Y
29E2 EOR (84),Y
29E4 STA (84),Y

Only problem is that 83 + 82 are &25D4 and 85 + 84 are &284C, both code areas, which clears 284C and causes a crash next time that code is hit.
I'll try putting a breakpoint at 29E0 and seeing what the values are when things are working correctly!

84 and 85 are both set a little earlier

Code: Select all

29C8 LDA 80 ; ADC #78 ; STA 84
29CE LDA 81 ; ADC #02 ; STA 85

So it's presumably an error with the values of 81 and 80 which then have a knock on effect!

Seems like it's the general sprite plot / removal routine?
Even on level 1, STA (84),Y is attempting to write above 8000, so it's looking like a good culprit for trampling on memory
Would seem that the word of 82+83 is *usually* 2350, which is the player sprite?

[iainfm]

Ooh, that's great! I wonder why you can get to level 35 when mine dies consistently on 23 though! What level do the graphical glitches start on yours, and what's your emulator etc?

Yeah, writing above &8000 doesn't seem wise...!

I've not worked out what the code around &29E0 does yet, and I'm a bit swamped today, but this is the area of code in question:

Code: Select all

.L29C3
        TYA
        PHA
        LDY     #$05
        CLC
        LDA     L0080
        ADC     #$78
        STA     L0084
        LDA     L0081
        ADC     #$02
        STA     L0085
        LDA     L0080
        AND     #$07
        EOR     #$07
        STA     L0074
        CMP     #$05
        BPL     L29EB

.L29E0
        LDA     (L0082),Y
        EOR     (L0084),Y
        STA     (L0084),Y
        DEY
        CPY     L0074
        BNE     L29E0

.L29EB
        LDA     (L0082),Y
        EOR     (L0080),Y
        STA     (L0080),Y
        DEY
        BPL     L29EB

        PLA
        TAY
        RTS

.L29F7
        RTS

[billcarr2005]

I'm using BeebEM 4.14
Might just be a coincidence, but are you reading the level number (stored at 1D5C?) in hex or decimal, since &23 is 35?

A stray bullet appears above the clouds on level 19, then the clouds mess up on level 20...

[iainfm]

I'm using BeebEM 4.14
Might just be a coincidence, but are you reading the level number (stored at 1D5C?) in hex or decimal, since &23 is 35?

A stray bullet appears above the clouds on level 19, then the clouds mess up on level 20...

That's the version I'm using as well. I'm just counting the number of waves while holding down return and running at 50x or 100x speed. It's possible I've missed some (although it would be a lot). I'll check that memory address in my save states (available on the github repo) and see what happens.

BTW, yes the player sprite is in a block of sprites around &2350

Edit, nope... my 'finger counted' level 22 matches &1d5c which is &16 (22) on my last savestate.