Page 75 of 110

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 07 Oct 2025 13:23
by exxos
coonsgm wrote: 07 Oct 2025 13:00 Sorry, I meant simply copying ROM into TTram.
Based on my limited experience, copying ROM into TTram seems to cause software incompatibilities. I've found this to be the case with maprom but I'm getting the feeling in using my STE536 that the same applies to copying ROM into TTram.
MAPROM does all sorts of "other stuff" as well. It caches some lower STram. While this can give a huge speed bump in some cases, I requested that the amount got reduced the number of times even down to 4K at some point because I found issues. How much STram got cached depends on what version you use. So I doubt it's copying ROM to TTram which is the problem.

MAPROM translates the ROM address with the MMU. So software wise, it doesn't "see" anything any different. The problem with doing that is it creates a inherent slowdown because of the amount of overhead of the ROM lookup tables for the MMU takes up.

I did away with that with the new firmware and TOS. It copies ROM to TTram, but does direct address translation in the PLD, so no MMU overhead and things run a bit faster.

You also have BLTfix to consider if you have a blitter.. If you can't run it before the games (assuming they use blitter) then it probably be better to remove the blitter from the ST.

Also, you shouldn't even be using MAPROM with the STE536 anyway.. You need to make sure your also using the latest firmware and TOS...
I'm working with a flawed comparison because I'm comparing running them from an ST536 with older firmware and older modified TOS so I could 100% be wrong in this.
The original ST536 & firmware had all sorts of bugs.. So you could be hitting one of those as well.

The new firmware can only be used if you replace the PLD with a 288XL. But I am also not supporting the older ST536 144XL builds, so can't guarantee the outcome. It *should* work. But there was also some minor hardware changes as well which could upset things.
This seems to especially the PPera hard drive adapted games. Just curious if you've seen similar issues?
I never get chance to play any games or test anything.. Though if you suspect MAPROM, you should try using FASTROM instead as it only sets up the ROM copy to TTram and nothing else. Or don't use it at all, then no TTram of course. CPU caches will impact some stuff as well.

Beyond that, you should probably report that is used to PPera . I don't know if any of his adaptations are even compatible with 030 CPU.. You would have to ask him.. AFAIK, it was mostly adapting them for hard drive use different TOS versions maybe. Though I would basically assume they should still only be run on a 68000 CPU. Again you would have to ask him ..

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 07 Oct 2025 16:28
by Miri
Having the CPLD doing the ROM address translation is indeed a great idea and not even using PMMU at all an even better one...

I freshly got the DFB1X for my Falcon and it luckily boots without any SW-tools, but with low gains in performance indeed.
Unfortunately the problems start, if you want to use the TT-RAM and feel forced to use MAPROM, BLITFIX etc.
Then the blitter problems get serious and at the end you use NVDI to get it out of the way, which indeed adds incompatibilities, but a huge boost as well :D .

The Falcon is certainly a more difficult case than the ST here. With your ST you either don't have a Blitter and already live without it or you simply remove it :twisted:

From my perspective the Blitter is the biggest hurdle to properly use the TT-RAM especially in the STE with Combo chip.
Atari probably had some good non-financial reason to not put a Blitter into the TT ... At the end it would maybe be the best to deactivate the Blitter in the CPLD (By intentionally masking/messing up it's decoding or DTACK or the like), because you don't need a ST based "TT Clone" with a Blitter ... STE, as the ultimate game machine may be a different story ... Perhaps a jumper on the ST536/STE536 to deactivate the Blitter ?

Back to the prototype build:

Which JED file do you recommend to start with a 85ns ROM, which I have at hand ? Current18.jed ?

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 07 Oct 2025 16:37
by exxos
Miri wrote: 07 Oct 2025 16:28 Perhaps a jumper on the ST536/STE536 to deactivate the Blitter ?
You disable it in TOS desktop menu. Otherwise BLTFIX / NVDI must be used. IIRC EMUTOS doesn't even enable the blitter for 030 type systems.

The whole situation is like hacks on top of hacks really adding boosters to Atari's. It's why I want to get rid of TTram and blitter / DMA issues by building a new FPGA chipset which will just work without all those "work arounds" we have now. It's just a mess.

Which JED file do you recommend to start with a 85ns ROM, which I have at hand ? Current18.jed ?
Yes. ROM IC isn't speeded up anymore.

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 26 Oct 2025 18:54
by exxos
Right let's see what goes or blows...

IMG_3997.JPG
IMG_3998.JPG

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 26 Oct 2025 19:26
by coonsgm
New firmware, new ROM version, or both?

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 26 Oct 2025 19:36
by exxos
coonsgm wrote: 26 Oct 2025 19:26 New firmware, new ROM version, or both?
Both.

It's actually the STE stuff I just copied over, ROM and firmware. In theory the STE and ST firmware should be the same now... but needs more testing :P

Just starting loop 12 :)

IMG_4000.JPG

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 26 Oct 2025 19:40
by coonsgm
This would require swapping the 144 for a 288 correct?

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 26 Oct 2025 19:41
by exxos
coonsgm wrote: 26 Oct 2025 19:40 This would require swapping the 144 for a 288 correct?
Yes.

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 26 Oct 2025 20:15
by coonsgm
Woohoo! Awesome news.

Re: REV 3 - REV 5 - The beginning (ST536)

Posted: 26 Oct 2025 20:21
by exxos
coonsgm wrote: 26 Oct 2025 20:15 Woohoo! Awesome news.
8-)


288XL 6ns PLD on the ST536 rev 5.50 :)

IMG_4001.JPG


I will have to loan it to @PhilC so he can try it in his STM at some point when has time..