exxos's Atari, Amiga & retro forum

Sound was always a problem on Mac emulators.

I remember Dave Small talking about it for Spectre. He only got sound working for System 6.0.5 up to 6.0.7. 6.0.8 broke things again. The emulators have to emulate the dual oddball Sony sound chips.

stephen_usher wrote: 05 Mar 2022 20:45 I'm happy to debug on my TT.

Cheers Stephen!
Some logs might be helpful even for the TT issue.
Based on what you describe it sounds like it's past the emulator init and is executing the Mac ROM.
I might have to make some additional "heavy debug" option or similar to catch what is going on there.

I'm assuming your disk is attached to the TT SCSI port? I'm not really betting on it, but I'm hoping I might be able to repro your issue in Hatari by running off a SCSI disk image and using HDDriver.

stephen_usher wrote: 05 Mar 2022 21:14 Sound was always a problem on Mac emulators.

Yeah, sound emulation is pretty bad even on the PC version of BasiliskII :/
I'll settle for it at least working.
Or as a very minimum first step, having the dummy sound driver at least working in the sense that a bunch of games aren't locking up when accessing it :)

agranlund wrote: 05 Mar 2022 21:22

stephen_usher wrote: 05 Mar 2022 20:45 I'm happy to debug on my TT.

Cheers Stephen!
Some logs might be helpful even for the TT issue.
Based on what you describe it sounds like it's past the emulator init and is executing the Mac ROM.
I might have to make some additional "heavy debug" option or similar to catch what is going on there.

I'm assuming your disk is attached to the TT SCSI port? I'm not really betting on it, but I'm hoping I might be able to repro your issue in Hatari by running off a SCSI disk image and using HDDriver.

I tried both on the SCSI drive and later on the UltraSATAN and it had the same problem. The bombs happen before the Mac rounded corners appear when it's still showing the GEM title bar. It's almost seems as soon as it tries to access the file for the first time to check that it's there.

@derkom , @stephen_usher

There is a new version with some debug info enabled if you want to give it a go.
You'll need to open basilisk.inf and add one of these lines depending on your preference.
logging file
logging serial
logging screen

file will write to a file called basilisk.log
serial is 307200 baud, 8 bits, no parity, 1 stop bit
screen writes directly on the screen

OK, I'll have a look at it later.

OK. Just tried it.

On the SCSI drive: Doesn't create a log file hard crashes the machine with black screen and only power cycle will recover.
On UltraSATAN (ACSI): Crashes with two bombs (no log file) and subsequent access to hard disk crashes the machine with multiple bombs.

The is HDDriver 10.10 loaded into TT-RAM.

I'm guessing that the program is overwriting HDDriver.

P.S. Actually it only stops HDDriver from accessing the SCSI drive. Doing so crashes the machine with a black screen and no sync. Reset sometimes gets it back but sometimes it's only power cycling.
P.P.S. Doesn't write any debugging to screen either, so whatever it's doing is causing a crash before it prints the first debug message.

stephen_usher wrote: 06 Mar 2022 20:40 On the SCSI drive: Doesn't create a log file hard crashes the machine with black screen and only power cycle will recover.

I'm getting exactly this behaviour in 68030 mode now, with disk logging enabled, or with logging disabled for that matter. No happy Mac, no question mark floppy.

In 68060 mode, I'm getting the following error, no logfile created, no screen logging:

The solution is simple.. y'all need to get yourselves 520ST's, everything seems to work on these machines :lol:

In all seriousness though, thanks for giving it a go!
I'll try to work it out with some special build for you @stephen_usher if you don't mind? If you have time later on in the week or next weekend or so? I can PM you.
I'm guessing it might be somehow file or standard output, related. Or extremely early init.
It's using the 3rd party libcmini rather than the humongous libc that comes with the compiler - might be a good idea to test building against the normal libc to at least rule that out.

I can test at any time.

Fantastic work, Anders!

Just gave it a quick boot test on my Falcon (50MHz DFB1r4/64MB TTRAM+FPU).

Firstly, booting from TOS4.04 in two colour mode (RGB 640x400) with NVDI installed I get a bit of odd screen corruption. I wonder if this is related to the videl initialisation bug in TOS4.04 in two colour modes?

Also it didn't seem to pick up the FPU:-



Firing up a PRG version of EmuTOS and skipping NVDI produces a properly formatted screen and highlights that the Mac expects the border to be black. ;)



I haven't yet tried true colour. 256 colour mode didn't work: unsupported video mode reported.

I wish I had a bit more time to play with this today, but so far so excellent. :-)

BW