! FlashROM 99 & FinalGROM 99 - Repository

[tmop69]

33 minutes ago, Omega-TI said:

Potential confirmation?  If so, a routine to set, or reset console memory could be inserted at the beginning of an updated .BIN... or am I off base here?

 

 

 

 

yes, I remember to have experienced the same behaviour with this game. Not a big issue, just a reset to have it working again. ?  

 

[+remowilliams]

With the PEB attached I can reset the FG99/system until the cows come home, get bored, go out for a stroll, and come home again - and it still doesn't work.

 

 

or something like this if it does load (which is not very often).  Spot the problem.. 

 

[fabrice montupet]

I wonder if the problem couldn't be in relation with timings... I made a test: I left the 32k RAM/SAMS, speech Synth. and all expansions connected. In all case, when I launch the game with my FinalGROM99, I get a crash with garbage on the screen. But, if I remove the little cartridge extender that I made and I plug the FinalGROM99 directely on the cartridge port, then I launch the game, In all case I get a first screen telling me to choose the number of players and the game crashes after the selection. The game still crashes but not at the begining as when I install the cartridge extender. This means that a very little decrease cartrige port signal  could have an impact on the behaviour of this game using the FinalGROM99. It is too late (2 AM) to verify with my logic analyzer, I will see tomorrow.

Edited February 2, 2021 by fabrice montupet

[Tursi]

3 hours ago, fabrice montupet said:

I wonder if the problem couldn't be in relation with timings... I made a test: I left the 32k RAM/SAMS, speech Synth. and all expansions connected. In all case, when I launch the game with my FinalGROM99, I get a crash with garbage on the screen. But, if I remove the little cartridge extender that I made and I plug the FinalGROM99 directely on the cartridge port, then I launch the game, In all case I get a first screen telling me to choose the number of players and the game crashes after the selection. The game still crashes but not at the begining as when I install the cartridge extender. This means that a very little decrease cartrige port signal  could have an impact on the behaviour of this game using the FinalGROM99. It is too late (2 AM) to verify with my logic analyzer, I will see tomorrow.

That's pretty bizarre...

 

Omega's crash is clearly a VDP register getting screwed up - that's external video being turned on. But remowilliams' screenshots clearly show it's not THAT register, at least, that is crashing his copy.

 

But yeah... timing and possibly hardware... though has anyone had the issues on an UberGROM board? Technically just having RAM and Speech plugged in shouldn't affect timing - RAM never should, speech only if it's accessed. But we all know computers don't care much about what SHOULD be.

 

 

 

 

[HOME AUTOMATION]

I spent a few hours fiddling with this yesterday. I came up with 4 separate patching attempts. The last one seemed to work... but more testing seemed to prove this to be a fluke.

 

While stepping through the program and writing the last patch... just as I had completed the ambitious patch... I thought I would step the program a little further, perhaps to find out when/wherefore/why interrupts would be off again.

 

Oddly execution seemed to get stolen... I expected B *R11 to execute next, as happened last time through...
Instead I found myself at >0900. Is that perhaps the interrupt driven sprite handler kicking in?

 

In my first patch attempt, I changed the first enabling of the sound processing interrupt, to a strobing on/off instead. The game started with no sprite movements.

I'm guessing that more strobing of interrupts, and less "just leaving them on" is necessary. I seem to be under the impression that leaving the interrupts enabled works well to update sprite movement. But sound processing needs interrupts off most of the time?

 

Curious, how the E/A manual shows/tells of the need to strobe the interrupt enables early on in the "sound" section, but in the actual examples, this is handled elsewise. Similarly, in the "sprites" section, it is explained that interrupts should be left on to accommodate the sprite's motion, yet in the provided example interrupts are strobed.

 

                            

[Tempest]

I wonder if the programmer of the game could be contacted to ask about this?  I know he was around, at least a few years ago.

[Tursi]

On 2/2/2021 at 5:01 PM, HOME AUTOMATION said:

I spent a few hours fiddling with this yesterday. I came up with 4 separate patching attempts. The last one seemed to work... but more testing seemed to prove this to be a fluke.

 

While stepping through the program and writing the last patch... just as I had completed the ambitious patch... I thought I would step the program a little further, perhaps to find out when/wherefore/why interrupts would be off again.

 

Oddly execution seemed to get stolen... I expected B *R11 to execute next, as happened last time through...
Instead I found myself at >0900. Is that perhaps the interrupt driven sprite handler kicking in?

 

In my first patch attempt, I changed the first enabling of the sound processing interrupt, to a strobing on/off instead. The game started with no sprite movements.

I'm guessing that more strobing of interrupts, and less "just leaving them on" is necessary. I seem to be under the impression that leaving the interrupts enabled works well to update sprite movement. But sound processing needs interrupts off most of the time?

 

Curious, how the E/A manual shows/tells of the need to strobe the interrupt enables early on in the "sound" section, but in the actual examples, this is handled elsewise. Similarly, in the "sprites" section, it is explained that interrupts should be left on to accommodate the sprite's motion, yet in the provided example interrupts are strobed.

 

>900 -- yes, that's the console interrupt handler starting. Tut leaves the interrupts on most of the time, so you can jump after almost any instruction. If you look at the readme with my patch attempt, you can see where I patched to prevent that from interrupting any VDP access (at least according to running under Classic99), which SHOULD render the interrupts safe.... but it's possible that some table being interrupted mid-update might cause random scribbling in RAM (though I am struggling trying to conceive of such a case).

 

TI recommended running the console with interrupts disabled, and just strobe them as you note at a fixed, safe point in your code. While people can argue whether that's a good overall strategy, the console's software was written with that assumption in mind, and when you violate assumptions, you start to get hard-to-find bugs.

 

Part of me wonders if this is why this otherwise-seemingly-complete software wasn't released...? 

 

[HOME AUTOMATION]

1 hour ago, Tursi said:

but it's possible that some table being interrupted mid-update might cause random scribbling in RAM (though I am struggling trying to conceive of such a case).

Ah, you mean a table in the game's program? ...interesting!

 

I thought perhaps execution was jumping into 32k. This was my reasoning when attempting my fourth patch, which simply cleared the 32k memory expansion. I've had this happen before in my own programs, often dealing with LOAD interrupt. If 32k is all >00s, execution should continue at >0000 or >6000. This could, under the right conditions, allow the program to continue running w/o any obvious faults.

 

To try and prove the patch didn't work, I than initialized all 32k words to >10ff, expecting a lockup if execution was diverted into 32k. But the game continued to run well! The issue does seem to have a rather phantom quality ...although for which I have come up with many justifications.

 

It is at these times that I feel like my console is playing Fizzbin with me! I wish I was set-up to step this on hardware though.

 

Guess I should have believed it when you suggested that 32k, went untouched.

 

  P.S. Now I'm moving towards thinking that something is aloof in PAD or it's use of WS(s), as the game often seems to start fine for many attempts, than not(also for many attempts).

[+remowilliams]

'Race through the pyramid in search of the hidden treasure and weird nondeterministic behavior!'   

[Tursi]

56 minutes ago, HOME AUTOMATION said:

Ah, you mean a table in the game's program? ...interesting!

 

I thought perhaps execution was jumping into 32k. This was my reasoning when attempting my fourth patch, which simply cleared the 32k memory expansion. I've had this happen before in my own programs, often dealing with LOAD interrupt. If 32k is all >00s, execution should continue at >0000 or >6000. This could, under the right conditions, allow the program to continue running w/o any obvious faults.

 

To try and prove the patch didn't work, I than initialized all 32k words to >10ff, expecting a lockup if execution was diverted into 32k. But the game continued to run well! The issue does seem to have a rather phantom quality ...although for which I have come up with many justifications.

 

It is at these times that I feel like my console is playing Fizzbin with me! I wish I was set-up to step this on hardware though.

 

Guess I should have believed it when you suggested that 32k, went untouched.

 

  P.S. Now I'm moving towards thinking that something is aloof in PAD or it's use of WS(s), as the game often seems to start fine for many attempts, than not(also for many attempts).

I meant a table like the console sound interrupt pointers... but if there is a custom interrupt hook (I didn't check), then that raises the possibility of internal state being corrupted. I did not that the screen draw code seems to be some kind of compression unpacker - those sorts of algorithms are very susceptible to corrupted data (where a blind data copy usually still finishes to the right target, you just get onscreen corruption ).

 

I tested whether the game touched expansion memory or speech by setting access breakpoints in Classic99, and then playing through the game. I worked out where the lives and time were stored so I could play for an extended period.  No hits to either one.

 

It is a strange bug... I've actually not tried to run it on my hardware, so I haven't seen the crash yet. I suppose crashing it with a logic analyzer attached might offer SOME insight... at least you can see if it jumped into hyperspace or is still executing normally with just corrupt graphics...

 

 

[+FarmerPotato]

3 hours ago, Tursi said:

I meant a table like the console sound interrupt pointers... but if there is a custom interrupt hook (I didn't check), then that raises the possibility of internal state being corrupted. I did not that the screen draw code seems to be some kind of compression unpacker - those sorts of algorithms are very susceptible to corrupted data (where a blind data copy usually still finishes to the right target, you just get onscreen corruption ).

 

I tested whether the game touched expansion memory or speech by setting access breakpoints in Classic99, and then playing through the game. I worked out where the lives and time were stored so I could play for an extended period.  No hits to either one.

 

It is a strange bug... I've actually not tried to run it on my hardware, so I haven't seen the crash yet. I suppose crashing it with a logic analyzer attached might offer SOME insight... at least you can see if it jumped into hyperspace or is still executing normally with just corrupt graphics...

 

 

@Tursi did you or @rasmus succeed in overrunning VDP memory speed, by executing LWPI >8C00, LI R0/R1 out of PAD? Is Tutankhamun doing any crazy optimization like that?

 

That's my guess for how you could get corrupt VDP registers/RAM on real hardware but not on Classic99.  Would it be immune to this sort of bug?

 

 

[Tursi]

Yeah, Classic99 is immune to overruns. I put some code in to warn about sequences that have the potential to overrun, but some TI software triggered it. Since my check didn't take into account whether the VDP was in a safe place, it was considered too spammy and I disabled it. I guess I can re-enable it... that would at least call out any potential hits...

 

... does not appear to be any such cases, at least not that Classic99 can detect.

Does it crash under MAME? Let's put that accuracy to the test. More importantly, if it doesn't, we can narrow down the possible causes.

 

[+mizapf]

As far as I know, the VDP implementation in MAME does not emulate overrunning.

[Tursi]

1 hour ago, mizapf said:

As far as I know, the VDP implementation in MAME does not emulate overrunning.

No... I don't think anyone who has attempted it has kept it (BlueMSX tried for a while too, IIRC)... but I do wonder, since it's a different implementation strategy, if the game behaves differently. If it does we can focus on the differences.

 

[+mizapf]

I mean, it may be possible to implement - if somebody cared for reimplementing the VDP as a true processor. Currently, it is (not very MAME-like, in fact) implemented as a simple slave device that only does its rendering by itself, but shows no real cycles for memory and register access. And if somebody did, this will cost some percent of performance again (I'm already hearing the comments... ? ).

 

[tmop69]

I don't know if could be of any help, in the MiSTer TI99 core the game is working correctly, no crashes.

[Tempest]

Do we have a list somewhere of games still missing from the FinalGrom repository?  Are all the cartridge based games accounted for at this point?  I know there are a few prototypes that are missing still like the other version of Wing War.

[Tursi]

7 hours ago, mizapf said:

I mean, it may be possible to implement - if somebody cared for reimplementing the VDP as a true processor. Currently, it is (not very MAME-like, in fact) implemented as a simple slave device that only does its rendering by itself, but shows no real cycles for memory and register access. And if somebody did, this will cost some percent of performance again (I'm already hearing the comments... ? ).

I don't think it's a VDP overrun - on the TI it's an exceptionally unlikely case, and the way the existing VDP access functions in Tut are coded, I really doubt there's another one that uses the highest performance functions to talk to the VDP.

 

MAME implements everything differently from Classic99, so if there is a behavior difference in the game, then we can focus on how the emulators differ to solve the issue. And if the game works perfectly in MAME, then it has a bug just like Classic99 does

 

As for whether it can be emulated to that level - of course. But you will need to rewrite the emulation down to the memory cycle, since the overrun is caused by the VRAM access slots and whether they are consumed by data fetches or not. That and the interaction with the CPU's memory cycles would need to be precise to be correct. It seems simple on the surface but yeah...

 

[+mizapf]

Does Tutankham use full 8K "GROMs" (that is, emulated GROM)? Searching the forum I found that @Ksarul once reported that there is a prototype cartridge; any pictures? What kinds of ROM chips are used? (I need this information for the ZIP version.)

 

I played Tutankham shortly, reaching level 2, so far no crashes.

 

The RPK below is defined as "gromemu" (8K GROM). The above one was "standard" (6K), so if the 8K space is used, it will fail at some time.

tutankham.rpk

[+Ksarul]

6 minutes ago, mizapf said:

Does Tutankham use full 8K "GROMs" (that is, emulated GROM)? Searching the forum I found that @Ksarul once reported that there is a prototype cartridge; any pictures? What kinds of ROM chips are used? (I need this information for the ZIP version.)

 

I played Tutankham shortly, reaching level 2, so far no crashes.

 

The RPK below is defined as "gromemu" (8K GROM). The above one was "standard" (6K), so if the 8K space is used, it will fail at some time.

tutankham.rpk 43.49 kB · 1 download

Here's a link to a picture of the prototype. Bryan Ropollo bought it from the original programmer a long time ago. . .it is a very strange board, but it emulates the PB CROMs described in the CROM specifications discovered a few years ago (posted here and on WHT, IIRC).

[Tempest]

The RLS.1 on those labels means they considered it ready for release.  This isn't a WIP version.

[+mizapf]

Are the files TUTANKHAMC.bin and TUTANKHAMG.bin genuine dumps of the two chips (nothing modified or rearranged)?

[+Ksarul]

1 hour ago, Tempest said:

The RLS.1 on those labels means they considered it ready for release.  This isn't a WIP version.

True, but what we don't know for sure is that the code we have is identical to the code on that prototype. The GRAM files came from a different source, and are of unknown provenance. Bryan had to sign a never-release-the-ROM NDA in order to complete the original transaction. Maybe we need to ask him to compare the code we have with the code in his proto to verify that they are the same release. . .that way, he isn't violating his NDA, but we will know for sure if the code is correct.

 

I think that answers your question @mizapf (we were typing at the same time).

 

@Toucan, can you safely shed any additional light here?

 

[HOME AUTOMATION]

On 2/4/2021 at 3:24 PM, Tursi said:

I meant a table like the console sound interrupt pointers...

...doh! Looks like I had you right the first time.

 

So, I put in another hour or so on this...

 

I set a breakpoint range of (6000-7FFF), to find the rom's entry point... it's >67AC... looking back, machine language execution begins at >8302. I believe that I see where GPL sets >8300 to >8302. I'm assuming that an XML to >A0(>8000) is used to exit GPL's interpreter. There are 2 >0F >A0 sequences in GROM, neither of which, when changed to >0F >70, alter the transfer of execution from >8302! I'm guessing either the program throws a transfer address on one of the stacks, or more likely, execution is starting at >8300 or >8302, through some rouge(unintended) process. 

 

Anyhow, one thing I did, was to change >67AC to >10FF. The program does loop here on Classic99(black screen). This program also stops on a black screen on a real TI, sometimes. However, many times, the same old errors occur. So, it seems the issue is happening in GPL, before ROM execution ever begins.

 

I'm afraid my expertise does not extend far enough to try any useful GPL patching right now... but I'm wondering if interrupts need to be off when SCAN or other console routines run from GPL.

 

Edited February 6, 2021 by HOME AUTOMATION

[Tursi]

Yeah, you can see in the trace that the GPL instruction is interpreted at >608, which is XML. The GROM instruction is at >E0C2: 0F F0 - the number in parenthesis after the GROM address in the debugger is the last GROM address that was actually /read/ by the CPU.

 

   0278  0454  b    *R4                    GPL Interpreter with the final opcode
   0608  D25D  movb *R13,R9         Start of XML interpreter, get the argument.
   060A  C109  mov  R9,R4              We can see in the debugger that the last read GROM address was >E0C4
   060C  09C9  srl  R9,12                 Shuffle the argument
   060E  0A19  sla  R9,1                   
   0610  0A44  sla  R4,4                   
   0612  09B4  srl  R4,11                  
   0614  A129  a    @>0cfa(R9),R4   look it up in the table, we get >8300
   0618  C114  mov  *R4,R4             indirect jump - get the word at >8300, which is >8302
   061A  0694  bl   *R4                    Branch to assembly function (>8302)
   8302  02E0  lwpi >8300               
   8306  C020  mov  @>6002,R0      Contains >8300
   830A  D420  movb @>8312,*R0   Contains the number of players requested (1 or 2)
   830E  0420  blwp @>6002            Jumps off into the ROM
>  67AC  02E0  lwpi >8300                 

 

So I may have misunderstood something here.. are we saying that the game crashes /before/ the player select screen? Or after?

 

Either way, your test does seem to have some merit. My understanding was that the Parker Bros games all used the same generic GROM, what if we drop, say, Popeye's GROM there instead? ... Tested no, that didn't work at all.  Apparently they are NOT the same, not even close according to a diff. Interestingly, they start the same way, with the same sequence as above, but then Tut goes crazy.

 

But then.. that makes sense, doesn't it? All the compressed graphic data would be wrong. What if we replace just the boot GROM...? This is the last one in the image, at offset 0x8000.

 

The startup code between the two is different - Tut's is a little longer, but I didn't try to disassemble it. I just copied 192 bytes from Popeye overtop of the same startup code in Tut. It seems to run okay in Classic99, so can we try that?

 

TutPop.zip

 

but I'm wondering if interrupts need to be off when SCAN or other console routines run from GPL.

 

You don't control the interrupt mask in GPL, so that's not a concern.

 

Edited February 6, 2021 by Tursi