Basilisk II Atari

[agranlund]

Disc speed much improved, although still half the LCIII.

I think 1x is around what I would expect on my ST that has the same slow 8Mhz bus as the Mac Classic. The LCIII has either a 25 or 33Mhz bus I think?
It's close enough to that for me with Atari TOS in MiNT. EmuTOS in MiNT is a little less. Just EmuTOS itself is super slow.

The fastest on my machine is actually just plain TOS206 + HDDriver.
I don't know why but I'm thinking it must be because HDDrivers internal Gemdos cache? And it also being quite fast living in TT-RAM.
I get 2.5x the speed of Mac classic in that scenario with my IDE drive, which should be impossible if not for the cache. (I did bump the HDDriver cache size a bit from the default setting as well)

Would be interesting to see how the IDE drive would perform when connected to the 50Mhz bus of the TF536. Sadly I don't have any header pins on mine (won't fit under the keyboard) One of these days I'll build myself an adapter so I can fit the drive :)
MacOS does mostly a ton of tiny access's though so I think it'll still be hampered a little bit by whatever per-access latency Gemdos have.


(When I use raw access instead of disk images I get 0.983 regardless of Atari OS, which I guess makes sense as it's not hindered by filesystem latency, nor benefitting from any eventual filesystem cache)

Edit: Gemdos access times are indeed less than stellar. 3.1ms vs 0.4ms, almost 8x penalty going through the filesystem. On my IDE drive, according to this particular benchmark tool. My ASCI Ultrasatan fares even worse with 15ms vs 0.5ms access times.

Without a decent Gemdos cache it would be absolutely terrible to do many small reads.
My guess is that HDDriver has an excellent one, MiNT a decent one, and EmuTOS a pretty bad one. And I need to build some kind of good-enough cache into Basilisk at some point for when you run it with plain EmuTOS.

hdd.jpg

[czietz]

Without a decent Gemdos cache it would be absolutely terrible to do many small reads.
My guess is that HDDriver has an excellent one, MiNT a decent one, and EmuTOS a pretty bad one.

FTR: EmuTOS does not have a "bad" GEMDOS cache, but a small one - exactly the same as Atari TOS (without 3rd party SW such as HDDRIVER). In fact, you would see similarly low performance if you used Atari TOS with, e.g., AHDI. This is by design because otherwise you get users complaining about "wasted RAM". Of course, EmuTOS supports the standard interface to add more cache buffers to GEMDOS. Therefore you can use utilities such as Atari's CACHEXXX.PRG or any of the numerous third-party utilities that provide the same functionality.

[shoggoth77]

I love this thing, hence I'll be the annoying tester from now on.

The version you just published:
Emulated TT (Hatari), TT high, 14mb STRAM, <= 16MB TTRAM = ok.
Emulated TT (Harari), TT high, 14mb STRAM, >16MB TTRAM = black screen + freeze during startup.

Tested on:
- Latest EmuTOS release + current freemint + XaAES.
- NVDI 5.03

However:
- on plain EmuTOS + same NVDI version, it seems to be fine with TTRAM size > 16 megs.

[agranlund]

Without a decent Gemdos cache it would be absolutely terrible to do many small reads.
My guess is that HDDriver has an excellent one, MiNT a decent one, and EmuTOS a pretty bad one.

FTR: EmuTOS does not have a "bad" GEMDOS cache, but a small one - exactly the same as Atari TOS (without 3rd party SW such as HDDRIVER). In fact, you would see similarly low performance if you used Atari TOS with, e.g., AHDI. This is by design because otherwise you get users complaining about "wasted RAM". Of course, EmuTOS supports the standard interface to add more cache buffers to GEMDOS. Therefore you can use utilities such as Atari's CACHEXXX.PRG or any of the numerous third-party utilities that provide the same functionality.

Fair enough! Bad wording on my part and I apologise.
I do assume Atari TOS without HDDriver is probably similar to EmuTOS (I can't really test without it since then I won't have a HDD :))
Thanks for linking those cache utilities, I had no idea about them and will give them a try.

I boot EmuTOS by default on my ST and use it almost exclusively except for when I need to test code compatibility with Atari TOS.
Would love to be able to use Basilisk with disk-images from it and preferably without having to write some kind of cache myself - which isn't going to have the same knowledge as Gemdos anyway, and also, I'm not very good at that type of code either :)

[tin]

Thanks a lot for this new version (and for your work obviously).

I can happily report that this works fine on my 4/4 TT with HDDriver+ACSI CE in TT high (as did the previous one). Aditionally it does work in ST high, too.

It might be my lack of coffee, but it seems to be a tad slower - with only 4MB only a few apps do actually start, so I can't do a benchmark unfortunately.

[agranlund]

Thanks a lot for this new version (and for your work obviously).
I can happily report that this works fine on my 4/4 TT with HDDriver+ACSI CE in TT high (as did the previous one). Aditionally it does work in ST high, too.
It might be my lack of coffee, but it seems to be a tad slower - with only 4MB only a few apps do actually start, so I can't do a benchmark unfortunately.

Nice thanks! :)
It is indeed a tad slower. For now, it's playing it more safe and doing some things that are probably not entirely necessary.
I figured it's better to optimise it further later when more things are working correctly.

The whole thing is already a bit like balancing on a knife's edge.. just barely, sometimes, in the drivers seat while Apple code is "free running" on the CPU and takes us wherever it wants to :lol:

[stephen_usher]

On my TT (under TOS 3.06 + HDDriver 10.10) it crashes the machine after printing the two Mac ROM messages (with logging screen).

P.S. It's the same under EmuTOS.

[agranlund]

Speedometer CPU score on Falcon CT60: 48x
That’s a pretty fast ”Jackintosh”

Still early days, and some issue to work out, but we’re getting there slowly but surely :)

[Badwolf]

Hi Anders!

Thanks for the update. :)

Here are some results from the latest version. Mixed, I'm afraid. All figures from a 50MHz Falcon with 64MB TTRAM in 640x480 mono using the onboard IDE. HDDriver 11 is used under TOS.

Positives: FPU now recognised under TOS4.04. MiNT disc access speeds are up from ~1.3x to 1.9x.

Negatives: everything is slower without MiNT.

The mouse stutters during disc access and disc benchmarks are roughly half their previous figure:

• EmuTOS disc access has got slower still down from around 0.3x to 0.15x.
• TOS (HDDriver) disc access has also regressed. Down to 0.45x from ~0.75x.

Playing with the cache size in HDDriver has no effect. Using CACHE100.PRG in the auto folder has no effect.

BW

[agranlund]

Negatives: everything is slower without MiNT.
The mouse stutters during disc access and disc benchmarks are roughly half their previous figure:

• EmuTOS disc access has got slower still down from around 0.3x to 0.15x.
• TOS (HDDriver) disc access has also regressed. Down to 0.45x from ~0.75x.

Playing with the cache size in HDDriver has no effect. Using CACHE100.PRG in the auto folder has no effect.
BW

Thanks for the report! This is super valuable :)

It's playing it more safe now, overall it's maybe a bit much but I think it might be better to go that route and optimise rather than the opposite way around.
Mac side Input/Graphics taking a break when doing tos stuff is a part of that and it will cause that mouse stutter when doing disk access through plain Atari TOS - do you get the same even in EmuTOS (or any TOS + Mint or Magic?)
"irqsafe -1" should make it choose based on OS, 0 means off, 1..2 are some safety settings. (-1 should pick 2 for plain Atari TOS, 0 for everything else if nothing is bugged :))
I am meaning to revisit this and try to get it solved for Atari TOS as well.

The previous version may have made the disk score off in previous versions as well.
Speedometer appears to be using the MacOS internal vbl counter variable to calculate the score, and that variable would tick less in during tos access before - giving you a higher calculated score from Speedometer.

With the disclaimer that there could still be bugs or some logical flaw, I believe the score should be more accurate now compared to what Speedometer would report in previous builds.


Another change from previous builds is that it is respecting the cache setting that you had in TOS (for when the emulator is accessing TOS -- MacOS is still in charge of the cache setting while in Mac mode).
Having data+instruction caches disabled in TOS will now likely effect disk speed negatively.