TT memory systems?

[Randy]

Just picked this one up, and it has a board (CA401059) 2 meg board that seems to be sitting over another series of ram chips on the motherboard.  Can anyone tell me how the memory works in the TT?  I have heard that the memory board is added ram to the memory on the motherboard, is that correct.  Thanks!

[larrylaffer]

The TT has ST RAM and TT RAM. The TT RAM if I remember correctly is where the devices DMA into.

 

Both are boards that get connected to the motherboard. Thre one under the hard drive enclosure is the ST memory where thre other one closer to the cartridge slot is the TT memory. 

[Randy]

Thanks Larry, so it would appear as though the ram I currently have is all ST ram, to get TT ram requires a board on that connector near the cartridge slot.  From what I have read so far, it appears that any real speed boost in the TT is from the TT ram, correct?

[snarkdluG]

Although some text in the pic is in german I hope you can get some relevant info from it. Of course there is different MB revisions.

Edited November 14, 2020 by snarkdluG

[larrylaffer]

1 hour ago, Randy said:

Thanks Larry, so it would appear as though the ram I currently have is all ST ram, to get TT ram requires a board on that connector near the cartridge slot.  From what I have read so far, it appears that any real speed boost in the TT is from the TT ram, correct?

 

Yes, you will need an extra board and extra memory SIMMs to expand your TT memory.

 

It is always dangerous to make generalizations about performance but yes, as a general rule the speed in the TT comes from the TT RAM. First of all I need to say that I said exactly the wrong thing in my first reply: It is the ST memory that is being used for DMA and graphics, not the TT. TThe TT memory is used only by software that is aware it is running on the TT. The TT memory has a wider bus, which means you can access more memory per clock cycle, so the program can indeed run faster if it runs there. But if the software is written for Atari STs (including F/M/STE) then it won't land there.

 

This is at least my findings from research, someone who has done programming for it please verify the validity or not of my understanding.

[ParanoidLittleMan]

The reason why so called TT RAM is faster is not wider bus, but that it is not shared with video. And slowdown of code running from so called ST RAM depends from used video mode - more res, more colors - more slowdown.

Just to add that in case of ST(E) at regular clock speed there is no slowdown in any regular resolution. But they can have so called Fast RAM above 4 MB.

Disk DMA can access only lower 4 MB on ST(E) and on TTs too. But that's only ACSI and floppy DMA. For SCSI on TT other DMA is used.

[lp060]

8 hours ago, larrylaffer said:

 

Yes, you will need an extra board and extra memory SIMMs to expand your TT memory.

 

It is always dangerous to make generalizations about performance but yes, as a general rule the speed in the TT comes from the TT RAM. First of all I need to say that I said exactly the wrong thing in my first reply: It is the ST memory that is being used for DMA and graphics, not the TT. TThe TT memory is used only by software that is aware it is running on the TT. The TT memory has a wider bus, which means you can access more memory per clock cycle, so the program can indeed run faster if it runs there. But if the software is written for Atari STs (including F/M/STE) then it won't land there.

 

This is at least my findings from research, someone who has done programming for it please verify the validity or not of my understanding.

Some bits in the program header can be adjusted to allow old software to allocate fastram or place the program itself in fastram. A small utility can be used to manipulate these bits or some of the more advanced desktops like Thing Desktop have this feature built in. Won't work on all old programs. https://freemint.github.io/tos.hyp/en/gemdos_programs.html

Edited November 14, 2020 by lp060

[Randy]

Thanks guys!  So from what I am reading, the ST ram on the ram board, which has 256k chips on it and gives me, along with the 2 meg on the motherboard, a total of 2 megs ST ram.  Now, apparently I can kick that up to 8 meg of ST ram by replacing those SMD chips with 1 meg chips, which would give me a total of 10 meg of ST ram.  Is there any advantage to having more ST ram over adding TT ram?

[lp060]

My system is 10mb STram/64mb TTram. Can't say I ever ran out memory. There are users out there with way more fastram than me. It probably depends on what you plan to do with the system and what types of programs you plan to run. My system runs MiNT and with multitasking the extra ram helps. If you are going to stick to single tasking TOS, then a setup like mine is overkill.

Edited November 15, 2020 by lp060

[larrylaffer]

3 hours ago, lp060 said:

My system is 10mb STram/64mb TTram. Can't say I ever ran out memory. There are users out there with way more fastram than me. It probably depends on what you plan to do with the system and what types of programs you plan to run. My system runs MiNT and with multitasking the extra ram helps. If you are going to stick to single tasking TOS, then a setup like mine is overkill.

Totally agree. Mine also has a lot of TT RAM because I run MiNT and other things that are more demanding. Also I think the backwards compatibility with the ST line of the TT is not good. So if you want to be playing games for example better use an STE/MegaSTE with enough memory (4MB is more than enough) than a TT. I think TT and Falcon are separate chapters on their own.

[larrylaffer]

On 11/14/2020 at 1:13 AM, ParanoidLittleMan said:

The reason why so called TT RAM is faster is not wider bus, but that it is not shared with video. And slowdown of code running from so called ST RAM depends from used video mode - more res, more colors - more slowdown.

Just to add that in case of ST(E) at regular clock speed there is no slowdown in any regular resolution. But they can have so called Fast RAM above 4 MB.

Disk DMA can access only lower 4 MB on ST(E) and on TTs too. But that's only ACSI and floppy DMA. For SCSI on TT other DMA is used.

@ParanoidLittleMan, why is there a slowdown depending on the graphics? Doesn't the graphics chip just reserve a part of ST RAM and DMA into it while the rest of the ST RAM is accessible? Does the TT lock somehow the ST RAM when the graphics chip DMAs into it causing the rest of the memory accesses to stall?

 

Also I just found the reference I was thinking of when I said "wider bus": https://www.atarimagazines.com/startv5n6/tterrific.html

 

In Burst Mode (which is a mode that only TT RAM can be, and requires non standard DRAM - Is it EDO really?) section, it says:

 

Quote

In burst mode, the 68030 pulls in 16 bytes, or four "longs" (a long is 32 bits, the size of TT memory) in just five cycles; one to set things up, one to fetch the first, the remaining three to fetch the other three. This is far, far better than the normal instruction-fetch mechanism. The 16 bytes are fed into the "instruction cache," a place inside the 68030 I'll talk about more later, and executed at top speed.

 

So what I was remembering (wrongly) as "wider bus" seems partially true I think depending how many bytes/cycle (or how cycles it takes to fetch four longs) the ST RAM can fetch but I guess it would be less than the TT (PLM, I am sure you will know the answer, please share with us).

 

On top of that, and again based on the above link the fact that other devices (such as graphics, sound, ASCSI) "lock" the memory when the DMA in/out of it?

 

On a different note, thank you @lp060 for the info:

On 11/14/2020 at 6:47 AM, lp060 said:

Some bits in the program header can be adjusted to allow old software to allocate fastram or place the program itself in fastram. A small utility can be used to manipulate these bits or some of the more advanced desktops like Thing Desktop have this feature built in. Won't work on all old programs. https://freemint.github.io/tos.hyp/en/gemdos_programs.html

I think it is very interesting (mostly from experimentation perspective, I guess most ST programs make assumptions they run in ST RAM and they will fail in all interesting ways if one changes their header and requires them to run in TT RAM)

[lp060]

22 minutes ago, larrylaffer said:

On a different note, thank you @lp060 for the info:

I think it is very interesting (mostly from experimentation perspective, I guess most ST programs make assumptions they run in ST RAM and they will fail in all interesting ways if one changes their header and requires them to run in TT RAM)

Sounds like a general assumption not based on experience. I did write a disclaimer "Won't work on all old programs." Sure some trial and error is required. I've had the TT030 since 1991 and great success with tweaking the header bits. Obviously I'm not trying to make games and demos run in fastram, but for productivity software and most gem applications, it works quite well.

[larrylaffer]

Quote

Sounds like a general assumption not based on experience

Exactly right! ? I never claimed I am an expert in the TT and I found your suggestion extremely interesting. I have applied this technique exactly zero times so far, but will do soon ? 

[ParanoidLittleMan]

Larrylafler asked: "why is there a slowdown depending on the graphics? " .

Let's start how it works by ST, STE: Video RAM is always 32000 bytes by ST.  Video circuit reads it 50, 60 or 70 times per second (PAL, NTSC, Monochrome) . But because borders real speed is higher. 16-bit RAM bandwith in ST is 8 MB/sec. It is shared 1:1 between CPU and video. Possible with RAM speed 150 nS or better.  Here just to add one interesting detail:  STE DMA audio slow down CPU not at all. Because all memory access happens in so called blank video periods (border, sync pulses). There is enough time for stereo audio at 50 K sample rate.

TT and Falcon have some video modes with much more than 32 K video RAM. They just can not work with 16 bit RAM and 250 nS cycle time (RAM speed must be lower of it, of course) . So, there is 32 bit, so called ST RAM - better would be to call it video/shared RAM - in TT and in Falcon too (which has only 16-bit CPU data bus).  Of course video has priority, because it must maintain exact timing. And when video accessing RAM a lot (higher res, more colors), sometime CPU must wait little for RAM access.

It is easy to test speed diff. with simple program, running it in diverse resolutions and measuring execution time. OK, that can be done in program self, but those not believers can use stopper ?

Fast RAM is not shared, it serves only CPU, so no slowdowns.