TI-99/4A ROMS

[+retroclouds]

Just a quick question:

 

Were there multiple revisions of the ROMS in the TI-99/4A console ?

I know there are multiple revisions of the GROMS. But just wondering if all consoles have the same code in the ROMS.

 

Should be possible to compare with the checksum memory location. Forgot the exact address though. This was discussed just recently

[Tursi]

The 4A and 4Av2.2 ROMs that I have are the same, IIRC. The ROM in the 4 is obviously different. TI Intern doesn't seem to think there are multiple ROM revisions either.

[RXB]

The only different ROMs I remember were the Plastic only tan console had a ROM that prevented something I do not remember.

 

It was only a 2 byte difference. I think it was mentioned in Micropendium or Smart Programmer.

 

It is like all the ROMs for XB are not the same, any version that uses the GRAM KRACKER version has to have the byte changed.

 

Original XB had >08 at >7D1Band GKXB or RXB or SXB must have >0B there instead.

 

Original XB had >08 at >7D35 and GKXB or RXB or SXB must have >0C there instead.

 

People often miss the 2 byte difference, but it will cripple some subroutines in XB or error them out.

 

Everyone assumes the XB ROMs are all the same, same as the OS ROMs.

[+retroclouds]

....

 

It is like all the ROMs for XB are not the same, any version that uses the GRAM KRACKER version has to have the byte changed.

 

Original XB had >08 at >7D1Band GKXB or RXB or SXB must have >0B there instead.

 

Original XB had >08 at >7D35 and GKXB or RXB or SXB must have >0C there instead.

 

People often miss the 2 byte difference, but it will cripple some subroutines in XB or error them out.

 

Everyone assumes the XB ROMs are all the same, same as the OS ROMs.

 

So for XB why do the 2 bytes have to be different for GKXB/RXB/SXB ? I thought that the GK behaved exactly as the corresponding modules ?

[+InsaneMultitasker]

Just a quick question:

 

Were there multiple revisions of the ROMS in the TI-99/4A console ?

I know there are multiple revisions of the GROMS. But just wondering if all consoles have the same code in the ROMS.

 

Should be possible to compare with the checksum memory location. Forgot the exact address though. This was discussed just recently

 

The addresses are at the end of the ROM. The TI Intern shows the locations relative to the ROM or GROM in question.

 

I attempted to compute the checksums and validate against the embedded values without any success. I tried byte and word-wise additions, skipping even/odd, and a few other permutations that escape my memory right now. Nothing "added up" (sorry, bad pun - grin)

 

I eventually moved on / gave up, figuring either the checksums had been recorded incorrectly or that I was computing them incorrectly. You're welcome to continue the quest

 

Tim

[Tursi]

The only different ROMs I remember were the Plastic only tan console had a ROM that prevented something I do not remember.

 

If you are talking about the locking out of ROM-based cartridges, that code chage is in GROM0, not the ROM. There are at least three versions of GROM0 in the 99/4A line that I know of.

[+retroclouds]

The only different ROMs I remember were the Plastic only tan console had a ROM that prevented something I do not remember.

 

If you are talking about the locking out of ROM-based cartridges, that code chage is in GROM0, not the ROM. There are at least three versions of GROM0 in the 99/4A line that I know of.

 

That's the reason why I asked about the ROMS. If there's only one ROM revision, then I should be safe to get some use out of it for my spectra² library.

[Tursi]

TI Intern's comments are the most telling I am aware of:

 

The operating system of the TI99/4A has several versions. In the ROM area between >0000 and >1FFF only minor changes have been evident up to now. Therefore the listing of only one version shall be enough. How little Texas Instruments has been able to make change in the ROM, can be seen for example, by the fact that the Extended Basic Modul accesses directly into some subroutines.

 

That's the most authoritative I have, though.

 

IMO, though, it would be preferable not to rely on it. This makes future clones and expansions more likely to work. Of course, if things like XB are as bad as suggested here, they may have no choice anyway.

[RXB]

....

 

It is like all the ROMs for XB are not the same, any version that uses the GRAM KRACKER version has to have the byte changed.

 

Original XB had >08 at >7D1Band GKXB or RXB or SXB must have >0B there instead.

 

Original XB had >08 at >7D35 and GKXB or RXB or SXB must have >0C there instead.

 

People often miss the 2 byte difference, but it will cripple some subroutines in XB or error them out.

 

Everyone assumes the XB ROMs are all the same, same as the OS ROMs.

 

So for XB why do the 2 bytes have to be different for GKXB/RXB/SXB ? I thought that the GK behaved exactly as the corresponding modules ?

 

I do not have the source code of the XB ROMs anymore that were from TI Original XB project, but notes in the GKXB and SXB and RXB all use the same GKXB commands I think it is in the Edit mode of GKXB.

[RobertLM78]

Sorry about posting in such a relatively old thread, but I thought this was the best place to ask since it's about the console ROM.

 

I've been reading about operating systems, and I came across the term "monitor", which is basically what the book calls a "simple batch system". So is this nomenclature telling of the TI's OS, which, according to the TI Intern, has the name "Monitor" (is the OS a "simple batch system")? (Anyone???)

 

from the book, Operating Systems: Internals and Design Principles:

Simple Batch Systems

Early computers were very expensive, and therefore it was important to maxi-

mize processor utilization. The wasted time due to scheduling and setup time was

unacceptable.

To improve utilization, the concept of a batch OS was developed. It appears

that the first batch OS (and the first OS of any kind) was developed in the mid-1950s

by General Motors for use on an IBM 701 [WEIZ81]. The concept was subsequently

refined and implemented on the IBM 704 by a number of IBM customers. By the

early 1960s, a number of vendors had developed batch operating systems for their

computer systems. IBSYS, the IBM OS for the 7090/7094 computers, is particularly

notable because of its widespread influence on other systems.

The central idea behind the simple batch-processing scheme is the use of a

piece of software known as the monitor. With this type of OS, the user no longer has

direct access to the processor. Instead, the user submits the job on cards or tape to a

computer operator, who batches the jobs together sequentially and places the entire

batch on an input device, for use by the monitor.

 

Edited July 14, 2013 by RobertLM78

[Stuart]

At microcomputer level, I think the term "monitor" is more a small program that supports simple user I/O and provides simple functionality like displaying/editting bytes in memory, dumping and loading blocks of memory, executing a machine code program in memory, and so on. TI had a monitor program called TIBUG for their TM990 line of computer modules (http://bitsavers.trailing-edge.com/pdf/ti/tm990-100/MP324_990-401_TIBUGlst.pdf), which they expanded to become the EasyBug program (option 2) on the MiniMem cartridge and the Debugger supplied on disk with the E/A catridge.

 

Stuart.

[RobertLM78]

Sounds like "Monitor" on the TI-99/4a is more than just a "monitor" then? (no pun intended )

 

Stuart - I assume you did in fact mean microcomputer (as you stated) and not minicomputer Ah, never mind, I see that the TM990 was in fact a microcomputer, so back to the question is TI "Monitor" more than a simple batch system? It's just that there doesn't seem to be much to it, so it strikes me as though it is a simple batch system, if maybe perhaps a bit more evolved than the earlier models of the system.

Edited July 12, 2013 by RobertLM78

[+OLD CS1]

IMO, though, it would be preferable not to rely on it. This makes future clones and expansions more likely to work. Of course, if things like XB are as bad as suggested here, they may have no choice anyway.

 

TERRIBLE that TI breaks best practices by doing that. I suppose if TI didn't bother with vectors or jump tables like you find (for the most part, anyway) in Commodore and Atari BASIC and Kernal ROMs, then they really had no choice. In terms of future clones or expansions, I do not see why it would not be possible to recognize certain "bad" modules and provide wrappers for the directly-accessed routines.

[+OLD CS1]

TI had a monitor program called TIBUG for their TM990 line of computer modules (http://bitsavers.tra...01_TIBUGlst.pdf), which they expanded to become the EasyBug program (option 2) on the MiniMem cartridge and the Debugger supplied on disk with the E/A catridge.

 

I guess it is meant o be a simple debugger, but EasyBug always felt like the Dark Ages of working with machine language compared to the aseembly monitors for some of my other machines (in particular, 6502-based stuff.) I would have loved to have an assembly monitor on the TI like the one in the Warp Speed cartridge on my 64. I might could have written one had I understood TMS-9900 better.

 

For that matter, I might have understood 9900 better had one like that existed. For the most part, I learned all my 6502 programming using that Warp Speed monitor. Call me spoiled, I guess. Though I did do a LOT in the LBL.

[RXB]

So for XB why do the 2 bytes have to be different for GKXB/RXB/SXB ? I thought that the GK behaved exactly as the corresponding modules ?

 

The GKXB including any XB with GKXB (RXB, SXB, XB2.5 and all the others all use the mods created by Miller Graphics.)

The Editor and other functions that use these XB ROM routines were modified to use the new commands.

Without the modification bytes GKXB errors out.

*
* Code for new commands DEL, COPY, and MOVE
*
* NOTICE !!!!!
* RAM BANK 2 CHANGED AS FOLLOWS-----
* 7D1B changed from >08 to >0B
* 7D35 changed from >08 to >0C
*
*
NEWCMD CH   >0B,V@CRNBUF If higher than MOVE token,
   BS   SZRUN4	    continue with old stuff
   DST  CRNBUF+1,@PGMPTR Anticipate usage of PGMCHR
   XML  PGMCHR	   Setup CHAT
   ST   V@CRNBUF,@FAC Copy token
   SUB  9,@FAC	   Adjust for CASE
   CASE @FAC		 Select the keyword
   BR   DEL
   BR   COPY
   BR   MOVE
*

[+mizapf]

Slightly related to that: Are there any specific, functional hardware changes in the QI consoles (apart from a new PCB layout)? I remember reading somewhere that CRU lines are not routed to the cartridge port anymore.

[+mizapf]

OK, I've got the information. Indeed, the schematics do not show any connections to the CRUIN / CRUCLK pins on the cartridge port.