Minimal multitask configuration for Hatari

[Entuzio]

EasyMint on Hatari: https://www.youtube.com/watch?v=LGThrtJfYTc. This Compilation is no longer available, PC HDD Crash.

More Emulators: https://www.youtube.com/channel/UC45S6xHekLAE4v0VinRwbnQ
... and more: http://marjanmencinsi.wixsite.com/majishop/single-post/2015/12/07/Apple-Macintosh-emulator

[helmut]

Is C:\CLIPBRD somewhow connected to the host-clipboard?

This is very likely totally unrelated, but I receive Bus-Errors in XaAES
from various clients on aranym, when I open the the clipboard and the
host-clipboard is empty. Of course only when clipboard is set to
u:/host/clipboard in xaaes.cnf.

I always make sure there's somthing in the clipboard before running
aranym.

-Helmut

[OL]

Is C:\CLIPBRD somewhow connected to the host-clipboard?

This is very likely totally unrelated, but I receive Bus-Errors in XaAES
from various clients on aranym, when I open the the clipboard and the
host-clipboard is empty. Of course only when clipboard is set to
u:/host/clipboard in xaaes.cnf.

I always make sure there's somthing in the clipboard before running
aranym.

-Helmut

In fact it's not specific to CLIPBRD, any empty folder on host crash Teradesk in my configuration.

Olivier

[helmut]

Well Eero said:

"The weird thing is that this happens only with the CLIPBRD folder, but I don't know whether that's just due to timing."

Now what?

I just ran my old hatari on my old XP-PC and in XaAES opening any empty folder on C: using the fileselector does not crash, but I can't open the folder, i.e. it keeps displaying C: with all titles greyed. Something seems wrong. Guess I'll have to install hatari finally ...

If you can build MiNT try to build a DEBUG-kernel, maybe that sheds some light.

-Helmut

[OL]

Well Eero said:

"The weird thing is that this happens only with the CLIPBRD folder, but I don't know whether that's just due to timing."

Now what?

I just ran my old hatari on my old XP-PC and in XaAES opening any empty folder on C: using the fileselector does not crash, but I can't open the folder, i.e. it keeps displaying C: with all titles greyed. Something seems wrong. Guess I'll have to install hatari finally ...

If you can build MiNT try to build a DEBUG-kernel, maybe that sheds some light.

-Helmut

I have try with Direct desktop, there is no issue opening empty folder. Teradesk looks crash after display the window, MyAES not report crash in AES. Perhaps AES don't like something in window redraw and write something somewhere it should not. Under MyAES only without Mint, Teradesk not crash. Difficult to understand. I'm going to add DEBUG-kernel. I notice in this config sometime Teradesk crash in AES for on wind_set call.

Olivier

[OL]

As I can see,

Teradesk crash after wind_get(WF_FIRSTXYWH), so looks in the window drawing.

Olivier

[helmut]

Does TOSFS provide . and ..-links?

[Eero Tamminen]

Is C:\CLIPBRD somewhow connected to the host-clipboard?

AFAIK yes on Aranym, but not on Hatari.

[OL]

Does TOSFS provide . and ..-links?

I have done the test 2 or 3 days ago, on empty folder TOSFS not return anything on dreadir.

Olivier

[helmut]

Could this be the reason for the crash? teradesk tries do draw a window with 0 lines or so? I remember vaguely I did something in XaAES to prevent entering such a directory for a similar reason.

[helmut]

Does hatari run on windows10?

I get the error-code 0xc0000022 from the 1.9-version (32 and 64 bit), when started from cmd. From the cygwin-terminal I get nothing.

[fmh]

For me Hatari runs on Windows10 64-bit. Not sure what version of Hatari. Not the newest as I haven't updated it in a long time.

[helmut]

Got it: some dlls from the distribution lacked the x-bit. Works now in 64 and 32-bit. Even with key-click! And even with an XaAES-crash ...

-rw-r--r-- 1 hk None 157184 Jun 18 2014 capsimg.dll
-rw-r--r-- 1 hk None 84616 Oct 15 2014 zlib1.dll

In hatari 1.9 XaAES can't open the virtual workstation - it crashes inside v_opnvwk (Addr=0).

The same works in hatari 1.7.

TOS is 2.06.

In hatari 1.7 I can open any empty folder on C: without a problem.

Sorry, no results from me.

-Helmut

[Eero Tamminen]

Got it: some dlls from the distribution lacked the x-bit. Works now in 64 and 32-bit. Even with key-click! And even with an XaAES-crash ...

-rw-r--r-- 1 hk None 157184 Jun 18 2014 capsimg.dll
-rw-r--r-- 1 hk None 84616 Oct 15 2014 zlib1.dll

In hatari 1.9 XaAES can't open the virtual workstation - it crashes inside v_opnvwk (Addr=0).

You mean NULL pointer error?

The same works in hatari 1.7.

TOS is 2.06.

In hatari 1.7 I can open any empty folder on C: without a problem.

Sorry, no results from me.

Could you try one of the daily Hatari Windows builds provided by CHS:
http://antarctica.no/~hatari/

Or try it on Linux, or provide your XaAES setup (minimal version of it) so that I can check the vopnvwk() issue?

[helmut]

./hatari-win64-release
Illegal instruction

My C: stripped down: http://home.arcor.de/zabruder/atari/hatx.zip
Hope I didn't forget anything. It boots into ash, then type xaloader.prg.

I don't have any linux, but OpenBSD

-Helmut

[Eero Tamminen]

./hatari-win64-release
Illegal instruction

My C: stripped down: http://home.arcor.de/zabruder/atari/hatx.zip
Hope I didn't forget anything. It boots into ash, then type xaloader.prg.

Thanks. As you said, xaloader.prg doesn't start up properly.

In my case, it:
- opens & closes XA_BOOT.LOG file over 30 times
- opens & closes MOOSE.ADI twice before telling that loading it failed
- Gives illegal instructions error twice and after that doesn't continue booting, just shows white screen with blinking cursor

Profiling shows that cursor blinking comes from (Emu)TOS.

This output on console and AES+VDI trace ("hatari --conout 2 --trace vdi,aes ..."):

Code: Select all

XaAES v1.8.4 Beta (m68000, Sep 11 2016 19:56) (MultiTasking AES for MiNT)
Part of freemint (http://sparemint.org).
home_path: 'u:\c\mint\1-19-cur\xaaes\'
Reading `u:\c\mint\1-19-cur\xaaes\xaaes.cnf' ... 9488 bytes done.
[u:\c\mint\1-19-cur\xaaes\xaaes.cnf:70] unknown variable 'GRADIENTS', skipped.
moose_w.adi not found
Wrong kentry-version (kernel-version too high)
Module moose.adi error, reason: Nothing (possibly from other kernel)
AES call  10 appl_init()
AES call  19 appl_exit()
VDI call   1/  0 (v_opnwk)
pBank flags mismatch: 0x2 & 0x1 (RAM = 0x1)
GEMDOS Fwrite() failed due to invalid RAM range 0xe3ea38+4
VDI call 100/  0 (v_opnvwk)
VDI call 104/  0 (vsf_perimeter)
VDI call 108/  0 (vsl_ends)
VDI call  16/  0 (vsl_width)
VDI call 106/  0 (vst_effects)
VDI call  19/  0 (vsm_height)
VDI call  12/  0 (vst_height)
Illegal instruction: 4a8d at 00172DB4 -> 0005DA58
Illegal instruction: 4a8d at 00172DB4 -> 0005DA58
GEMDOS 0x40 Fwrite(64, 105, 0x74fa8) at PC 0xFA002A
GEMDOS 0x40 Fwrite(64, 2, 0x22ce5) at PC 0xFA002A


Fwrite() after physical workstation opening trying to overwrite ROM looks suspicious, but it happens only with EmuTOS so I'm going to ignore it.

Last Fwrite(64...) lines are error message (+\r\n) from XaAES happening both with TOS v2 and EmuTOS.

It doesn't show on screen or in XaAES log, but I think tells the actual problem:

Code: Select all

> m 0x74fa8
00074FA8: 70 69 64 20 20 20 34 20 28 41 45 53 53 59 53 29   pid   4 (AESSYS)
00074FB8: 3a 20 49 4c 4c 45 47 41 4c 20 49 4e 53 54 52 55   : ILLEGAL INSTRU
00074FC8: 43 54 49 4f 4e 3a 20 55 73 65 72 20 50 43 3d 31   CTION: User PC=1
00074FD8: 37 32 44 42 34 20 28 62 61 73 65 70 61 67 65 3d   72DB4 (basepage=
00074FE8: 31 36 30 45 34 2c 20 74 65 78 74 3d 31 36 31 45   160E4, text=161E
00074FF8: 34 2c 20 64 61 74 61 3d 36 30 39 44 38 2c 20 62   4, data=609D8, b
00075008: 73 73 3d 36 34 31 32 34 29 00 00 00 00 00 00 00   ss=64124).......
> d "0x172DB4-6"
- '0x172DB4-6' -> $172dae
$00172dae : 303c 0073                          move.w    #$73,d0
$00172db2 : 4e42                               trap      #2
$00172db4 : 4a8d                               tst.l     a5
> info vdi 1
...       
70 vsf_udpat       71 vsl_udsty       72 vr_recfl        73 vqin_mode
...


I.e. it's actually this that fails:
http://toshyp.atari.org/en/Inquire_func ... #vqin_mode

Is moose.adi ABI mismatch & loading failure problem for XaAES running? And could you provide setup with a working one?


For completeness, XA_BOOT.LOG contains:

Code: Select all

XaAES v1.8.4 Beta (m68000, Sep 11 2016 19:56) (MultiTasking AES for MiNT)
Part of freemint (http://sparemint.org).
stack is long-aligned:FBE40
PRG: km=FE000, base=FE160, text=FE260 -> 1734A0(479808), kentry:0.21,dos_version=40
home_path: 'u:\c\mint\1-19-cur\xaaes\'
Loading config u:\c\mint\1-19-cur\xaaes\xaaes.cnf
keyboard#0=aradenum
sysfile_exists: 'u:\c\mint\1-19-cur\xaaes\moose_w.adi'
moose_w.adi not found
sysfile_exists: 'u:\c\mint\1-19-cur\xaaes\moose.adi'
lang='en' (from AKP) code=0.
load adi modules
Loading AES Device Drivers:
load_adi: enter (0x185304, 0x185204, moose.adi)
Module moose.adi error, reason: Nothing (possibly from other kernel)
load_adi: return -1
adi_load: done
Creating XaAES kernel thread
AESSYS:Installed 'nAES' cookie in readable memory at C1A00
apid=-1,P_handle=0,next_res=0
k_init: videomode=0.vm=0
could not determine nvdi version
could not determine fvdi version
k_init:vdo=0 vm=0 video=0
Default screenmode
Screenmode is: 1
Physical work station opened: 1
opening vwk:v=17F0A8
exception 4 for AESSYS pc:172DB4 addr:0


I don't have any linux, but OpenBSD

That should be fine. Have you tried building latest Hatari / did you encounter any errors?

[helmut]

Thanks. As you said, xaloader.prg doesn't start up properly.

In my case, it:
- opens & closes XA_BOOT.LOG file over 30 times
- opens & closes MOOSE.ADI twice before telling that loading it failed
- Gives illegal instructions error twice and after that doesn't continue booting, just shows white screen with blinking cursor

The boot-log is closed after every line, so that's normal.
The moose.adi I provided is indeed wrong, it does not run for me either. Sorry, I didn't notice that because I also have moose_w which seems to work, and obviously XaAES used that.

This output on console and AES+VDI trace ("hatari --conout 2 --trace vdi,aes ..."):

Code: Select all

...
Wrong kentry-version (kernel-version too high)


This should not happen. If it comes XaAES won't start anyway. Looks like the strings in the XaAES-binary are messed up.

Module moose.adi error, reason: Nothing (possibly from other kernel)
AES call 10 appl_init()
AES call 19 appl_exit()
VDI call 1/ 0 (v_opnwk)
pBank flags mismatch: 0x2 & 0x1 (RAM = 0x1)
GEMDOS Fwrite() failed due to invalid RAM range 0xe3ea38+4

VDI call 100/ 0 (v_opnvwk)
VDI call 104/ 0 (vsf_perimeter)
VDI call 108/ 0 (vsl_ends)
VDI call 16/ 0 (vsl_width)
VDI call 106/ 0 (vst_effects)
VDI call 19/ 0 (vsm_height)
VDI call 12/ 0 (vst_height)

Is it possible that these VDI-calls come from the VDI itself?

Illegal instruction: 4a8d at 00172DB4 -> 0005DA58
Illegal instruction: 4a8d at 00172DB4 -> 0005DA58
GEMDOS 0x40 Fwrite(64, 105, 0x74fa8) at PC 0xFA002A
GEMDOS 0x40 Fwrite(64, 2, 0x22ce5) at PC 0xFA002A
Fwrite() after physical workstation opening trying to overwrite ROM looks suspicious, but it happens only with EmuTOS so I'm going to ignore it.

I don't understand how an Fwrite() can write into ROM.

I.e. it's actually this that fails:
http://toshyp.atari.org/en/Inquire_func ... #vqin_mode

XaAES does not call vqin_mode directly.

Is moose.adi ABI mismatch & loading failure problem for XaAES running? And could you provide setup with a working one?

http://home.arcor.de/zabruder/atari/hatx.zip
Remove the old moose.adi.

For completeness, XA_BOOT.LOG contains:

This is how it should look like:

Code: Select all

~~~~~~~~~~~~ XaAES start up ~~~~~~~~~~~~~~~~
XaAES v1.8.4 Beta (m68000, Sep 16 2016 13:34) (MultiTasking AES for MiNT)
Part of freemint (http://sparemint.org).
stack is long-aligned:F2C40
PRG: km=F2E00, base=F2F60, text=F3060 -> 168404(480164), kentry:0.21,dos_version=40
home_path: 'u:\c\mint\1-19-cur\xaaes\'
Loading config u:\c\mint\1-19-cur\xaaes\xaaes.cnf
keyboard#0=aradenum
sysfile_exists: 'u:\c\mint\1-19-cur\xaaes\moose_w.adi'
moose_w.adi not found
sysfile_exists: 'u:\c\mint\1-19-cur\xaaes\moose.adi'
lang='de' (from AKP) code=1.
load adi modules
Loading AES Device Drivers:
load_adi: enter (0x17E304, 0x17E204, moose.adi)
load_adi: return 0
adi_load: done
Creating XaAES kernel thread
AESSYS:Installed 'nAES' cookie in readable memory at B8800
apid=-1,P_handle=0,next_res=0
k_init: videomode=0.vm=0
could not determine nvdi version
could not determine fvdi version
k_init:vdo=0 vm=0 video=0
Default screenmode
Screenmode is: 1
Physical work station opened: 1
opening vwk:v=1740A0
vwk openend :v=1740A0,handle=2
Virtual work station opened: 2
lookup-support:0, planes:1
Video info: (1280/960),1, colours 2 pixel-format 8
loading palette:'u:\c\mint\1-19-cur\xaaes\pal/gem.pal'
palette not found:-33
stdfont: id = 1, size = 9, cw=8, ch=8, dev=0
smlfont: id = 1, size = 8, cw=6, ch=6, dev=0
Display Device: Phys_handle=1, Virt_handle=2
 size=[1280,960], colours=2, bitplanes=1
Loading system resource file 'xaaes016.rsc'
xaaes_sysfile: check if 'u:\c\mint\1-19-cur\xaaes\xaaes016.rsc' exists - return = 0
open lang-file 'u:\c\mint\1-19-cur\xaaes\xaaes016.rsl'
system resource = 185A04 (u:\c\mint\1-19-cur\xaaes\xaaes016.rsc)
xaaes_sysfile: check if 'u:\c\mint\1-19-cur\xaaes\xa_xtobj.rsc' exists - return = 0
xaaes_sysfile: check if 'u:\c\mint\1-19-cur\xaaes\xaaeswdg.rsc' exists - return = 0
AESSYS:Installed 'BGEM' cookie in writeable memory at B8C00
AESSYS:read_inf:u:\c\mint\1-19-cur\xaaes\xaaes.inf
alert:6, KBD:7,pferr=0
No wheel support
Using moose adi
Loading AES modules...
loading accs ---------------------------
loading accessories from 'C:\'
loading shell and autorun ---------------


I made a few more tests:
GEM=ROM, start xaloader from the TOS-desktop (works in 1.7, crash in 1.9):

XaAES calls graf_handle from the ROM-TOS which causes
exception 4 for AESSYS pc:165CCA addr:0

GEM=...xaloader.prg (works in 1.7, crash in 1.9):

Physical work station opened: 1
opening vwk:v=14B4A4
exception 4 for AESSYS pc:13F1B0 addr:0

Here v_opnvwk crashes, a completely different location. I don't think it has to do with XaAES.

BTW: hatari 1.8 works like 1.7.

I don't have any linux, but OpenBSD

That should be fine. Have you tried building latest Hatari / did you encounter any errors?

Haven't tried yet.

-Helmut

[Eero Tamminen]

Is it possible that these VDI-calls come from the VDI itself?

Could be, but in general only AES is one really using itself through trap.

Btw. aes_exit() following aes_init() is also suspicious, but that seems to happens with Hatari v1.8 too.

I don't understand how an Fwrite() can write into ROM.

It won't succeed, but even trying to do that is suspicious.

XaAES does not call vqin_mode directly.

Sorry, I forgot few VDI array indirection when getting the opcode. I.e. the VDI function name I gave was wrong.

Anyway, now I can verify that 1.8 works, both with EmuTOS and real TOS, but v1.9+ doesn't work with either.

Additionally:
- Issue happens both with OldAUE CPU core and WinUAE CPU core, i.e. it's something in common between CPU cores that has changed
- Running from ACSI image doesn't help, so it's not GEMDOS HD emulation issue

Differences in v1.8 and v1.9 output are new warnings about illegal instructions...

Before xaloader.prg:

Code: Select all

XBIOS 0x26 Supexec(0x527BC) at PC 0x5305C
Illegal instruction: 42c1 at 000542D8 -> 00054324
M68000 Bus Error reading at address $fffa40 PC=$543b2.

Illegal instruction is 68010+ variant:

Code: Select all

$0005d602 : 42c1                               move      ccr,d1


During XaAES startup:

Code: Select all

VDI call 100/  0 (v_opnvwk)
VDI call 104/  0 (vsf_perimeter)
VDI call 108/  0 (vsl_ends)
VDI call  16/  0 (vsl_width)
VDI call 106/  0 (vst_effects)
VDI call  19/  0 (vsm_height)
VDI call  12/  0 (vst_height)
Illegal instruction: 4a8d at 00169D18 -> 0005472E
GEMDOS 0x4E Fsfirst("C:\MINT\1-19-CUR\XAAES\XA_BOOT.LOG", 0x37) at PC 0xFA002A


Code: Select all

GEMDOS 0x40 Fwrite(64, 2, 0x199bb) at PC 0xFA002A
Illegal instruction: 4a8d at 00169D18 -> 0005472E
GEMDOS 0x40 Fwrite(64, 103, 0x6bc7e) at PC 0xFA002A


Illegal instruction is 68020+ variant:

Code: Select all

$00172f12 : 303c 0073                          move.w    #$73,d0
$00172f16 : 4e42                               trap      #2
$00172f18 : 4a8d                               tst.l     a5


There are also several other TST instructions with direct address register addressing. TST addressing valid on 68000 are: Dn, (An), (An)+, -(An), x(An), x(An,xr.s).

Hatari version v1.8 and earlier 68000 emulation didn't give errors for non-68000 instructions. Hatari v1.9+ does.

Something in XaAES startup isn't compiled properly for 68000, or has inline assembly that isn't 68000 compatible.

[helmut]

I rebuilt libgem and now XaAES runs on hatari 1.9. The build from Alan

http://www.freemint.org/builds/freemint

should work anyway. There was a mess (maybe still is) in my environment.

I can say hatari ain't that bad: I can run XaAES in the pure-Debugger, and all works

-Helmut

[Eero Tamminen]

I rebuilt libgem and now XaAES runs on hatari 1.9.

Great to hear that my late night debugging wasn't in vain!

Did that sort out the empty clipboard directory problem also, is that still to be debugged?

[helmut]

Much effort because of a small sloppiness, but that's the way it is sometimes ...

I never had a problem with the empty folder, it must be something special to OL.

[Eero Tamminen]

Could you provide update zip of your minimal setup, so that I can check whether empty folder issue has disappeared also for me?

[OL]

The issue not diseapear at all, it is Teradesk issue in this configuration and why I don't know.

I try to propose Thing but I found there is a MyAES bug for sure but no issue with empty folder, I try Direct it work fine but not want to work on lowres and Mdesk I should add some feature to be able manage icon in 16 color and black and white.

I have worked to add debug information when application crash, it could be usefull.

Olivier

[helmut]

I've added some files from teradesk (don't know if something's missing):

http://home.arcor.de/zabruder/atari/hatx.zip

And as I said before: The build from freemint.org should run as well.

[Eero Tamminen]

The icon RSC files were missing and teradesk.inf had lot of stuff (that didn't exist in the mini setup), but after adding icons it was working fine.

I tried then replicating OL setup. Teradesk from that worked fine too. After adding "myaesmin.prg" and gemsys directory with OL's MyAES & MiNT-mini builds, Teradesk started crashing to bus error. Doesn't help much I admit.

OL, I'm wondering why in your setup there are two of these, and why they differ:

Code: Select all

$ ls -l gemsys/ldg/screen.ldg gemsys/myaes/libs/screen.ldg
163816 gemsys/ldg/screen.ldg
163812 gemsys/myaes/libs/screen.ldg

?