Basilisk II Atari

[agranlund]

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:-

Nice! Thank you :)

Is that videl initialisation bug a know thing? It asks VDI for video information but it looks like the screen pointer is off by a word there.
I guess I could adjust for it if it's a known issue which happens under certain circumstances such as TOS4.04 and NVDI (unless I'm doing something wrong in my code that is causing this).

FPU is odd. It's only supposed to disable FPU on 040+ at the moment so there's something wrong there for sure.
Saying that, I have only tried 030 FPU in Hatari. I was never able to get an FPU working reliably in my TF534 and the 536 doesn't have an option for one.

I have a debug build with a bunch of extra logging that might help explain what is going on but I'm holding off re-uploading a proper build until that test version checks out ok-ish (It's mainly an attempt to please timer-c sensitive hard disk drivers such as HDDriver).

Out of curiosity, which type of interface, driver and driver version are you using on your Falcon?

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. ;)

Wow, yeah that border certainly needs to be black, and luckily for me I'm able to repro it in Hatari :)

[Badwolf]

Is that videl initialisation bug a know thing? It asks VDI for video information but it looks like the screen pointer is off by a word there.
I guess I could adjust for it if it's a known issue which happens under certain circumstances such as TOS4.04 and NVDI (unless I'm doing something wrong in my code that is causing this).

I think it was discovered by the EmuTOS team relatively recently when they fixed a Videl initialisation sequence. This may not be related though if you're using the existing screen parameters.

I quickly tried again a little earlier and the problem didn't recur. I didn't have chance to check the FPU at that time, however. Possibly it's a one off.

I'll give it a really proper run out later this week -- simply no time today.

I have a debug build with a bunch of extra logging that might help explain what is going on but I'm holding off re-uploading a proper build until that test version checks out ok-ish (It's mainly an attempt to please timer-c sensitive hard disk drivers such as HDDriver).

Out of curiosity, which type of interface, driver and driver version are you using on your Falcon?

I'll see if I can reproduce it, but that could be a clue. This is Falcon motherboard IDE with HDDriver 11. EmuTOS uses its own driver, of course, so that's an obvious difference.

I did also get it booted up in 16-bit colour mode -- that was also with HDDriver under TOS. It seemed quite responsive without any screen issues that time.

Just out of interest would you know where I can find more information on the memory structure of the Mac's 256 colour mode? I see it's indexed and chunky, but I'm interested in how and where the palette is stored.

I love it already! :)

BW

[agranlund]

Just out of interest would you know where I can find more information on the memory structure of the Mac's 256 colour mode? I see it's indexed and chunky, but I'm interested in how and where the palette is stored.
I love it already! :)

Yeah this is super interesting stuff for me to play with as well :)

All the Mac modes are indeed chunky. From what I can tell most games seems to require either b&w or 256 color mode. I found one 16 color game but that mode is also chunky.

For the palette, the Mac display driver must expose a Control() function and one of the parameters is to set the palette.
On a real Macintosh I guess the actual location is going to be different, and internal to, whatever graphics card it's equipped with.

In Basilisk's case, the ROM is patched to include an Atari display driver.
The driver doesn't do anything fancy in terms of converting graphics(*) just presents the Atari framebuffer as-is for MacOS to use.
When MacOS calls Control() to set the palette, those colours are converted from Mac format (0-255 per channel) to VDI format (0-1000 per channel) and finally vs_color() is called and VDI takes care of updating the hardware palette on the shifter/videl/graphics card.

(*) It could though, and it does have a debug mode where it can convert Mac 8bit mode to Atari 16 color mode.
I made it so I could debug some 256 colour-only stuff in Hatari, but it's much too slow to be usable in the real world, and also broken now :lol:

[agranlund]

Warcraft! :yay2:

[stephen_usher]

:dualthumbup: :cheer:

[sporniket]

:bravo:

[mikro]

Is that videl initialisation bug a know thing? It asks VDI for video information but it looks like the screen pointer is off by a word there.
I guess I could adjust for it if it's a known issue which happens under certain circumstances such as TOS4.04 and NVDI (unless I'm doing something wrong in my code that is causing this).

I think it was discovered by the EmuTOS team relatively recently when they fixed a Videl initialisation sequence.

Implemented maybe but certainly not discovered. :) It was in use as early as 2000, for instance here: http://yescrew.atari.org/bin/misc/ycvp.tar.gz.

For implementation see for example here: https://github.com/freemint/freemint/bl ... ios.c#L467

The bug demonstrates itself if you switch to a mono resolution, be it directly via the Videl or by a TOS call.

[Badwolf]

I think it was discovered by the EmuTOS team relatively recently when they fixed a Videl initialisation sequence.

Implemented maybe but certainly not discovered. :) It was in use as early as 2000, for instance here: http://yescrew.atari.org/bin/misc/ycvp.tar.gz.

My sincere apologies for the miscredit! *bows extravagently*

:thumbup:

BW

[shoggoth77]

A fast (but perhaps not that pretty) alternative to C2P conversion in 8bpp chunky mode, is to set e.g. a 320x480 16bpp mode and pretend that it's actually 640x480x8bpp. It won't look right, but it will provide some degree of usability at no cost at all (one could have a hotkey to switch between fast+ugly and slow+pretty).

8bpp_fakery.png

EDIT: I ran this thing on my own NVDI drivers (hence the faked 8bpp chunky mode), on XaAES/FreeMiNT. I didn't expect that to work.

[stephen_usher]

The latest test version still needs some tweaking to get it to run on the TT it seems.

Crashes outright when accessing the SCSI drive and mostly crashes with ACSI.

Still, early days. Fix this and no doubt it'll be more stable on the other machines.