Basilisk II Atari

[agranlund]

Thanks for the report!
I uploaded a new version. There's not a ton of feature changes, mainly just these:

• Sound can play during TOS access (it would skip horribly during disk access before)

• The input handler is better at preventing IKBD overflow from happening, and if it does happen it is now better at recovering from it without completely freaking out.
  (Warcraft is playable without loosing the mouse button all the time. The keyboard should no longer go nuts and start sending false keypresses if the mouse is moved a lot during disk access etc)

• By default, Mac interrupts are now allowed to happen during TOS mode.
  Previously, this was only a thing if you were using EmuTOS, MagiC or MiNT which is why you'd get mouse stutters on disk access with normal Atari TOS.
  It seems ok on my machine and in Hatari but if this is causing issues you can disable it with "irqsafe true" or in the new Debug menu option in the GUI.
  I'd be interested to hear if it's all-ok.. looking nervously at @stephen_usher 's TT which I think hates me :lol:

I thought fixing Restart would be a quick thing but it turned out to be much more than I expected so as a temporary measure it's just going to shut down instead. I figure it's better than an uncontrolled crash at least.

I wasn't aware of the issues when quitting the GUI. I'll see if it's something I can reproduce. Thanks for making me aware :)

[agranlund]

Oh yeah and about sound.
The aim is to support SoundManager 3.x just like BasiliskII for PC.
At the moment, there are problems when SoundManager3.2.1 or later is used but I hope to get that fixed.
What this means in practice:

System 7.0:
Is using an earlier sound system.
Install QuickTime 2.1 + SoundManager 3.1 for sound to work.

System 7.1:
Install system update 3
(Or QuickTime 2.1 + SoundManager 3.1)

System 7.5:
Has SoundManager 3.2 built in and works out of the box.

MacOS 8.x:
Has SoundManager 3.2.1 built in. Does not work (yet).

I found QuickTime 2.1 and SoundManager 3.1 available as separate installers on some Mac software sites.

QuickTime 2.5 (or later) will install SoundManager 3.2.1 (or later) and that will stop sound from working.
If you need to install such version for some reason then you could try and downgrade the SoundManager that QT installs to 3.1.
(I've only tested this with QT2.5, and downgraded SM to 3.1)

System 7.0/7.1 will always need some kind of update for sound to work (same as when using the PC version of BasiliskII), but I hope to solve the Atari specific issue with SoundManager3.2.1+ so that it will "just work" on MacOS8 and/or if you have more recent versions of QuickTime installed.

[stephen_usher]

Well, it works, but booting into MacOS is far slower.

All the benchmarks except integer arithmetic are slightly lower:

IMG_2665.jpg

Sound works.

"Restart" causes the TT to reset and enter a strange ST-Low mode with HDDriver knowing it's there but not working. To get an operating machine I have to use Ctrl-Alt-Shift-Del to do a hard reset.

[Steve]

@agranlund I was just thinking 'out of the box' a little and was thinking that your project could be used to create a kind of MacOS application 'wrapper'. Kind of like Wine/Cider, but for TOS/MiNT?.

Would be kind of cool to be able to just double click a program, for instance 'Mac_Civ2.prg' and it loads the game into Tos/MiNT kind of seamlessly, like the game is actually an Atari game.

I don't know whether it would be best to include the 'backend' as installable on the hard disk, or somehow package everything into a single PRG. Probably has to have the backend on the hard disk to avoid packaging Apple code inside distributable games etc etc. Anyway, I like this idea a lot.

[stephen_usher]

This wouldn't work well. Other than the fact that Mac programs aren't self-contained and rely upon a deep and large set of libraries for almost everything the FAT and HFS/HFS+ filesystems don't map in their capabilities at all well. Each file itself is actually two files, the data fork and resource fork, then you have the linking and other advanced features. Remember that FAT is a slightly modified version of the mid-70s CP/M filesystem and extremely rudimentary. HFS is two or three generations later.

[Steve]

This wouldn't work well. Other than the fact that Mac programs aren't self-contained and rely upon a deep and large set of libraries for almost everything the FAT and HFS/HFS+ filesystems don't map in their capabilities at all well. Each file itself is actually two files, the data fork and resource fork, then you have the linking and other advanced features. Remember that FAT is a slightly modified version of the mid-70s CP/M filesystem and extremely rudimentary. HFS is two or three generations later.

Maybe I'm not explaining myself properly, I understand everything you're saying don't get me wrong. Perhaps a good analogy is using the MacOSX OS9 'Classic' emulation. They had a fully working installation of OS9 that could be opened as either a full system either windowed or full screen - or - which is what I am proposing - it would load the system arbitrarily in the background and just render a specific app from within the OS9 instance into the OSX GUI, with a few visual queues to know you were running an OS9 app.

I am proposing a similar thing but with the Baselisk II Atari system. The OS part is already there, you just need a way to fork/output the windows into a basic GDI interface, maybe the emulator creates a frame-buffer from within the Apps physical window dimensions and then the TOS part displays it within the same area? I don't know.

[stephen_usher]

I see. Well, that used re-implemented MacOS libraries underneath the applications to re-implement the MacOS system as a shim so as to render them under NeXTstep (which is what early MacOS X is) using the Carbon interfaces, which closely match the MacOS ones, so it's almost trivial to translate them. Something similar was done for AU/X, Apple's UNIX.

Basilisk is merely doing hardware translation, which is at a far lower level.

[agranlund]

At first I thought you were proposing something exactly like Wine.
Or, in fact, Executor which runs System6 apps natively on x86 based operating systems.
My reply was going to be that I'm sure it's possible.. anything is.. but that it would be a tremendous amount of work for someone to reverse engineer and re-implement all MacOS system calls.
The good thing about Mac applications is that they use system calls for everything and never touch hardware directly.

But as you explained more I think it start to fall at least a bit closer into the realm of possible (not by me, but maybe by someone else?).
Kind of like Parallels Desktop?
That one runs the entire emulation and OS, but in "coherence mode" it will put the graphics of each running Windows app inside an OSX window.
(I can't claim I know how it does it but I suspect it's maybe one of those Windows helper programs that you install that does the Windows-side stuff and talks to Parallels Desktop which does the Host side stuff.. maybe..?)


There is another thing though. BasiliskII for Atari cannot multitask. At least not the way it works right now.
On Atari, it actually has more in common with Shapeshifter than BasiliskII in the way it does native code execution.

In a nutshell, it lets MacOS runs free in real supervisor mode as opposed to being 100% isolated inside an emulated supervisor environment that is actually usermode.

The benefit is speed. There is almost no extra overhead for MacOS system calls.
The drawback is less control and making some problems slightly more complex to solve.

I started with that approach as an experiment and thought that if it doesn't work out then I'll just do the safe-proper-but-slightly-slower route instead.
So far I've been happy with it but you never know.

[agranlund]

I feel this is more than adequate. ;)

That does indeed look adequate :)

I was meaning to ask, and I apologise in advance if this is a really stupid question..
Is 640x400 in True Color something that is actually usable on Falcon?

I have never used, or even seen, a real one so I'm mostly concerned if "Interlace On" is something that cause a flickering mess, doesn't work on certain output modes, or generally have other drawbacks that makes one not wanting to use it?

falcon_video.jpg

The reason I'm asking is that I'm adding an option to run MacOS in 256 color, through Falcon TrueColor mode.
Translating the video is of course a lot slower compared to doing nothing at all so there will be some frameskip option and whatnot.
Maybe later down the line something a bit more clever to update the area around the mouse more often like was suggested earlier in the thread.
I guess I could also add an option for running MacOS in 16bit color, translating to Falcon 16bit format, while at it.


Oh, and on the same topic. I recall hearing something about custom resolutions on the Falcon somehow?
Is that with hardware modifications or can you do it with just software tools?

The reason :)

war.jpg

Because I need to be able to debug 256 color stuff in Hatari I'll make it possible to use a virtual 640x480 with line-skips so it fits inside 640x400, but I was curious if a real Falcon can be set to that resolution using some other magic tools than the one built into TOS?

[Steve]

Because I need to be able to debug 256 color stuff in Hatari I'll make it possible to use a virtual 640x480 with line-skips so it fits inside 640x400, but I was curious if a real Falcon can be set to that resolution using some other magic tools than the one built into TOS?

Yes I'm pretty sure with a tool like Videlity or Centscreen (I've used both) You can get 640x480x256 easily. In fact on a stock Falcon I think even 800x600x256 is possible with these tools. I'm not 100% sure but I'm think that I've seen a tool like these (maybe these ones also offer developer tools) which is designed to be a tool for devs who want to include custom Falcon resolutions in their programs .. but you might need to ask on atari-forum I cannot remember what it was called, but I'm sure I read about it!!! :)