Modify QI console for finalgrom99 use

[+arcadeshopper]

Starting this thread to document and discuss modifying the QI console to include the signal missing that the FinalGrom99 needs to operate. 

 

Anyone with details, schematics, instructions please chime in.  @ralphb especially

[wierd_w]

I would think that a sidecar adapter would be the way to go. Something that basically just gives a vertical cartridge slot, and otherwise just passes through.  Every signal is present in the sidecar port, so the FG99 should work there just fine.

[+arcadeshopper]

19 minutes ago, wierd_w said:

I would think that a sidecar adapter would be the way to go. Something that basically just gives a vertical cartridge slot, and otherwise just passes through.  Every signal is present in the sidecar port, so the FG99 should work there just fine.

seems overkill for isn't it one bodge wire needed?  

[wierd_w]

Not if you want something solder-free, and easy for the user to use.

[+arcadeshopper]

4 minutes ago, wierd_w said:

Not if you want something solder-free, and easy for the user to use.

Ok well, this isn't that.    This is documenting the internal fix for those that want to solder.   If you want to design such a thing go for it 

[+OLD CS1]

ISTR the mutliplexing circuitry at the peripheral port prevents access to >6000 - >7FFF.

[jrhodes]

1 hour ago, wierd_w said:

I would think that a sidecar adapter would be the way to go. Something that basically just gives a vertical cartridge slot, and otherwise just passes through.  Every signal is present in the sidecar port, so the FG99 should work there just fine.

I'm all for that. A finalgrom that plugs into the side like the Espial / Miner 2049er carts. ?

[wierd_w]

It would not work appropriately as-is though, as OLD-CS1 points out. I had forgotten about the multiplexer crap.

 

While many cartridges can work with relocated base addresses, others expect the 32k area to be available for data. (rather than have the cartridge there.)

The FG99 itself expects the window to be in the cartridge rom area also, so the FG99 would need to be revised to live on the sideport since the cartridge rom area cannot be mapped directly from the sideport. (Due to the multiplexer crap.)

 

I guess a bodge-wire likely is the way to go.

 

Is it WE that is not passed to the cartridge port of the QI consoles? (making them unable to bank switch with write on rom?)

[+FALCOR4]

This is from Michael Bunyard's Hardware Manual regarding the cart port:

 

 

TI99_4A cart port info.pdf

[AwkwardPotato]

Assuming that the logic equations in the QI's TAL for GS#, ROMG#, A15 and WE# are identical to those in the standard 4A, you ought to be able to run one jumper wire from pin 4 on the cart slot to pin 11 of U28 (a chip right next to the 9900), and another wire from pin 6 on the cart slot to pin 4 of the 9901.

 

I don't have a QI board to test this on; no guarantees that it'll work, don't hold me responsible for damage to you or your TI ?

[AwkwardPotato]

Backing up slightly -- it's been suggested before that the FinalGROM/QI incompatibility was partly due to the missing CRU signals on the cartridge port. However looking at Ralph's schematics, it turns out that the FinalGROM doesn't make use of the CRU lines.

 

Worth noting that the QI TAL not only generates GS#, ROMG#, A15 and WE#, but also the RESET line for the cartridge port. In the 4A, this signal is generated by the TIM9904 clock IC. Perhaps differences in the RESET timing are enough to break compatibility with the FinalGROM?

[HOME AUTOMATION]

1 hour ago, AwkwardPotato said:

Perhaps differences in the RESET timing are enough to break compatibility with the FinalGROM?

I had considered the same. If the issue were timing alone, I would think @ralphb would have tried tweaking that a bit if possible. But maybe not, or perhaps he doesn't have a QI. I don't.

 

If I did have a QI, I would try using a POWER-UP header on the FinalGROM's menu. I can provide such a file, if someone with a QI wants to attempt this. It will require a FinalGROM .AVR update.

 

No guarantees that it'll work, don't hold me responsible if you "brick" your FinalGROM. I did, once! ?

[+arcadeshopper]

I have a console to test

Sent from my LM-V600 using Tapatalk

[AwkwardPotato]

2 hours ago, AwkwardPotato said:

Worth noting that the QI TAL not only generates GS#, ROMG#, A15 and WE#, but also the RESET line for the cartridge port.

Correction: the cart port's RESET line actually doubles as an input to the TAL, so scratch that.

 

However, as I understand it, the TAL does generate GS# (GROM select), A15.CRUOUT and WE# differently than the 4A did. For instance, in both the 4A and QI, the conditions for GS# going low include:

• MEMEN, A0, A3 and A4 being high
• A1, A2 and A15 being low

The last condition that must be met for GS# to go low differs between the 4A and QI. In the 4A, A5 and DBIN are NAND'd together:

 

 

If the above conditions are satisfied, GS# will go low as long as A5 and DBIN aren't both high. In the QI, however, A5 and DBIN are XOR'd rather than NAND'd. In other words, the QI's GS# will only go low if A5 is high while DBIN is low, or vice-versa. I'm not certain whether this difference has any impact on the operation of the machine.

 

In addition, the wait state generator in the TAL, which is involved in producing the A15.CRUOUT and WE# signals, is wired slightly differently than in the 4A. Still trying to understand the ways in which that might affect things...

Edited June 27, 2021 by AwkwardPotato

[HOME AUTOMATION]

2 hours ago, arcadeshopper said:

I have a console to test

Yes, you would be a good choice ...since you can unbrick!

 

I'll PM you the files.

[+DuaneAL]

4 hours ago, AwkwardPotato said:

Backing up slightly -- it's been suggested before that the FinalGROM/QI incompatibility was partly due to the missing CRU signals on the cartridge port. However looking at Ralph's schematics, it turns out that the FinalGROM doesn't make use of the CRU lines.

 

Worth noting that the QI TAL not only generates GS#, ROMG#, A15 and WE#, but also the RESET line for the cartridge port. In the 4A, this signal is generated by the TIM9904 clock IC. Perhaps differences in the RESET timing are enough to break compatibility with the FinalGROM?

When I first got my Finalgrom, I only had a working QI machine.  The FG didn't work, but as I tried it over and over, I occasionally could get several levels deep in the menu and once, just once, I got a program to run.  My first thought was that I was doing something wrong, but then I was set straight by others on the forum about the QI and bought several nonQI machines.  As I've thought about it over the years, I have come to the belief that it is a timing issue.  Just passing my experience on the off chance that it helps.

 

Edited June 27, 2021 by DuaneAL

[AwkwardPotato]

On the GROM select difference: I'm not convinced it has any effect on the QI's operation. Unlike in the 4A, GS# isn't activated in the QI when both DBIN and A5 are low. I'm not sure, though, if there's ever a time when both DBIN and A5 are low in the 4A. A5 being low would mean the GROM read ports at >98xx are being accessed, which implies that DBIN should be high. If any of the more GROM-knowledgeable people want to confirm that, it would be much appreciated  : - )

 

That being said, if the TAL really is to blame here, I think it's most likely related to the WE# and/or A15.CRUOUT lines.

Edited June 29, 2021 by AwkwardPotato

[JJB]

Finally managed to get my hands on a QI, now sitting next to my non-QI console. One of the reasons to get a QI was to have a look at this issue. I have a FG99, a scope and a logic analyser, happy to test suggestions. 

 

Cheers, 

 

Jochen

[+OLD CS1]

@JJB God speed, good sir!

[F.G. Kaal]

Hi all, Is there a complete schematic available of the TI99 QI?

 

Fred

[HOME AUTOMATION]

@F.G. Kaal...

 

TI 994/A Console And Peripheral Expansion System Technical Data

[F.G. Kaal]

2 hours ago, HOME AUTOMATION said:

@F.G. Kaal...

 

TI 994/A Console And Peripheral Expansion System Technical Data

Thanks!

 

[JJB]

To give you an update, I narrowed down the problem but no solution yet.

 

I am pretty confident it is not just a timing problem; I have spent hours comparing logic analyzer and scope output for a variety of test programs and there is no significant difference between classic and QI in terms of the main signals that I can see (see attached logic analyzer comparison between QI and classic for a GROM set address / read data).

 

One of the things I discovered is that ROM images load fine (you can test this by putting a single ROM image in the root of the SD). The problem lies with the GROM emulation, more specifically in setting and updating the GROM address. This is why you don't see a FG99 menu entry as it is GROM emulated.

 

The GROM emulation is a mix of clever programming and unnecessary bits. For instance, the code that generates GROM Ready can be omitted completely (including freeing up the GR pin) and FG99 still works fine. My hope is that by updating the GROM emulation I can get the thing to work. It's slow going as the CPLD is pretty much fully used so it's hard to add any useful debugging code (slightly hampered by the fact that I haven't used VHDL before this adventure). 

 

One other aspect that might or might not play a role is that the data bus termination on the QI GROM port is different to the classic. It is held high by pull-ups while the classic seems to be able to switch between pull-up and pull-down depending on read or write. The GROM addresses I see generated within FG99 (what a pain it is to probe SMD BTW) are all >FFFFFFFFFFFFF so this might be something. I was thinking that this might be due to the CPLD being a 3.3V device (but 5V tolerant); but driving the data bus is obviously not a problem as we can load ROM images so probably another red herring.

 

I'll keep you posted,

 

Jochen

 

[+mizapf]

Are these genuine hardware signals? I'm just curious to see whether I did it right in the MAME emulation.

[Tursi]

11 hours ago, mizapf said:

Are these genuine hardware signals? I'm just curious to see whether I did it right in the MAME emulation.

I posted timing diagrams for all kinds of reads and writes here as well, a few years back:

https://docs.google.com/document/d/16seTZczVk_We9FNbwMp2q5hLOKgwkVJitHrRKoH4VAo/edit?usp=sharing