Better cpu

[MrDave]

I wonder how difficult  it would be a put a better CPU in the ti ? Like a high speed 6309 ?

[+Lee Stewart]

34 minutes ago, MrDave said:

I wonder how difficult  it would be a put a better CPU in the ti ? Like a high speed 6309 ?

 

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.

 

Also, what makes you think the 6309 implementation would be faster?

 

...lee

[GDMike]

How bout 2 ea 9900s...mmmm ,

i'm game!!

[+chue]

Just throwing this out there. I’ve no idea if it will work for what you are doing.

 

There’s a higher spec’d (faster) 9900 built into the F18A video adapter. I’ve always wondered if it could be used as some sort of an accelerator. 

[wierd_w]

It's been my understanding that a big portion of the system's slowness is not really the CPU's fault, but the way they designed the bus. Hobbling the 16bit processor with a multiplexed 8bit bus architecture hits it hard straight out of the gate.  Further, the added waitstates for many things means it spends a good deal of time just sitting there waiting.

 

Sadly, the only way to address that is to redesign the computer.

 

One possibility might be a second CPU placed inside the multiplexed bus side. That way only the CPU-CPU communication gets the muliplex, and the now 'local' CPU can manage the memory and IO in the bus at 16 bits.

 

 

 

[+mizapf]

Yes, wait states are the primary problem, and missing bus control lines. As for the 8 data lines, remember the 9995 which has its multiplexer built into the CPU, but which is 2-3 times faster than the 9900. In addition, the 9995 can do real byte accesses, while the 9900 can only access 16-bit words, and thus needs that awful read-before-write. It would have required just two control lines for turning one half of the data bus on or off, as the x86 systems do.

[+FarmerPotato]

With a processor bump to the 2nd generation TMS9995, you'd be looking at the 99/4C or 99/5. These updates were designed around the 9995's 8-bit data bus. Long ago, I saw one working, and it played Parsec just fine at regular speed (extra wait states added), or alternately, at ludicrous speed (no wait states). The TI Basic was also much improved.

 

As it stood in late 1982 (new home computers were to debut at CES in March!), the 99/4C would have a TMS9995, 7 GROMs (vs 3 in the 4A), 16K of ROM (vs 8K), 512 bytes of scratchpad RAM, and oddly, 16K of expansion RAM onboard. Cost of goods (excluding labor) was going to be $177 vs $152 for the 4A. Costs for the 4A were dropping faster.

 

Fabrice Montupet documents the prototype 99/5 here:

 

http://www.ti99.com/ti/index.php?article2/ti-99-4b-et-ti-99-5

 

 

[Omega-TI]

19 hours ago, GDMike said:

How bout 2 ea 9900s...mmmm ,

i'm game!!

 

I dunno, even if it worked, it might be like playing an XT or 286 class video game on a Pentium or better.

[Elia Spallanzani fdt]

https://hackaday.io/project/15430-rc201699-ti-994a-clone-using-tms99105-cpu

[Firefly]

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.

[hhos]

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

[apersson850]

Simply by installing 16-bit wide RAM inside the console, the speed of assembly programs where both the workspace and code is in expansion RAM is increased by about 110%.

Thus you don't have to consider where to put your workspace in RAM PAD to avoid disrupting something in the system, but still get full speed.

The difference when running programs in TI Extended BASIC is much smaller, but can still be noticed. Forth runs a bit faster, but just like the p-system (Pascal), it already has the workspace and the inner interpreter in fast RAM, so the difference isn't astonishing.

[senior_falcon]

5 hours ago, apersson850 said:

Simply by installing 16-bit wide RAM inside the console, the speed of assembly programs where both the workspace and code is in expansion RAM is increased by about 110%......

The difference when running programs in TI Extended BASIC is much smaller, but can still be noticed.....

Yes, this is a worthwhile modification. Plans are available for piggybacking 2 memory chips and a couple more chips on the console chips, plus some wires to connect various pins. As I remember, assembly programs took about 60% of the time to run - i.e. a program that took 100 seconds on the 8 bit bus took about 60 seconds on the 16 bit bus. I don't remember any significant speedup when running an XB program - a program that took 60 seconds to run would take about 59 seconds in XB. You can "try before you buy" by using Win994a which has the option of putting the expansion memory on the 8 bit or 16 bit bus. 

[Tursi]

XB and GPL are both a bit harder to speed up, since neither is memory bound. Changing out the RAM doesn't help much, even changing out the GROMs for faster ones doesn't help much. Keyword is "much", it does make a small difference.

[+TheBF]

15 hours ago, apersson850 said:

Simply by installing 16-bit wide RAM inside the console, the speed of assembly programs where both the workspace and code is in expansion RAM is increased by about 110%.

Thus you don't have to consider where to put your workspace in RAM PAD to avoid disrupting something in the system, but still get full speed.

The difference when running programs in TI Extended BASIC is much smaller, but can still be noticed. Forth runs a bit faster, but just like the p-system (Pascal), it already has the workspace and the inner interpreter in fast RAM, so the difference isn't astonishing.

For reference when I put the Forth workspace in RAM on the 8 bit buss versus in the 16bit memory things move only about 20% slower.

However if the entire program including ALL the intrinsic routines (assembler code) were in 16bit RAM it might be more than 20% faster I think. (?)

[Asmusr]

Would it be possible to develop a faster drop in replacement for the TMS9900 (like the F18A GPU), cut the power to the old chip, and piggy bag the new chip/pcb on top?

[+OLD CS1]

[RickyDean]

29 minutes ago, Asmusr said:

Would it be possible to develop a faster drop in replacement for the TMS9900 (like the F18A GPU), cut the power to the old chip, and piggy bag the new chip/pcb on top?

Or your can install a socket and daughter board......

 

[Omega-TI]

19 minutes ago, OLD CS1 said:

No kidding!  FOR ME, your opinion(s) may vary... I'm all for attaching new devices to work with the TI to expand it's capabilities and usefulness, but if you change the heart of the beast, it's no longer a TI, you might as well run an emulator.  

[+OLD CS1]

1 hour ago, --- Ω --- said:

No kidding!  FOR ME, your opinion(s) may vary... I'm all for attaching new devices to work with the TI to expand it's capabilities and usefulness, but if you change the heart of the beast, it's no longer a TI, you might as well run an emulator.  

Nonetheless, I think it is an interesting exercise to see what can be done with alternate hardware.  Why do we climb the mountain?  Because it is there.

[Omega-TI]

4 hours ago, OLD CS1 said:

Nonetheless, I think it is an interesting exercise to see what can be done with alternate hardware.  Why do we climb the mountain?  Because it is there.

I've said it many times here, "...this hobby is different things to different people, so whatever interests them."  Again, I speak only for myself, but this particular quest has no driving interest for me.  I was only commenting on your photo/post, to which I'm in agreement.  I know from past experience that a difference of opinion can offend some people, but as I get older, I no longer care to be intimidated into silencing myself out of a fear of triggering someone.  It used to be people could have a difference of opinion and still get along, but now days it seems in life many things are turned into a snipe fest, which accomplishes nothing other than diminishing the fun for all involved.  And I probably should not have even posted this, but there it is.

 

For the record, I'm not referring to you, and I'm not specifying anyone in particular either.

[HOME AUTOMATION]

Snipe test...

7 hours ago, --- Ω --- said:

I'm all for attaching new devices to work with the TI to expand it's capabilities and usefulness, but if you change the heart of the beast, it's no longer a TI, you might as well run an emulator.

What's wrong with emulators? Me thinks, you are comparing apples to apples!

[Omega-TI]

1 minute ago, HOME AUTOMATION said:

Snipe test...

What's wrong with emulators? Me thinks, you are comparing apples to apples!

 

Actually I have nothing against emulators, I love my Classic 99. ?

But you are right, it really would be apples to apples, because an FPGA TMS9900 replacement would by all definition be an emulator... would it not?

[HOME AUTOMATION]

Ah, really, I think it would be something entirely new, and that hasn't been emulated yet.

As you stated "it's no longer a TI" ...so I took the emu. part of the statement to "stand on it's own".

[carlsson]

Given there were so many other systems using the VDP (9918/28/29) and PSG (SN76489 which IIUC equals 9919), what you would be building is yet another of those systems, using a Motorola/Hitachi CPU instead of a Zilog, MOS, TI CPU. Probably you could even interface it with an Intel if you wanted, like 8080, 8086/88, 80286 and so on. Interesting exercise but as pointed out you no longer would have a TI-99/4x compatible computer. Perhaps a co-pro like mentioned above, so you could switch CPU as required.