Basilisk II Atari

[stephen_usher]

If it has the happy Mac icon then it's starting to read the disk image and trying to boot from it.

[agranlund]

I should be able to fire up my H4 + TF536 and maybe the Falcon (no CT60 I'm afraid).
Hoping to test other Atari stuff over the weekend as well, so will probably be a brief try at this point.
Will report back with my findings!

I should be able to fire up my H4 + TF536 and maybe the Falcon (no CT60 I'm afraid).
Hoping to test other Atari stuff over the weekend as well, so will probably be a brief try at this point.
Will report back with my findings!

Cool! You may be able to run it in Falcon 16bit mode, if you can get a resonable resolution in interlaced or something.
No games support 16bit mode though and colors are going to be wrong so I'm really sure what the point would be
(Falcon Videl 16bit is RGB565 while Mac use RGB555).

Mac OS7.5 might be on the heavy side for a 16Mhz machine.
It's a quite a jump from 7.0 in terms of cpu, disk and memory usage. But then again, it's also more modern.
Still, it would be interesting to hear if/how it works on a Falcon

Maybe I should make a small 7.0 disk image, it's useful for myself for testing as well I think.
OS8 is a larger jump still, officially dropping support for 68030 CPU's but can be hacked to make it boot on those.
But yeah, even a 50Mhz 68030 is borderline too slow for OS8.

[agranlund]

Running this on my CT60 Falcon, in 68030 mode I very briefly get a happy Mac icon, then the question mark floppy icon. The inf file does appear to be pointing to the correct rom and disk image, but there may still be something I'm doing wrong.

Happy Mac means it did find the disk, question mark later means it doesn't find a bootable disk.
Usually means a disk is not "blessed" by the almighty Fruit, which is odd since the disk is bootable here on Atari and PC Basilisk.
(Sometimes, when not being shut down correctly, or XPRAM is not matching for whatever reason, a disk may loose its "blessed" status and you have to rebless it by booting from another disk, then use some boot disk selection tool or drag-and-drop finder back and forth etc etc...)
In Basilisk, you can nuke xpram by deleting the xpram file (if it exists).
However, I don't really think that is the problem here if you just tried to launch it and that's what happened first thing..

However, I'm sure you're more interested in 68060 mode, where I'm afraid I get the following right after launching BASILISK.PRG:
If it matters, this is regular TOS 4.04, CT60e BIOS 1.03e, no AUTO folder programs, no ACCs.

Yep
It looks like it's dying very early on but I can't pinpoint exactly where.
Now kicking myself for not having logging enabled in that build

Hatari patches TOS4.04 when running on '040 and '060, as I'm sure CT60 Bios must be doing as well.
Are you able to check the _CPU cookie somehow on your machine? Either with sysinfo (if that works on 060) or some control panel extension such as "System Info" or "Cookies"?

Basilisk is using that cookie to determine if it should run 020-030 or 040-060 specific init code.
Hatari patches TOS 4.04 to make the cookie say "60" (0x0000003C), maybe there's chance CT60 bios isn't?
It's on some todo list to have Basilisk determine the CPU type itself instead of relying on TOS.

(It doesn't have to be this that is the problem, it could very well be something else, but if an 060 ends up in the 030 init code it would for sure trigger an Illegal instruction. From your screenshot it looks like it's crashing before that point though )


I have no idea if the CT60 bios freaks out if you launched EmuTOS, nor if EmuTOS works on the CT60 even though it supports the 68060 CPU, but "emutos-prg-1.1.1.zip" allows you to launch EmuTOS from AtariTOS like any other program.
I don't know if that would help make it work or not, but if you have plenty of time and nothing to do...
https://sourceforge.net/projects/emutos ... tos/1.1.1/

[derkom]

Hatari patches TOS4.04 when running on '040 and '060, as I'm sure CT60 Bios must be doing as well.
Are you able to check the _CPU cookie somehow on your machine? [...]

Hatari patches TOS 4.04 to make the cookie say "60" (0x0000003C), maybe there's chance CT60 bios isn't?

_CPU cookie is set to 3C in both TOS 4.04 and EmuTOS. Basilisk fails silently in EmuTOS, which surprises me, since EmuTOS is generally speaking more verbose about errors.

I'm happy to run a logging build if you want me to explore further.

[stephen_usher]

OK, on my TT I have the following:

If I use a relative path for either a disk or floppy image then I get two bombs (HDDriver 10).
If I use an absolute path it seems to act as if it can't find the file.

I've tried the Disk Utilities floppy image from the Basilisk Wiki to do this as it'll fit on my partition (which is on an internal SCSI disk).

P.S. Tried a basic System 7 boot floppy image and it's the same.

[stephen_usher]

It couldn't find the file because I was stupid and put the wrong drive letter.

Two bombs whenever a disk or floppy image is specified.

[agranlund]

I'm happy to run a logging build if you want me to explore further.

Thank you, that's great!
I'll make one tomorrow if I get a chance, or later in the week.

That'll help narrow down where it dies, not just for the CT60 but possibly other hardware/tos configurations which aren't like mine. Makes you wish you bought a Falcon (and TT) while they where still somewhat "cheap"

On a positive note, Warcraft1 is now finally running at the correct speed

[derkom]

I'll make one tomorrow if I get a chance, or later in the week.

Not to rush you (okay, somewhat to rush you), but starting on 9 March, I won't have access to my Falcon again until late April, due to travels. I'm happy to try out any test builds between now and the 9th, but after that it'll have to be someone else, or a long wait.

[stephen_usher]

I'm happy to debug on my TT.

[agranlund]

Not to rush you (okay, somewhat to rush you), but starting on 9 March, I won't have access to my Falcon again until late April, due to travels. I'm happy to try out any test builds between now and the 9th, but after that it'll have to be someone else, or a long wait.

In that case, I'll try to make something happen tomorrow
To be honest, a long wait is probably fine too. There's so much else missing at the moment anyway, sound in particular is causing a ton of issues.
There's no proper sound code at the moment. "nosound false" in the .INF file just adds a dummy hardware for those games that refuse to run without it - but it also cause some other games to lock up requiring you to toggle it to true.