! FlashROM 99 & FinalGROM 99 - Repository

[Tursi]

1 hour ago, Ksarul said:

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.

Yeah, but the test that changes the first assembly instruction to an infinite loop - still crashing - seems to discount that theory. I checked it and there's nothing wrong with the implementation.

 

Based on the disassembly of the GPL, I don't see anything that matches the cold-boot theory of RAM init, either.

 

A pure software issue should fail in emulation as well, unless it is /so subtle/ a timing issue, or caused by unemulated hardware. I would not expect a subtle timing issue to fail so reliably though.

 

I'm waiting to hear if the UberGROM fails in the same manner or not. Or to get my own TI set up already, darn it.  

 

[Omega-TI]

55 minutes ago, Tursi said:

I'm waiting to hear if the UberGROM fails in the same manner or not. Or to get my own TI set up already, darn it.  

 

My UberGROM version of Tutankham has NEVER failed on any of my TI's.  I was actually surprised to hear it was an issue.  When I tested for failure I used the FinalGROM as most people tend to use that cartridge these days.

Edited February 9, 2021 by Omega-TI

[+Ksarul]

1 hour ago, Tursi said:

Yeah, but the test that changes the first assembly instruction to an infinite loop - still crashing - seems to discount that theory. I checked it and there's nothing wrong with the implementation.

 

Based on the disassembly of the GPL, I don't see anything that matches the cold-boot theory of RAM init, either.

 

A pure software issue should fail in emulation as well, unless it is /so subtle/ a timing issue, or caused by unemulated hardware. I would not expect a subtle timing issue to fail so reliably though.

 

I'm waiting to hear if the UberGROM fails in the same manner or not. Or to get my own TI set up already, darn it.  

 

Actually, I did some extensive tests with the UberGROM this weekend using both of the Tutankham cartridges I had on hand. I had no failures, and I had a lot of different hardware connected while doing the tests. I also used a Navarone cartridge expander for some tests just to add a small timing delay--and the cartridges still worked every time.

 

That was why I suggested testing it with other GRAM devices, just in case that would help us isolate where the problem was showing up. I need to look at the specs to carve up a GRAM Kracker compatible image to test with (unless someone has already done that and can post it here).

 

Omega's UberGROM copy doesn't fail either, so that is a second data point.

 

It is a thorny compatibility problem, that's for sure.

[HOME AUTOMATION]

I still have high hopes for the tinning of the module's contacts idea. I'd have done so long ago, but haven't been able to find solder similar to TI's original type. I also didn't want to screw anything up while I was developing. The problems with the MINI MEMORY image, finally did get me into trouble though.

 

I seem to feel curious about the GREADY line perhaps not holding the CPU back strongly.

 

Even if the issue turns out to be electrical... it would be keen to understand the software side's interaction.

For right now, I'm trying to consider the problem musically...

 

Mystery...
Like this and many others
In the trees...
Blow in the night...
In the southern skies!

[+mizapf]

I could not trigger any crash with Tutankham in MAME. I tried 20 starts (selecting 1 player) with 50Hz, then 20 starts with 60 Hz. The game always started normally. There were no warning outputs either (e.g. like unknown opcode).

[+Ksarul]

47 minutes ago, HOME AUTOMATION said:

Even if the issue turns out to be electrical... it would be keen to understand the software side's interaction.

For right now, I'm trying to consider the problem musically...

 

Mystery...
Like this and many others
In the trees...
Blow in the night...
In the southern skies!

Ack! You have reminded me of a twisted poem I wrote in high school (nearly 50 years ago):

 

Bees, Bees,

In the trees,

Not asking please,

To bite me on the knees!

 

The teacher wanted a four-liner in a recognizable format. He was expecting one of the standard poetry formats, but did not contemplate a nut like me who would devise their own format on the fly. He wanted to know where I found the format--and was pleasantly surprised when I told him the format was my own. I think I wrote 40-50 of them over the years, and I know of two or three others that adopted the format as well.

 

Bats, Bats,

Furry gliding rats,

And uncomfortable living hats.

Now I need some flying cats!

 

And another one, written now for the fun of it. . .

[Asmusr]

Here are my findings for Tutankham:

• FG with no side port attachment: Always works
• FG with speech synth: Never works
• FG with SAMS memory: Works 4 out of 5 times

[+mizapf]

The speech synthesizer should not be a problem from the logical aspect, since I included it in my tests. As for physical aspects (signal stability), I don't know. The FG is not emulated either.

[HOME AUTOMATION]

Oops. I forgot to give credit to:

 

Allen Toussaint & Glen Campbell!!

 

@Ksarul, Kool poems! Thx for sharing!

 

Data's are good too...

 

"A tail is quite essential for your acrobatic talents;
You would not be so agile if you lacked its counterbalance."

 

https://memory-alpha.fandom.com/wiki/Ode_to_Spot

 

...But, I like yours better.

 

     P.S. Dad used to call pigeons, flying rats.

[sparkdrummer]

That’s good- flying rats!

I’ve always called them feathered rats. 

[fabrice montupet]

I Think I made a good progress about Tutankham ?
At the beginning, I noticed that (using the FG99) :
- The game regularly crashed on the real TI-99/4A with the Speech Synth. and expanded memory plugged.
- The game generally works on a real TI-99/4A without any expansions plugged.
- The game works even lesser on the TIny-99/4Av2 (has embedded Speech Synth. and SAMS )
That led me to look more closely the signals at the GROM connector for each computer setup.  After having study them with my logic analyzer, I noticed a weird behavior on the memory space decoding.  On the 99/4A computer and (also the TIny-99/4Av2) the components responsible of the decoding of the memory space for GROM, Speech Synth., VDP or sound are two 1-of-8 demultiplexers 74LS138 ( U504 and U505) and a quad 2-Input NAND Gates with open-collector 74LS03 (U506).

 

As all the IC on my TIny-99/4Av2 are socketed, I tested the game after replacing the two LS138 with HCT138 (high speed with TTL compatibility)... and FG99/Tutankham perfectly worked!  It worked during long minutes and passing the two levels (I lost before passing the next level  but I was able to redo a round). I switched-off the computer, relaunched the game: The game has worked fine too. No garbage. I redone the operation 9 or 10  times: And the game still works! ?

OK. now It  will be interesting to deeply study what is happening with the F99 and the game but I haven't any low level hardware specifications/information about this (great) cartridge.  It will be complicated.

 

Anyway, I'm happy. At least I can play the game with my FB99 with all  the peripherals attached.

 

[HOME AUTOMATION]

Intrigue!

[fabrice montupet]

I played again Tutankham during near 30mn and it works like a charm ?
The game has been tested in the two speed modes of the computer (with 12MHz and 14.318MHz crystals ) without any problem.
Since the beginning of my hardware correction, I have used the Tursi's modified files so I wanted to see how the game now reacted with the original tutankhG.bin and tutankhC.bin files... and the game works too with these files. 

Entered in the Stage 3. The game becomes more and more difficult, the green labyrinth asks two keys to enter Stage 4. I like this game!

Edited February 9, 2021 by fabrice montupet

[+arcadeshopper]

this reminds me of the issue with facemaker and finalgrom99...   if you have anything else plugged in you get graphics corruption

 

 

[fabrice montupet]

Since I made the correction, all the expansions of the computer are presents, among them the Speech Synthesizer, SAMS 1MB, RTC, expansion bus with the TI FDC and PIO cards.

I have tested Facemaker. In game and build mode, it works. I made 5 heads and no graphic garbage or anomaly on screen appeared.

[Tursi]

Driver strength, perhaps? The UberGROM drives pins directly from the AVR (we'd have to check the datasheet for drive current). GREADY is driven low when ready, and floats when not ready. The data bus is driven high to +5v or pulled low as applicable (and floats when not active).

 

Is the FG a 3 or 5 volt system? Or am I way off base?

 

 

[HOME AUTOMATION]

Both sort of...

 

When I re-flashed the AVR(Atmel ATmega 328P) I used 3.3v as indicated on the PCB's port.

 

Wikipedia says the 328P runs from 1.8v to 5v.

https://en.wikipedia.org/wiki/ATmega328

 

The Xilinx XC95144XL-10TQ100's specs say it runs on 3.3v, but can handle TTL input, but can only output 2.5v or 3.3v.

XC95144XL-10TQG100C Datasheet (PDF)

 

I believe there's a 3.3v regulator on board.
 
However, I can't get KICAD's Pcbnew to open the file. I was already using a workaround to open the file, but now I think my windows is too broken for inter-program launch... not sure why I can't open anymore!

 

a couple old screenshots is all I can pull up now...

 

[HOME AUTOMATION]

...Finalgrom99 on GitHub

[HOME AUTOMATION]

7 hours ago, Tursi said:

Is the FG a 3 or 5 volt system? Or am I way off base?

Back in action...

 

Not being too familiar with KICAD, I had somehow overwritten the project's files.

 

 

Looks like the CPLD is what interfaces with the TI's port. So probably 3v.

Edited February 11, 2021 by HOME AUTOMATION

[Asmusr]

No matter what hardware issues might exist, the software must also be doing something special compared to all the carts that work fine with the FG and sideport attachments, right?

[HOME AUTOMATION]

Certain combinations of data can cause excessive switching noise...⚡

 

https://en.wikipedia.org/wiki/Gray_code

[Tursi]

Yeah, it's still weird. Dragon's Lair was a 3.3v cart using a CPLD as a level shifter, and I didn't receive any complaints of it not working when plugged into a full system. Mind you, for better than 99% of the data you would not be able to tell if one byte was off... 

 

[+Lee Stewart]

The binary for fbForth 2.0 referenced in post #1 has not been updated since fbForth 2.0:12 (11/2019). We are now at fbForth 2.0:13. Everything you might need for FlashROM99/FinalGROM99 is in this ZIP file:

fbForth200_fROM99-fGROM99_20210305.zip

 

At the very least, you should load fbForth200_8.bin as the (non-inverted) cartridge ROM and put FBLOCKS and FBFONT (in FBLOCKS_20210223.zip contained in the above ZIP file) into DSK1. The cartridge ROM will run without FBLOCKS and FBFONT, but FBLOCKS has a lot of useful utilities and FBFONT has true lowercase with descenders.

 

I do not yet have the FlashROM99 or the FinalGROM99 to test the cartridge ROM on real iron, so please let me know if you have trouble with it and we can try to sort it out.

...lee

[Tempest]

Any more progress on Tutankham?  From what I'm reading it sounds like more of a hardware issue than something that can be fixed in software.

[HOME AUTOMATION]

By XMLing out from various addresses, I seem to have localized the trouble to a small section of the GPL code.

 

The issue can be seen, both on screen and in the source code provided by @Ksarul.

 

I didn't give it much thought at first ...but I had noticed early during debugging, that the nuber of players is supposed to display on screen ...yet happens so fast, that it cannot be seen!

 

Looking at the source...

 

e089 08   fmt                        display the selected key
e08a 81   col+  >02                  
e08b e1   hmove >02, @>8301          
e08c 01                              
e08d fb   fend                       

 

HMOVE is not a valid OPCODE, FMT or otherwise...

 

From:  The TI-99/4A Tech Pages:

 

FMT subinterpreter opcodes...

These opcodes become active once a FMT instruction has been executed and remain so until a FEND is encoutered. During this time all the regular opcodes become invalid. The interpreter thus enters a special mode that deals exclusively with screen access.

 

 

 

Perhaps it should be HTEX. The bytes appear to be invalid as well?

 

The MOVE can't happen in FMT mode either.

 

I don't see an example of the proper OPCODE and format for this type of MOVE, and I don't have a GPL assembler ...that I know of.

 

I think the MOVE is needed, as just branching past this section failed.