Jump to content
IGNORED

! FlashROM 99 & FinalGROM 99 - Repository


Recommended Posts

4 hours ago, Tursi said:

The GROM instruction is at >E0C2: 0F F0...

Oh brother, I didn't even see the last entry in the table: >F    >8300    Scratch-pad memory


Table    Address    Memory
>0    >0D1A    Console ROM
>1    >12A0    "
>2    >2000    Low memory expansion
>3    >3FC0    "
>4    >3FE0    "
>5    >4010    Peripheral card ROM (or RAM)
>6    >4030    "
>7    >6010    Cartridge ROM/ Rambo bank (RAM)
>8    >6030    "
>9    >7000    Cartridge bank / Rambo bank
>A    >8000    Decoded as >8300 on most machines
>B    >A000    High memory expansion
>C    >B000    "
>D    >C000    "
>E    >D000    "
>F    >8300    Scratch-pad memory

 

So, knowing this, I did correct my patch. It didn't help though, because I cant get the error to reproduce tonight!

On that note... This issue's occurrence pattern, does strike a chord with me... It's the same issue I often have on the FG's MINI MEMORY image, particularly at the LOAD(option 1) screen. I imagine that when the port connection's qualities are this intermittent, there is no more room for FANOUT, or perhaps noise levels dominate! So, I'm not too sure that this can be solved by program debugging.:twisted:

 

@fabrice montupet... I think you take the prize on this one...?

On 2/1/2021 at 8:06 PM, fabrice montupet said:

This means that a very little decrease cartrige port signal  could have an impact on the behaviour of this game using the FinalGROM99.

 

 

Personally, I think the solution might be to tin the FG99's contacts.:ponder:

  • Like 1
Link to comment
Share on other sites

9 hours ago, fabrice montupet said:

Thank you for all the effort to make this game working.

I tried tutpop, it doesn't work.

Doesn't work better, or doesn't work at all??

 

I mean, it could be an electrical problem, but why is this game so much more susceptible than the dozens of other programs that people run successfully?

 

Edited by Tursi
Link to comment
Share on other sites

The symptoms are exactly to same than before on the TIny-99/4Av2.
My cartridge port is clean, I regularly clean it.  My FG99 contacts are clean too.

 

BUT, this morning I have tested the new files and... The game works on a real TI-99/4A (with 32KB), even after some minutes of playing . It's a good news!  
I have tested the game with an another TI-99/4A equipped with the Mechatronic  80 col (so with a V9938 VDP), a CC9900 (so with 32Kb, FDC and I/O) and the Speech Synth. It works too after 6 or 7 tests. But on one test, I had two red balls that appeared just in front of the guy... I re-lauched the game and it worked. I  Don't know what it can be concluded to this stealthy problem.

 

So, now I have to understand why the game still doesn't work on my computer... It is the only one that causes problem, it is crazy ?
Finally, I was not able to verify the whole with my logic analyzer because of a lack of time. But I will do the soonest to understand this oddness!

  • Like 3
Link to comment
Share on other sites

16 hours ago, Tursi said:

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?

 

Works with the FG99 when PEB is not connected, random character garbage on startup with PEB connected.

Link to comment
Share on other sites

UberGROM with PEB, SAMS, Myarc HFDC, HRD4000B, and homebrew speech in PEB adapter. Starts and runs fine, generally made it to the second game screen before I got killed off (a normal thing for me).

 

I'm sending Fabrice an UberGROM board with the game loaded on it to see if that changes his symptoms. . .

  • Like 6
Link to comment
Share on other sites

6 hours ago, fabrice montupet said:

I have made some other tests on the second real 99/4A setup and I have seen again parasite graphics. This game is evil.

Yes, yes it is. The symptoms are still quite baffling. That usually means we aren't looking at the right symptoms, but at the moment I'm stumped. :)

 

Link to comment
Share on other sites

53 minutes ago, Tursi said:

Yes, yes it is. The symptoms are still quite baffling. That usually means we aren't looking at the right symptoms, but at the moment I'm stumped. :)

 

Just a thought. Looking at the picture of the Tutankham cartridge, we see that there is a whole world in it.  Reading the history of the game we learn that Parker Brothers was one of the few companies to be allowed to produce their own GROM,  we also learn that the cartridge was in its release stage. But we well see that there is still no GROM on the cartridge. Instead of that, we recognize a complex logic components set to emulate this GROM. So, could we imagine that the game were finally not really finalized and that some problems were stayed? The produced TI GROM didn't react as the emulated one in this prototype? That caused game working problems?

And the GROM file that we use is really the one that is in this prototype? Is it really the file ready to release?

... Many questions! ?

 

Edited by fabrice montupet
  • Like 1
Link to comment
Share on other sites

One important thing that is obvious from the PB documentation that turned up a few years back: they did NOT have TI permission to use GROMs. Parker Brothers designed their own chips that they believed successfully got around the issue by solving the problem in a slightly different way. These chips were called CROMs (not GROMs). The world of random chips on the boards replicates their CROM address selection circuitry (a workalike to the TI GROM). TI did something similar on their EGROM cartridge boards for GROM circuitry.

 

There isn't a dump of the original prototype anywhere, so we can't make a direct comparison of the files, unfortunately. Making a dump of it available to compare against might violate the owner's NDA, so it isn't an option. In his defense, I wouldn't want to take that particular risk either, based on what I know of the NDA. I suspect that it's likely that the builds would match if they could be compared though, as anyone else at PB who had copies back then would have had the latest builds for their testing--and those builds would have been the ones that walked out the door. It really depends on how many test builds there were before they reached final (and a copy of the debug testing records would be most informative there, although I doubt one of those will ever turn up).

 

Something I didn't identify in my original test was that I also tested it in a cartridge expander--and there were no issues there either. I suspect there may be a subtle difference in the FinalGROM timing that makes a difference with this game, especially if the emulators aren't experiencing the same issues. It would be interesting to look at it on real iron using a Wiesbaden Supermodul, a GRAM Kracker, a GRAMulator, a Maximem, a p-GRAM, a Mechatronic GRAM Karte, and an HSGPL. Maybe something will show up in those tests that would give us a clue as to where the problem is buried. . .

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Thank you for these informations. I wondered why, if Parker Brothers was allowed to produce TI GROM, they made a GROM simulator instead of using the TI dev kit and tools. Now it is clear that the reason is that they haven't any licence.

Timing problems... This possibility is running in my head since the beginning. I have to do some measures.

  • Like 3
Link to comment
Share on other sites

I knew we had the Parker Brothers development documentation somewhere (I spent much of this evening hunting my copy down). They call their GROM-like chips PCROMs (Program Counter Read Only Memory)--I forgot about the leading "P" when discussing it in the past. Here is the document, which describes exactly how it was used and how much of it was usable by the game programmer as well. It also includes the source code and some examples of how to hook to their startup code. Like GROMs, these were 6K, 16-pin chips. About 5.5K could be used for part of the program, the rest was eaten by the PCROM control program.

 

Here's a link to an interview with the Tutankham developer. He admits that there is a single known bug--but considers it more feature than bug.

 

Also, the source of the PCROM files also had complete, original source code for Frogger, so I included that here as well.

 

wickstead_ti994a_PCROM_overview.pdf

wickstead_assembler_d4_11-15-83_ti994a.pdf

  • Like 2
  • Thanks 3
Link to comment
Share on other sites

5 hours ago, fabrice montupet said:

Thank you for these informations. I wondered why, if Parker Brothers was allowed to produce TI GROM, they made a GROM simulator instead of using the TI dev kit and tools. Now it is clear that the reason is that they haven't any licence.

Timing problems... This possibility is running in my head since the beginning. I have to do some measures.

Sure, but there are two weaknesses with this theory...

 

First: we aren't running it on the original hardware - we're running it on modern hardware. So timing weirdness in the original cartridge seem unlikely to be the cause of failure today (and even if it was - it's extremely hard in GPL to do anything timing-wise. The console GROMs will slow any simulator down to their own speed.) Furthermore, if data was, say, misaligned to account for a strange hardware oddity, then it wouldn't work in emulation.

 

Second: Other Parker Brothers games, like Popeye, don't have this problem. That's why I tested copying the Popeye GPL code, but it appeared to make no difference. This means it's probably not the GPL code, at least, and reading data is unlikely to be tuned for a strange timing.

 

It's not impossible, at this point I'd give any theory credence, but I wouldn't bet my Coke on it. ;)

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Popeye works consistently.

 

Tonight Tut is malfunctioning almost 5% of the time. On the first night, it only started 5% of the time.

 

Here is what I've been up to over the last couple days...

 

      all.zip

 

They all fail to change the original symptoms(other than the specific graphic anomaly... sometimes) ...even TUT6, which I stop on the first ROM instruction.
 

  • Like 2
Link to comment
Share on other sites

The first 500 or so bytes of the PCROM for is the GPL needed to launch the cartridge and select the number of players. This part of the code should be identical in all four PB cartridges. Launch to ROM occurs once the number of players is selected and passed to the ROM routines. The remaining 5.5K of the PCROM contains graphics and sound lists and also controls ROM bank switching--it doesn't contain anything else, based on the spec, as PB considered GPL to be too slow for program execution. The Frogger source may be helpful in looking at how PB was setting up the grabs for graphics and sound data in their code.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

@Tursi: Yes, Popeye works fine, I have never saw it crashing after at least two years using it this the FG99.  But these two games are quiet dissimilar: Popeye and Tutankham don't share the same  hardware design.

Yes the FG99 is an new hardware, and this is exactly why I said that a timing or a signal problem can be a possibility.  Maybe the problem is software,  I don't exclude as well.   I just like to not exclude any way of reflection.

Studying the behavior of Tutankham on FG99 is interesting. I have noticed that the game crashed even more on the TIny-99/4A v2 than the real TI-99/4A,  so  an analyze of the bus connector of each computer could point on a/the problem.  

Edited by fabrice montupet
  • Like 2
Link to comment
Share on other sites

6 hours ago, Ksarul said:

The first 500 or so bytes of the PCROM for is the GPL needed to launch the cartridge and select the number of players. This part of the code should be identical in all four PB cartridges. Launch to ROM occurs once the number of players is selected and passed to the ROM routines. The remaining 5.5K of the PCROM contains graphics and sound lists and also controls ROM bank switching--it doesn't contain anything else, based on the spec, as PB considered GPL to be too slow for program execution. The Frogger source may be helpful in looking at how PB was setting up the grabs for graphics and sound data in their code.

Yeah, I looked at it and copied the startup code from POPEYE over in post 1325. Just from looking at the bytes, it seemed like only 192 bytes were needed for the startup code.

 

image.thumb.png.e83ee413d62431015cd0955063996985.pngimage.thumb.png.e6a6ff9632fd977fc8c9ff824ef6bbe1.png

 

Originally, I didn't look too deeply, just wanting to try it quickly I anchored off the F0 0F sequence, which is at offset 80BC in Popeye and 80C2 in Tut. But in looking closer now, we can see that Tut pads the header out with a few extra zeroes. Besides the padding, which causes all the addresses to be off, only the first instruction varies - the one that checks whether the byte at >6000 is >55:

 

e028 d6   ceq   >55, @>6000          ; Tut uses ceq
e02d 40   br    >e0cc   

 

e022 da   clog  >55, @>6000          ; Popeye uses clog!
e027 60   bs    >e0c6 

 

First time I've run xdg99 - very nice! I didn't need to strip the binaries as far as I did, but I'll attach the disassemblies too. Ultimately, though, I think we can rule out a coding error in the GROM portion... they are the same and it still fails with the Popeye boot, which is a known good.

 

popBoot.dis.txtTutBoot.dis.txt

 

 

 

 

  • Thanks 1
Link to comment
Share on other sites

11 minutes ago, fabrice montupet said:

@Tursi: Yes, Popeye works fine, I have never saw it crashing after at least two years using it this the FG99.  But these two games are quiet dissimilar: Popeye and Tutankham don't share the same  hardware design.

No, but they do share the same GPL startup code! Mostly. ;)

 

 

  • Like 1
Link to comment
Share on other sites

On 2/6/2021 at 6:43 PM, Tursi said:

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

 

Always right after pressing 1 or 2. I usually press 1. It seems like there are 3 different scenarios. 1. VDP Ext. video mode. 2. Cyan screen with a fast changing pattern of @ signs. 3. Fast changing pattern of mostly color blocks, often w/some in rows.

 

Pattern 2, kicks in instantly. While pattern 3, seems to take a second, kicking in just when the game would normally start.:roll:

 

Patching, seems to alter pattern 3, significantly. Pattern 2, always stays the same!

  • Thanks 1
Link to comment
Share on other sites

12 hours ago, HOME AUTOMATION said:

Always right after pressing 1 or 2. I usually press 1. It seems like there are 3 different scenarios. 1. VDP Ext. video mode. 2. Cyan screen with a fast changing pattern of @ signs. 3. Fast changing pattern of mostly color blocks, often w/some in rows.

 

Pattern 2, kicks in instantly. While pattern 3, seems to take a second, kicking in just when the game would normally start.:roll:

 

Patching, seems to alter pattern 3, significantly. Pattern 2, always stays the same!

Reading the documentation, that indicates that the issue is most likely in the ROM file, not the PCROM file. Pressing the selection key sets up the parameter pass to the ROM by placing the value in the Scratch Pad and lobs control to the ROM. It looks like the ROM is then failing to set up the game screen when it is supposed to reach back to the PCROM to grab the necessary graphics data. Something in that startup loop is off. I wonder if it has to do with the bank switching functionality? Is that initial write to select the bank overwriting something important to the rest of the program? This might explain the difference between a GRAM device failing, but a GROM device working. . .just thinking out loud here and I may be totally off base.

  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...