hhos
-
Content Count
66 -
Joined
-
Last visited
Posts posted by 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
-
15 hours ago, GDMike said:I'm gardening instead of working on my program..shhhh.. don't tell anyone.
BURN HIM!!! 😆
-
1
-
1
-
-
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.
On 3/24/2020 at 4:17 AM, Lee Stewart said:I seem to recall that the QI version has a prayed-on metal coating on the inside of the clamshell.
...lee
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.
-
1
-
-
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.
-
1
-
-
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
-
1
-
-
On 3/20/2020 at 5:00 PM, matthew180 said:Would this topic be considered bait? The OP posted something that should have been controversial, and then never participated in the conversation. I guess the joke is on them, they failed to realize we all get along really well in this forum and like to talk about things like this. 🙂
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.
On 3/20/2020 at 6:15 PM, carlsson said:Haha.. CoCo people trying to start a fight with 99:er people, because they know it is futile to try to mess with C64 or A8 people.
Even A2 people might be a bit too big game for CoCo:ers.
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
DoonesburyDilbert 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
-
On 1/23/2020 at 8:41 AM, Lee Stewart said:Considering that the TMS9900 is a 16-bit CPU with 16-register context-switched workspaces and the 6309 is an 8-bit CPU with a totally different register scheme, that would be well nigh impossible without a complete redesign of the motherboard. Then, of course, it would not be a TI-99/4A and no other software/hardware designed for the 4A would work without some sort of translation interface.
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.😀
On 1/23/2020 at 8:41 AM, Lee Stewart said:Also, what makes you think the 6309 implementation would be faster?
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.
On 1/31/2020 at 12:13 PM, Firefly said:Well, the 6309 could be seen as "better" because it might have had a speedier Basic onboard the computer it was in, and the rest of the architecture didn't slow it down .... but really the 9900 cpu itself wasn't known as slow or bad as such. Think of it as a High Speed Train that's been made to wait at every damn red signal along the route it goes. Take out those red signals and the train will surprise you at how fast it can travel. Keep them in and slower trains that don't have any signals will be getting there quicker.
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
-
1
-
-
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...
On 1/27/2020 at 9:20 PM, Ed in SoDak said:
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.
-
1
-
-
On 1/22/2020 at 2:10 PM, FarmerPotato said:DEF START B DATA >B,>C START AR @B * ADD REAL TO R0-R1 LMF R3,1 * LOAD MAP FILE 1 FROM R3 (or is it *R3) DCA R9 * XOP R1,0 DCS R7 * XOP R3,1 LIIM R3 * XOP R3,2 JMP $ ENDFarmer 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
-
1
-
-
19 hours ago, hhos said: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
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:
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
-
3
-
-
2 hours ago, BeeryMiller said:You could use some DATA constructions to construct what you may believe is an opcode and operand(s), and I believe it is the NMI on the 9995 in MDOS mode you could then use to capture an illegal instruction.
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.
-
5 hours ago, HOME AUTOMATION said:How observant of you! I never spent much time on that particular page.
Page 65, states there are 9 formats. I Couldn't find anything about this otherwise.
I also looked on the blue "Quick Reference Card", but found nothing relevant either.
X |0 |0 |0 |0 |0 |0 |1 |1 |0 |0 |1 | REG |
| 0 | 3 | 2 |
If the register field is really 5 bits wide, than might not field 3, be considered a 1 rather than a 2.
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.
-
1
-
-
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
-
2
-
-
32 minutes ago, Samuel Pedigo said:hello, new to this sub forum. I am trying to assemble the first program on this page. it is asking for the source file, object code and device name.
Source code is Dsk1.save no object code, no idea what device name means. any help would be appreciated. Using classic99
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.
-
1
-
-
Yea would not be hard with the TI Basic listing he never let it finish listing.
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.
-
You going to do GPL as it is 1/3rd as complicated as the program shown and TI Basic is the worst.
Maybe you could write the program and send it to him? Then he could make another video with that in it.
-
1
-
-
Does anyone have a list of the scratchpad addresses you cannot use if you use the ISR?
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
-
1
-
-
I came across this someone has done up and is of much better quality than anything else I have seen to date.
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
-
In theory there is no difference between theory and practice, but in practice there is.
-
VDP is only "slow" because of the need to set the address before accessing, the VDP can run at the speed of the bus otherwise (and so reads/writes are the same speed as reads/writes to RAM). Wait states are not necessary to talk to it, but if you remove them fully, more software than before will have overrun issues.
GROMs are quite slow but they halt the CPU, so wait states are not necessary to access them.
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
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Assembly on the 99/4A
in TI-99/4A Development
Posted