Basilisk II Atari

[derkom]

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

Damn, you would get that working right after I lose access to my Falcon for a while. ;-)

Great work so far. I'm looking forward to more testing once my Falcon and I are reunited.

[Badwolf]

Anders, one other data point for you. I've only just figured it out as it doesn't appear to happen *every* time:

The combination of an FPU, TTRAM and memory protection on in MiNT causes a bus error immediately on launch on the vast majority of occasions, but not seemingly always (!).

Disabling the FPU (in the case of Hatari), disabling memory protection or TTRAM (in the case of both Hatari and my Falcon) causes the program to run as normal much more reliably.

I have seen it run in this configuration without the bus error -- after all I was able to get that disc access figure of 1.9x -- but it's quite rare. I had reached the point of looking for my YAARTT disc as turning off AltRAM cured the problem. I thought DFB1 was failing :shock:

Now, I don't know if having memory protection on is sensible or feasible for a low-level emulator like this, but it's an odd enough corner case I thought I'd mention it. :)

BW

[agranlund]

Anders, one other data point for you. I've only just figured it out as it doesn't appear to happen *every* time:
The combination of an FPU, TTRAM and memory protection on in MiNT causes a bus error immediately on launch on the vast majority of occasions, but not seemingly always (!).

Now, I don't know if having memory protection on is sensible or feasible for a low-level emulator like this, but it's an odd enough corner case I thought I'd mention it. :)

Thanks! That's great.
As I was testing a bunch of different TOS and MMU configurations I am getting some "random" oddness too which I haven't yet been able to pinpoint.
I'm getting a hang in Speedometer right after the GFX test if I use the IISI rom but not with the LCIII rom. But only on my actual machine, it's fine in Hatari.
At first I thought it may just be that the 1024k LCIII rom is more compatible but putting the 512k IISI rom in a 1024k buffer also gets rid of the hang.. I'm now suspecting I have a "random" memory overwrite bug somewhere... hurray!


I haven't actually tried with MiNT in memory protection mode, I should really do that
Memory protection shouldn't cause issues in theory, but who knows in practice..
All memory is allocated upfront using TOS, and then the MMU gets completely reconfigured for Mac (temporarily restored when calling into TOS, for disk access etc)

If the issue you describe can be reproed in Hatari then that's awesome since I don't have an FPU in the real machine, and debugging in Hatari is so much better anyway.

[agranlund]

I started writing a simple disk cache and began measuring time from startup to reaching MacOS desktop.

And as I was doing this I realised why I am getting quite good speed with TOS206/HDDriver.
It's being helped quite a bit by maprom.prg
That program maps ROM into TT-RAM of course, but it also remaps parts of low ST-RAM into TT-RAM (similar to MuMapZero on Amiga)
It's able to map more TOS206 memory compared to EmuTOS simply because it's no longer a moving target.

Even though it's possible I'm not sure I want to make Basilisk modify the TOS side MMU config to do something similar to maprom.
I don't really think it's within the mandate for Basilisk to mess with that. It sets up the MMU in a certain way for the Mac side of course but when it calls into TOS it switches to whatever config the user had for TOS.

On IDE (on the ST bus), I get these times from program start to entering the Mac desktop. ASCI seems a tad slower.

TOS206: 40s (disk cache makes no difference)
EmuTOS: 2m 30s (1m 10s with disk cache)

And since I now realise that's maybe not the normal case, I'm getting these numbers when TOS is in ROM (or ST-RAM) and zeropage in ST-RAM just like default:

TOS206: 1m 50s (1m 00s with disk cache)
EmuTOS: 5m 10s (2m 14s with disk cache)

And here I thought 40 seconds was too long.. over 5 minutes is a bit over the top.

The disk cache, even though very simple, does halve the boot time in most cases. Maybe in part because it avoids having to call into TOS and that dreadful 8Mhz.
This may also explain why MiNT makes everything faster, it being in TT-RAM and all. That, plus different Gemdos caching algorithms.

I think I'll keep plucking away at that disk cache some more. Would be nice for disk images to be decent or at least usable in case you don't want to make a dedicated partition for Mac stuff.

[stephen_usher]

With respect to a disk cache you really could do with parsing the HFS(+) filesystem, finding the System folder and then caching that as much as possible and locking it into memory as MacOS reads the system file and extensions constantly as that's the shared library which all applications will use.

With respect to MiNT and memory protection, remember that you don't have control of the system, so changing the MMU will break things as you never know when you're going to be pre-empted and another process run instead. Just restoring it before a system call won't work.

With regards to sometimes crashing and sometimes not with memory protection on probably means that you're using an uninitialised pointer somewhere which happens to point somewhere benign sometimes and other time not. Or you're running over the end of an array.

P.S. Any idea as to why a large amount of memory causes it to crash?

[stephen_usher]

Anders, are you making assumptions about the use of TT-RAM?

I just disabled the TT-RAM flags (and fastload) on basilisk.prg and from the debug log it's STILL detecting and seemingly using TT-RAM!

Are you using your own memory allocation routines?

HDDriver uses TT-RAM for itself and if you're not using the OS to allocate memory then VeryBadThings(tm) will happen. This would especially be true under MiNT or any other pre-emptive multitasking operating system.

[stephen_usher]

With fastload turned off and no disk file set I can get as far as the flashing question mark floppy, before the machine hangs after about 20 seconds.

I think that as soon as it's trying to access the disk it's crashing HDDriver and locking the system.

The program must be doing something incredibly hacky.

[Badwolf]

If the issue you describe can be reproed in Hatari then that's awesome since I don't have an FPU in the real machine, and debugging in Hatari is so much better anyway.

Hi Anders,

Here's a packaged up example that exhibits the problem and can be worked around by removing TTRAM, memory protection or the FPU.

Just launch Hatari in the extracted directory with /path/to/hatari -c anders.cfg

https://www.dropbox.com/s/1evb39cnx53at ... .tbz?raw=1

A little bit meta -- disc images inside disc images, emulators within emulators. :?

BW

[agranlund]

Anders, are you making assumptions about the use of TT-RAM?
HDDriver uses TT-RAM for itself and if you're not using the OS to allocate memory then VeryBadThings(tm) will happen. This would especially be true under MiNT or any other pre-emptive multitasking operating system.

I think we're way past the point of VeryBadThings(tm) :)

This thing is doing all kinds of things that isn't compatible with TOS.
It's keeping TOS on a pretty strict leash, alive but dormant. The main reason it's being kept around is to avoid having to write hard disk drivers from scratch. I'm sure we're going to find other uses for it but that's what we use it for now.
The emulator enters a somewhat TOS compatible context whenever it needs to call TOS for anything but for the most part it's a bit of its own thing.
Having both Tos and Mac around at the same time does complicate matters since they both lay claim to some of the same resources but the alternative is much worse.

MiNT's multitasking doesn't really stand a chance. I don't think it does it for supervisor programs, but even if it wanted to it really can't, it only has as much (temporary) control over the machine as we allow it to.
It doesn't even matter if it changes any vectors. Tos assumes, just the MacOS do, that the CPU VBR is at the default location 0.
We've moved it though. So the CPU jumps to our table and we decide if we want to dispatch to Tos or Mac's virtualised tables, or do something completely different, as we see fit.
It's memory protection is only active when we are in tos context, the rest of the time the MMU is reconfigured specifically for the emulator.

At its core the "emulator" is just a little bit of oddball setup code before it jumps into the Mac ROM and we lose control over the "main loop".
Past that point we're just a glorified exception and interrupt handler :)

It's not really an emulator as such. It's "free running" Apple code directly on the machine while we try to grab control where we can - mostly in exceptions and interrupts but also by patching the Macintosh ROM to call our code.
At the same time prevent MacOS and TOS from fighting since they both are laying claim to some of the same resources and logical memory regions.


...But the memory is actually completely normal :)
It's just a normal Mxalloc() TOS call with flag 3 (Allocate either, Alternative-RAM preferred)
I could change it to Malloc() to not specify a preferred pool and thus let it be completely up to the program flags.

The program must be doing something incredibly hacky.

Yes, that's an understatement of the year :)

The OS calls are normal Fread() so that's nothing weird..
How we get to the point from a Mac->Atari in order to do so and then back to to Mac is though..
We do tick the virtualised 200hz counter for TOS's and HDDrivers convenience though, since it's not being allowed to process it's own timer-C interrupt :)

[agranlund]

[Here's a packaged up example that exhibits the problem and can be worked around by removing TTRAM, memory protection or the FPU.

Thank you so much! I was trying to repro the issue on my ST but couldn't get it to happen since I don't have an FPU.
My best-guess has been that I'm maybe not handling one of the FPU exceptions correctly or at all, possibly sending it into TOS code while the machine is configured for Mac.

Being able to debug it in Hatari is surely going to help :)