exxos's Atari, Amiga & retro forum

Cyprian wrote: 26 May 2025 22:05 2) TOS Desktop cache/blitter settings conflict with BLITTER.ACC settings somehow. I suspect that the Desktop's "Options" menu is using its internal variable for cache/blitter status, instead of checking if cache/blitter is really enabled/disabled. I'll try to check it in Thorsten's source code.

I can confirm that the TOS 1.62 Desktop uses its variables and can restore the BLiTTER status.

First attempt:
Set Options --> Blitter enabled
Run SysInfo: Blitter On
Blitter.Acc: Turn blitter Off
Run SysInfo: Blitter Off
Run SysInfo: Blitter On <-- The Desktop restored the status from its internal variable

Second attempt:
Set Options --> Blitter disabled
Run SysInfo: Blitter Off
Blitter.Acc: Turn blitter On
Run SysInfo: Blitter On
Run SysInfo: Blitter Off <-- The Desktop restored the status from its internal variable

May not be a fair test though as it's likely not cache aware? I guess 306 would be the one to try...

exxos wrote: 25 May 2025 22:36 @Badwolf current9 is up.

You don't need TOSCOPY for it to work (you just wont get fast-rom enabled)

Boots to my 206 and EMUTOS in a quick test...

Current9 flashed and 47pF across CLK and GND and it boots nicely to EmuTOS (60MB allocated) and is running the TT-RAM test now, but it's only got to test 3 of pass one after 20 mins, so I think I may have my PRGFLAGS set incorrectly.

Getting some pretty odd results from MEMSPEED, mind. Congratulations, you're about on a level with an 060 at 200MHz! ;)


NEMBENCH reports more reasonable figures (ST-RAM figures relative to a Falcon, IIRC):


OK, YAARTT had wrong flags set. Much quicker now it's running in TT-RAM. Up to pass three in just over a minute. Will leave it soak testing for an hour or so, which is the best I can manage tonight.

All this running from IDE under ETOS.

Good start!

BW

Badwolf wrote: 26 May 2025 22:48 Getting some pretty odd results from MEMSPEED, mind. Congratulations, you're about on a level with an 060 at 200MHz! ;)

Cool!! :lol:

Yeah no idea how that's the case... I'm tending to use TOS as it seems to be easier to spot RAM corruption.. But not seen any issues with current9..

The only odd thing is STram speed is 78% when running the CPU at 8mhz.. I was sure it was 99% before... So don't know what's normal or not currently..

exxos wrote: 26 May 2025 22:42 May not be a fair test though as it's likely not cache aware? I guess 306 would be the one to try...

yes and no :) In some aspects the Desktop has not changed significantly between 1.x and 2.x/3.x
I've just checked 2.06 and the Desktop behaves the same as 1.06.

Anyway it looks like the Desktop uses the same mechanism for cache and blitter:
https://github.com/th-otto/tos3x/blob/m ... top.c#L597

Tomorrow I'll check why BLITTER.ACC affects the "Options-->Cache" settings

Badwolf wrote: 26 May 2025 22:48 NEMBENCH reports more reasonable figures (ST-RAM figures relative to a Falcon, IIRC):

True, @dml 's Nembench is really accurate.

Cyprian wrote: 26 May 2025 23:13 Anyway it looks like the Desktop uses the same mechanism for cache and blitter:
https://github.com/th-otto/tos3x/blob/m ... top.c#L597

Yeah that's what I was playing with earlier. I took out a lot and I think it stopped working totally :)

Atari must have been a bit lazy in reusing the same menu item. The behaviour is just really weird.

@Badwolf I've been experimenting with slowing the CPU to 8Mhz and it doesn't seem like a good idea.

The problem is STram speed gets limited to 78% with data cache on. With it off, you can get 91%. So a "stock 8MHz STE" will be painfully slow.

Having the CPU run 50MHz when AS30 is high makes STram speed just tick over 100%. Caches are better used most likely.

TTram doesn't get found anyway in this setup.

Basically the only thing which could be really done is disabling TTram. Data cache should probably be turned off as well.

I've forgotten the problems you was having which led to all this investigation now though...

Badwolf wrote: 26 May 2025 22:48 OK, YAARTT had wrong flags set. Much quicker now it's running in TT-RAM. Up to pass three in just over a minute. Will leave it soak testing for an hour or so, which is the best I can manage tonight.

Ran YAARTT for just over an hour getting to test 4 of pass 10 without problem.

Obviously needs to be properly use tested, but very good signs in this configuration so far!

BW

Badwolf wrote: 27 May 2025 10:59 Ran YAARTT for just over an hour getting to test 4 of pass 10 without problem.
Obviously needs to be properly use tested, but very good signs in this configuration so far!

:thumbup:

Hopefully there will be light at the end of the tunnel soon......

exxos wrote: 27 May 2025 10:52 @Badwolf I've been experimenting with slowing the CPU to 8Mhz and it doesn't seem like a good idea.
The problem is STram speed gets limited to 78% with data cache on. With it off, you can get 91%. So a "stock 8MHz STE" will be painfully slow.
...
I've forgotten the problems you was having which led to all this investigation now though...

My particular request wasn't to switch down to 8MHz, but to have an ability to disable the caches and MMU that wasn't reliant on the OS being present (for bootloading games, basically. They'd work under 2.06 which didn't enable the caches, declare TT-RAM nor set up an MMU table, but would fail under ExxTOS and EmuTOS which do). Jumpering the CDIS and MMUDIS pins did seem to do the trick for the most part, but obviously would need switch(es) in the case. I was asking if these could be set by register such than a program could shut them off in hardware for the duration of power up.

An 8MHz option sounds like a good idea (if it could be made to work), but wasn't part of my request. I'd just like three bits of a register to en/disable MMU, Cache and TT-RAM (although the latter was found not to be invovled in my tests in the end). Perhaps reserve a fourth bit for a possible 8MHz mode if it could be made to work in the future?

Cheers,

BW