Better cpu

[GDMike]

Very interesting

[HOME AUTOMATION]

I'm sure 9900s were used on the earlier PATRIOT SAMS! Used to have docs. on it.

[carlsson]

Hm. Very arbitrary crossing out on page 4: The letters "or" in "Technical Report", the word "and" in "Michael C. Pitruzzello and Robert S. Sparks", the letters "ember 19" in "8 December 1978". Was this due to the military need to censor something in documents made public and in this case there was nothing really sensitive that needed to be crossed out?

[Asmusr]

With a faster CPU the bottleneck for games would soon become the CPU to VDP transfer bandwidth (for assembly games, that is). It's not possible to push much more through than we do now. With multiple CPUs only one at a time would be able to access the VDP.

[Tursi]

3 hours ago, Asmusr said:

With a faster CPU the bottleneck for games would soon become the CPU to VDP transfer bandwidth (for assembly games, that is). It's not possible to push much more through than we do now. With multiple CPUs only one at a time would be able to access the VDP.

Yes. A proper accelerator would include dual-port VDP RAM.  Or the F18A, I guess, since it can keep up for quite a while.

[Ed in SoDak]

23 hours ago, Ksarul said:

Actually, someone did build a 16-processor parallel computer using TMS9900s about ten to fifteen years ago. I'm pretty sure the website documenting it is gone now, unfortunately.

Got a link? Maybe archive.org has it.

[+FarmerPotato]

1 hour ago, Tursi said:

Yes. A proper accelerator would include dual-port VDP RAM.  Or the F18A, I guess, since it can keep up for quite a while.

 I was imagining removing the TMS4464s in my 9958 board* in favor of a channel through the FPGA to an 8-bit SRAM.  So the VDP RAM would become dual-port**.

 

The VDP RAM could be paged into CPU space. Or at least the FPGA could intercept VDPWA, VDPRD, VDPWD etc, manipulating memory for you, with never a wait state. Only register writes would be passed directly through to the VDP. The VDP could still do block moves as usual.

 

I don't know how you'd pull this off for the 4A's 9918A.  

 

 

 

* This is in Geneve2020. My 9958 PCB arrived from OSH Park this week.

 

** in the sense of having 2 complete I/O paths for bytes.. not exactly the buffer for one line of pixels, output serially to the display circuitry, which is how it worked in dual-port VRAM.

 

[+Ksarul]

I lost the link in a computer crash last year, unfortunately. I also had a copy of the pictures from the site on the disk, but they are gone too, as it wasn't one I regularly backed up.

[Tursi]

7 hours ago, FarmerPotato said:

The VDP RAM could be paged into CPU space. Or at least the FPGA could intercept VDPWA, VDPRD, VDPWD etc, manipulating memory for you, with never a wait state. Only register writes would be passed directly through to the VDP. The VDP could still do block moves as usual.

Paging it in is better. It's not really the speed of VDP access that's an issue - reading or writing the VDP on the 99/4A is the same speed as reading or writing RAM or 8-bit ROM (there are no additional wait states). The problem is that random access is three times slower due to the need to write two bytes of address. - four times slower if you consider that only byte access is available. Hell, even being able to set the address in a single 16-bit write would give you 30% faster random access (and the sad part is, I think the VDP could do it if it was just hooked up to the multiplexer).

 

[+FarmerPotato]

2 minutes ago, Tursi said:

Paging it in is better. It's not really the speed of VDP access that's an issue - reading or writing the VDP on the 99/4A is the same speed as reading or writing RAM or 8-bit ROM (there are no additional wait states). The problem is that random access is three times slower due to the need to write two bytes of address. - four times slower if you consider that only byte access is available. Hell, even being able to set the address in a single 16-bit write would give you 30% faster random access (and the sad part is, I think the VDP could do it if it was just hooked up to the multiplexer).

 

Imagining how to park this inside the console - how could the RAM be paged onto the 16 bit bus? Maybe in combination with an internal 32K mod, it could be paged into that space.

 

[Tursi]

10 hours ago, FarmerPotato said:

Imagining how to park this inside the console - how could the RAM be paged onto the 16 bit bus? Maybe in combination with an internal 32K mod, it could be paged into that space.

 

I'd leave it on the 8-bit side of the multiplexer so that you don't have to worry about being 16-bits on the CPU side and 8 bits on the VDP side.

 

As for where in the memory map... that's a good question. DSR space ( >4000 ) speaks to me...

 

[HOME AUTOMATION]

More chips=More Power

 

     

 

[+Ksarul]

PLCC heaven. . .

 

[GDMike]

Now, of course we need to stack these boards in a rack that holds hundreds, hundreds I say.

[jens-eike]

On 3/7/2020 at 12:05 AM, Ed in SoDak said:

Got a link? Maybe archive.org has it.

16 TMS9995 in parallel:

http://famkoplien.de/henry/TI99/

 

 

[matthew180]

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. ?

 

On 1/23/2020 at 12:23 PM, chue said:

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.

Yes, but it is confined to the VDP, so the code to execute has to be moved to VRAM.

 

On 1/24/2020 at 1:20 AM, mizapf said:

It would have required just two control lines for turning one half of the data bus on or off, as the x86 systems do.

And look at that, the 9900 has *FIVE* no-connect pins...  Grrr.

 

On 2/18/2020 at 10:20 AM, 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?

Yes, but the physical design would be very complicated.  Easier to cut the pins on the 9900, take it out, and put in a socket.  But this would have such a limited user-base due to the install requirements, you might as well just make a on-off for yourself.

 

On 2/18/2020 at 6:18 PM, INVISIBLE said:

because an FPGA TMS9900 replacement would by all definition be an emulator... would it not?

Depends on your definition of "emulator".  Emulator, simulator, reproduction, new implementation in hardware, etc.  What people consider the same as the original is complete opinion.  In the defense of an FPGA implementation, using an FPGA is actual hardware, so IMO is it not the same as software emulation or simulation.

[carlsson]

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.

[Ed in SoDak]

7 hours ago, jens-eike said:

16 TMS9995 in parallel:

http://famkoplien.de/henry/TI99/

19, actually.

 

Quote from the link: "A real working parallel computer made with 19 TMS-9995 and a TMS32010, interactive programming environment under NeXT built by myself. The perfect symbiosis of TI and NeXT. This parallel computer was used for time aspects. Beside this it was used for evolving networks, ie. neural networks combined with gentic algorithms. The prime task was also implemented, but not worth to spend more than these words. The algorithm was not parallelized, so no gain in speed. "

 

[hhos]

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 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

 

 

Edited March 24, 2020 by hhos
Wrong name used for cartoon

[carlsson]

Yes, A8 would in some sense be shorthand for Atari 8-bit computers, which to most part were forward compatible from 1979 to 1985/86. A2 would be shorthand for Apple II series which I think withstood more changes along the way, but still somewhat forward compatible. As for custom chips, it is true that both Atari and Commodore, just like TI for that matter, developed their own custom chips for video and sound. Out of those, Commodore "changed track" a couple of times before they had found the C64 formula.

[matthew180]

5 minutes ago, hhos said:

... I am at a loss to find a GOOD explanation for why they put in so many wait states. ...

Just dig around this 99/4A sub-forum, you will find the threads where the 99/4A design has been beat to death.  Everyone has their opinion and speculations, and there are tons of "if they had just ...", etc..  The 99/4A is a great machine trying to shine through despite a lot of bad design decisions.  It can't be changed now, since the "right design" would not be the 99/4A nor have software compatibility.  In fact, some members here *have* built better one-off computers around the 9900 family.

 

12 minutes ago, hhos said:

... I think I may soon be similarly impressed by the TMS9900.

The 9900 is actually a pretty nice CPU to program.  The instruction set is very orthogonal, and it is very interesting how much is seems to have borrowed from the venerable PDP-11.

[+Ksarul]

On 3/20/2020 at 3:55 PM, jens-eike said:

16 TMS9995 in parallel:

http://famkoplien.de/henry/TI99/

 

 

This is the one I remembered. . .many thanks.

[+Schmitzi]

On 3/20/2020 at 8:55 PM, jens-eike said:

16 TMS9995 in parallel:

http://famkoplien.de/henry/TI99/

 

 

 

ah yes, I was searching for it wgen Ksarul asked, but no result

Added it to the list of Links now.

thx!!