Interfacing with the cartridge port

[AwkwardPotato]

Lately I've been working on interfacing an Arduino to the cartridge port of the TI-99 in an attempt to emulate a GROM. The Arduino has functions for reading data, along with reading and writing to/from the GROM address, and it is programmed to handle the GROM select, mode, and direction lines, along with the address/data bus. However, upon inserting the cartridge that connects to the Arduino and powering up the system, it doesn't manage to move past the point at which the sound chip is turned off at the beginning of the boot process. After a few hours of troubleshooting, I am still unable to find a cause for the problem. What are some the reasons that a problem like this might occur?

 

Thanks!

Edited May 21, 2017 by AwkwardPotato

[AwkwardPotato]

UPDATE: The error in which the system couldn't get to the point at which it would turn off the sound chip occurred when I powered the Arduino off the cartridge port. Now, when powering it via USB, the TI-99 starts having strange graphical issues:

 

The TI also fails to move past turning off the sound chip when the cartridge is plugged in but the Arduino is not powered on.

Edited May 21, 2017 by AwkwardPotato

[Tursi]

The system initialization including clearing the sound chip happens via GPL. Furthermore, all GROMs on the bus must respond to all GROM sequences. The most likely causes of this issue are not handling GROM Ready correctly and getting the sequencing of the signals wrong. Response speed is not likely an issue, with correct sequencing I was able to run both much faster and much slower than the console GROMs without any issues. (That was one of my tests, in fact).

 

My UberGROM code runs on an AVR - though it's lower level than Arduino it should have the details you need. Have a look here: http://harmlesslion.com/software/ubergrom

 

The actual GROM interface to the console is handled in main.c

[AwkwardPotato]

I have the Ready pin set to INPUT after the end of every operation, and back to an OUTPUT, LOW, when GROM Select is pulled high. Should Ready only be set to floating at the end of some operations?

[Tursi]

The first thing to realize about READY is that it doesn't work like most other chips with a READY does. What it actually means is "operation complete". A GROM must always stay in the "not ready" state until it receives a command. Once it is finished processing the command, then it goes READY, and it stays READY until the GROM SELECT goes away.

 

The console takes care of gating the READY signal to the CPU, so you don't need to worry about that. It's a common collector signal so you should pull it low to indicate NOT READY (the /normal/ state!) and release it to indicate READY as above (pull-ups in the console will pull the line high when /all/ GROMs are ready, you must never pull the line high).

 

There are a couple of weirdnesses with data reads. If the current GROM address matches the address your chip handles, then you should place data on the data bus before signaling READY. Otherwise, leave the data bus alone but do everything else. You need to do everything else for all accesses because you need to keep your GROM address in sync with all the other GROMs.

 

Read Address is the other interesting one. While you are getting your system stable, it is easier to NOT return the address. The reason for this is that if your counter differs from what the real GROMs see, you'll conflict with them and probably crash the system. As long as there's one real GROM in the system you don't need to answer it. When you are confident, then you can add it back in. It's a little trickier than it seems at first glance to get this right - for me it fell into place when I emulated the internal prefetch.

[AwkwardPotato]

I've fixed the handling of GROM Ready, and now I am able to get to a stable "Ready - Press Any Key to Begin" screen, however when I press a key, instead of the selection screen, I just get a blank blue screen. It does this whether or not the Read Address functionality is enabled.

 

EDIT: Now when powering the Arduino off the cartridge port, I can get to the selection screen as well, but no options show up except for TI Basic.

Edited May 21, 2017 by AwkwardPotato

[AwkwardPotato]

I've now reworked most of the code, and now the TI will do one of the following:

 

a) Get stuck at a blank blue screen with the startup beep endlessly playing

b) Get stuck at the "Ready" screen with the startup beep endlessly playing

c) Get stuck at the "Ready" screen but with the startup beep ending correctly

[Tursi]

You've still got a timing or bus loading issue somewhere... make sure your outputs are only active when they should be, make sure when you deselect GROM READY that you set input first, and make sure you are managing your pull-ups when in input mode (ie: make sure they are off), otherwise you can force the line. I needed to use a logic analyzer to get the sequencing right - but feel free to read my main.c and see if you are doing things in a similar order. It's proven to work.

 

The only other gotcha I can think of - when the console releases GROM SELECT, you have to get off the data bus immediately. The CPU is no longer paying attention to the GROM READY line when that happens, and will attempt to fetch the next CPU instruction from ROM/RAM. If you are still driving the data bus when it tries to read, you'll corrupt the data.

 

All three of those symptoms sound like you ran okay for a few cycles then crashed. There are a few possibilities -- one of them is actually software. Maybe you are returning corrupt data that the console is trying to interpret?

 

One other thing that helped me, though it slows the console down a lot, was to use the UART to dump all accesses to a PC terminal (I let the UART part run /before/ asserting GROM READY, that way the console would wait for it). Then when it hung, I could trace the code, using TI Intern as my reference, to see how far it got and whether I was doing the right thing at the right time.