hhos

Were any updated, and complete, schematics ever sent on this? I bought a 400-800 Field Service Manual that looks a little bit more complete than what is shown here. I think it cost me about $30 with shipping from eBay. I did not get the impression that they were rare. Right now it says there are 4 left. hh

BURN HIM!!! 😆

I think almost all the home computers of the '80s were pretty quiet RF-wise. The Model 1 TRS-80 was pretty bad, but it was late 70s. I think the expansion box was pretty bad, too. I can't seem to locate any of my QIs. I am sure I had either 3, or 5, of them, but since I can't find them, I can't check this out.

I might find more time for TI99 later, especially if I can discover the safe place I put my stash of TTL logic chips. Right now I have to fix some things on my truck, and repair my air compressor.

Does the QI version even have shields? It seems to me that it does not. If my memory serves, the 9918A has some sort of spring metal heat sink attached to it. I have a few of those consoles. I will have to take a look later. If someone else beats me to it, that's even better. HH

He could have been silenced by a possible ignorance of the difference between the 2 processors. As was pointed out almost immediately, different processors understand only their own language, and it would also be putting an 8 bit CPU into a 16 bit bus. I'm a CoCoNut. Really, I'm more into the MC6809 than the CoCo, though. I do admit I like the CoCo3 much more than its predecessors. Its color pallet is much better and it's twice as fast at 1.7897725 MHz. I found the TI99 an easy target myself. It looked so SLLOOWW the first time I saw one running a BASIC program! It could have been so much better if they had just decided to make it a 16 bit computer to start with, given it 4-16K RAM (the VRAM does not count!), and dispensed with GROM altogether, or just used GROM as a debugging tool. Also, the 4 extra wait states for each memory access to the PEB, not to mention 8 bit ROM and VRAM, is one huge burden on system performance. I am at a loss to find a GOOD explanation for why they put in so many wait states. I always picture the Doonesbury Dilbert cartoon characters when I think of the TI decision making process concerning the TI99/4 design. Even the GROM only needs the last two wait states, if I understood it correctly, and I don't know why it needs wait states added, anyway. It has a ready output that it can use to force as many waits as it needs, doesn't it? Kind of just like normal RAM memory setups in other computers? I don't really know what "A8" or "A2" refer to. What are these? Atari somethings? Apple? I have a C64, and a fair amount of software/hardware to go with it, but I don't know much about it. It is a pretty high performance computer from what I've seen. (Please ignore the oh so slow access to the floppy disk) What little I do know is that Commodore put in a fair bit of "helper" chips to increase its performance, a tactic that RS's CoCo would have greatly benefited from. I assume the Atari computer/consoles also spread their investments out to more support chips, but I know even less about them. As far as Atari goes I have only an Atari 7800, joysticks, and a bunch of game cartridges for it. I found all of this beside a trash dumpster in a small backpack. (I think it was originally in the overfilled dumpster but rolled off) Everything works and it also seems to be a pretty high performance machine. I have a much higher opinion of the 6502 CPU family than most of my fellow CoCoNuts do. And now that I am seeing several ways to improve my TI99/4A's performance, I think I may soon be similarly impressed by the TMS9900. And maybe even a little more so? Perhaps. HH

I agree. It would be better and easier to build a complete new system around the 6309. Trying to put it into the TI99/4A would be almost as bad as trying to shoe horn a TMS9900 into an 8 bit console.😀 The 6809 is fast,... very fast. If a 1 MHz 6809 running the original Defender arcade game isn't a good enough example, you should see a 1.79 MHz 6809 in a CoCo3 playing a Star Wars, episode 4 video. The hard drive containing the data it was playing was the only speed upgrade if I remember right. The 6309 is even faster than the 6809 when operated in native mode. I agree that the BASIC for the 6809/6309, in all the machines I'm familiar with, is a great deal faster, even when the CPU clock is significantly slower on the 6809 based machine. In my opinion, the difference in speed is primarily due more to the lack of CPU directly accessible RAM than anything else, and as a result of that shortcoming, the BASIC is written in GPL, which is SLOW. (Running on tracks that don't have any railroad ties?) Secondarily, I would blame excessive wait states (stop lights?), and thirdly, the register file being in RAM, right next to the read before write behavior it displays when writing byte values. TI didn't even take advantage of the 16 bit nature of the processor, or the one thing the 9900 is really GOOD at, rapidly handling 16 levels of interrupt conditions. Because the 6809 is pretty good at handling interrupts, too, I think it would probably run rings around the 9900 in most cases. The 6309, in native mode, would be even faster. It's hard to say, though, the larger register file could be a much greater advantage than I'm giving it credit for. Also, the A(dd), S(ubtract), C(ompare), MOV(e), SOC and SZC, all have a great many addressing options (they take op 3/4 of the total number of possible opcodes). That could give significant advantages to some applications by cutting down on the number of instructions needed. (Would that be bigger wheels for the train analogy above?) There really isn't any point in trying to run any BASIC benchmarks between a TI99 and any other microcomputer I can think of. Has anybody ever run any assembly language benchmarks for a 3 MHz TI99/4A vs. 0.895 MHz CoCo1/2? 1.79 MHz CoCo3? 1 MHz C64 (6502 microprocessor), or a 6502 based game console? HH

OK. That's pretty much the what I was expecting the case to be. Thank you. I'm trying to get another PEB to tinker with so I don't have to put the one I have at risk. If I get a /4 and find any further significant differences I'll post them here. HH

I guess I didn't make my question clear. Sorry about that. The mechanical difference on the back of the 99/4 unit might interfere with the use of some boards, which is why I mentioned it. Do those fuses have different capacities, or are they just different form factors? Did they change the power switch because the older one was unreliable? Is the power supply the same, or is one heavier than the other? What I want to ascertain is, will all the same peripheral hardware work in both units? If you plug a Geneve in the 99/4 PEB will it work just the same as if it was plugged into the TI PEB? Will the schematics for one also apply to the other without any changes? (I have only found one set of schematics on-line for the PEB) Are the PC board layouts the same? Can the fire hose cables be swapped between them and both units will still work? In short, if I'm not too late for that, are there any substantive differences? Thanks, HH

I see some mechanical difference on the back of the units. The 99/4 attempts to restrict any external connection to an edge card, or at least an extension to the outside before going to something else. Are there any other differences? HH

I started with a Radio Shack calculator that could not be distinguished from a TI57 if you didn't read the RS model # off of it. It was made by TI for RS. Then I bought the TI58... TRS-80, model I... I also had one to three similar to this, maybe even still have one. 🙂 If I still have it somewhere, I'll bet it still works and I won't have to change the batteries.

Farmer Potato, I went back through that manual and I think you have it right on the execution of LMF. The register field on opcodes >0320 - >033F has just "w" in it. I got it mixed up with the LDD and LDS opcodes which have a "ts" and "s" fields in them. So, presumably, "LMF 3,1" loads data from the addresses of R3-R8, not a *R3 pointer as I indicated above. I think I would rather have it go to *R3, but it doesn't look like it would. I see LMF, LDD, and LDS (the 3 opcodes added to the 990/10 with mapping option) are in the 99105/110 instruction set so anyone who is running a system with one of these could check this for us. Anyone? HH

Is this the Geneve development forum now? I hope I'm not the only one in here that hasn't moved on to the Geneve.😁 I'm still talking about the TI99/4A. I found my own answer at: http://bitsavers.trailing-edge.com/pdf/ti/990/945250-9701_990_Computer_Family_Systems_Handbook_3ed_May76.pdf It's on page 97 at the top. These opcodes at >0320 to >033F come from the TMS990/10. They were added, as an option, to that computer in order to make 1MWords of memory available. The mnemonic for it is LMF. The M bit designates the memory map to load, 0 or 1, and the REG is the register that points to the 6 word map, or source data (SD), to load. X |0 |0 |0 |0 |0 |0 |1 |1 |0 |0 |1 |M | REG | | 0 | 3 | 2 | SD | This is not a TMS9900, nor TMS9995, opcode. On the 990/10+'s LMF is used only when the CPU privilege bit (bit 7,ST) is 0. This was definitely pasted into the E/A manual by mistake. Thanks, HH

I only have TI99/4A consoles. I don't think any of the TI99/4As were made with anything but TMS9900s in them. I am certain that none of mine were. In fact, my recollections are telling me that only the Geneve has the TMS9995, and I don't have one of those.

I also found that the rest of the manual only claims 9 formats. If the opcode shown hadn't fallen so neatly into the empty spot in the opcode map I wouldn't still be looking at it. A 1 rather than a 2? I don't see how myself, unless of course it is a typo as I suggested in my original post. In the book, Editor/Assembler, you can see there are 6 0's, 2 1's, 2 0's, and a 1. That's 11 bits, leaving 5 bits that are designated "REG". Anyone who doesn't have the book can have a look for themselves here: https://archive.org/details/TI994a_Editor_Assembler_Manual/page/n242 There is a single format 10 instruction listed on Wikipedia for the TMS990 called LMF. I'm looking through a manual on the 990 now. I think it's going to be something for the later versions, /10 - /12. I'll post it when I find it.

I was trying to map out the opcodes for the TMS9900 and finally noticed an instruction format X in the E/A manual on page 242. At first I thought it was a typo, that they had left off the preceding "I" for a format IX, but IX is back up on the same line as format III. On closer inspection I found the binary shown, X |0 |0 |0 |0 |0 |0 |1 |1 |0 |0 |1 | REG | | 0 | 3 | 2 | falls neatly into a blank space in the opcode map with its 5 bit wide reg field. In hexadecimal it is >0320 - >033F. I think probably this space is used on another, probably previous, TI processor, and that this table was copied over from a previously published manual, without deleting the unused format X. Does anyone have any knowledge about this? Is there possibly an undocumented opcode in here? Thanks, HH

The "DSK1." part of the file name is the device name. The object code is the device name and file name to which the output of the assembler will be stored. You probably have the option to send that output to an alternate device with Classic99, like "DSK2", "DSK3" or another device supported by the emulator.

The data that he uses for the displayed characters is complete. It is at time index 7:19. Once you have that you would just have to choose positions to put them onto the screen, poll the joysticks and display characters as desired, according to which bits are set.

Maybe you could write the program and send it to him? Then he could make another video with that in it.

There is a listing in the E/A manual on pages 404-406. The description of the ISR, DSR, etc. usage of this memory, as described on these pages, has such a large foot print that I have thrown out any idea of allowing the current interrupt system any access. I don't know of any other list, and I've seen this one referenced every time I've seen the subject come up, as far as I can recall anyway. HH

Since that's exactly what I was looking for I guess it'll have to do. Thank you. HH

That is much better than what I had. Thank you. Are there any other guides in the same place you found this? I am looking specifically for V9958, but would be interested in many others. HH

According to this at least one wait state, after A15 toggles LOW, is needed when accessing GROM. "Solving the GROM access problem....... But there is a problem here: the cicuitery that generates this holding signal is fairly complex (two 74LS138, and two 74LS03). As a result, it takes time for SysRdy to go low after A15 has toggled. If we remove wait state #4, the request for a hold actually arrives too late for the CPU to take it into account. The situation is even worse with zero-wait-states timing, where there is no way the signal can get there in time." According to my understanding one wait state after A15 toggles LOW is all that is ever provided by the circuitry around the 74LS194 (wait state generator). HH