exxos's Atari, Amiga & retro forum

Hmmn... now I need to optimize something!
This identical spec Amiga is beating my CPU score with 0.03 and we can't let that happen :evil:
(It's with Speedometer 4.02 so the scores are completely different to those of 3.x)

Shapeshifter, Amiga, Blizzard1230 @50Mhz BasiliskII, Atari, TF536 @50Mhz Pretty cool video though :)

agranlund wrote: 08 Jun 2022 23:42 I can be remembering wrong, but I think Speedometer measures by doing a cycle of "large write, then a tiny read" over and over again. In such scenario the disk-image read cache wouldn't have that much of an impact on the score given by Speedometer.
The best indication is if startup time is faster and hopefully ok-ish, and icons in the Finder come up quicker.

Make sense -- yes, start-up is much improved.

Badwolf wrote: 08 Jun 2022 20:24 Still have the issue with the colour map seeming off for menus. Black on black when activated.

Is it just the top-level menubar, or is it the same for any highlighted item in the dropped down menu?

What happens when the Apple logo is selected? Does the entire section turn black including the logo or does that one stay correct?

I'll check. When I had these problems before I recall it also affected Civ's introduction -- I didn't have a chance to try that yesterday.

I take it there's no difference for the colour issue if you turn off CMP emulation?

Correct.

BW

Icons seem unaffected:


With neither MMU nor CMP selected (yes, I know...) it works as expected:-


So, by clever process of elimination, it looks like it's the MMU logic (this is CMP only ;) :



BW

Badwolf wrote: 09 Jun 2022 19:03 So, by clever process of elimination,

Awesome! Thanks for the detailed test. This narrows it down quite a bit :)
:thanksyellow:

The latest version makes the Atari border black in emulated modes.
Makes it look quite a bit more polished :)

It can't do much about the border color in native mono, without turning that too into a non-native mode..
(Is white border in mono a Falcon-only issue btw, or is it the same on TT using ST-High?)


http://www.happydaze.se/basiliskii/

The TT shows ST-High with black boarder, so all's fine. I'm just testing the new version in TT-Medium at the moment.

OK. Slight problem. MacOS half locked up when I tried to save the machine record for TT-Med. The latest version is a lot slower (in TT-Medium) than the previous one too, especially the graphics side of things.

stephen_usher wrote: 12 Jun 2022 15:34 The TT shows ST-High with black boarder, so all's fine. I'm just testing the new version in TT-Medium at the moment.

OK. Slight problem. MacOS half locked up when I tried to save the machine record for TT-Med. The latest version is a lot slower (in TT-Medium) than the previous one too, especially the graphics side of things.

Thank you @stephen_usher !

The chunky-to-planar conversion increased by a few instructions (*) for palette index inversion so I expect that to have a little impact.
But if it's a lot slower I should probably check if I left some temp or debug stuff enabled in the build by misstake.
(*) two "not.l" per 16 pixels in 4bit->4bit as in TT-Med, four of them in 8bit->8bit.


(Mac is using color 0 for white and the highest number for black. Due to the Atari border we'll want it the other way around so we're simply inverting the bits of the color index for the Atari side hardware palette, and adjusts for the now different palette layout in the c2p routine)

I would have posted a comparison, but when the system soft-locked it corrupted the "System Records" file again so I lost all the previous metrics.

It's not quite ready for prime time yet but here's a non-official work in progress of shared folder support:
http://www.happydaze.se/wp-content/uplo ... 20615b.zip

This is super useful for transferring downloaded Mac applications to an existing Mac disk without having to make new disk images for everything :)


Some caveats:

It requires MiNT and a filesystem with support for long filenames. MagiC will be supported but at this point it does not work.
I've only been testing on normal Atari partitions with VFAT enabled so I can't say for sure if ext2 works but I assume it would.
Once I get such partition set up I'll be able to do some test there as well.

I don't think it's worth trying to make this work on normal TOS at all? Possibly in some limited fashion for 8.3 files.. maybe that's still useful.

Reading or copying from the shared folder seems fine.

Writing or copying to the shared folder works, but with the following problems:
- overwriting existing stuff does not yet work correctly
- stuff in the shared folder can be moved to trash, but that trash cannot yet be emptied


Enable it with "extfs <path>" in basilisk.inf, for example:
extfs H:\shared

That folder will get cluttered with many (hidden) extra files emulating resource forks and metadata, so I recommend making a folder that is just for Atari<->Mac sharing rather than sharing your Atari home folder or such.

There's a rather large overhead to it, I'd mainly use it to copy things across rather than working on things directly in it.

This one should work well under both MiNT and MagiC. For both reading + writing to the shared folder.
http://www.happydaze.se/wp-content/uplo ... 0615b2.zip

It now links to Mintlib instead of Libcmini.
As such, the binary is 150Kb larger.. can't say I'm super happy about this so I'm considering one of the following options going forward:

1) Make Mintlib part of the BasiliskII source tree and strip away some stuff I don't need.
I think it's completely fine if it makes the exe a bit larger but an almost 50% increase is a bit hard to stomach.
Also get rid of floating point stuff and that silly/weird FPU *requirement* for 020-060 target. Or maybe just live with Mintlib-000, all other code is still built for 020-060 anyway.

2) Continue using Basilisk's version of Libcmini but make the posix file routines fully compliant by copy/pasting the Mintlib ones.