Jump to content
arcadeshopper

Modify QI console for finalgrom99 use

Recommended Posts

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 ;)

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites
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?  

Share this post


Link to post
Share on other sites
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 

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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. 🙂

Share this post


Link to post
Share on other sites

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?)

Share this post


Link to post
Share on other sites

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 🙂

  • Like 2

Share this post


Link to post
Share on other sites

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?

  • Like 3

Share this post


Link to post
Share on other sites
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! 🙂

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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:

 

nand.thumb.png.71b42a05d20cdbdcdffa706894ed6412.png

 

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 by AwkwardPotato
  • Like 3

Share this post


Link to post
Share on other sites
2 hours ago, arcadeshopper said:

I have a console to test

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

 

I'll PM you the files.:)

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
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 by DuaneAL
  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)

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 by AwkwardPotato

Share this post


Link to post
Share on other sites

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

  • Like 6

Share this post


Link to post
Share on other sites

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

 

c vs qi-GROM RW timing.png

  • Like 8

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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...