Basilisk II Atari

[shoggoth77]

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?

640x400x16bpp is available on TV/RGB on stock Falcons. On VGA, it isn't, because of bus bandwidth.

However. Resolutions aren't fixed on Falcons, i.e. there are utilities that allows much larger resolutions than those offered by TOS (at the expense of vertical frequency, or having to use interlace etc). Some accelerators speed up the bus to 25MHz, allowing 640x480x16bpp or even higher on VGA.

About drawbacks - a 16MHz 68030 on a 16-bit bus struggles quite a bit with the sheer amount of data that needs pushing around in the modes in question.

On an accelerated machines (040, 060, in this case), it is faster to use a copyspeed C2P algorithm (I'd use the one by Kalms/MiKRO) to emulate 8bpp modes. It doesn't sound counter intuitive but instructions are scheduled in a way that cause the bus to be the limiting factor rather than the horrible algorithm itself. On a 030, this is probably not true however.

I'd say do what you've done so far; use what you get. Whatever that is.

[shoggoth77]

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?

No need for line skips. Either "just" extend the vertical border (it is "just" a matter of reprogramming a few hardware registers) or start Basilisk with a modecode with the OVERSCAN-flag enabled. Or require VGA.

[mikro]

The tool is (among others) Screenspain: http://files.dhs.nu/files_coding/scrnpain.zip

However I'm a little confused why do you need it for 640x480@256c, that's a standard Falcon resolution - double lines off, 80 columns (on VGA, that is).

[mikro]

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?

The drawback is that it is RGB only and terribly slow. ;) So I'd leave it out, better support SuperVidel's video modes then (256c chunky mode, high resolutions with 32-bit colour depth etc).

[stephen_usher]

What people forget here is that colour modes on classic Macs WERE slow as there was no accelleration, though the VRAM was slightly faster.

A video driver for the Atari display would be no slower but would need to be written to control the hardware, such as changing resolutions. It would need someone who knew how to write System 7 device drivers though.

With regard to graphics resolutions, @agranlund, seeing as Basilisk is taking over the whole display it could save the information about the mode the program was started in and then switch to an appropriate mode to boot into. e.g. always attempting to switch to an apropriate modes, say ST-HIGH, and later let the MacOS driver change to a new one if the NVRAM says to use it. When Basilisk quits it can restore the video mode back so tat GEM doesn't get confused.

[shoggoth77]

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.

I beg to differ, respectfully! Preload a small dedicated HFS-disk in RAM, run stuff from there in some auto-starting fashion. It doesn't have to be more sophisticated than that to be useful for stuff like games.

[agranlund]

The tool is (among others) Screenspain: http://files.dhs.nu/files_coding/scrnpain.zip
However I'm a little confused why do you need it for 640x480@256c, that's a standard Falcon resolution - double lines off, 80 columns (on VGA, that is).

Thanks mikro!

That's 640x480@256c on the "Macintosh", but in reality 640x480@TrueColor on the Atari.

This is based on nothing more than me guessing that the cost of 8-plane C2P in 640x480 is probably even more terribly slow than using that slow RGB mode (where we only need a simple pal->rgb lookup instead of c2p)
I can absolutely be completely wrong about that though..

The drawback is that it is RGB only and terribly slow. ;) So I'd leave it out, better support SuperVidel's video modes then (256c chunky mode, high resolutions with 32-bit colour depth etc).

My guess is that SuperVidel in 256c chunky probably already works and is blazingly fast.
(Haven't heard if anyone tested Basilisk with one yet though, but if it presents the mode correctly in VDI like everything else then it should just work)


The main reason for adding emulation of non-native video modes is basically for me to be able to debug some 256c only applications in Hatari, but I figure since I'm doing it anyway then I may as well spend a little bit extra time to make it clean and expose it as a proper option - as long as it doesn't turn into a great timesink for little to no gain :)
I'm under no illusion that anyone with a non-accelerated Falcon would want to use an emulated video mode, but maybe useful on a SuperVidel-less CT60 or a 50Mhz Falcon with FastRAM.

[agranlund]

A video driver for the Atari display would be no slower but would need to be written to control the hardware, such as changing resolutions. It would need someone who knew how to write System 7 device drivers though.

This is actually already how it works.
There is no hardware emulation going on - Basilisk patches out the Mac built-in display driver and replaces it with one made for Atari.
It still has to follow same rules as what Apple required from real gfxcards and display drivers though..
They can't just present their own exotic formats but must use the few pixel formats as dictated by Apple (1,2,4,8bpp must be chunky, 16bit must be RGB555 in Big Endian etc..)

As a side note, sound is actually the same. It does not emulate the sound hardware - it patches itself in as an extension to Sound Manager.
Disk access is the same, etc etc..
This is the good thing about Mac. Nothing touches hardware expect for the ROM. And the ROM is *heavily* patched at startup to call Host code instead of accessing Mac hardware = there is almost no emulation on the hardware level.
(Ok, well, MacOS itself and extensions etc could, and there is runtime patching of these types of things going on too)

With regard to graphics resolutions, @agranlund, seeing as Basilisk is taking over the whole display it could save the information about the mode the program was started in and then switch to an appropriate mode to boot into. e.g. always attempting to switch to an apropriate modes, say ST-HIGH, and later let the MacOS driver change to a new one if the NVRAM says to use it. When Basilisk quits it can restore the video mode back so tat GEM doesn't get confused.

Yep this is a good idea and I have it noted down to expose video stuff as options at some point.
For now, it uses whatever mode you are already in and errors out if it is completely incompatible.

You can change the MacOS resolution from the control panel, kind of.
The Atari video driver for MacOS is exposing the resolution you started with, and when applicable a few smaller ones.
Changing the MacOS resolution from inside MacOS won't change the actual Atari resolution though, it will just centre the smaller MacOS screen and surround it with black.
It's still useful - especially if you want to play very old games that expect the resolution to be 512x384 or 512x342.

I haven't found a hardware or driver independent way of easily changing resolution or mode on Atari gfxcards. This is why it works like that.
This is also why it's not trying to be clever and guess if the user maybe wants Basilisk to auto-switch into ST-High or not.
(Maybe someone doesn't even have the output from the Atari Shifter/Videl connected to a monitor)
If only there was a good device-independent way of talking to graphics cards on the Atari, a'la RTG on the Amiga..

One of these days I will get around to look at exposing a set of video options though :)

[stephen_usher]

The only device independence with regards to the graphics on the Atari systems is via the VDI interface unfortunately.

[agranlund]

The only device independence with regards to the graphics on the Atari systems is via the VDI interface unfortunately.

Yep. It's decent enough for querying the current resolution and pixel format though. Extremely detailed info actually if EdDI is available.
Would be nice if there was an official way to get the framebuffer pointer from it but in practice it works just as well just grabbing the phys ptr.

What I think is really missing is to be able to enumerate the available modes and setting one though :)
(Nope... I'm not in the mood of reverse engineering and parsing NVDIVGA.INF, or any of the other variations thereof)