Basilisk II Atari

[stephen_usher]

I have success:

Original basilisk.prg binary.
EmuTOS 1.1.1
Running from ACSI
Using a hard disk image.

It's *very* slow but it's booting.

[stephen_usher]

Well, here it is:

IMG_2604.jpg

As you can see from the benchmarks, disk access is 1/10th that of a Mac Classic! Otherwise the TT is close to an LCIII.

IMG_2605.jpg

[stephen_usher]

Typing quickly will cause the system to lock up.

[shoggoth77]

Looks like a disk cache in Basilisk could help a bit, I guess the context switching required to keep TOS + hard disk drivers happy impose quite a bit of overhead.

[stephen_usher]

The disk light is going on for a couple of seconds and then off for a couple of seconds etc.

[Badwolf]

Well, here it is:

...merry christmas!

:cheer:

BW

[Badwolf]

A few more data points:-

Disk speeds are quite up and down. EmuTOS allows FPU to be recognised but disk speeds vary between about 0.35 and 0.25x Mac Classic. I may be wrong, but it seems that moving the mouse during boot up speeds the disc loading as I eyeball the disc LED. Is this possible, Anders?

TOS4, no FPU, but disc speed better at around 0.7x.

MiNT really kicks things into gear, though. TOS4+MiNT, I get disc figures around 1.3x and the FPU is recognised.

EmuTOS+MiNT, the disc access is similar, around 1.3x, but I experience my first lock up when rendering the results graph of the tests.

All tests with 50MHz 030 + 25MHz FPU and 64MB TT RAM running from Falcon IDE.

BW

TOS+MiNT (left), plain TOS (right)

TOS+MINT vs TOS.jpeg

EmuTOS+MiNT (left). Hang on drawing the graphs.

EmuTOS+MiNT_hang.jpeg

[agranlund]

Yes, disk images are insanely slow under EmuTos, to the point of almost unusable.
Not sure yet what it’s spending its time on really.

They are very quick under Atari TOS, at least with HDDriver, so as much as it pains me, I’d recommend Atari Tos over EmuTOS for Basilisk at this moment.
(But not with that test build I uploaded on my website, and then took down again. That one is just too broken)

I’m preparing to upload a new one in a day or so.
(I found why the FPU was not detected under AtariTos so it’s been fixed too, thanks for reporting it @Badwolf :) )

MacOS does a lot of mostly individual 512 byte reads and I am thinking it’s maybe tos filesystem latency that kills it, but I’m not entirely sure.
I made a very simple disk cache option as a test and it helps a little but it’s something I’d need to develop further.

The raw device option is fast under EmuTos, about the same speed as when using disk images in Atari TOS.
That option access the drive directly bypassing the tos filesystem code completely, but I don’t think it’s ready to be enabled for prime time yet. Disk images are for sure much safer :)

[agranlund]

I may be wrong, but it seems that moving the mouse during boot up speeds the disc loading as I eyeball the disc LED. Is this possible, Anders?

No you may be right actually..
I’ve only had a chance to take a very quick glance at the EmuTOS code, so I can be completely wrong, but it looked like it’s maybe halting the CPU until an interrupt occurs in certain circumstances.
Moving the mouse would trigger interrupts and wake the CPU as the IKBD sends new mouse data.

I haven’t had time to try it yet but I was meaning to build an EmuTos with that disabled just to rule out if that’s at all related to the issue or not.

[agranlund]

A fast (but perhaps not that pretty) alternative to C2P conversion in 8bpp chunky mode, is to set e.g. a 320x480 16bpp mode and pretend that it's actually 640x480x8bpp. It won't look right, but it will provide some degree of usability at no cost at all (one could have a hotkey to switch between fast+ugly and slow+pretty).
EDIT: I ran this thing on my own NVDI drivers (hence the faked 8bpp chunky mode), on XaAES/FreeMiNT. I didn't expect that to work.

That is a great idea and I'm definitely going to try that. Thank you so much! :yay:
I don't need it to be pretty, just visible enough so I can launch a troublesome 256-color game and get into the Hatari debugger :)