tmop69 Posted February 1, 2021 Share Posted February 1, 2021 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? ERROR CONDITION.mp4 yes, I remember to have experienced the same behaviour with this game. Not a big issue, just a reset to have it working again. ? Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted February 1, 2021 Share Posted February 1, 2021 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.. 1 Quote Link to comment Share on other sites More sharing options...
fabrice montupet Posted February 2, 2021 Share Posted February 2, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 2, 2021 Share Posted February 2, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted February 3, 2021 Share Posted February 3, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
Tempest Posted February 3, 2021 Share Posted February 3, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 4, 2021 Share Posted February 4, 2021 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...? 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted February 4, 2021 Share Posted February 4, 2021 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). Quote Link to comment Share on other sites More sharing options...
+remowilliams Posted February 4, 2021 Share Posted February 4, 2021 'Race through the pyramid in search of the hidden treasure and weird nondeterministic behavior!' 1 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 4, 2021 Share Posted February 4, 2021 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... 2 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted February 4, 2021 Share Posted February 4, 2021 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? Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 5, 2021 Share Posted February 5, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 5, 2021 Share Posted February 5, 2021 As far as I know, the VDP implementation in MAME does not emulate overrunning. Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 5, 2021 Share Posted February 5, 2021 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 5, 2021 Share Posted February 5, 2021 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... ? ). Quote Link to comment Share on other sites More sharing options...
tmop69 Posted February 5, 2021 Share Posted February 5, 2021 I don't know if could be of any help, in the MiSTer TI99 core the game is working correctly, no crashes. 1 Quote Link to comment Share on other sites More sharing options...
Tempest Posted February 5, 2021 Share Posted February 5, 2021 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 5, 2021 Share Posted February 5, 2021 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... Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 5, 2021 Share Posted February 5, 2021 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 2 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted February 5, 2021 Share Posted February 5, 2021 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). 4 1 Quote Link to comment Share on other sites More sharing options...
Tempest Posted February 5, 2021 Share Posted February 5, 2021 The RLS.1 on those labels means they considered it ready for release. This isn't a WIP version. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted February 5, 2021 Share Posted February 5, 2021 Are the files TUTANKHAMC.bin and TUTANKHAMG.bin genuine dumps of the two chips (nothing modified or rearranged)? Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted February 5, 2021 Share Posted February 5, 2021 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? 3 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted February 6, 2021 Share Posted February 6, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted February 6, 2021 Share Posted February 6, 2021 (edited) 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 1 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.