What would a true 16 bit TI 99 be like?

[oddemann]

41 minutes ago, Asmusr said:

To return to the original subject, I'm not sure if it has been made clear that the only difference between an ordinary TI-99/4A and a 'true 16-bit' version would be that the latter would be somewhat faster (depending on the software). They would be able to run more or less the same software. The true 16-buit version wouldn't magically have USB or WiFi or anything else unless new hardware and software was developed.

So... then there is some good reason for making the TI-99/4A to all it can be and STILL have all the software running on the "modern" one.

[oddemann]

47 minutes ago, retroclouds said:

RMC are planning on doing a MISTER console run in the near future. 
I might consider getting one.

 

 

Cool... the good thing about this system is that you can have so many "different" systems on it. So I am pretty sure there is a future for complete and ready systems like this. In one way... Some work and there could be a "true" 16 bit TI-99/4A on this.

I have a Raspberry Pi that I installed with Retro Pi and the TI. Ask me how I did it ? Do not know. It works. The next thing I will do is to try to install ALL the stuff I have on the card to maybe use the Raspberry Pi to use it on my Big screen. So... for me... Raspberry Pi and Retro Pi and I am all OK.

[matthew180]

5 minutes ago, oddemann said:

So... then there is some good reason for making the TI-99/4A to all it can be and STILL have all the software running on the "modern" one.

 

As stated previously, you can't have an "all it can be" 99/4A, and still have 100% software compatibility.  As soon as you start changing things in hardware, you start breaking software.

[Asmusr]

9 hours ago, matthew180 said:

 

As stated previously, you can't have an "all it can be" 99/4A, and still have 100% software compatibility.  As soon as you start changing things in hardware, you start breaking software.

It depends on what we're talking about. I'm still trying to answer the original question, which I understand as: "What would the impact had been if TI had taken the time to redesign the motherboard once the knew that the TMS9900 would be used?". I think that to a 12 year old with a console, a tape recorder and a few cartridges, the impact would have been very small. Parsec would have run slightly faster, maybe. There wouldn't have been any software compatibility issues because all software would have been designed for the 'true 16-bit' computer. If we're talking about a new computer with an overclocked FPGA 9900 core, I guess there could be compatibility issues. 

[matthew180]

@Asmusr  I see three or more "questions" being asked, among a lot of other possible directions for the thread.

 

There is the question about the past and what "TI" might have done:

On 9/10/2021 at 7:51 PM, oddemann said:

What if they did a real 16 bit motherboard, what could the TI have done then or be like?

The present, as to what "we" think would be a good design:

On 9/10/2021 at 7:51 PM, oddemann said:

"How would a true 16 bit TI 99 be? What is your thinking? How realistic is it to do, today? Just a Classic99-16bit emulator? What would have needed to be made to make it work?"

Also... What would be different or even very different? I understand that the TI BASIC and EX BASIC might have been very different. But what would a true TI 99 16 bit computer be like. What would be more or less the same?

The future, what the O.P. is thinking about might be features they would want in a "new" 99/4A:

On 9/10/2021 at 7:51 PM, oddemann said:

Personally I am thinking about something that would make the TI wireless and makes a connection from modern stuff down to the TI via wireless. Wireless joystick. Wireless signal to smart TV.

 

11 hours ago, Asmusr said:

To return to the original subject, I'm not sure if it has been made clear that the only difference between an ordinary TI-99/4A and a 'true 16-bit' version would be that the latter would be somewhat faster (depending on the software).

This is an open ended discussion, and I don't think you will get consensus as to what a "true 16-bit version" of a 99/4A would be.  TI never made one, so I suppose the first person to make and sell one gets to define what it would be.

[GDMike]

Future TI computer tech started going the way of the pc and split between gaming and upper tech computing so to speak. So I guess the real question is would they have had a line of gaming consoles because we kinda knew where the pc went.

[senior_falcon]

19 hours ago, Asmusr said:

To return to the original subject, I'm not sure if it has been made clear that the only difference between an ordinary TI-99/4A and a 'true 16-bit' version would be that the latter would be somewhat faster (depending on the software).

This is an open ended discussion, and I don't think you will get consensus as to what a "true 16-bit version" of a 99/4A would be.  TI never made one, so I suppose the first person to make and sell one gets to define what it would be.

 

Not trying to stir up an argument, but I'm with Rasmus here. To me a "true 16-bit version" of the 99/4A is a 99/4A with all the memory except for the VDP on the 16 bit bus. This would include the 32K, the cartridge ROM, and maybe the disk controller, etc. All the other bells and whistles being discussed 40 years after this computer was designed are nice to think about and even nicer to actually implement. But then it is no longer a TI99/4A any more than the Macintosh was somehow an Apple 2.

This reminds me of my grandfathers hammer. I had to replace the head once and the handle 3 times, but it is still the same hammer that he used 100 years ago.

 

Edited September 23, 2021 by senior_falcon

[RXB]

Backward Compatibility would have to be maintained in  "true 16-bit version" of a 99/4A so who is going to write this OS that can duplicate XB, Pascal, and Basic?

Having worked on XB for over 20 years I think this would be pretty hard to pull off quickly.

[Tursi]

4 hours ago, senior_falcon said:

But then it is no longer a TI99/4A any more than the Macintosh was somehow an Apple 2.

Macintosh was deliberately not supposed to be an Apple 2.

 

Now the IIgs on the other hand...

 

#distractionend

 

[PeteE]

If I were redesigning a true 16-bit 99/4A, I would love to have access to the VDP RAM through the 16-bit bus in addition to the VDP read/write port.  Would this require some sort of RAM chips that can be accessed by two different buses simultaneously, one for the CPU side and one for the VDP side.  (Is that what dual-ported RAM means?)  To access the RAM on the CPU side, I would want it to be accessible directly, perhaps by mapping it by 8K chunks into the DSR address space from >4000 to >5FFF.  Using the CRU to activate the mapping and select which bank is active.  There would be no need to limit it to 16K VRAM either, since it could access more by bank-switching.  If external peripherals also need to share the DSR address space through the 8-bit bus, then the 8-bit multiplexer and wait states would need to be disabled when accessing the banked VRAM.  Having fast access to the VRAM would make it possible to develop more advanced and better performing graphic demos and games.

[+FarmerPotato]

8 hours ago, PeteE said:

If I were redesigning a true 16-bit 99/4A, I would love to have access to the VDP RAM through the 16-bit bus in addition to the VDP read/write port.  Would this require some sort of RAM chips that can be accessed by two different buses simultaneously, one for the CPU side and one for the VDP side.  (Is that what dual-ported RAM means?)  To access the RAM on the CPU side, I would want it to be accessible directly, perhaps by mapping it by 8K chunks into the DSR address space from >4000 to >5FFF.  Using the CRU to activate the mapping and select which bank is active.  There would be no need to limit it to 16K VRAM either, since it could access more by bank-switching.  If external peripherals also need to share the DSR address space through the 8-bit bus, then the 8-bit multiplexer and wait states would need to be disabled when accessing the banked VRAM.  Having fast access to the VRAM would make it possible to develop more advanced and better performing graphic demos and games.

I’ve thought about this a lot in the past year, dual access to VDP Ram. 

Dual port VRAM isn’t two independent buses. There’s one side that treats it like DRAM with random access plus refresh cycles. The other side is used to output (or input) a whole line of pixels, so it’s called the serial port. it’s a very long shift register that can read or write into a whole row of DRAM.  
 

now say you could get the 9918 to work with the DRAM interface. It might be enough to have the block write capability, doing input to the serial port. I think you are required to do 512 bytes or 1024 bytes in one go. However, you have to multiplex on the address pins to first tell the serial register what address to load or store. 
 

this is backwards from the typical use. A CPU uses the random access port, while the serial port streams pixels out to the video port. (Thru a color palette lookup table and RGB generator.) No sprites, no character lookups, no random access, just pure lines of pixels out. 

 

Some part numbers are I think MT4256 for 256k x 4 bit VRAM. TI’s 34076 is one palette generator but BT458 and friends are older simpler and cheaper. 

Rather than this kind of VRAM, I think a fast SRAM plus arbitration logic is better suited. It works out to a lot of buffer chips though. An FPGA could solve the whole problem with enough I/O pins and 16K RAM. I’m not really happy with either solution. 
 

The SRAM arbitration would give attention to each side on every other cycle. Like time sharing. 

 

 

[Hans23]

20 minutes ago, FarmerPotato said:

Rather than this kind of VRAM, I think a fast SRAM plus arbitration logic is better suited. It works out to a lot of buffer chips though.

There are one-chip solutions to this, and while they are not cheap, they're probably still cheaper than a bunch of TTLs to implement buffering and arbitration logic separately.  Here's one of those: Renesas 7016 16K x 9 Dual-Port RAM - A single XC95144XL + an SRAM chip would probably be an alternative viable route.

[wierd_w]

This is a dumb reply, so treat accordingly, but--

 

If you intend to bank the vram anyway, why not just have one bank on the CPU's address bus, and the other bank on the VDP's? On bank switch, you just move the windows accordingly.  You would need to keep the VDP busy doing something so it does not notice the bank switch though. I do not think there is a bus-mastering line to tell it to be patient, because something else is talking to/diddling with the RAM.  If it is busy doing a multi-cycle instruction though, you might be able to switch it behind its back without it noticing. (alternatively, break the VDP RAM into 2 sections, both 8k in size, and have the VDP be busy with one half of that memory while you switch the bottom and or top, depending.)

 

EG, suppose you wanted to have 32k of VDP memory:

 

You have 8k of it in page 1, and another 8k in page 2.  The VDP owns both of them, and this is the 16k that the VDP expects.  At the same time, another 16k is mapped into the CPU's address space as 2 more 8k pages, 3, and 4.  We can write all over pages 3 and 4 using the CPU's address and data busses with abandon, the VDP is not using them.  We can then have the VDP work with data in page 2, and then switch out page 1 for either page 3 or page 4 while the VDP is busy with page 2.  We can then have the VDP work with the newly mapped in page, and page out page 2. Pages 1 and 2 are then on the CPU bus, and can be diddled with.

 

Rinse an repeat.

 

This concept is similar to a shadow framebuffer.

 

This should be doable with just some XORs and a mapper chip, I think. Use a single byte bitfield, accessible with the CRU, to help control the mapper and page in-out operations, which basically just drive the logic lines to do the XOR with.

 

 

 

 

 

 

[matthew180]

It sound like cost just went out the window?

 

I agree with @wierd_w , the VRAM would need to be mapped into the CPU address space, and possibly even include some logic to allow the entire 16K VRAM block to be specified.  As for how to technically do that, there are plenty of ways to achieve the multiple access, and a *really* nice example is the Williams computer used in arcade machines like Joust, Robotron 2048, Sinistar, Defender, Startgate, etc..  The 48K of DRAM (made from 1x16K 120ns DRAM chips, IIRC) allows 24-bit access for video scan-out (which also serves as the refresh since it reads the entire 48K every 16.6ms), 8-bit access for the CPU, and 4-bit access for the blitter.  It is a very clever design, so let me know if anyone wants to discuss it in detail.  The problem is cost, BITD it was a very big circuit (about 1/4 of an arcade board) and would have costs a lot of money.

 

16-bit access to all memory, with upper/lower byte logic.  Even if the 9900 could not do this, the next generation of CPU might.

A memory mapper.

Shadow ROM (can swap out the system ROM for RAM), allows RAM in the vector space.  If not shadow ROM, the move the ROM out of the vector space.

DMA.

Ditch the GROM.

Proper interrupt handling.

 

The MSX has a really nice design, so I would probably take a long hard look at that system and see if it could be adapted to a 16-bit data bus.

[+OLD CS1]

While I hate discussing our retro systems in the hypothetical, I have always like the way Nintendo did its video memory for the NES.  An NES cartridge has PRG and CHR ROMs, for program (in CPU space) and character (in PPU space.)  CHR ROM can also be RAM.  2k of RAM is available on-board to the PPU.  If we are talking a bank-switched VDP memory, why not have a bank or two at the cartridge port?  It will require a wider port, a problem for backward compatibility if this is such a concern.

[+FarmerPotato]

10 hours ago, Hans23 said:

There are one-chip solutions to this, and while they are not cheap, they're probably still cheaper than a bunch of TTLs to implement buffering and arbitration logic separately.  Here's one of those: Renesas 7016 16K x 9 Dual-Port RAM - A single XC95144XL + an SRAM chip would probably be an alternative viable route.

Thanks! I did not know about those. Only, 8K cost $32, 16K for $40, and 64K cost $70. Oh my. 

I could see using the 1K part ($14) where absolutely needed. (The TMS9650 dual port for multiprocessor is unobtainable unless you are @Ksarul   Not a complete replacement but.)

 

Thanks for pointing these out. 
 

Still, the FPGA is the easiest, might even use the internal SRAM. 
 

Also , putting this on 16 bit bus means VDP needs a 16-to-8 —another logic chip. I imagine you might do a mapping scheme to switch pages on/off at the >8800-8FFE area, though >4000 would be easier.

Then,  mIght as well throw in a DSR ROM with enhanced VMBW etc. For BASIC, support CALL PEEKV, POKEV etc. like MiniMemory. 

Memory-Mapped File Access to VDP RAM

 

if you were really including a DSR ROM, implement a memory mapped file! Imagine BASIC: 

 

OPEN #1:”VDPRAM”, RELATIVE,UPDATE,FIXED 128

 

then 

 

Write data into a desired record number… to fill screen or pattern Table! 

 

Read /write screen or pattern table to store on disk!

I forget the syntax for RELATIVE file access. 
 

Use smaller record lengths to modify or load/save BASIC programs.

The DSR might as  well have a CHARA1 loader, since BASIC can’t access PGM files.  tho that must needs move some code to execute outside the DSR. Magic required to DSRLNK from a DSR ROM  to another card’s disk DSR.

 

Exciting possibilities here!

 

Hey, why not add a DSR ROM to SAMS that offers Level 3 file access to raw blocks? Memory-mapped file access to memory…Weird, I know. Primitive RAM disk. 

Related DSR RAM facility!

given that…

 

I think there are opportunities for loading BASIC support routines into a non-volatile DSR RAM. With trampolines for very large library of routines. . It would be like loading assembly support into >2000, but then instead of CALL LINK(“AWESME”) you could do CALL AWESOME() !!!

 

the DSR concept had such nice opportunities. 

 

[kl99]

Geneve is doing a good job when it comes to run 99/4(A) software. Can't we take their approach?

I guess to go beyond some boundaries one would need to rewrite the Monitor&GPL Interpreter. If it comes to replace that all GPL code is coming via one Grom Read Port, same for Video Ram.

There could be a 99/4a mode and a full 16 bit machine mode.

A FPGA based unit could offer these seamless towards the user.

[speccery]

Inspired by the discussion here, I fired up my TMS99105 based FPGA system again. I back ported the TMS9918 version I created for the soft-CPU version to the TMS99105 version. There were only minor updates and bug fixes, support for the COINC flag and the 5th sprite flag - I didn't have those in place when working with the TMS99105 version .

 

As it's been a very long time, I did not remember that the TMS99105 version synthesises much faster than the version with FPGA CPU. The design occupies only 8% of the XC6SLX9 FPGA logic slices, it includes the TMS9918, TMS9919, memory paging for SAMS memory, the TMS99105 CPU interface etc). I have not updated this FPGA design in a long while. But I think it is the perfect candidate system to implement memory mapped access to VRAM, as the VRAM is anyway implemented inside the FPGA.

[RXB]

On 9/24/2021 at 7:27 AM, matthew180 said:

It sound like cost just went out the window?

 

I agree with @wierd_w , the VRAM would need to be mapped into the CPU address space, and possibly even include some logic to allow the entire 16K VRAM block to be specified.  As for how to technically do that, there are plenty of ways to achieve the multiple access, and a *really* nice example is the Williams computer used in arcade machines like Joust, Robotron 2048, Sinistar, Defender, Startgate, etc..  The 48K of DRAM (made from 1x16K 120ns DRAM chips, IIRC) allows 24-bit access for video scan-out (which also serves as the refresh since it reads the entire 48K every 16.6ms), 8-bit access for the CPU, and 4-bit access for the blitter.  It is a very clever design, so let me know if anyone wants to discuss it in detail.  The problem is cost, BITD it was a very big circuit (about 1/4 of an arcade board) and would have costs a lot of money.

 

16-bit access to all memory, with upper/lower byte logic.  Even if the 9900 could not do this, the next generation of CPU might.

A memory mapper.

Shadow ROM (can swap out the system ROM for RAM), allows RAM in the vector space.  If not shadow ROM, the move the ROM out of the vector space.

DMA.

Ditch the GROM.

Proper interrupt handling.

 

The MSX has a really nice design, so I would probably take a long hard look at that system and see if it could be adapted to a 16-bit data bus.

TURSI has demoed that GROM can run as fast as Forth if you remove the hardware delays.

TI99/4A can have 640K of GROM/GRAM and that is more memory then any computer at time or any upgrade by anyone except SAMS!

Also most of the stuff we have runs from GROM/GRAM including XB and PASCAL and GAMES!

Would not be hard for me to update RXB to run from 16-bit data bus.