Why did the TI-99/4 have two databuses?
Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
Wikipedia says on Russian page:
ÃÂôýðúþ ú 16-ÃÂð÷ÃÂÃÂôýþù ÃÂøýõ ñÃÂûø ÿþôúûÃÂÃÂõýàÃÂþûÃÂúþ 256 ñðùàÃÂÃÂðÃÂøÃÂõÃÂúþù ÿðüÃÂÃÂø ø ÃÂøÃÂÃÂõüýþõ ÃÂÃÂã. ÃÂÃÂÃÂðûÃÂýðàÿðüÃÂÃÂà(ÃÂÃÂã) ø ÿõÃÂøÃÂõÃÂøùýÃÂõ ÃÂÃÂÃÂÃÂþùÃÂÃÂòð ñÃÂûø 8-ÃÂð÷ÃÂÃÂôýÃÂüø ø ÿþôúûÃÂÃÂðûøÃÂàÃÂõÃÂõ÷ üÃÂûÃÂÃÂøÿûõúÃÂþÃÂ, ÃÂÃÂþ ÃÂÃÂõñþòðûþ ÃÂôòþõýøàÃÂøÃÂûð ÃÂøúûþò þñÃÂðÃÂõýøàú ýøü.
which means
So anyway the 16-bit bus was connected to only 256 bytes of static RAM, and the system's ROM. The rest of the memory and peripherals were 8-bit and were connected through a multiplexor, which means it takes twice as many cycles to access.
and on its German page
Auf diese Weise können alle 8-Bit-Systemkomponenten wie Grafikchip, Soundchip oder GROM-Chips von der CPU mit der entsprechenden Wortbreite angesteuert werden.
which means
In this way, all the 8-bit components such as the graphics chip, sound chip, and GROM chips may be controlled by the CPU with the corresponding wordsize.
Now given that the TMS9900 has a 16 bit databus, it seems to me that they could have put all memory and all periphery on that bus. It would have saved the cost of the multiplexor, and made the computer a good deal faster too. Presumably it would have simplified the routing of the circuit board also.
If some hardware register is only 8 bits wide, it's not a problem to ignore the upper 8 bits, is it? Writing - just ignore the bits. Reading - just let the line float. In this way, it would behave the same way as the upper bits of the Color RAM of the Commodore 64, which is 4-bit memory connected to an 8-bit bus.
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus.
memory-layout ti-99
add a comment |Â
up vote
5
down vote
favorite
Wikipedia says on Russian page:
ÃÂôýðúþ ú 16-ÃÂð÷ÃÂÃÂôýþù ÃÂøýõ ñÃÂûø ÿþôúûÃÂÃÂõýàÃÂþûÃÂúþ 256 ñðùàÃÂÃÂðÃÂøÃÂõÃÂúþù ÿðüÃÂÃÂø ø ÃÂøÃÂÃÂõüýþõ ÃÂÃÂã. ÃÂÃÂÃÂðûÃÂýðàÿðüÃÂÃÂà(ÃÂÃÂã) ø ÿõÃÂøÃÂõÃÂøùýÃÂõ ÃÂÃÂÃÂÃÂþùÃÂÃÂòð ñÃÂûø 8-ÃÂð÷ÃÂÃÂôýÃÂüø ø ÿþôúûÃÂÃÂðûøÃÂàÃÂõÃÂõ÷ üÃÂûÃÂÃÂøÿûõúÃÂþÃÂ, ÃÂÃÂþ ÃÂÃÂõñþòðûþ ÃÂôòþõýøàÃÂøÃÂûð ÃÂøúûþò þñÃÂðÃÂõýøàú ýøü.
which means
So anyway the 16-bit bus was connected to only 256 bytes of static RAM, and the system's ROM. The rest of the memory and peripherals were 8-bit and were connected through a multiplexor, which means it takes twice as many cycles to access.
and on its German page
Auf diese Weise können alle 8-Bit-Systemkomponenten wie Grafikchip, Soundchip oder GROM-Chips von der CPU mit der entsprechenden Wortbreite angesteuert werden.
which means
In this way, all the 8-bit components such as the graphics chip, sound chip, and GROM chips may be controlled by the CPU with the corresponding wordsize.
Now given that the TMS9900 has a 16 bit databus, it seems to me that they could have put all memory and all periphery on that bus. It would have saved the cost of the multiplexor, and made the computer a good deal faster too. Presumably it would have simplified the routing of the circuit board also.
If some hardware register is only 8 bits wide, it's not a problem to ignore the upper 8 bits, is it? Writing - just ignore the bits. Reading - just let the line float. In this way, it would behave the same way as the upper bits of the Color RAM of the Commodore 64, which is 4-bit memory connected to an 8-bit bus.
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus.
memory-layout ti-99
2
"It would have saved the cost of the multiplexor" ... I can't find a schematic, but my suspicion is that the multiplexor is at most 4 or 5 74-series ICs which would have cost < $1 each, even at late 70s prices. And that's even if you ignored the fact that TI manufactured them themselves... the cost of redesigning would have been a lot more significant.
â Jules
3 hours ago
What Wikipedia article is the quoted information from?
â Steven Vascellaro
1 hour ago
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
Wikipedia says on Russian page:
ÃÂôýðúþ ú 16-ÃÂð÷ÃÂÃÂôýþù ÃÂøýõ ñÃÂûø ÿþôúûÃÂÃÂõýàÃÂþûÃÂúþ 256 ñðùàÃÂÃÂðÃÂøÃÂõÃÂúþù ÿðüÃÂÃÂø ø ÃÂøÃÂÃÂõüýþõ ÃÂÃÂã. ÃÂÃÂÃÂðûÃÂýðàÿðüÃÂÃÂà(ÃÂÃÂã) ø ÿõÃÂøÃÂõÃÂøùýÃÂõ ÃÂÃÂÃÂÃÂþùÃÂÃÂòð ñÃÂûø 8-ÃÂð÷ÃÂÃÂôýÃÂüø ø ÿþôúûÃÂÃÂðûøÃÂàÃÂõÃÂõ÷ üÃÂûÃÂÃÂøÿûõúÃÂþÃÂ, ÃÂÃÂþ ÃÂÃÂõñþòðûþ ÃÂôòþõýøàÃÂøÃÂûð ÃÂøúûþò þñÃÂðÃÂõýøàú ýøü.
which means
So anyway the 16-bit bus was connected to only 256 bytes of static RAM, and the system's ROM. The rest of the memory and peripherals were 8-bit and were connected through a multiplexor, which means it takes twice as many cycles to access.
and on its German page
Auf diese Weise können alle 8-Bit-Systemkomponenten wie Grafikchip, Soundchip oder GROM-Chips von der CPU mit der entsprechenden Wortbreite angesteuert werden.
which means
In this way, all the 8-bit components such as the graphics chip, sound chip, and GROM chips may be controlled by the CPU with the corresponding wordsize.
Now given that the TMS9900 has a 16 bit databus, it seems to me that they could have put all memory and all periphery on that bus. It would have saved the cost of the multiplexor, and made the computer a good deal faster too. Presumably it would have simplified the routing of the circuit board also.
If some hardware register is only 8 bits wide, it's not a problem to ignore the upper 8 bits, is it? Writing - just ignore the bits. Reading - just let the line float. In this way, it would behave the same way as the upper bits of the Color RAM of the Commodore 64, which is 4-bit memory connected to an 8-bit bus.
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus.
memory-layout ti-99
Wikipedia says on Russian page:
ÃÂôýðúþ ú 16-ÃÂð÷ÃÂÃÂôýþù ÃÂøýõ ñÃÂûø ÿþôúûÃÂÃÂõýàÃÂþûÃÂúþ 256 ñðùàÃÂÃÂðÃÂøÃÂõÃÂúþù ÿðüÃÂÃÂø ø ÃÂøÃÂÃÂõüýþõ ÃÂÃÂã. ÃÂÃÂÃÂðûÃÂýðàÿðüÃÂÃÂà(ÃÂÃÂã) ø ÿõÃÂøÃÂõÃÂøùýÃÂõ ÃÂÃÂÃÂÃÂþùÃÂÃÂòð ñÃÂûø 8-ÃÂð÷ÃÂÃÂôýÃÂüø ø ÿþôúûÃÂÃÂðûøÃÂàÃÂõÃÂõ÷ üÃÂûÃÂÃÂøÿûõúÃÂþÃÂ, ÃÂÃÂþ ÃÂÃÂõñþòðûþ ÃÂôòþõýøàÃÂøÃÂûð ÃÂøúûþò þñÃÂðÃÂõýøàú ýøü.
which means
So anyway the 16-bit bus was connected to only 256 bytes of static RAM, and the system's ROM. The rest of the memory and peripherals were 8-bit and were connected through a multiplexor, which means it takes twice as many cycles to access.
and on its German page
Auf diese Weise können alle 8-Bit-Systemkomponenten wie Grafikchip, Soundchip oder GROM-Chips von der CPU mit der entsprechenden Wortbreite angesteuert werden.
which means
In this way, all the 8-bit components such as the graphics chip, sound chip, and GROM chips may be controlled by the CPU with the corresponding wordsize.
Now given that the TMS9900 has a 16 bit databus, it seems to me that they could have put all memory and all periphery on that bus. It would have saved the cost of the multiplexor, and made the computer a good deal faster too. Presumably it would have simplified the routing of the circuit board also.
If some hardware register is only 8 bits wide, it's not a problem to ignore the upper 8 bits, is it? Writing - just ignore the bits. Reading - just let the line float. In this way, it would behave the same way as the upper bits of the Color RAM of the Commodore 64, which is 4-bit memory connected to an 8-bit bus.
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus.
memory-layout ti-99
memory-layout ti-99
edited 1 hour ago
asked 4 hours ago
Wilson
8,291436103
8,291436103
2
"It would have saved the cost of the multiplexor" ... I can't find a schematic, but my suspicion is that the multiplexor is at most 4 or 5 74-series ICs which would have cost < $1 each, even at late 70s prices. And that's even if you ignored the fact that TI manufactured them themselves... the cost of redesigning would have been a lot more significant.
â Jules
3 hours ago
What Wikipedia article is the quoted information from?
â Steven Vascellaro
1 hour ago
add a comment |Â
2
"It would have saved the cost of the multiplexor" ... I can't find a schematic, but my suspicion is that the multiplexor is at most 4 or 5 74-series ICs which would have cost < $1 each, even at late 70s prices. And that's even if you ignored the fact that TI manufactured them themselves... the cost of redesigning would have been a lot more significant.
â Jules
3 hours ago
What Wikipedia article is the quoted information from?
â Steven Vascellaro
1 hour ago
2
2
"It would have saved the cost of the multiplexor" ... I can't find a schematic, but my suspicion is that the multiplexor is at most 4 or 5 74-series ICs which would have cost < $1 each, even at late 70s prices. And that's even if you ignored the fact that TI manufactured them themselves... the cost of redesigning would have been a lot more significant.
â Jules
3 hours ago
"It would have saved the cost of the multiplexor" ... I can't find a schematic, but my suspicion is that the multiplexor is at most 4 or 5 74-series ICs which would have cost < $1 each, even at late 70s prices. And that's even if you ignored the fact that TI manufactured them themselves... the cost of redesigning would have been a lot more significant.
â Jules
3 hours ago
What Wikipedia article is the quoted information from?
â Steven Vascellaro
1 hour ago
What Wikipedia article is the quoted information from?
â Steven Vascellaro
1 hour ago
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
9
down vote
According to Wikipedia,
The unusual architecture of the 99/4 series is documented to be due to the failure of the 9985, an 8-bit processor which was being created specifically for the machine. When it was abandoned, the 16-bit 9900 was selected to replace it, and a great deal of "glue logic" had to be added to fit the processor into the existing design, while no changes were made to take advantage of the 9900's strengths.
(Surprisingly for Wikipedia, especially since this âÂÂis documentedâÂÂ, there is no reference to supporting documentation.)
Apparently the TI-99/4 was designed as a 8-bit system, but when its intended 8-bit CPU failed to materialise, the 9900 was retro-fitted into it. The 9900âÂÂs architecture, in particular its reliance on external registered accessed via its 16-bit databus, meant that a 16-bit bus had to be added alongside the existing 8-bit bus.
Lets say it was inteded to use a 16 bit microcontroller with an 8 bit external memory expansion bus. Also, the 9900 wasn't retrofited, but during development a plug-in daughter board with a 9900 and external circuitry to emulate the memory protocoll of the microcontroller was made and placed instead of the microcontroller. When the deadline for the computer closed in, the microcontroller was still not finished, so they decided to go with integrating the daughter board for the first series. And that's the way it stayed.
â Raffzahn
2 hours ago
@Raffzahn, wow, that begs the question then, why the bizarre memory protocol?
â Stephen Kitt
2 hours ago
Stephen, it's rather simple when looking at the intended architecture, which is unusual from canonical point of view, but none the less a good one. I got to do a shoping run right now and write a better answer tonight. Ok?
â Raffzahn
2 hours ago
1
@Raffzahn oh thereâÂÂs no rush ;-)
â Stephen Kitt
2 hours ago
add a comment |Â
up vote
4
down vote
If you look at the description of the databus multiplexer e.g. here
The TMS9900 being a 16-bit processor, it has 16 data lines and 15 address lines. However, only the console GROMs (>0000-1FFF) and the scratch-pad RAM (>8300-83FF) are accessed in this way. Peripheral memory in the range >2000-7FFF and >A000-FFFF is accessed via an 8-bit data bus, and a 16-bit address bus. A small circuit in the console multiplexes the data bus, creates the 16th address line (A15) and puts the TMS9900 on hold while the least significant byte (the one at the odd address) is processed.
The VDP is hooked on the 16-bit bus, but only to lines D0-D7, i.e. it accesses the most significant byte only. The GROMs, the sound chip, and the speech synthesizer are hooked to the multiplexed 8-bit bus. However, their selection logic senses A15, so they only react to even addresses. In both cases the multiplexer (uselessly) puts the CPU on hold, since all these devices map in the range >8400-9FFF.
you can see that the VDP is connected in exactly that way.
However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place).
The multiplexer consists of a few chips, and isn't that expensive.
As for why the peripheral memory doesn't have 16 bit databus: I don't know. Possibly they wanted to keep the peripherials more simple (at the cost of making the main board a bit more complex).
Having an 8-bit databus instead of a 16-bit databus for the periphery has actually worse consequences:
[...] the data bus has to be multiplexed. This is achieved by a small logic circuit inside the TI console: any memory access to the range >2000-7FFF and >A000-FFFF is multiplexed. The least significant byte (odd address, D8-D15) is passed first, and this is signaled by a high level on the additional address line A15. For input operations, this byte is latched into the console by a 74LS373 D-type latch. Then the multiplexer puts the CPU on hold (with the READY line) and places the most significant byte on the data bus (even address, D0-D7), which is signaled by a low level on A15. The operation will only be completed after 4 clock cycles on Phi3*, by releasing the block on the TMS9900.
Concretely, this means several drawbacks:
- It is impossible to access only one byte: each read/write instruction actually consists in two read/write cycles, one for the odd byte and one for the even byte.
- While dealing with the second byte, the CPU is put on hold. Thus all peripheral access is of the 4 wait-state type.
- As the TMS9900 has a 16-bit data bus, it never deals with single bytes. Even an instruction like MOVB actually writes a 16-bit word. To avoid erasing the lower byte, the CPU reads the word first, changes the most significant byte and rewrites the whole word. For peripheral card it means that every write operations (4 wait cycles) is preceded by a read operation to the same pair of addresses (4 more wait cycles).
So the "an 8-bit processor was replaced by an 16-bit processor" explanation from wikipedia mentioned in another answer sounds very plausible.
1
"However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place)." ... half of the memory space is wasted anyway. Whenever the CPU generates an address (15-bit address bus) the multiplexer hits both the odd and the even address (generating both values of the least significant bit, which for some reason TI decided to call A15). The peripherals all respond only when A15=0, but if you connected another which responded when A15=1 it would be triggered whenever the original was used, which isn't desirable. Besides ...
â Jules
3 hours ago
... TI had a great solution to address space issues in terms of their GROM/GRAM system, which is effectively a serially-accessed ROM or RAM, containing up to 8KiB of data IIRC (theoretical limit 64KiB, but TI never manufactured a chip that large), that occupies only 8 addresses on the CPU memory map. The entire system was built to work around this, the CPU can execute code from them, and so on. The TI99/4A was designed to allow 16 GR*Ms to be connected, it was capable of supporting 128KiB of ROM/RAM in addition to the CPU-bus based expansions (up to 32.25KiB) and VDP RAM (16KiB) = ~160KiB.
â Jules
3 hours ago
How hard would it have been to say that accesses to addresses where A15:A14==10 would be processed as 16-bit bus accesses, those with A15:A14=0x would be treated as 8-bit addresses on the 8-bit bus, and those with A15:A14=11 would be treated as a pair of 8-bit accesses? Being unable to perform an isolated 8-bit operation seems unnecessarily confining from both a semantic and performance standpoint.
â supercat
1 hour ago
add a comment |Â
up vote
2
down vote
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus?
The TMS9900 CPU only has three on-chip registers, none of them being so much as an accumulator. I.e., every mathematical and logical operation occurs in RAM registers. From Wikipedia:
Only the Program Counter, Status Register, and Workspace Pointer registers are on the chip; all work registers are kept in RAM at an address indicated by the Workspace Pointer. 16 registers are available at any given time, and a context switch instruction which changed to another workspace automatically allows fast context switches compared to other processors which may have had to store and restore the registers. For CPU RAM, the machine has only 256 bytes of "scratchpad" memory to support the storage of workspaces. This memory is placed directly on the 16-bit bus with zero wait states, making it much faster than any other memory available to the system.
The professional versions of the TMS9900 family had on-chip cache which handled the registers. The home version instead used 256 bytes of "scratchpad RAM" to emulate cache. While faster than other RAM on the system, the effectively registerless design led to one of the slowest 16-bit computers ever. Proponents say that this design allowed for extremely quick context switches. True. But once in a context (i.e. actually doing something), all operations were off-chip.
so you reckon this entire contraption was just to provide a little double-speed memory? But then My question is essentially "Why not wire all the memory to that faster bus".
â Wilson
1 hour ago
@Wilson, yes, although "just to provide a little double-speed memory" seems to be missing the point. There are no work registers on the chip! Nor is there a RAM cache. To make up for those flaws they came up with the kludge of scratchpad RAM. Nothing can be accomplished, not even a simple add of two virtual registers, without accessing memory. Every operation involves not just CPU time but double bus access time. Horrible design, IMO! // Making all memory as fast as scratchpad RAM would have been expensive.
â RichF
22 mins ago
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
9
down vote
According to Wikipedia,
The unusual architecture of the 99/4 series is documented to be due to the failure of the 9985, an 8-bit processor which was being created specifically for the machine. When it was abandoned, the 16-bit 9900 was selected to replace it, and a great deal of "glue logic" had to be added to fit the processor into the existing design, while no changes were made to take advantage of the 9900's strengths.
(Surprisingly for Wikipedia, especially since this âÂÂis documentedâÂÂ, there is no reference to supporting documentation.)
Apparently the TI-99/4 was designed as a 8-bit system, but when its intended 8-bit CPU failed to materialise, the 9900 was retro-fitted into it. The 9900âÂÂs architecture, in particular its reliance on external registered accessed via its 16-bit databus, meant that a 16-bit bus had to be added alongside the existing 8-bit bus.
Lets say it was inteded to use a 16 bit microcontroller with an 8 bit external memory expansion bus. Also, the 9900 wasn't retrofited, but during development a plug-in daughter board with a 9900 and external circuitry to emulate the memory protocoll of the microcontroller was made and placed instead of the microcontroller. When the deadline for the computer closed in, the microcontroller was still not finished, so they decided to go with integrating the daughter board for the first series. And that's the way it stayed.
â Raffzahn
2 hours ago
@Raffzahn, wow, that begs the question then, why the bizarre memory protocol?
â Stephen Kitt
2 hours ago
Stephen, it's rather simple when looking at the intended architecture, which is unusual from canonical point of view, but none the less a good one. I got to do a shoping run right now and write a better answer tonight. Ok?
â Raffzahn
2 hours ago
1
@Raffzahn oh thereâÂÂs no rush ;-)
â Stephen Kitt
2 hours ago
add a comment |Â
up vote
9
down vote
According to Wikipedia,
The unusual architecture of the 99/4 series is documented to be due to the failure of the 9985, an 8-bit processor which was being created specifically for the machine. When it was abandoned, the 16-bit 9900 was selected to replace it, and a great deal of "glue logic" had to be added to fit the processor into the existing design, while no changes were made to take advantage of the 9900's strengths.
(Surprisingly for Wikipedia, especially since this âÂÂis documentedâÂÂ, there is no reference to supporting documentation.)
Apparently the TI-99/4 was designed as a 8-bit system, but when its intended 8-bit CPU failed to materialise, the 9900 was retro-fitted into it. The 9900âÂÂs architecture, in particular its reliance on external registered accessed via its 16-bit databus, meant that a 16-bit bus had to be added alongside the existing 8-bit bus.
Lets say it was inteded to use a 16 bit microcontroller with an 8 bit external memory expansion bus. Also, the 9900 wasn't retrofited, but during development a plug-in daughter board with a 9900 and external circuitry to emulate the memory protocoll of the microcontroller was made and placed instead of the microcontroller. When the deadline for the computer closed in, the microcontroller was still not finished, so they decided to go with integrating the daughter board for the first series. And that's the way it stayed.
â Raffzahn
2 hours ago
@Raffzahn, wow, that begs the question then, why the bizarre memory protocol?
â Stephen Kitt
2 hours ago
Stephen, it's rather simple when looking at the intended architecture, which is unusual from canonical point of view, but none the less a good one. I got to do a shoping run right now and write a better answer tonight. Ok?
â Raffzahn
2 hours ago
1
@Raffzahn oh thereâÂÂs no rush ;-)
â Stephen Kitt
2 hours ago
add a comment |Â
up vote
9
down vote
up vote
9
down vote
According to Wikipedia,
The unusual architecture of the 99/4 series is documented to be due to the failure of the 9985, an 8-bit processor which was being created specifically for the machine. When it was abandoned, the 16-bit 9900 was selected to replace it, and a great deal of "glue logic" had to be added to fit the processor into the existing design, while no changes were made to take advantage of the 9900's strengths.
(Surprisingly for Wikipedia, especially since this âÂÂis documentedâÂÂ, there is no reference to supporting documentation.)
Apparently the TI-99/4 was designed as a 8-bit system, but when its intended 8-bit CPU failed to materialise, the 9900 was retro-fitted into it. The 9900âÂÂs architecture, in particular its reliance on external registered accessed via its 16-bit databus, meant that a 16-bit bus had to be added alongside the existing 8-bit bus.
According to Wikipedia,
The unusual architecture of the 99/4 series is documented to be due to the failure of the 9985, an 8-bit processor which was being created specifically for the machine. When it was abandoned, the 16-bit 9900 was selected to replace it, and a great deal of "glue logic" had to be added to fit the processor into the existing design, while no changes were made to take advantage of the 9900's strengths.
(Surprisingly for Wikipedia, especially since this âÂÂis documentedâÂÂ, there is no reference to supporting documentation.)
Apparently the TI-99/4 was designed as a 8-bit system, but when its intended 8-bit CPU failed to materialise, the 9900 was retro-fitted into it. The 9900âÂÂs architecture, in particular its reliance on external registered accessed via its 16-bit databus, meant that a 16-bit bus had to be added alongside the existing 8-bit bus.
answered 3 hours ago
Stephen Kitt
29.5k4121142
29.5k4121142
Lets say it was inteded to use a 16 bit microcontroller with an 8 bit external memory expansion bus. Also, the 9900 wasn't retrofited, but during development a plug-in daughter board with a 9900 and external circuitry to emulate the memory protocoll of the microcontroller was made and placed instead of the microcontroller. When the deadline for the computer closed in, the microcontroller was still not finished, so they decided to go with integrating the daughter board for the first series. And that's the way it stayed.
â Raffzahn
2 hours ago
@Raffzahn, wow, that begs the question then, why the bizarre memory protocol?
â Stephen Kitt
2 hours ago
Stephen, it's rather simple when looking at the intended architecture, which is unusual from canonical point of view, but none the less a good one. I got to do a shoping run right now and write a better answer tonight. Ok?
â Raffzahn
2 hours ago
1
@Raffzahn oh thereâÂÂs no rush ;-)
â Stephen Kitt
2 hours ago
add a comment |Â
Lets say it was inteded to use a 16 bit microcontroller with an 8 bit external memory expansion bus. Also, the 9900 wasn't retrofited, but during development a plug-in daughter board with a 9900 and external circuitry to emulate the memory protocoll of the microcontroller was made and placed instead of the microcontroller. When the deadline for the computer closed in, the microcontroller was still not finished, so they decided to go with integrating the daughter board for the first series. And that's the way it stayed.
â Raffzahn
2 hours ago
@Raffzahn, wow, that begs the question then, why the bizarre memory protocol?
â Stephen Kitt
2 hours ago
Stephen, it's rather simple when looking at the intended architecture, which is unusual from canonical point of view, but none the less a good one. I got to do a shoping run right now and write a better answer tonight. Ok?
â Raffzahn
2 hours ago
1
@Raffzahn oh thereâÂÂs no rush ;-)
â Stephen Kitt
2 hours ago
Lets say it was inteded to use a 16 bit microcontroller with an 8 bit external memory expansion bus. Also, the 9900 wasn't retrofited, but during development a plug-in daughter board with a 9900 and external circuitry to emulate the memory protocoll of the microcontroller was made and placed instead of the microcontroller. When the deadline for the computer closed in, the microcontroller was still not finished, so they decided to go with integrating the daughter board for the first series. And that's the way it stayed.
â Raffzahn
2 hours ago
Lets say it was inteded to use a 16 bit microcontroller with an 8 bit external memory expansion bus. Also, the 9900 wasn't retrofited, but during development a plug-in daughter board with a 9900 and external circuitry to emulate the memory protocoll of the microcontroller was made and placed instead of the microcontroller. When the deadline for the computer closed in, the microcontroller was still not finished, so they decided to go with integrating the daughter board for the first series. And that's the way it stayed.
â Raffzahn
2 hours ago
@Raffzahn, wow, that begs the question then, why the bizarre memory protocol?
â Stephen Kitt
2 hours ago
@Raffzahn, wow, that begs the question then, why the bizarre memory protocol?
â Stephen Kitt
2 hours ago
Stephen, it's rather simple when looking at the intended architecture, which is unusual from canonical point of view, but none the less a good one. I got to do a shoping run right now and write a better answer tonight. Ok?
â Raffzahn
2 hours ago
Stephen, it's rather simple when looking at the intended architecture, which is unusual from canonical point of view, but none the less a good one. I got to do a shoping run right now and write a better answer tonight. Ok?
â Raffzahn
2 hours ago
1
1
@Raffzahn oh thereâÂÂs no rush ;-)
â Stephen Kitt
2 hours ago
@Raffzahn oh thereâÂÂs no rush ;-)
â Stephen Kitt
2 hours ago
add a comment |Â
up vote
4
down vote
If you look at the description of the databus multiplexer e.g. here
The TMS9900 being a 16-bit processor, it has 16 data lines and 15 address lines. However, only the console GROMs (>0000-1FFF) and the scratch-pad RAM (>8300-83FF) are accessed in this way. Peripheral memory in the range >2000-7FFF and >A000-FFFF is accessed via an 8-bit data bus, and a 16-bit address bus. A small circuit in the console multiplexes the data bus, creates the 16th address line (A15) and puts the TMS9900 on hold while the least significant byte (the one at the odd address) is processed.
The VDP is hooked on the 16-bit bus, but only to lines D0-D7, i.e. it accesses the most significant byte only. The GROMs, the sound chip, and the speech synthesizer are hooked to the multiplexed 8-bit bus. However, their selection logic senses A15, so they only react to even addresses. In both cases the multiplexer (uselessly) puts the CPU on hold, since all these devices map in the range >8400-9FFF.
you can see that the VDP is connected in exactly that way.
However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place).
The multiplexer consists of a few chips, and isn't that expensive.
As for why the peripheral memory doesn't have 16 bit databus: I don't know. Possibly they wanted to keep the peripherials more simple (at the cost of making the main board a bit more complex).
Having an 8-bit databus instead of a 16-bit databus for the periphery has actually worse consequences:
[...] the data bus has to be multiplexed. This is achieved by a small logic circuit inside the TI console: any memory access to the range >2000-7FFF and >A000-FFFF is multiplexed. The least significant byte (odd address, D8-D15) is passed first, and this is signaled by a high level on the additional address line A15. For input operations, this byte is latched into the console by a 74LS373 D-type latch. Then the multiplexer puts the CPU on hold (with the READY line) and places the most significant byte on the data bus (even address, D0-D7), which is signaled by a low level on A15. The operation will only be completed after 4 clock cycles on Phi3*, by releasing the block on the TMS9900.
Concretely, this means several drawbacks:
- It is impossible to access only one byte: each read/write instruction actually consists in two read/write cycles, one for the odd byte and one for the even byte.
- While dealing with the second byte, the CPU is put on hold. Thus all peripheral access is of the 4 wait-state type.
- As the TMS9900 has a 16-bit data bus, it never deals with single bytes. Even an instruction like MOVB actually writes a 16-bit word. To avoid erasing the lower byte, the CPU reads the word first, changes the most significant byte and rewrites the whole word. For peripheral card it means that every write operations (4 wait cycles) is preceded by a read operation to the same pair of addresses (4 more wait cycles).
So the "an 8-bit processor was replaced by an 16-bit processor" explanation from wikipedia mentioned in another answer sounds very plausible.
1
"However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place)." ... half of the memory space is wasted anyway. Whenever the CPU generates an address (15-bit address bus) the multiplexer hits both the odd and the even address (generating both values of the least significant bit, which for some reason TI decided to call A15). The peripherals all respond only when A15=0, but if you connected another which responded when A15=1 it would be triggered whenever the original was used, which isn't desirable. Besides ...
â Jules
3 hours ago
... TI had a great solution to address space issues in terms of their GROM/GRAM system, which is effectively a serially-accessed ROM or RAM, containing up to 8KiB of data IIRC (theoretical limit 64KiB, but TI never manufactured a chip that large), that occupies only 8 addresses on the CPU memory map. The entire system was built to work around this, the CPU can execute code from them, and so on. The TI99/4A was designed to allow 16 GR*Ms to be connected, it was capable of supporting 128KiB of ROM/RAM in addition to the CPU-bus based expansions (up to 32.25KiB) and VDP RAM (16KiB) = ~160KiB.
â Jules
3 hours ago
How hard would it have been to say that accesses to addresses where A15:A14==10 would be processed as 16-bit bus accesses, those with A15:A14=0x would be treated as 8-bit addresses on the 8-bit bus, and those with A15:A14=11 would be treated as a pair of 8-bit accesses? Being unable to perform an isolated 8-bit operation seems unnecessarily confining from both a semantic and performance standpoint.
â supercat
1 hour ago
add a comment |Â
up vote
4
down vote
If you look at the description of the databus multiplexer e.g. here
The TMS9900 being a 16-bit processor, it has 16 data lines and 15 address lines. However, only the console GROMs (>0000-1FFF) and the scratch-pad RAM (>8300-83FF) are accessed in this way. Peripheral memory in the range >2000-7FFF and >A000-FFFF is accessed via an 8-bit data bus, and a 16-bit address bus. A small circuit in the console multiplexes the data bus, creates the 16th address line (A15) and puts the TMS9900 on hold while the least significant byte (the one at the odd address) is processed.
The VDP is hooked on the 16-bit bus, but only to lines D0-D7, i.e. it accesses the most significant byte only. The GROMs, the sound chip, and the speech synthesizer are hooked to the multiplexed 8-bit bus. However, their selection logic senses A15, so they only react to even addresses. In both cases the multiplexer (uselessly) puts the CPU on hold, since all these devices map in the range >8400-9FFF.
you can see that the VDP is connected in exactly that way.
However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place).
The multiplexer consists of a few chips, and isn't that expensive.
As for why the peripheral memory doesn't have 16 bit databus: I don't know. Possibly they wanted to keep the peripherials more simple (at the cost of making the main board a bit more complex).
Having an 8-bit databus instead of a 16-bit databus for the periphery has actually worse consequences:
[...] the data bus has to be multiplexed. This is achieved by a small logic circuit inside the TI console: any memory access to the range >2000-7FFF and >A000-FFFF is multiplexed. The least significant byte (odd address, D8-D15) is passed first, and this is signaled by a high level on the additional address line A15. For input operations, this byte is latched into the console by a 74LS373 D-type latch. Then the multiplexer puts the CPU on hold (with the READY line) and places the most significant byte on the data bus (even address, D0-D7), which is signaled by a low level on A15. The operation will only be completed after 4 clock cycles on Phi3*, by releasing the block on the TMS9900.
Concretely, this means several drawbacks:
- It is impossible to access only one byte: each read/write instruction actually consists in two read/write cycles, one for the odd byte and one for the even byte.
- While dealing with the second byte, the CPU is put on hold. Thus all peripheral access is of the 4 wait-state type.
- As the TMS9900 has a 16-bit data bus, it never deals with single bytes. Even an instruction like MOVB actually writes a 16-bit word. To avoid erasing the lower byte, the CPU reads the word first, changes the most significant byte and rewrites the whole word. For peripheral card it means that every write operations (4 wait cycles) is preceded by a read operation to the same pair of addresses (4 more wait cycles).
So the "an 8-bit processor was replaced by an 16-bit processor" explanation from wikipedia mentioned in another answer sounds very plausible.
1
"However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place)." ... half of the memory space is wasted anyway. Whenever the CPU generates an address (15-bit address bus) the multiplexer hits both the odd and the even address (generating both values of the least significant bit, which for some reason TI decided to call A15). The peripherals all respond only when A15=0, but if you connected another which responded when A15=1 it would be triggered whenever the original was used, which isn't desirable. Besides ...
â Jules
3 hours ago
... TI had a great solution to address space issues in terms of their GROM/GRAM system, which is effectively a serially-accessed ROM or RAM, containing up to 8KiB of data IIRC (theoretical limit 64KiB, but TI never manufactured a chip that large), that occupies only 8 addresses on the CPU memory map. The entire system was built to work around this, the CPU can execute code from them, and so on. The TI99/4A was designed to allow 16 GR*Ms to be connected, it was capable of supporting 128KiB of ROM/RAM in addition to the CPU-bus based expansions (up to 32.25KiB) and VDP RAM (16KiB) = ~160KiB.
â Jules
3 hours ago
How hard would it have been to say that accesses to addresses where A15:A14==10 would be processed as 16-bit bus accesses, those with A15:A14=0x would be treated as 8-bit addresses on the 8-bit bus, and those with A15:A14=11 would be treated as a pair of 8-bit accesses? Being unable to perform an isolated 8-bit operation seems unnecessarily confining from both a semantic and performance standpoint.
â supercat
1 hour ago
add a comment |Â
up vote
4
down vote
up vote
4
down vote
If you look at the description of the databus multiplexer e.g. here
The TMS9900 being a 16-bit processor, it has 16 data lines and 15 address lines. However, only the console GROMs (>0000-1FFF) and the scratch-pad RAM (>8300-83FF) are accessed in this way. Peripheral memory in the range >2000-7FFF and >A000-FFFF is accessed via an 8-bit data bus, and a 16-bit address bus. A small circuit in the console multiplexes the data bus, creates the 16th address line (A15) and puts the TMS9900 on hold while the least significant byte (the one at the odd address) is processed.
The VDP is hooked on the 16-bit bus, but only to lines D0-D7, i.e. it accesses the most significant byte only. The GROMs, the sound chip, and the speech synthesizer are hooked to the multiplexed 8-bit bus. However, their selection logic senses A15, so they only react to even addresses. In both cases the multiplexer (uselessly) puts the CPU on hold, since all these devices map in the range >8400-9FFF.
you can see that the VDP is connected in exactly that way.
However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place).
The multiplexer consists of a few chips, and isn't that expensive.
As for why the peripheral memory doesn't have 16 bit databus: I don't know. Possibly they wanted to keep the peripherials more simple (at the cost of making the main board a bit more complex).
Having an 8-bit databus instead of a 16-bit databus for the periphery has actually worse consequences:
[...] the data bus has to be multiplexed. This is achieved by a small logic circuit inside the TI console: any memory access to the range >2000-7FFF and >A000-FFFF is multiplexed. The least significant byte (odd address, D8-D15) is passed first, and this is signaled by a high level on the additional address line A15. For input operations, this byte is latched into the console by a 74LS373 D-type latch. Then the multiplexer puts the CPU on hold (with the READY line) and places the most significant byte on the data bus (even address, D0-D7), which is signaled by a low level on A15. The operation will only be completed after 4 clock cycles on Phi3*, by releasing the block on the TMS9900.
Concretely, this means several drawbacks:
- It is impossible to access only one byte: each read/write instruction actually consists in two read/write cycles, one for the odd byte and one for the even byte.
- While dealing with the second byte, the CPU is put on hold. Thus all peripheral access is of the 4 wait-state type.
- As the TMS9900 has a 16-bit data bus, it never deals with single bytes. Even an instruction like MOVB actually writes a 16-bit word. To avoid erasing the lower byte, the CPU reads the word first, changes the most significant byte and rewrites the whole word. For peripheral card it means that every write operations (4 wait cycles) is preceded by a read operation to the same pair of addresses (4 more wait cycles).
So the "an 8-bit processor was replaced by an 16-bit processor" explanation from wikipedia mentioned in another answer sounds very plausible.
If you look at the description of the databus multiplexer e.g. here
The TMS9900 being a 16-bit processor, it has 16 data lines and 15 address lines. However, only the console GROMs (>0000-1FFF) and the scratch-pad RAM (>8300-83FF) are accessed in this way. Peripheral memory in the range >2000-7FFF and >A000-FFFF is accessed via an 8-bit data bus, and a 16-bit address bus. A small circuit in the console multiplexes the data bus, creates the 16th address line (A15) and puts the TMS9900 on hold while the least significant byte (the one at the odd address) is processed.
The VDP is hooked on the 16-bit bus, but only to lines D0-D7, i.e. it accesses the most significant byte only. The GROMs, the sound chip, and the speech synthesizer are hooked to the multiplexed 8-bit bus. However, their selection logic senses A15, so they only react to even addresses. In both cases the multiplexer (uselessly) puts the CPU on hold, since all these devices map in the range >8400-9FFF.
you can see that the VDP is connected in exactly that way.
However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place).
The multiplexer consists of a few chips, and isn't that expensive.
As for why the peripheral memory doesn't have 16 bit databus: I don't know. Possibly they wanted to keep the peripherials more simple (at the cost of making the main board a bit more complex).
Having an 8-bit databus instead of a 16-bit databus for the periphery has actually worse consequences:
[...] the data bus has to be multiplexed. This is achieved by a small logic circuit inside the TI console: any memory access to the range >2000-7FFF and >A000-FFFF is multiplexed. The least significant byte (odd address, D8-D15) is passed first, and this is signaled by a high level on the additional address line A15. For input operations, this byte is latched into the console by a 74LS373 D-type latch. Then the multiplexer puts the CPU on hold (with the READY line) and places the most significant byte on the data bus (even address, D0-D7), which is signaled by a low level on A15. The operation will only be completed after 4 clock cycles on Phi3*, by releasing the block on the TMS9900.
Concretely, this means several drawbacks:
- It is impossible to access only one byte: each read/write instruction actually consists in two read/write cycles, one for the odd byte and one for the even byte.
- While dealing with the second byte, the CPU is put on hold. Thus all peripheral access is of the 4 wait-state type.
- As the TMS9900 has a 16-bit data bus, it never deals with single bytes. Even an instruction like MOVB actually writes a 16-bit word. To avoid erasing the lower byte, the CPU reads the word first, changes the most significant byte and rewrites the whole word. For peripheral card it means that every write operations (4 wait cycles) is preceded by a read operation to the same pair of addresses (4 more wait cycles).
So the "an 8-bit processor was replaced by an 16-bit processor" explanation from wikipedia mentioned in another answer sounds very plausible.
edited 3 hours ago
answered 4 hours ago
dirkt
7,0231738
7,0231738
1
"However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place)." ... half of the memory space is wasted anyway. Whenever the CPU generates an address (15-bit address bus) the multiplexer hits both the odd and the even address (generating both values of the least significant bit, which for some reason TI decided to call A15). The peripherals all respond only when A15=0, but if you connected another which responded when A15=1 it would be triggered whenever the original was used, which isn't desirable. Besides ...
â Jules
3 hours ago
... TI had a great solution to address space issues in terms of their GROM/GRAM system, which is effectively a serially-accessed ROM or RAM, containing up to 8KiB of data IIRC (theoretical limit 64KiB, but TI never manufactured a chip that large), that occupies only 8 addresses on the CPU memory map. The entire system was built to work around this, the CPU can execute code from them, and so on. The TI99/4A was designed to allow 16 GR*Ms to be connected, it was capable of supporting 128KiB of ROM/RAM in addition to the CPU-bus based expansions (up to 32.25KiB) and VDP RAM (16KiB) = ~160KiB.
â Jules
3 hours ago
How hard would it have been to say that accesses to addresses where A15:A14==10 would be processed as 16-bit bus accesses, those with A15:A14=0x would be treated as 8-bit addresses on the 8-bit bus, and those with A15:A14=11 would be treated as a pair of 8-bit accesses? Being unable to perform an isolated 8-bit operation seems unnecessarily confining from both a semantic and performance standpoint.
â supercat
1 hour ago
add a comment |Â
1
"However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place)." ... half of the memory space is wasted anyway. Whenever the CPU generates an address (15-bit address bus) the multiplexer hits both the odd and the even address (generating both values of the least significant bit, which for some reason TI decided to call A15). The peripherals all respond only when A15=0, but if you connected another which responded when A15=1 it would be triggered whenever the original was used, which isn't desirable. Besides ...
â Jules
3 hours ago
... TI had a great solution to address space issues in terms of their GROM/GRAM system, which is effectively a serially-accessed ROM or RAM, containing up to 8KiB of data IIRC (theoretical limit 64KiB, but TI never manufactured a chip that large), that occupies only 8 addresses on the CPU memory map. The entire system was built to work around this, the CPU can execute code from them, and so on. The TI99/4A was designed to allow 16 GR*Ms to be connected, it was capable of supporting 128KiB of ROM/RAM in addition to the CPU-bus based expansions (up to 32.25KiB) and VDP RAM (16KiB) = ~160KiB.
â Jules
3 hours ago
How hard would it have been to say that accesses to addresses where A15:A14==10 would be processed as 16-bit bus accesses, those with A15:A14=0x would be treated as 8-bit addresses on the 8-bit bus, and those with A15:A14=11 would be treated as a pair of 8-bit accesses? Being unable to perform an isolated 8-bit operation seems unnecessarily confining from both a semantic and performance standpoint.
â supercat
1 hour ago
1
1
"However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place)." ... half of the memory space is wasted anyway. Whenever the CPU generates an address (15-bit address bus) the multiplexer hits both the odd and the even address (generating both values of the least significant bit, which for some reason TI decided to call A15). The peripherals all respond only when A15=0, but if you connected another which responded when A15=1 it would be triggered whenever the original was used, which isn't desirable. Besides ...
â Jules
3 hours ago
"However, it would have hurt too much to throw away half of the peripheral memory (a 64KB address range isn't that much in the first place)." ... half of the memory space is wasted anyway. Whenever the CPU generates an address (15-bit address bus) the multiplexer hits both the odd and the even address (generating both values of the least significant bit, which for some reason TI decided to call A15). The peripherals all respond only when A15=0, but if you connected another which responded when A15=1 it would be triggered whenever the original was used, which isn't desirable. Besides ...
â Jules
3 hours ago
... TI had a great solution to address space issues in terms of their GROM/GRAM system, which is effectively a serially-accessed ROM or RAM, containing up to 8KiB of data IIRC (theoretical limit 64KiB, but TI never manufactured a chip that large), that occupies only 8 addresses on the CPU memory map. The entire system was built to work around this, the CPU can execute code from them, and so on. The TI99/4A was designed to allow 16 GR*Ms to be connected, it was capable of supporting 128KiB of ROM/RAM in addition to the CPU-bus based expansions (up to 32.25KiB) and VDP RAM (16KiB) = ~160KiB.
â Jules
3 hours ago
... TI had a great solution to address space issues in terms of their GROM/GRAM system, which is effectively a serially-accessed ROM or RAM, containing up to 8KiB of data IIRC (theoretical limit 64KiB, but TI never manufactured a chip that large), that occupies only 8 addresses on the CPU memory map. The entire system was built to work around this, the CPU can execute code from them, and so on. The TI99/4A was designed to allow 16 GR*Ms to be connected, it was capable of supporting 128KiB of ROM/RAM in addition to the CPU-bus based expansions (up to 32.25KiB) and VDP RAM (16KiB) = ~160KiB.
â Jules
3 hours ago
How hard would it have been to say that accesses to addresses where A15:A14==10 would be processed as 16-bit bus accesses, those with A15:A14=0x would be treated as 8-bit addresses on the 8-bit bus, and those with A15:A14=11 would be treated as a pair of 8-bit accesses? Being unable to perform an isolated 8-bit operation seems unnecessarily confining from both a semantic and performance standpoint.
â supercat
1 hour ago
How hard would it have been to say that accesses to addresses where A15:A14==10 would be processed as 16-bit bus accesses, those with A15:A14=0x would be treated as 8-bit addresses on the 8-bit bus, and those with A15:A14=11 would be treated as a pair of 8-bit accesses? Being unable to perform an isolated 8-bit operation seems unnecessarily confining from both a semantic and performance standpoint.
â supercat
1 hour ago
add a comment |Â
up vote
2
down vote
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus?
The TMS9900 CPU only has three on-chip registers, none of them being so much as an accumulator. I.e., every mathematical and logical operation occurs in RAM registers. From Wikipedia:
Only the Program Counter, Status Register, and Workspace Pointer registers are on the chip; all work registers are kept in RAM at an address indicated by the Workspace Pointer. 16 registers are available at any given time, and a context switch instruction which changed to another workspace automatically allows fast context switches compared to other processors which may have had to store and restore the registers. For CPU RAM, the machine has only 256 bytes of "scratchpad" memory to support the storage of workspaces. This memory is placed directly on the 16-bit bus with zero wait states, making it much faster than any other memory available to the system.
The professional versions of the TMS9900 family had on-chip cache which handled the registers. The home version instead used 256 bytes of "scratchpad RAM" to emulate cache. While faster than other RAM on the system, the effectively registerless design led to one of the slowest 16-bit computers ever. Proponents say that this design allowed for extremely quick context switches. True. But once in a context (i.e. actually doing something), all operations were off-chip.
so you reckon this entire contraption was just to provide a little double-speed memory? But then My question is essentially "Why not wire all the memory to that faster bus".
â Wilson
1 hour ago
@Wilson, yes, although "just to provide a little double-speed memory" seems to be missing the point. There are no work registers on the chip! Nor is there a RAM cache. To make up for those flaws they came up with the kludge of scratchpad RAM. Nothing can be accomplished, not even a simple add of two virtual registers, without accessing memory. Every operation involves not just CPU time but double bus access time. Horrible design, IMO! // Making all memory as fast as scratchpad RAM would have been expensive.
â RichF
22 mins ago
add a comment |Â
up vote
2
down vote
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus?
The TMS9900 CPU only has three on-chip registers, none of them being so much as an accumulator. I.e., every mathematical and logical operation occurs in RAM registers. From Wikipedia:
Only the Program Counter, Status Register, and Workspace Pointer registers are on the chip; all work registers are kept in RAM at an address indicated by the Workspace Pointer. 16 registers are available at any given time, and a context switch instruction which changed to another workspace automatically allows fast context switches compared to other processors which may have had to store and restore the registers. For CPU RAM, the machine has only 256 bytes of "scratchpad" memory to support the storage of workspaces. This memory is placed directly on the 16-bit bus with zero wait states, making it much faster than any other memory available to the system.
The professional versions of the TMS9900 family had on-chip cache which handled the registers. The home version instead used 256 bytes of "scratchpad RAM" to emulate cache. While faster than other RAM on the system, the effectively registerless design led to one of the slowest 16-bit computers ever. Proponents say that this design allowed for extremely quick context switches. True. But once in a context (i.e. actually doing something), all operations were off-chip.
so you reckon this entire contraption was just to provide a little double-speed memory? But then My question is essentially "Why not wire all the memory to that faster bus".
â Wilson
1 hour ago
@Wilson, yes, although "just to provide a little double-speed memory" seems to be missing the point. There are no work registers on the chip! Nor is there a RAM cache. To make up for those flaws they came up with the kludge of scratchpad RAM. Nothing can be accomplished, not even a simple add of two virtual registers, without accessing memory. Every operation involves not just CPU time but double bus access time. Horrible design, IMO! // Making all memory as fast as scratchpad RAM would have been expensive.
â RichF
22 mins ago
add a comment |Â
up vote
2
down vote
up vote
2
down vote
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus?
The TMS9900 CPU only has three on-chip registers, none of them being so much as an accumulator. I.e., every mathematical and logical operation occurs in RAM registers. From Wikipedia:
Only the Program Counter, Status Register, and Workspace Pointer registers are on the chip; all work registers are kept in RAM at an address indicated by the Workspace Pointer. 16 registers are available at any given time, and a context switch instruction which changed to another workspace automatically allows fast context switches compared to other processors which may have had to store and restore the registers. For CPU RAM, the machine has only 256 bytes of "scratchpad" memory to support the storage of workspaces. This memory is placed directly on the 16-bit bus with zero wait states, making it much faster than any other memory available to the system.
The professional versions of the TMS9900 family had on-chip cache which handled the registers. The home version instead used 256 bytes of "scratchpad RAM" to emulate cache. While faster than other RAM on the system, the effectively registerless design led to one of the slowest 16-bit computers ever. Proponents say that this design allowed for extremely quick context switches. True. But once in a context (i.e. actually doing something), all operations were off-chip.
So my question is why the TI-99/4 had these two databuses. Why not put everything on a single databus?
The TMS9900 CPU only has three on-chip registers, none of them being so much as an accumulator. I.e., every mathematical and logical operation occurs in RAM registers. From Wikipedia:
Only the Program Counter, Status Register, and Workspace Pointer registers are on the chip; all work registers are kept in RAM at an address indicated by the Workspace Pointer. 16 registers are available at any given time, and a context switch instruction which changed to another workspace automatically allows fast context switches compared to other processors which may have had to store and restore the registers. For CPU RAM, the machine has only 256 bytes of "scratchpad" memory to support the storage of workspaces. This memory is placed directly on the 16-bit bus with zero wait states, making it much faster than any other memory available to the system.
The professional versions of the TMS9900 family had on-chip cache which handled the registers. The home version instead used 256 bytes of "scratchpad RAM" to emulate cache. While faster than other RAM on the system, the effectively registerless design led to one of the slowest 16-bit computers ever. Proponents say that this design allowed for extremely quick context switches. True. But once in a context (i.e. actually doing something), all operations were off-chip.
answered 2 hours ago
RichF
4,1641334
4,1641334
so you reckon this entire contraption was just to provide a little double-speed memory? But then My question is essentially "Why not wire all the memory to that faster bus".
â Wilson
1 hour ago
@Wilson, yes, although "just to provide a little double-speed memory" seems to be missing the point. There are no work registers on the chip! Nor is there a RAM cache. To make up for those flaws they came up with the kludge of scratchpad RAM. Nothing can be accomplished, not even a simple add of two virtual registers, without accessing memory. Every operation involves not just CPU time but double bus access time. Horrible design, IMO! // Making all memory as fast as scratchpad RAM would have been expensive.
â RichF
22 mins ago
add a comment |Â
so you reckon this entire contraption was just to provide a little double-speed memory? But then My question is essentially "Why not wire all the memory to that faster bus".
â Wilson
1 hour ago
@Wilson, yes, although "just to provide a little double-speed memory" seems to be missing the point. There are no work registers on the chip! Nor is there a RAM cache. To make up for those flaws they came up with the kludge of scratchpad RAM. Nothing can be accomplished, not even a simple add of two virtual registers, without accessing memory. Every operation involves not just CPU time but double bus access time. Horrible design, IMO! // Making all memory as fast as scratchpad RAM would have been expensive.
â RichF
22 mins ago
so you reckon this entire contraption was just to provide a little double-speed memory? But then My question is essentially "Why not wire all the memory to that faster bus".
â Wilson
1 hour ago
so you reckon this entire contraption was just to provide a little double-speed memory? But then My question is essentially "Why not wire all the memory to that faster bus".
â Wilson
1 hour ago
@Wilson, yes, although "just to provide a little double-speed memory" seems to be missing the point. There are no work registers on the chip! Nor is there a RAM cache. To make up for those flaws they came up with the kludge of scratchpad RAM. Nothing can be accomplished, not even a simple add of two virtual registers, without accessing memory. Every operation involves not just CPU time but double bus access time. Horrible design, IMO! // Making all memory as fast as scratchpad RAM would have been expensive.
â RichF
22 mins ago
@Wilson, yes, although "just to provide a little double-speed memory" seems to be missing the point. There are no work registers on the chip! Nor is there a RAM cache. To make up for those flaws they came up with the kludge of scratchpad RAM. Nothing can be accomplished, not even a simple add of two virtual registers, without accessing memory. Every operation involves not just CPU time but double bus access time. Horrible design, IMO! // Making all memory as fast as scratchpad RAM would have been expensive.
â RichF
22 mins ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7559%2fwhy-did-the-ti-99-4-have-two-databuses%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
"It would have saved the cost of the multiplexor" ... I can't find a schematic, but my suspicion is that the multiplexor is at most 4 or 5 74-series ICs which would have cost < $1 each, even at late 70s prices. And that's even if you ignored the fact that TI manufactured them themselves... the cost of redesigning would have been a lot more significant.
â Jules
3 hours ago
What Wikipedia article is the quoted information from?
â Steven Vascellaro
1 hour ago