Thanks, this is pretty interesting! (And it's really nice that Helmut resurrected the GEMDOS FATFS so that MiNT works with Hatari GEMDOS HD)

Any idea why:

Command line in basepage has garbage when MyAES Pexec()s LDG files, before it starts MiNT? (You can see this by using Hatari "--trace os_base" option)

Teradesk viewer shows just blank for files in /u/kern/? (Whereas for files in /u/proc/ it says that it cannot access them)

With 16 colors it doesn't really look its best. Some kind of monochrome support could look better, and maybe more importantly, should be much faster on (emulated) ST & use less memory...

TosWin and e.g. EmuCON2 shell from EmuTOS would also be nice. Attached is patch to latest EmuTOS sources which fixes compilation for standalone version of EmuCON2 and adds support for reading of startup batch file (resulting in 34K binary which supports several shell commands and filename tab completion).

You do not have the required permissions to view the files attached to this post.

1) For Pexec, I have to check2) I don't know, this is very minimal Mint setup without configuration so perhaps a problem, or perhaps I have put an very old version of Teradesk, I have to compare with a more standard configuration.3) I can add some other tools but it's only a most basic system possible, I'm going to check if env can be set correctly or not I'm not sure it work.

Olivier

Eero Tamminen wrote:Thanks, this is pretty interesting! (And it's really nice that Helmut resurrected the GEMDOS FATFS so that MiNT works with Hatari GEMDOS HD)

Any idea why:

Command line in basepage has garbage when MyAES Pexec()s LDG files, before it starts MiNT? (You can see this by using Hatari "--trace os_base" option)

Teradesk viewer shows just blank for files in /u/kern/? (Whereas for files in /u/proc/ it says that it cannot access them)

With 16 colors it doesn't really look its best. Some kind of monochrome support could look better, and maybe more importantly, should be much faster on (emulated) ST & use less memory...

TosWin and e.g. EmuCON2 shell from EmuTOS would also be nice. Attached is patch to latest EmuTOS sources which fixes compilation for standalone version of EmuCON2 and adds support for reading of startup batch file (resulting in 34K binary which supports several shell commands and filename tab completion).

I have to check this in this basic configuration, strange. As you can see for so small resolution I not manage correctly text redraw, this is something new for me I have always work on true color with higher resolution!

Eero Tamminen wrote:With 16 colors it doesn't really look its best. Some kind of monochrome support could look better, and maybe more importantly, should be much faster on (emulated) ST & use less memory...

.

I'm working on speed (in fact MyAES is fast probably faster than TOS AES) but redraw and I think to menu is more slow for sure.

For the memory, it's not my goal, all is design for true color inside so it need more memory, this is style try just show it work not too badly

I want to explain some other possible configuration you can do with this one:

- You can replace myaes68k.prg from "auto" folder by mintmini.prg (in drive/gemsys/myaes/kernel), in this case Mint will be loaded and the AES will be the TOS (or Emutos) AES and desktop.

- You can remove myaes68k.prg from "auto" folder and move it anywhere and from TOS (Emutos) desktop start it, in this case mintmini will be started and MyAES will start too as if it was in "auto" folder.

Olivier

OL wrote:Hello,

very small configuration on HostFS with Mint (thanks to Helmut Branch), MyAES and Teradesk for Hatari

As to my suggestion about monochrome mode support instead of 16-colors, that was partly due to crappy looking window titlebars, which I just noticed to be some issue with EmuTOS (more info on emutos-devel mailing list). Titlebars look much better with real TOS.

(You need newer TOS version or EmuTOS with above, older TOS versions are crashy with this large screen sizes.)

joska wrote:I would assume this is because these files are 0 bytes long. So any program that checks the size before loading them will show an empty file. The same happens if you try to load them in qed.

I see. Doing e.g. "cat welcome" in EmuCON2 works fine (giving input to a TOS program without running it inside TOSWin or something similar is hard though as desktop / windows eat half the keypresses. ).

I know, I'm looking at this on very small resolution I have this, but button relocation for other program is ok so there is something I not understand at this moment, I try to understand why but already take some hours on this subject and I'm not able to find the reason up to now!

Cyprian wrote:dropdown menu clearing / restoring:

grab0003.png

grab0004.png

sometimes it bombs when I try to open a folder:

Schowek-1.png

Strange I'm not able to reproduce this, but since I have updated archive with new Teradesk, perhaps it solve your problem

Cyprian wrote:and the last point: how to close folder without closing whole window?

Looks like a problem of Teradesk, I put very old version of this software, I just update archive with last one and now looks work as on TOS desktop.

I haven't seen the indicated dropdown menu clearing/restoring problem with the latest myhatari.zip contents, but selecting Desk -> About sometimes restores incorrect part of desktop to a small top-/left-most part of the area that was under menu. This is easiest to reproduce by doing it right after booting:

myaes-stlow.png

Bombing with folder handing could also be issue with older TOS version. I would recommend TOS 2.x or EmuTOS.

As to button sizes in ST-low, it looks like they're sized according to (huge) font size used for showing file info in folder windows, window buttons and window scroll bars, not according to font size of the button text.

You do not have the required permissions to view the files attached to this post.

I have finally found the bug, it was not easy because all was correctly calculated in the rsrc_load() and I found height value was modified by Teradesk itself (very strange this is the job of AES!), so I have looked to Teradesk source and found it patch the size and for this use appl_getinfo(0) -> AES large size font that was not set correctly in this resolution, this is done.

I not update the archive for the moment I have some other enhancement to do

Cyprian wrote:I've checked the latest version and I can't change resolution to ST-Medium.

I can reproduce it, ok perhaps I have an explanation, I have done a change just before proposed this archive to do trial to understand a crash with a megast + ET4000 card (not common configuration!). I check this.

Eero Tamminen wrote:One can select ST-med from the TeraDesk dialog, OK it, and something happens, but the resolution doesn't change.

IMHO main issue with ST-low resolution is the huge size of the folder content texts and scrollbars & window titlebar.

I'm working on small version it doesn't work for the moment. I have fixed too redraw size problem in this resolution with radio button and check box it will be avaible at my next update.

Olivier

I have fixed several bugs for change resolution but still not work, I not understand passing in work_in[0] resolution need + 2 looks have no effects!

Olivier

After some check, in fact I'm able to switch resolution for TOS 3 and 4 but not for TOS 1, 2 and Emutos, probably need some xbios call, there is some information not correctly updated after resolution change as palette and switch font size if need.