My summer project: A colour Stacy

[Atarian Computing]

:yay:

[JezC]

@derkom Yay, nice result.

All we need now are the obligatory Gembench screenshots in 68k and 68030 modes.
:thumbup: :yay2: :cheer: :goodpost:

[derkom]

I've been playing around a bit today with approaching something resembling my intended final hardware on the switcher board, by pulling out the exxos IDE/TOS board and putting in the Lightning ST, Cloudy, and Storm ST. I was hoping to end up with some kind of configuration that would let me have the TF536's 64 MB fastram when I'm running the 68030, and the Storm's 8 MB alt-ram when running the 68000, but alas it isn't looking possible. I figured it was a bit of a long shot.

Interestingly, when I boot the TF536, the splash screen says 72 MB of alt-ram detected, but then the desktop says only 64 MB. I was a little bit surprised that the system would even run this way, but it does, and passes YAART, etc. The problem, however, turns out to be that it's running all the alt-ram at only 8 MHz, so it ends up being very slow alt-ram. :)

I kind of knew this next thing wouldn't work, but tried anyway... I put the Storm downstream of my muxes, so that the BG, BGACK, BR, and E pins would get switched off when I was running the 68030, but as I expected, this doesn't do anything, and EmuTOS still sees all 72 MB, and still runs the RAM at 8 MHz.

So, it looks like I'm forced to choose between having slow alt-ram or having no alt-ram in 68000 mode. Since the whole point of the 68000 is compatibility, and software that's going to be picky about that generally won't benefit from alt-ram anyway, I'll take the fast alt-ram option. :)

Something odd I've run into today is that maprom.prg freezes the system. When I was using maprom earlier with the TF536, it was in the H4, not the Stacy, but I can't imagine what would be causing the problem. I'm going to stick the TF536 and Thunder/Cloudy into the H4 and see if it indeed does not crash there. This is curious, but not a big deal, because fastram.prg works fine for activating the fastram on the TF536.

[czietz]

Any idea why all the Alt-RAM is running at 8 MHz? (Or: How did you come to this conclusion?)

Alt-RAM timing is a solely matter of the HW. I don't know about the terriblefire cards, but when using a PAK & FRAK and a Storm ST, the "68030-only" RAM is of course accessed fast, only the RAM on the Storm ST is accessed with 8 MHz because it's on the bus with 68000 timing. Why would this be different with a TF?

[derkom]

IMG_20200911_182718.jpg

Proud member of the exxos Tower Building Society. That's what's sitting on the CPU bus at the moment. :lol:

[derkom]

Any idea why all the Alt-RAM is running at 8 MHz? (Or: How did you come to this conclusion?)

Because of the mere existence of the Storm ST, apparently. The RAM on the TF card has no trouble running at 50 MHz, but only if it's the only Alt-RAM in the system. As long as the Storm is sitting on the bus, it apparently slows down to 8 MHz. (I determine that it's running at 8 MHz by the fact that GEMBench shows Alt-RAM performance at 117%, which is the same as I see for normal RAM.)

I suppose I can't unequivocally say it "all" slows down, since I have no way of knowing which RAM is being used when, but if I can't control that, then I'm going to get a performance hit anyway.

You mention "68030-only RAM", but how does this even exist? As far as I'm aware, there's no distinction as far as TOS is concerned between the RAM on the Storm card and the RAM on the TF card. It's all just "Alt-RAM". I admit to not knowing much/anything about how Alt-RAM is allocated.

[czietz]

Because of the mere existence of the Storm ST, apparently. The RAM on the TF card has no trouble running at 50 MHz, but only if it's the only Alt-RAM in the system. As long as the Storm is sitting on the bus, it apparently slows down to 8 MHz. (I determine that it's running at 8 MHz by the fact that GEMBench shows Alt-RAM performance at 117%, which is the same as I see for normal RAM.)

I suppose I can't unequivocally say it "all" slows down, since I have no way of knowing which RAM is being used when, but if I can't control that, then I'm going to get a performance hit anyway.

I suppose GEMBENCH is allocating Alt-RAM on the Storm ST, which is why you see slower access speeds during the test. This does not mean that the Alt-RAM actually on that TF card is also being slowed down.

You mention "68030-only RAM", but how does this even exist? As far as I'm aware, there's no distinction as far as TOS is concerned between the RAM on the Storm card and the RAM on the TF card. It's all just "Alt-RAM". I admit to not knowing much/anything about how Alt-RAM is allocated.

I was talking from a HW perspective. You're right that TOS does not know/care whether Alt-RAM is on the slow (68000 bus) or the fast (directly attached to 68030) side.

Great thing about EmuTOS: it's open-source and thus open for tinkering. You could e.g. disable detection of the Storm ST when running in 68030 mode. That way you will ensure that Alt-RAM is allocated from the RAM on the TF card.

[derkom]

I suppose GEMBENCH is allocating Alt-RAM on the Storm ST, which is why you see slower access speeds during the test. This does not mean that the Alt-RAM actually on that TF card is also being slowed down.

Right, I've been thinking that. The Storm RAM is probably just coming first, and therefore the TF RAM isn't getting allocated, which obviously impacts performance.

Great thing about EmuTOS: it's open-source and thus open for tinkering. You could e.g. disable detection of the Storm ST when running in 68030 mode. That way you will ensure that Alt-RAM is allocated from the RAM on the TF card.

Yeah, I pondered this as well, and of course with the Cloudy, it's easy to flash a new EmuTOS. I have very little experience actually using EmuTOS, so I don't have a good sense of how ready it is for daily driver use. Given how challenging it is to open the Stacy up once I close it all (if I ever do :lol:), I'm hesitant to create a hardware scenario where I'm forced to run a specific TOS in order to get good Alt-RAM performance. It's likely to be a long time before I'm locked into any decision here though. :)

[agranlund]

Great thing about EmuTOS: it's open-source and thus open for tinkering. You could e.g. disable detection of the Storm ST when running in 68030 mode. That way you will ensure that Alt-RAM is allocated from the RAM on the TF card.

Yeah, I pondered this as well, and of course with the Cloudy, it's easy to flash a new EmuTOS. I have very little experience actually using EmuTOS, so I don't have a good sense of how ready it is for daily driver use. Given how challenging it is to open the Stacy up once I close it all (if I ever do :lol:), I'm hesitant to create a hardware scenario where I'm forced to run a specific TOS in order to get good Alt-RAM performance. It's likely to be a long time before I'm locked into any decision here though. :)

If the Storm ram is always served up before the TF536 ram then it would be fairly straightforward to write a small auto prg that, if running on a 68030, eats up all of the non 32-bit alt-ram.
I'm assuming TOS sorts free alt-ram memory blocks by address? Thus handing out the slow stuff first.

Maybe EmuTOS could be modified to hand out alt-ram from the free list in reverse, or put TT and ST alt-ram in different pools, or otherwise somehow make sure the good stuff is handed out first :)


I'm guessing you don't have this problem with TOS2.06?
At least my Maprom/Fastram programs will only scan the TT range so it shouldn't find any of the Storm memory for you.


I 100% agree regarding EmuTOS though :)
For me, it's absolutely ready as a daily driver and I love that I can easily modify it to add or enable stuff for myself, that probably wont be available in official builds (such as Blitter enabled on 68030/alt-ram machines, Low/Med/High resolution switch dialog on ST, and so on)

[derkom]

If the Storm ram is always served up before the TF536 ram then it would be fairly straightforward to write a small auto prg that, if running on a 68030, eats up all of the non 32-bit alt-ram.

Heh, yeah, I was wondering about something like that. That could be feasible, and wouldn't lock me into a modified TOS. That is, if the Storm memory really is all being given out at the bottom. Would require some testing.

I'm guessing you don't have this problem with TOS2.06?
At least my Maprom/Fastram programs will only scan the TT range so it shouldn't find any of the Storm memory for you.

Oh yes, 2.06 behaves the same as EmuTOS, after I activate the altram with fastram.prg.

I'm a little confused by your second statement there, because I am using your fastram.prg (maprom.prg is causing the system to freeze for some reason). @czietz can confirm, but I believe that the Storm puts its memory at 0x01000000, which is why it's not possible to distinguish. <-- I'm being dumb. Ignore all of this. :roll:

I'm glad to hear the thumbs up on EmuTOS. I've definitely been planning to *try* to make it my primary OS for 68030 mode.