Miner49er - jump to death (or crash)?

[matthew180]

If anyone has Miner49er and a *real* 99/4A with a stock 9918A VDP (no F18A), can you please do this for me:

 

Start the first level and just start jumping. Jump as much as you can, climb a ladder or two and jump some more, jump across some holes, pick up an item or two, but just keep jumping. Please let me know if the 99/4A crashes, locks up, or anything similar. I can't get more than 10 seconds of game play when doing this on the console I'm using and I'm wondering if this is a serious bug in Miner49er, a flaky console, a flaky cartridge, or both.

 

Again, no F18A consoles since this has to do with trying to verify vaguely-documented characteristics of the 9918A that I'd like to match in the F18A, and Miner49er is currently the only game I know that (accidentally) relies this certain vague 9918A behavior.

[dphirschler]

Wish I still had my Miner cart for this test. But I guarantee you it never crashed like that on me back in the 80's. Neither the cart, nor the disk version...

 

 

Darryl

[TheGameCollector]

This is another one of those "when I say jump, you jump" moments... (budum chhhhhh!)

[Asmusr]

Is it somehow using the >4 sprites on a line flag for collision detection?

[matthew180]

It was *supposed* to use the 5th-sprite flag, however Tursi spent a bit of time tracing the code and the test of the status register in m49er is actually masking with >02 instead of >20. This lead to the question of, what does the 9918A do with the low 5-bits of the status register that the F18A is not? The nature of the low 5-bits is not specifically documented other than when the 5th-sprite flag is set and the frame-flag is clear.

 

I think I have reproduced the low 5-bit behavior of the status register, but I'm having trouble testing because m49er keeps crashing on my F18A test console as well as the stock 99/4A I am using. I think the cartridge I have is crapping out. Is there any way I can run the game from a CF7 device perhapse?

[Tempest]

I have a Miner cart and an unaltered TI99. I can try this out tonight if no one else beats me to it.

[am1933]

I tried it on my 4a that has no modifications, I have tried jumping about climbing ladders etc and my system is behaving normally.

[Asmusr]

>20 is the collision bit, so perhaps they were trying to check that instead of >40 which is the 'more than 4 sprites on a line' bit? Do you know what would they would accomplish by checking the 'more than 4 sprites on a line' bit?

 

It's somewhat surprising that checking >02 would work, since this means that either sprite #2, #6, #10, etc. is the fifth sprite, but I guess that must happen often enough for the collision to work. Collision checking doesn't work at all for Miner 2049er in my emulator because it doesn't emulate the 'more than 4 sprites on a line' bits, and it doesn't work in Classic99 either if you turn off flicker.

 

The cartridge image files I have found look like ROM to RAM loaders, so I guess it should be relatively easy to make a E/A#5 version from one of these, but I'm sure someone else will have one already that they can post. If not I will be happy to try to make one.

 

Rasmus

 

Miner2049er.zip

[Asmusr]

I just checked that always setting bit >02 makes the collision detection work in my emulator for Miner 2049'er. It looks to me like a simple bug, that they were actually trying to use the collision flag >20, but I may be wrong.

[matthew180]

I was going from memory so I don't remember exactly which bit it was in the status register (could have been >04), but the mask should have been for the upper nibble instead of the lower nibble. Based on Tursi's research we think it is a bug and m49er is not working on the v1.5 F18A firmware. Miner49er only works *at all* due to dumb-luck because the 9918A actually updates the low 5-bits of the status register while it is scanning sprites (undocumented), so it is actually constantly changing during the frame. When a 5th-sprite condition is detected and the Frame-flag is clear (meaning during the visible portion of the vertical raster), the 5S-flag is set and the low 5-bits are latched into the status register until the status register is read. A lot of other systems, i.e. MSX, use this to do scanline detection.

 

The reason that the status register mirrors and changes with the sprite counter is unclear, and it is obviously two separate internal registers in the VDP since sprite scanning has to continue even though a 5th sprite might have been previously latched during the current frame. Maybe this was a convenient way for the designers to peek inside the chip during development.

 

Anyway, if the low 5-bits don't change while sprites are being scanned during the frame (i.e. in the F18A and Classic99), then m49er won't do collision detection. A patched version the game would actually be more efficient and responsive to collisions.

 

Thanks for the disk version, I'll give that a try tonight so I can test my changes. Also, anyone else still willing to try and crash the game, please do so. All I had to do was jump, fall, or even sometimes move or just climb a ladder to crash the game.

[Tempest]

I don't know which firmware I have on my F18A but I tried my miner cart and it doesn't crash but there's no collision detection. I'll dig out my unaltered TI tomorrow and try it with that.

[dphirschler]

Here is my disk version from the 80's. Well, it's on this game disk. I haven't tested it though.

 

Games_4.dsk

 

Darryl

[Fritz442]

I played mine for about 20 minutes with no issues on my stock TI.

Jumped, ran, climbed, jumped...

Edited October 17, 2014 by Fritz442

[matthew180]

The disk version worked and I was able to get stable game play on a stock 99/4A and my F18A changes to match the behavior of the low 5-bits of the status register during the active frame.

 

Thank you everyone for the info, files, and help.

 

I will include this change in the next (and hopefully final) F18A firmware update.

[Asmusr]

Are there any programs that are actually using the 5th sprite bit and/or the low 5 bits, and not just by accident? I would like something to test my emulation.

[matthew180]

I don't know for sure. You might have to look to other platforms for that. However Pole Position is known to have a bugged loop similar to m49er related to the VDP interrupt. Popeye is also a game to test with, but I don't remember the details about it. Tursi will probably know.

[Tursi]

I just checked that always setting bit >02 makes the collision detection work in my emulator for Miner 2049'er. It looks to me like a simple bug, that they were actually trying to use the collision flag >20, but I may be wrong.

 

Yes... the bit being set triggers the code to do hitbox comparisons on all the sprites -- it appears that it was intended as an optimization to only test for collisions when a pixel collision occurred, but they got the wrong bit. As a result, it ends up testing every single frame (and so the game appears to work fine, except collisions are not pixel accurate ).

[Tursi]

Oh, and Popeye's "feature" is that if you don't correctly emulate VDP prefetch, the bottles that the sea hag throws won't be erased properly and will leave trails.

 

Pole Position's bug is a weird one that took a long time to sort out, and we're still not 100% certain why it works on the 9918 unless my theory that the 9918's VDP interrupt trigger is not 100% stable (ie: may vary by a scanline or two) is correct. It basically has two parts of the main loop which read the VDP status register, but only one of them tests the vertical blank bit. This happens during the blimp. The F18A would sometimes get into lockstep with this code and never exit the loop - pressing a key would disrupt the timing and let it continue. Matt fixed it by varying the trigger of the interrupt slightly. I probably still have that description somewhere.

[Asmusr]

 

Yes... the bit being set triggers the code to do hitbox comparisons on all the sprites -- it appears that it was intended as an optimization to only test for collisions when a pixel collision occurred, but they got the wrong bit. As a result, it ends up testing every single frame (and so the game appears to work fine, except collisions are not pixel accurate ).

 

Thank you for the explanations. Perhaps I will put together a demo that uses the 5th sprite bit.

[Asmusr]

I'm curious as to why the lower 5 bits contains the index of the the sprite with the lowest priority and not the one with highest priority, i.e. if sprites 0-5 are lined up the lower 5 bits contains 5 instead of 4. It seems to me that this way the VDP will have to continue checking all the sprites on a line even though it has already found 5.

[matthew180]

I'm curious as to why the lower 5 bits contains the index of the the sprite with the lowest priority and not the one with highest priority, i.e. if sprites 0-5 are lined up the lower 5 bits contains 5 instead of 4.

Where are you seeing this behavior?

 

It seems to me that this way the VDP will have to continue checking all the sprites on a line even though it has already found 5.

It does, we know this for a fact based on Tursi's first test that was polling the status register continuously. The only conditions that stop sprites from being processed during a scan line are:

 

1. All 32-sprites have been scanned.

2. A >D0 in a sprite's Y location.

3. The vertical scan line is not within the visible area, i.e. lines 0 to 191.

 

When sprite scanning begins for any visible scan line, the low 5-bits of the status register reflect the current sprite being checked as long as the 5S-flag is zero and the Frame-flag is zero.

 

As soon as a sprite is checked that *would be displayed* and would be the 5th sprite on a line, the 5S-flag is set to one and the low 5-bits of the status register are latched and no longer follow the current sprite being checked.

[Asmusr]

Where are you seeing this behavior?

 

That's how I'm reading section 5.2.3 of the attached:

 

 

5.2.3 Fifth Sprite Flag (5S) and Number

The Fifth Sprite Flag is set to a 1 whenever there are five or more sprites active on a horizontal

line. The Fifth Sprite Flag is cleared to a 0 after the Status Register is read or whenever the

VDP is externally reset. The number of the lowest priority sprite on the horizontal line is

loaded into thee lower five bits of the Status Register whenever the Fifth Sprite Flag is set and

is valid whenever the Fifth Sprite Flag is a 1. The setting of the Fifth Sprite Flag will not generate

an interrupt.

 

I assume the lowest priority sprite is the of with the highest number.

vdp_pg.pdf

[Tursi]

No, it's the lowest number. The VDP scans the sprite table in ascending order. We don't honestly KNOW if it processes the rest of the sprite list after setting 5S because there is no insight into that behavior, but it doesn't matter if it does because there's no external indication. (I would imagine it does since that would probably save some silicon... we could probably prove it with an analyzer on the RAM lines, but, it doesn't really matter.)

 

Instead of the confusing terminology in the datasheet there, think about it in terms of how it works, as Matthew described it.

[sometimes99er]

The first thing you might notice about the TI-99/4A version of Miner 2049er is its weird cartridge shape. This is due to the fact that it plugs into the system's expansion port (where the Speech Synthesizer plugs into) instead of the normal cartridge port. Most likely Tigervision did this because TI would not license out its GROM chips to many 3rd party developers. The GROM chip allowed for greater amounts of memory to be put onto a single cartridge, and without the chip you were limited to 8K of ROM. Therefore, in order to fit Miner 2049er onto a cartridge Tigervision made it plug into the expansion port, which allowed for more memory than standard cartridges.

I guess the original cartridge (perhaps also Espial, Killer Caterpillar, Arcturus and GROM Buster) mapped into the >A000- space ? Does any emulator support this ? Also, does any of the multi-cartridges/.. support this design ? Finally, how was the cartridge identified and started by the system ?

 

[+Ksarul]

Arcturus and Killer Caterpillar mapped into the >A000 space, but they also mapped into the >4000 DSR space to grab control and map the cartridge into the system. I suspect the other cartridges did the same, as did the Kantronics Hamsoft module (another side-port module).