Why did the TI-99/4 have two databuses?

The name of the pictureThe name of the pictureThe name of the pictureClash 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.










share|improve this question



















  • 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














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.










share|improve this question



















  • 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












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.










share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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












  • 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










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.






share|improve this answer




















  • 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

















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.






share|improve this answer


















  • 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

















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.






share|improve this answer




















  • 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










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "648"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















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






























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.






share|improve this answer




















  • 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














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.






share|improve this answer




















  • 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












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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










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
















  • 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










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.






share|improve this answer


















  • 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














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.






share|improve this answer


















  • 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












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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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












  • 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










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.






share|improve this answer




















  • 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














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.






share|improve this answer




















  • 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












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.






share|improve this answer













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.







share|improve this answer












share|improve this answer



share|improve this answer










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
















  • 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

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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













































































Comments

Popular posts from this blog

Long meetings (6-7 hours a day): Being “babysat” by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery