Basilisk II Atari

General Discussion, STOS.

Moderator: troed

User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Basilisk II Atari

Post by agranlund »

shoggoth77 wrote: Sun Apr 10, 2022 10:33 am 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.
I like it. A small and targeted scope that seems doable without it turning into an enormous project.

All sourcecode is going to end up on Github and it would be very cool if more people wanted to hop onboard!
@shoggoth77, you did some BasiliskII related stuff before right? :)

I've been enjoying the freedom of being able to make quick and large changes with no concern for others. Likewise, dirty and temporary proof-of-concept type implementations of things and so on.
But I don't know, it's starting to feel like maybe I should concentrate on cleaning up and documenting a bit in preparation for putting the sources on Github.

(Since I have published binaries I am bound by GPL to provide source to anyone that wants them though, so if someone absolutely want to exercise their rights in that regard I would be forced to send what I have.
I'd much rather make it available when I think it's in a less terrible state as a starting point for collaboration though)
mikro
Posts: 474
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: Basilisk II Atari

Post by mikro »

In my experience, code cleanup always pays off, regardless of intention to publicly release something or not. Usually one finds some hidden bugs, inefficient calls, better algorithms etc. :)
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Basilisk II Atari

Post by agranlund »

mikro wrote: Mon Apr 11, 2022 6:52 am In my experience, code cleanup always pays off, regardless of intention to publicly release something or not. Usually one finds some hidden bugs, inefficient calls, better algorithms etc. :)
I agree, even if it's not always the most exciting thing to do :)
Besides, ScummST sources was on my machine for quite some time waiting for a code cleanup that never happend, and eventually got put on Github anyway.
So I may as well do some of that now-ish instead of doing the same thing again :lol:
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: Basilisk II Atari

Post by Badwolf »

agranlund wrote: Sat Apr 09, 2022 7:35 pm 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?
On an original CRT it was fairly eye-breaking for anything with a high spacial frequency (eg. the dithered desktop), but was pretty excellent for images.

With modern flat panels, it depends on the monitor a lot, but most are perfectly usable these days. I have a cheap SCART to HDMI adapter and it's my normal mode of use, although in some modes (like ST high) you get some interesting effects from the image processing (look for cursor trails below).

I've put together another quick demo for you. Sorry about the bit in the middle where I try to test the sound with the sound turned off, but I thought I'd leave it so you can see the full experience.



The reason I'm asking is that I'm adding an option to run MacOS in 256 color, through Falcon TrueColor mode.
Interesting! Translating indexed colour modes to true colour modes must be a fair overhead, but probably less than going chunky to planar. Will be an interesting experiment, I think.
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?
As others have said, you can program the Videl registers quite flexibly, but RGB mode already has an overscan function that gives you 768x480 natively.

Something like TeraDesk has the overscan option in the resolution change menu. I suspect there are other tools to enable it too, or possibly even hacking the newdesk.inf. Shouldn't need to resort to a scrollable window or the like.

It's also exposed on VSetMode if you wanted to get into choosing a resolution from your GUI, for example.

BW

PS: Oh! I meant to say! Another memory violation bug report, I'm afraid. Can't launch the new version from the GUI with memprot enabled. It's in the video.
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Basilisk II Atari

Post by agranlund »

Thank you @Badwolf !
I don't think any game from that era is happy when MacOS is in 16bit mode, almost all of them needs it to be 8bit or mono :)
Badwolf wrote: Tue Apr 12, 2022 10:45 pm Interesting! Translating indexed colour modes to true colour modes must be a fair overhead, but probably less than going chunky to planar. Will be an interesting experiment, I think.
It works and it's "usable" for the purpose I needed it for in Hatari but it's certainly not fast.
I'm sure someone better experienced with Atari graphics would be able to do a much better job than me :)
But still, based on how it performs in Hatari it might be useful for at least desktop applications provided you have a fast machine.
(Maybe even games if you have a CT60 but no SuperVidel or gfxcard?)

I really need to do a proper refactor/cleanup of the very messy video-driver interface anyway and part of that is to make it easy to add new ones.
The idea is that the current native one + my feeble attempt at the emulated 8bpp->16bpp driver could serve as examples on how to add more.
After that's done I'll expose an option to pick video driver and it would be super interesting to see how the emulated one performs on your beefed up Falcon.
Badwolf wrote: Tue Apr 12, 2022 10:45 pm PS: Oh! I meant to say! Another memory violation bug report, I'm afraid. Can't launch the new version from the GUI with memprot enabled. It's in the video.
Oops! Thanks for letting me know :)
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Basilisk II Atari

Post by agranlund »

@Badwolf,
If you have the time, would you like to try this test build?
http://www.happydaze.se/wp-content/uplo ... test02.zip

It's a proof of concept screen driver that will emulate a MacOS 8bit display on Falcon 16bit mode.
Very very rough around the edges but it'll be super valuable to know if this is something worth pursuing further or not.
(I haven't had a chance to look at the MiNT memory protect crash yet so I'm guessing this build will have the same issue as the last one in that regard)
  • You need to start it in Falcon 16bit mode, this build is hardcoded to run with the experimental driver.
  • This build will only work on 68030
  • There can be some artifacts and graphical glitches
  • You need to manually set the Mac memory size. Put it a couple of MB below the amount of free memory you have.
    Otherwise the work buffers risk ending up in st-ram and you don't want that.
    (to give it 8MB, change "ramsize 0" to "ramsize 8" in basilisk.inf)
Not very userfriendly yet :)
But if performance is somewhere in the ballpark of being acceptable on your machine then I think it'll be worthwhile turning this into a proper feature, implement the 68040/60 screen drivers etc..

Others are of course welcome to test it too but I wouldn't expect miracles on a stock Falcon. Would still be interesting to hear just how slow it is on such machine though.
User avatar
stephen_usher
Posts: 5580
Joined: Mon Nov 13, 2017 7:19 pm
Location: Oxford, UK.
Contact:

Re: Basilisk II Atari

Post by stephen_usher »

With respect to chunky-to-planar issue for non-falcon colour, have you seen this? https://web.archive.org/web/2007020817 ... /c2p_I.htm
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Basilisk II Atari

Post by agranlund »

stephen_usher wrote: Sun Apr 17, 2022 6:06 am With respect to chunky-to-planar issue for non-falcon colour, have you seen this? https://web.archive.org/web/2007020817 ... /c2p_I.htm
Thanks! Yep I saw that one and I've also been pointed at some other 030/060 optimised c2p routines for which I am grateful.
This kind of stuff is far outside my zone of knowledge and I find it quite fun and interesting :)

I do want to make some experiments with c2p for TT & Falcons 8bit mode too.
Machines which are fast enough may be able to offset the higher computational cost by the fact that ST-RAM access is halved?
(though I don't know where the threshold for "fast enough" is :D )

One fairly large drawback for the Mac8bit->Atari16bit method is that it needs to flag the entire screen as changed if the Mac palette is changed, and this really hurts things that use palette cycling.
Normally it tries to avoid doing work by not converting screen areas that it thinks hasn't changed since last frame.
This 16bit driver is going to be useful for Mac16bit -> Atari16bit emulation as well though.
mikro
Posts: 474
Joined: Mon Aug 28, 2017 11:22 pm
Location: Kosice, Slovakia
Contact:

Re: Basilisk II Atari

Post by mikro »

stephen_usher wrote: Sun Apr 17, 2022 6:06 am With respect to chunky-to-planar issue for non-falcon colour, have you seen this? https://web.archive.org/web/2007020817 ... /c2p_I.htm
Careful, this is efficient only on the ST. 68030 will not by happy but will swallow it (a lot of cache misses, though) but 68060 will scream as hell -- movep is not implemented in hardware.
User avatar
agranlund
Posts: 777
Joined: Sun Aug 18, 2019 10:43 pm
Location: Sweden
Contact:

Re: Basilisk II Atari

Post by agranlund »

mikro wrote: Sun Apr 17, 2022 1:11 pm
stephen_usher wrote: Sun Apr 17, 2022 6:06 am With respect to chunky-to-planar issue for non-falcon colour, have you seen this? https://web.archive.org/web/2007020817 ... /c2p_I.htm
Careful, this is efficient only on the ST. 68030 will not by happy but will swallow it (a lot of cache misses, though) but 68060 will scream as hell -- movep is not implemented in hardware.
I was planning on trying the 030 and 060 routines from the DHS site, and then I recognised the name.. is that 060 optimised one your doing @mikro ? :)
If so, do you mind if I use it in Basilisk?
Post Reply

Return to “SOFTWARE”