Interesting bugs in old games

[matsondawson]

I've spent about 20 hours on games that don't seem to work right in my emulator, and most of the problems have come down to one thing.
Games using unitialised memory.

Poker and AE are two examples.

In AE PAL at least, the screen is sometimes offset to the left and up incorrectly all due the intialisation code calling the Kernal ROM to get the screen base, but not initialising the memory the kernel uses to 0 before it starts. So the screen base ends up being something like 1E20 instead of 1E00. Certain random values that are in memory cause it to fail on a real Vic20 sometimes, but on an emulator which generally does not have random memory on startup it can consistently fail, or consistently succeed.
You can reproduce in Vice 2.1 by loading ae, starting the game, and then resetting.

Another example is Poker. Sometimes the F1 key to start doesn't work, I've tested this on my Vic20 by turning it on and off heaps. Turns out it has the same problem, certain random values in memory on startup cause the F1 key not to work.

King Tut, and Xeno are another example, I press any key with the uninitialised memory set to certain values and the games crash.

All lots of fun really!

[Mayhem]

I have to ask those who've tried it so far, are both of these issues fixed in the beta of the new Vice?

Yeah, Poker wouldn't work properly in GB20, the F1 button refused to respond. And AE is offset on the screen. I think I asked NBLA to come up with workarounds to get them to function correctly, but it would be nice to have to pure cart dumps operate 100% in emulation too.

[matsondawson]

You could try detecting reads from uninitialised memory, and depending on the memory location that the read is coming from and going to put the most likely value to work in.
That'll be my initial fix, hopefully I can get a combination that fits all the buggy games.

[matsondawson]

I notice also that the Kernal Tape load code does a: BIT $B0E6
Which has neither ram or peripheral attached to it, I wonder what its purpose is. If you look at FA2D in the kernel you'll see the instruction.
I think instructions following it remove any effect it might have.

Edit:
I figured it out, B0 E6 is BCS *-something
It must be a timing thing, BIT $B0E6 is mean to have no effect, unless you branched into the middle of it.

[Mike]

Code: Select all

.C:fa25   A5 92      LDA $92
.C:fa27   F0 07      BEQ $FA30
.C:fa29   30 03      BMI $FA2E
.C:fa2b   C6 B0      DEC $B0
.C:fa2d   2C E6 B0   BIT $B0E6
.C:fa30   A9 00      LDA #$00

It's a masked 'INC $B0' instruction, that only gets executed, when $92 contains a negative value.

[matsondawson]

Oops, I read it backwards, INC it is!

[carlsson]

Hm, that's a programming trick I always forget.

[TBCVIC]

Damn, that's clever. Is there a document or webpage somewhere with more such neat tricks? I know some tricks myself, though I guess most are common knowlegde. Maybe we should just make a thread here

[wimoos]

How about pushing a calculated address on the stack and later perform an RTS. Mind you, the address will be incremented before operation continues at the desired location.


LDA #>(LABEL-1)
PHA
LDA #<(LABEL-1)
PHA
.
.
.
RTS

LABEL:
LDX #$0A
.
.

[nbla000]

Poker and AE are two examples.

Both games seems to work properly on Mega-Cart (PAL machines), I'm wrong ?

[matsondawson]

They work depending on what random garbage is in memory when you restart. There's a small number values that will make the games not work properly. So you have to switch your computer on and off heaps to get it to start in a non-working state.

[nbla000]

They work depending on what random garbage is in memory when you restart.

Interesting... I never noticed that