TiStorm

[Brufnus]

Knowing what a PiStorm can do to - and for - an Amiga, I really want to design and build a similar one for the TI/Geneve.  

 

Trouble is... I have absolutely no idea how to do that. 😕 But a "TiStorm" would be the ultimate upgrade for the TI/Geneve's, no doubt about that! 🥳

In any case... I do believe it's "only" a question of producing a similar interface card for the CPU socket, program the appropriate firmware, and have an ARM edition of, e.g. MAME, running on the Raspberry.

 

It may be quite a job, but not undoable I think...?

 

Imagine having a Geneve with as much RAM as it can possibly support (8 MB isn't it?), hi speed access to a "hard drive" on an sd-card, wi-fi,perhaps 3,000 times the speed of the original CPU, hi res graphics through HDMI, and 16 bit high quality sound through the RPi? 🤔

Edited November 5 by Brufnus

[Gary from OPA]

3 hours ago, Brufnus said:

Knowing what a PiStorm can do to - and for - an Amiga, I really want to design and build a similar one for the TI/Geneve.  

 

Trouble is... I have absolutely no idea how to do that. 😕 But a "TiStorm" would be the ultimate upgrade for the TI/Geneve's, no doubt about that! 🥳

In any case... I do believe it's "only" a question of producing a similar interface card for the CPU socket, program the appropriate firmware, and have an ARM edition of, e.g. MAME, running on the Raspberry.

 

It may be quite a job, but not undoable I think...?

 

Imagine having a Geneve with as much RAM as it can possibly support (8 MB isn't it?), hi speed access to a "hard drive" on an sd-card, wi-fi,perhaps 3,000 times the speed of the original CPU, hi res graphics through HDMI, and 16 bit high quality sound through the RPi? 🤔

Do you have a link about this PiStorm, I haven't heard about it before.

[Brufnus]

1 hour ago, Gary from OPA said:

Do you have a link about this PiStorm, I haven't heard about it before.

Certainly! There's this one for example: https://www.raspberrypi.com/news/pistorm-keeping-the-amiga-alive/  I bought one of them for my CDTV when it was more or less in it's infancy; at the time it used Linux which then ran the so called Musashi emulator, which gave it quite a speed boost as well as the many other options. Today though, we mostly use the Emu68, which is a bare metal version (JIT compiler), which is insanely fast. The price has risen, but it's still pretty cheap compared to many other solutions (and way faster and more expandable).  

[stevee671]

I have PiStorms in all my Amiga’s. What's the best part about PiStorm is that the PiStorm board is about $35. It gives the performance of a FAST 68040. It work ONLY with PiZero2W, Pi 3a and 3B.

It doesn't work with Pi 4 or 5 (That's PiStorm32). PiStorm development is being done on all 68000 based systems, compact 68000 Macs and Atari STs.

Edited November 6 by stevee671

[Brufnus]

13 minutes ago, stevee671 said:

I have PiStorms in all my Amiga’s. What's the best part about PiStorm is that the PiStorm board is about $35. It gives the performance of a FAST 68040. It work ONLY with PiZero2W, Pi 3a and 3B.

It doesn't work with Pi 4 or 5 (That's PiStorm32). PiStorm development is being done on all 68000 based systems, compact 68000 Macs and Atari STs.

Yep, it's an incredible creature!  I've had mine for several years now, and even today I'm amazed about the speed and what it's capable of!

[Asmusr]

I think desoldering the TMS9900 and replacing it with a socket is a major, risky operation, which is probably why nobody has attempted to develop a CPU replacement for the TI-99/4A.

Edited November 6 by Asmusr

[+arcadeshopper]

3 hours ago, Asmusr said:

I think desoldering the TMS9900 and replacing it with a socket is a major, risky operation, which is probably why nobody has attempted to develop a CPU replacement for the TI-99/4A.

with the 99/22 board you'd have a better chance..

[Gary from OPA]

4 hours ago, Asmusr said:

I think desoldering the TMS9900 and replacing it with a socket is a major, risky operation, which is probably why nobody has attempted to develop a CPU replacement for the TI-99/4A.

For the original 4A how we were planning to release the 99105 accelerator it would be a board that push down over the 9900 soldered cpu, and you had to cut one trace on the motherboard to keep the old cpu in in-active state, now of course as Gregory points out the 99/22 it is easier, and my plain is to recreate the 99105 accelerator first as daughterboard, and then work on a fpga or pico design that can fit within the 64pin dip package, but for original 4a not much of gain can be done because of the 16bit to 8bit bus conversion and wait states added and also the usage of slow rom memory on the peb cards and 32k, gaining extra speed can really only be done on new design of a system, unless of course you keep everything internal on the daughterboard and only allow certain stuff to access the bus, it could be done, at least for some parts of the ti99.

[Tursi]

I would say ditch the 99105 and go for a more modern emulation-based approach. It's not only going to be faster, but you can tailor it to the application and improve compatibility at the same time.

 

The way a few of the accelerators that I've looked at work is clever. They basically pull the whole system in and run everything they can internally. They only do actual system bus cycles when they need to access hardware. By doing this, you get a significant acceleration of software without concerning yourself about the slow speed of the real hardware.

 

I've toyed with ideas for a few years. I know the 6502-based one sucks in the 64k address range before it starts. But I toyed with a caching system instead... break up the memory space into 8k chunks like the real machine does. Then as memory areas are accessed, we can load them in and keep them onboard - first access is slow, then it's fast after that. So the first ROM hit interleaves processing with reading the full 8k space into cache, after that the ROMs are fully on the accelerator.

I'd build in a 1MB AMS, that would cover most cases.

 

GROMs work the same way, with their own memory space. Again, once they are fully loaded they'll fly, and you can dedicate 'x' number of GROM bases to cover that case.

 

Peripheral I/O I had considered leaving on the hardware, since you never really know what's attached. But you COULD make exceptions for, say, the pCode card, since you know that's just GROMs. Otherwise I'd probably leave it on the bus for compatibility's sake.

 

CRU would need to stay on the hardware, I think, cause you never really know where it's going. Plus you want the keyboard to work.

 

The cartridge port is really the hardest part. There are so many possibilities for what is plugged in there. But, we can at least make a few assumptions that should cover most cases. GROM is GROM is GROM, doesn't matter where it's attached. ROM is 8k, but can be paged. ROM write paging of cart space is pretty easy to implement, and you could even cache up to whatever RAM size you have. To be honest, that might be all I'd accelerate, and it would cover most cases. When a write to ROM happens, the simple case is you invalidate the 8k cache, the complex case is you track which page you switched to and know whether you already cached it or not.

 

Then, to cover the compatibility cases, you simply need a config menu that turns caching off for memory locations. When off, the hardware is always hit for real. Performance will suffer (and won't be much better than the original machine, though some), but this will prove out compatibility and allow hardware that you didn't design for to work.

 

So basically, I'd map the default like so:

>0000-1FFF = ROM, cacheable
>2000-3FFF = RAM, onboard AMS
>4000-5FFF = DSR space, hardware
>6000-7FFF = Cartridge ROM, paged on write, cachable
>8000-9FFF = I/O space, hardware* (possible exception for GROMs)
>A000-FFFF = RAM, onboard AMS

You could potentially accelerate VDP RAM too - only send writes to the real VDP while reads stay internal. The only gotcha here is the F18A GPU can modify VRAM externally, and I'd be wary of trying to emulate that too. The F18A might, ironically, need to be unaccelerated to work.

Then for any of the 8 blocks (the last RAM block is 3 blocks), you can toggle cacheable or not. When it is not, all accesses go to real hardware.

To be honest, for the first pass I wouldn't even emulate GROM or VDP - leave them external. You'll still see a massive speed boost. I've tested the GPL interpreter before and it spends far, far more time executing 9900 code than accessing GROMs.

 

Edited November 6 by Tursi

[Gary from OPA]

42 minutes ago, Tursi said:

I would say ditch the 99105 and go for a more modern emulation-based approach. It's not only going to be faster, but you can tailor it to the application and improve compatibility at the same time.

 

The way a few of the accelerators that I've looked at work is clever. They basically pull the whole system in and run everything they can internally. They only do actual system bus cycles when they need to access hardware. By doing this, you get a significant acceleration of software without concerning yourself about the slow speed of the real hardware.

 

I've toyed with ideas for a few years. I know the 6502-based one sucks in the 64k address range before it starts. But I toyed with a caching system instead... break up the memory space into 8k chunks like the real machine does. Then as memory areas are accessed, we can load them in and keep them onboard - first access is slow, then it's fast after that. So the first ROM hit interleaves processing with reading the full 8k space into cache, after that the ROMs are fully on the accelerator.

I'd build in a 1MB AMS, that would cover most cases.

 

GROMs work the same way, with their own memory space. Again, once they are fully loaded they'll fly, and you can dedicate 'x' number of GROM bases to cover that case.

 

Peripheral I/O I had considered leaving on the hardware, since you never really know what's attached. But you COULD make exceptions for, say, the pCode card, since you know that's just GROMs. Otherwise I'd probably leave it on the bus for compatibility's sake.

 

CRU would need to stay on the hardware, I think, cause you never really know where it's going. Plus you want the keyboard to work.

 

The cartridge port is really the hardest part. There are so many possibilities for what is plugged in there. But, we can at least make a few assumptions that should cover most cases. GROM is GROM is GROM, doesn't matter where it's attached. ROM is 8k, but can be paged. ROM write paging of cart space is pretty easy to implement, and you could even cache up to whatever RAM size you have. To be honest, that might be all I'd accelerate, and it would cover most cases. When a write to ROM happens, the simple case is you invalidate the 8k cache, the complex case is you track which page you switched to and know whether you already cached it or not.

 

Then, to cover the compatibility cases, you simply need a config menu that turns caching off for memory locations. When off, the hardware is always hit for real. Performance will suffer (and won't be much better than the original machine, though some), but this will prove out compatibility and allow hardware that you didn't design for to work.

 

So basically, I'd map the default like so:

>0000-1FFF = ROM, cacheable
>2000-3FFF = RAM, onboard AMS
>4000-5FFF = DSR space, hardware
>6000-7FFF = Cartridge ROM, paged on write, cachable
>8000-9FFF = I/O space, hardware* (possible exception for GROMs)
>A000-FFFF = RAM, onboard AMS

You could potentially accelerate VDP RAM too - only send writes to the real VDP while reads stay internal. The only gotcha here is the F18A GPU can modify VRAM externally, and I'd be wary of trying to emulate that too. The F18A might, ironically, need to be unaccelerated to work.

Then for any of the 8 blocks (the last RAM block is 3 blocks), you can toggle cacheable or not. When it is not, all accesses go to real hardware.

To be honest, for the first pass I wouldn't even emulate GROM or VDP - leave them external. You'll still see a massive speed boost. I've tested the GPL interpreter before and it spends far, far more time executing 9900 code than accessing GROMs.

 

Yes, all good points you are on the right track and some of what I been thinking of as well.

 

Yes, in the end the 99105 will be ditched as its hard to come by, and my previous experience not all 99105's are the same even when they were brand-new and now with silicon aging, even worse in regard to overall timing and glitches with errors due to the need to demux the bus, etc.

 

I only want to have original 99105 hardware up and running for proper testing and compatibility reasons, and to then work on the fpga or pico replacement, as I can logically scope and compare timing and things to real hardware to do physical testing, etc. it is good to have a physical baseline you are aiming for, to help in debugging a replacement when it comes to the added opcodes, and faster speeds, etc.

[Tursi]

I'd use the 9900 as my physical baseline. There's no advantage to going to a 99105 and plenty of disadvantages. There is no software that uses it and writing software for it will only be useful to the few people who have it, and nobody else. You'll also have to deal with potential incompatibilities with both legacy and modern hardware that may have made assumptions. Keeping the 9900 baseline at least guarantees no software split, and there's no need to worry about making the 99105 timing work. 

 

It's not the same world as it was when you first worked on the 99105 accelerator. Compatibility is more important than new features, because the future potential is ever-shrinking.

 

IMO. Also understand the drive to finish old projects!