+retroclouds Posted May 3, 2011 Share Posted May 3, 2011 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 3, 2011 Share Posted May 3, 2011 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted May 3, 2011 Share Posted May 3, 2011 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. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted May 4, 2011 Author Share Posted May 4, 2011 .... 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 ? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted May 4, 2011 Share Posted May 4, 2011 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 Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 4, 2011 Share Posted May 4, 2011 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. Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted May 4, 2011 Author Share Posted May 4, 2011 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 spectra2 library. Quote Link to comment Share on other sites More sharing options...
Tursi Posted May 4, 2011 Share Posted May 4, 2011 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted May 5, 2011 Share Posted May 5, 2011 .... 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. Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted July 11, 2013 Share Posted July 11, 2013 (edited) 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 SystemsEarly 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 Quote Link to comment Share on other sites More sharing options...
Stuart Posted July 11, 2013 Share Posted July 11, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted July 12, 2013 Share Posted July 12, 2013 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 12, 2013 Share Posted July 12, 2013 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. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted July 12, 2013 Share Posted July 12, 2013 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted July 12, 2013 Share Posted July 12, 2013 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 * 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 12, 2013 Share Posted July 12, 2013 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted July 13, 2013 Share Posted July 13, 2013 OK, I've got the information. Indeed, the schematics do not show any connections to the CRUIN / CRUCLK pins on the cartridge port. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.