NEW HARDWARE HACK for the TI?

[Omega-TI]

I have a technical/feasibility/interest question for the programmers and hardware gurus out there.

 

Would there be any way to construct a device that one could load a bit-mapped graphic into that would be able to wrestle control away from the main TI screen? I believe it’s possible, because if I remember correctly, my old CorComp disk drive controller used to by-pass the main TI-Screen.

 

I envision a small pass-thru device that plugs into the side of the TI, before the fire-hose or Nano-PEB. This little device would have enough memory to store the graphic, and using Tursi’s TMS9918A converter, that could be just about be anything the user wants. I suppose it could also be constructed to support the F18A formats as well!

 

Of course there would also have to be a software program written that would take the image and program it into the chip.

 

So my questions are:

 

1) Is it possible?

2) Is anyone interested

[+Gemintronic]

I have no idea. There have been concepts like the prototype Hellbound Hellraiser game for the NES. It had an extra co-processor that remapped the characters into its own bit-mapped display. Couldn't you bypass the on-board graphics altogether with a expansion that had it's own VGA port?

[+OLD CS1]

There is a card which offers a new VDP but requires a number of modifications to the 4A's motherboard. (BTW, would it accurately be called a "motherboard" since there is no additional card internally?)

Edited August 22, 2013 by OLD CS1

[Omega-TI]

I guess I was not too clear in my original post. I want to replace this...

 

With THIS...

[Asmusr]

United Federation of Planets? Wouldn't they be using a slightly more powerful CPU?

[+Gemintronic]

Is it a sign of a diseased mind when all I could think of with that last picture was "Klingon's near Uranus"?

[Omega-TI]

United Federation of Planets? Wouldn't they be using a slightly more powerful CPU?

Oh yeah! But of course you could use this too...

... actually anyone could CUSTOMIZE their TI startup screen to anything they wanted! I also got to thinking after my original post, besides a side-car arrangement, this thing could also be mounted INTERNALLY and soldered in just like the internal speech modification.

Heck, I'm sure someone would even be willing to make money soldering them in if users did not feel up to the task.

[Omega-TI]

Is it a sign of a diseased mind when all I could think of with that last picture was "Klingon's near Uranus"?

I guess you are not alone look!

[+mizapf]

LOL ... honestly, it was not long ago that I, as a non-native speaker, finally discovered the pun with Uranus - gladly, in German, there is nothing even remotely similar to that word. By the way, as I learned, the astronomically correct way to call it is "Yooo-rannas". :-)

[Tursi]

You have two options for something like that.

 

Option 1 is actually to override the built-in GROMs with a GRAM device, then you can do anything you want.

 

The side port/internal option can be made to work as well, from GROM or ROM with a power-up vector (which is option 2).

 

The technical side is not too hard. Deciding exactly how to install it into the machine is trickier. GROM needs the least hardware and is probably simplest (since when the user presses a key, you need to undo all that and display the selection menu). In that case it's just a GROM0 replacement. How to update the picture becomes a new issue...

 

It's not something I can take on right now myself. But I intend to have bitmap support in my MPD GUI when I get back to that. (MPD without GUI is here: http://www.youtube.com/watch?v=gNvlO_LDUqg ).

 

I want a nice background picture at startup too

Edited August 23, 2013 by Tursi

[Omega-TI]

You have two options for something like that.

 

The side port/internal option can be made to work as well, from GROM or ROM with a power-up vector (which is option 2).

 

I want a nice background picture at startup too

 

I LIKE IT!!!!!

Hmm, can you burn GROMS too? It would be so SWEET to have full-time true lower case in the 4A to go with a custom start-up screen. You could probably make some good money modding peoples TI's. I'd send you mine for an upgrade!

[RXB]

I LIKE IT!!!!!

Hmm, can you burn GROMS too? It would be so SWEET to have full-time true lower case in the 4A to go with a custom start-up screen. You could probably make some good money modding peoples TI's. I'd send you mine for an upgrade!

 

If you have a GRAMKRACKER or GRAMULATOR or HSGPL card or some other mods that have been out for many years you can do that.

 

Kracker Facts and other magazines like it had stories written on fonts people used. By the way even Classic99 or MESS or PC99 allow you to modify the characters in GROM 0.

 

(I made my own custom start up screen with my GRAMULATOR many many years ago with my name and Sprites.)

Edited August 24, 2013 by RXB

[Omega-TI]

If you have a GRAMKRACKER or GRAMULATOR or HSGPL card or some other mods that have been out for many years you can do that.

 

Kracker Facts and other magazines like it had stories written on fonts people used. By the way even Classic99 or MESS or PC99 allow you to modify the characters in GROM 0.

 

(I made my own custom start up screen with my GRAMULATOR many many years ago with my name and Sprites.)

While I do not have any of those items, this whole concept excites me. After I get my F18A installed, it would be COOL to have a "Scanline Pallette Bitmapped F18A" (higher grade) custom image to replace the TI screen and have true a lower case font too! It's been a few years since I've opened up a TI, so I'm assuming they are not socketed. I think I'd feel more comfortable having them replaced than doing it myself.

[Tursi]

I was thinking of doing console mods as an alternative to the kits that I just can't seem to source parts for. But that's way out in the future right now.

[+OLD CS1]

What about this:

http://atariage.com/forums/topic/215926-grom-files/?p=2817485

The documentation mentions power-up routines. It also mentions that power-up routines should end with a GPL RTS. Table 4.1, GROM Header, shows

>6004 word address of power-up routine header

 

Then this:

 

4.5 POWER-UP ROUTINES

The monitor initializes the system by calling power-up routines. Power-up routines are
executed whenever the system is reset by either hardware or software. The console
power-up routine executes first. This routine puts up the initial screen and menu and calls
the selected program. Next, the monitor searches peripheral ROM and then GROM
headers for power-up routine addresses and executes them as it finds them. After each
power-up routine is executed, a search is made for the next one. When there are no more
power-up routines found, the selected program is started with the system initialized as
described in the last paragraph.

 

 

I hypothesize that one could create a header with a start-up routine that usurps the monitor, thus giving the start-up screen (mater title screen) desired. Mind, from the description the first thing the monitor does is throw up the master title screen and then execute start-up routines, so I suspect there would be a flicker when that happens. After completely adulterating the master title screen, you could then RTS to the monitor and resume normal operations. I assume the monitor expects its settings (screen, character set, colors, etc.) to be left alone, so there would have to be some provision to ensure the menu screen displays properly.

 

Thoughts?

[Tursi]

The documentation mentions power-up routines. It also mentions that power-up routines should end with a GPL RTS. Table 4.1, GROM Header, shows

The side port/internal option can be made to work as well, from GROM or ROM with a power-up vector (which is option 2).

A tiny bit ahead of you.

 

The common method in the past was to use a ROM DSR powerup routine, and that's only possible on the side port, because the address lines are not available on the cartridge port for DSR space. GROM powerups could in theory go anywhere, I must admit I haven't played with them.

[+OLD CS1]

A tiny bit ahead of you.

 

The common method in the past was to use a ROM DSR powerup routine, and that's only possible on the side port, because the address lines are not available on the cartridge port for DSR space. GROM powerups could in theory go anywhere, I must admit I haven't played with them.

 

I was thinking of the cartridge port considering the >6000 - >7FFF range. The side port might be interesting with a flash RAM option as a kitschy add-on: upload your favorite start screen in 9918A format and have the system display that instead of the standard master title screen. Maybe even play a start-up sound. As a bonus, have it rotate through a bunch. I do not know if you can set the order of start-up routines, but maybe even have it check DSK1 for a start-up screen file. It would be faster on a CF7/nanoPEB.

 

(Thierry's page answers the order question, as they are scanned in order of CRU address. So put this device at the highest CRU address available and other external devices will power-up first. He also dashed my hopes with this:

 

 

 

Power-up routines are executed when you reset the TI-99/4A, before the user can press a key to leave the main title screen. They can be found in GROMs or peripheral card ROMs, but not in cartridge ROM.

 

That seems contrary to the documentation, though my guess is the monitor ignores the power-up routine in a cartridge header.)

Edited August 26, 2013 by OLD CS1

[RXB]

 

 

 

 

 

That seems contrary to the documentation, though my guess is the monitor ignores the power-up routine in a cartridge header.

 

Here is a RXB demo of turning on the RXB power up with the Powerup header:

 

http://www.youtube.com/watch?v=e-d-j3Re_iE&feature=c4-overview&list=UUULwPKqrRFCtNv5_xMuOqQw

 

 

[Willsy]

 

 

Here is a RXB demo of turning on the RXB power up with the Powerup header:

 

http://www.youtube.com/watch?v=e-d-j3Re_iE&feature=c4-overview&list=UUULwPKqrRFCtNv5_xMuOqQw

 

 

 

Right, but that's a GPL power-up routine, right? We know we can put a GPL power up routine in a cart. I think the debate is over whether or not it's possible to put an assembler PUR in a cart. I don't think it is, but I've never tried it.

 

But hell... I say write one in GPL... It would be a good excuse to hack out some GPL, and the new cart design will support GROM, so there's no problem!

[Tursi]

You can't have an assembly powerup routine in a cartridge, the console never even looks for it. I've played with this idea many times in the past.

 

The only way to do it on the cartridge port is via GROM (which, it's nice to see works!) That said, GPL is easy to do things like build a picture with. It's also easy for it to copy assembly to RAM, branch to it, and come back.

 

here are actually two options in that case - the powerup routine, and a "translation" routine which is branched to if the header bytes are set a certain way. (I can't remember the details, they are on Theirry's page, too, and I tried that one once to see it work. )

[RXB]

How hard would it be to put 640K GRAM on a cart and then just load up that GRAM as I have written the code that used the SWGR and it did work fine for me in tests.

 

The issue was RTGR to get back, but if you are just loading Assembly by using GPL to MOVE it into RAM from GROM then SWGR works great as it just goes to the that 8K GROM bank SWGR points to.

 

You could do a cascade effect of each bank with a SWGR points to the next one and the last one loops back with RTGR. (32K chunks or 24K chunks for loading RAM)

Edited August 26, 2013 by RXB

[+OLD CS1]

As I understand it, and might have actually read somewhere, you can replace the TI BASIC GROMs with GROMs from cartridges. Hypothetically, I could put GROMs for TI Invaders and Munch Man and make the console just a game machine.

 

To that end, I should also be able to create an Extended BASIC console by putting an Extended BASIC GROM in the console, BUT the ROM would have to be somehow installed and overlay the cartridge port, thus preventing a ROM cartridge from working.

 

That sound right?

[Willsy]

I believe you can do that, yes. But actually, no need. You can just solder the GROMs on top of each other, and they'll work just fine. This is because a GROM only responds to its own unique address, thus it's safe to stack them. IIRC some cartridges have exactly this arrangement inside them. So you could put a few GROM only games directly inside your console, and they'll work just fine.

 

That's my understanding, at least!

[+OLD CS1]

I believe you can do that, yes. But actually, no need. You can just solder the GROMs on top of each other, and they'll work just fine. This is because a GROM only responds to its own unique address, thus it's safe to stack them. IIRC some cartridges have exactly this arrangement inside them. So you could put a few GROM only games directly inside your console, and they'll work just fine.

 

That's my understanding, at least!

 

I believe I have read that, as well. I am considering doing just that and making one of my spare consoles just a classic TI game machine with as many GROM-based games as I can. Just because I can.

[Tursi]

Almost, Mark.

 

Because the GROMs each respond to their built-in address, you can only stack GROMs that respond to different addresses. Basically, this means you can have one of each in the system, and it doesn't matter where they are physically installed. You get one GROM0, one GROM1, one GROM2, etc, etc. Most cartridges contain a GROM3 at least, so most GROM cartridges won't interwork if just stuck together. (Hopefully I'm counting right.. can't recall if the first is considered 0 or 1... though it's just terminology, the point remains).

 

As for XB, yeah.. the ROM would conflict with any other ROM cartridge (and the XB GROM would conflict with most GROM cartridges). But you could of course install it inside the console with a switch to disable. I also toyed with the concept of a smart cartridge port that would check for a cartridge and enable/disable its built-in code (which could be XB) automatically, though I didn't build it.

 

Back to GROMs, they can be relocated but the process is pretty much the same as for ROM code - you have to disassemble, find all the absolute references, and reassemble. (Or attempt code-tracing, or both, which was my approach.) It's tedious and error-prone. I did relocate the Editor/Assembler to GROM1 for my MPD project, but I doubt I'd attempt anything bigger, as it was a pain.