Hatari 2.1.0 has been released

[Eero Tamminen]

Ok, I got the pattern now:
* On TOS <= 2.x and >= 4MB of RAM, screen width needs to be 128 + multiply of 256 pixels, regardless of how many planes there are
* With less RAM, TOS v3 or EmuTOS, it's enough for width to be multiply of 16 bytes (i.e. 128/planes)

I've commited a fix for this and update to documentation.

Cr*p. I get crashes with TOS <= 2.x also with the new aligned screen size when there's >= 4MB of RAM. I just need to move cursor for several seconds in the 16x16 area of the Atari screen bottom right corner. In happens also with OldAUE CPU core, so it's not CPU core specific.

It happens also with Hatari v2.0. Can somebody tests older release down to v1.4 to see whether it's a regression, and if yes, when it happened?

Note: use "-s 4" command line option to specify memory size, don't rely on saved Hatari config file (as memory config option has changed as does config file location). For VDI size, you could use something like "--vdi-planes 1 --vdi-width 1280 --vdi-height 960".

[Eero Tamminen]

Cr*p. I get crashes with TOS <= 2.x also with the new aligned screen size when there's >= 4MB of RAM. I just need to move cursor for several seconds in the 16x16 area of the Atari screen bottom right corner. In happens also with OldAUE CPU core, so it's not CPU core specific.

It happens also with Hatari v2.0. Can somebody tests older release down to v1.4 to see whether it's a regression, and if yes, when it happened?

Note: use "-s 4" command line option to specify memory size, don't rely on saved Hatari config file (as memory config option has changed as does config file location). For VDI size, you could use something like "--vdi-planes 1 --vdi-width 1280 --vdi-height 960".

Finally bisected the issue. It was a regression in Hatari v1.0 from 2007. I.e. the bug was >10 years old, and nobody apparently had noticed it before Hatari v2.1 release!

(I'm myself using VDI mode only with EmuTOS, not old TOS versions, so I couldn't trigger it in my own VDI mode usage.)

The weird thing with this issue was that the problem wasn't mouse pointer being in the 16x16 bottom right corner area, but moving to that area from the left. Moving within that area, and going to it vertically was fine, so it's some extra operation that older TOS versions do when mouse pointer is exactly at 16 pixel offset from the right border.

I've fixed the crash by adding padding (for the 16x16 mouse shape) between screen end, and end of RAM. With that I can't trigger it anymore, so I've removed the additional VDI screen width restrictions with >=4 MB of RAM and TOS <= v2.x.

[Emphii]

debugger2.PNG

debugger.PNG

I ran into weird problem with Mon030 and HAtari 2.1.0 pre-built for Windows.

Those two pics shows clearly that if I start debugger in similar version of HAtari, but 2.0.0, everything comes up fine and it can do the job - I can debug the code as wanted.
But - When I do just the same with 2.1.0, Mon030 "crashes" with Line-F exception and if I ctrl+c from it, first time is ok, but if I start debugger again, it crashes completely - I need to reset the "machine" to get further.

Debug window doesn't give any hint, what's going on.

It's probably unnecessary to mention, that both version of HAtari uses same configuration and TOS rom 4.04. Only HAtari version is changed.

[Eero Tamminen]

... both version of HAtari uses same configuration and TOS rom 4.04. Only HAtari version is changed.

I see from your screen shots that you have enabled MMU emulation.

One of them main difference between v2.0 and v2.1 is cache emulation with MMU. 2.0 didn't emulate cache when MMU was enabled.

To get approximately same behavior with MMU emulation with v2.1 as you had with 2.0, disable cycle exact mode.

[Emphii]

Thanks for the reply Eero. It still crashes, even I took MMU emulation and cycle exact off and in the end I tried with no "exacts".

But this time I got a lot of these to consolewindow:
PMOVE MMUSR,00000000 PC=000FC696 (this is every other line)
PTESTW 05,00000005,#7 PC=000FC690
PTESTW 05,00000006,#7 PC=000FC690
PTESTW 05,00000007,#7 PC=000FC690
PTESTW 05,00000008,#7 PC=000FC690
PTESTW 05,00000009,#7 PC=000FC690
PTESTW 05,0000000A,#7 PC=000FC690
PTESTW 05,00000000,#7 PC=000FC690
PTESTW 05,00000000,#7 PC=000FC690
PTESTW 05,00000001,#7 PC=000FC690
PTESTW 05,00000002,#7 PC=000FC690
PTESTW 05,00000003,#7 PC=000FC690
PTESTW 05,00000004,#7 PC=000FC690
PTESTW 05,00000005,#7 PC=000FC690
....
PTESTW 05,00000006,#7 PC=000FC690
PTESTW 05,00000007,#7 PC=000FC690
PTESTW 05,00000008,#7 PC=000FC690
PTESTW 05,00000009,#7 PC=000FC690
PTESTW 05,0000000A,#7 PC=000FC690
PTESTW 05,00000000,#7 PC=000FC690
PTESTW 05,00E00030,#7 PC=000FC690
PTESTW 05,00E00046,#7 PC=000FC690
PTESTW 05,00E00030,#7 PC=000FC690
PTESTW 05,00E00046,#7 PC=000FC690
PTESTW 05,00E00034,#7 PC=000FC690
PTESTW 05,00E0004A,#7 PC=000FC690
PTESTW 05,00E00038,#7 PC=000FC690
PTESTW 05,00E0004E,#7 PC=000FC690
PTESTW 05,00E0003A,#7 PC=000FC690
PTESTW 05,00E00050,#7 PC=000FC690
PTESTW 05,00E0003E,#7 PC=000FC690
PTESTW 05,00E00054,#7 PC=000FC690
....
PTESTW 05,00000008,#7 PC=000FC690
PTESTW 05,00000009,#7 PC=000FC690
PTESTW 05,0000000A,#7 PC=000FC690
PTESTW 05,00000000,#7 PC=000FC690
PTESTW 05,00E00030,#7 PC=000FC690
PTESTW 05,00E00046,#7 PC=000FC690
PTESTW 05,00E00030,#7 PC=000FC690
PTESTW 05,00E00046,#7 PC=000FC690
PTESTW 05,00E00034,#7 PC=000FC690
PTESTW 05,00E0004A,#7 PC=000FC690
PTESTW 05,00E00038,#7 PC=000FC690
PTESTW 05,00E0004E,#7 PC=000FC690
....
PTESTW 05,0000002E,#7 PC=000FC690
PTESTW 05,0000002F,#7 PC=000FC690
PTESTW 05,00000030,#7 PC=000FC690
PTESTW 05,0000002C,#7 PC=000FC690
PTESTW 05,00121454,#7 PC=000FC690
PTESTW 05,00121455,#7 PC=000FC690
PTESTW 05,00121456,#7 PC=000FC690
PTESTW 05,00121457,#7 PC=000FC690
PTESTW 05,00121458,#7 PC=000FC690
PTESTW 05,00121459,#7 PC=000FC690
PTESTW 05,0012145A,#7 PC=000FC690
....
PTESTW 05,00121C18,#7 PC=000FC690
PTESTW 05,000FE05C,#7 PC=000FC690
PTESTW 05,000FE05D,#7 PC=000FC690
PTESTW 05,000FE05E,#7 PC=000FC690
PTESTW 05,000FE05F,#7 PC=000FC690
PTESTW 05,000FE060,#7 PC=000FC690
PTESTW 05,000FE061,#7 PC=000FC690
PTESTW 05,000FE062,#7 PC=000FC690
PTESTW 05,000FE063,#7 PC=000FC690
PTESTW 05,000FE064,#7 PC=000FC690
PTESTW 05,000FE065,#7 PC=000FC690
PTESTW 05,000FE066,#7 PC=000FC690
PTESTW 05,000FE05C,#7 PC=000FC690
....
PTESTW 05,0013D382,#7 PC=000FC690
PTESTW 05,0013D383,#7 PC=000FC690
PTESTW 05,0013D384,#7 PC=000FC690
PTESTW 05,0013D380,#7 PC=000FC690
PTESTW 05,0013D384,#7 PC=000FC690
PTESTW 05,0013D385,#7 PC=000FC690
PTESTW 05,0013D386,#7 PC=000FC690
PTESTW 05,0013D387,#7 PC=000FC690
PTESTW 05,0013D388,#7 PC=000FC690
PTESTW 05,0013D384,#7 PC=000FC690

Well, it's not from the beginning.

And if I restart the Mon030, output is following and the emulation screen is garbage with the black background:
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A
Illegal instruction: 00e0 at 00000030 -> 0010341A

Should I move this subject separately? Or generate a bug ticket?

[Eero Tamminen]

Thanks for the reply Eero. It still crashes,

But this time I got a lot of these to consolewindow:
PMOVE MMUSR,00000000 PC=000FC696 (this is every other line)
PTESTW 05,00000005,#7 PC=000FC690

Mon030 does MMU instructions, so it requires MMU to be enabled.

even I took MMU emulation and cycle exact off and in the end I tried with no "exacts".

I can reproduce this. It doesn't happen on loading Mon030, but starting a program from it.

With Hatari v2.0 (MMU enabled), Mon030 stops at first instruction in the program after loading it with Pexec(3,...) and starting it with Pexec(4,...).

With Hatari Mercurial version, there's exception in Min030 code after Pexec(3,...) finished, on ptestw instruction, like seen in your screen shot.

It happens also when things are run from floppy image, so GEMDOS HD emulation stuff doesn't affect it.

Should I move this subject separately? Or generate a bug ticket?

Separate topic could be better.

note that we don't have a separate bug tracker, bugs are reported either to hatari-devel/hatari-users mailing list or here.

[Faucon2001]

I have build Hatari 2.1.0 latest snapshot for Ubuntu (14.04,15.10,16.10), and in every case the HD drive doesn't boot properly.
source : hg clone http://hg.tuxfamily.org/mercurialroot/hatari/hatari
I build it with default ./configure, make, make install and got no error.

Hatari boots normally on the HDD, launches auto and accessories if any, but the newdesk.inf is not read and therefore it boots in low res or mono with default settings. If I manually reload the saved newdesk.inf, the desktop setup is restored.
I have the same issue with ACSI and IDE images, with AHDI and HDDRIVER, and with both TOS 2.06 and TOS 4.04.
I suspected a corrupted image, so I did a new one, without any auto nor accessories, and got the same problem.
These ACSI and IDE HD images were booting correctly with Hatari 1.9.0.

Any idea?

[Eero Tamminen]

I'm able to reproduce this.

Hatari supports nowadays INF file overloading also for floppy/HD images, not just GEMDOS HD drive. When override is used without GEMDOS HD being C:, Hatari cannot just override suitable parts of the existing INF, it has to use Hatari default INF file (there are separate ones for TOS <v2, TOS >v2 and EmuTOS).

Unfortunately VDI mode handling seems to enable INF overriding even when VDI mode isn't set. I'll look how to best fix that.

In the meanwhile you can do autostart & resolution setting for the INF override with the Hatari options like this:

Code: Select all

--auto c:\desktop\desktop.prg --tos-res med

And e.g. add on your host PC a desktop shortcut of that. That should enable you to at least start your replacement desktop under Hatari 2.1.

[Faucon2001]

Thanks Eero, I’ll give a try
For Falcon mode how do you set boot resolution to vga 640x480 16 or 256 colors?

[Faucon2001]

It works as expected in TOS 2.06.
To make it work I had to put the path in capital letter and between comas, otherwise I had an error message at boot.
hatari --auto 'C:\DESKTOP\DESKTOP.PRG'

Now for the Falcon mode, how do you force a VGA mode at boot?

[Eero Tamminen]

Now for the Falcon mode, how do you force a VGA mode at boot?

I didn't find good documentation about Falcon screen mode setup in NEWDESK.INF file, so only ST/TT resolutions are currently supported by --tos-res.

I.e. for Falcon you need to have GEMDOS HD directory with suitable NEWDESK.INF file and boot from that. That, or Hatari "--auto" option with it, can then run programs from (other) drives mounted from HD images.

Only thing with which GEMDOS HD doesn't work is MiNT, as it hijacks the GEMDOS vector from Hatari.

PS. I haven't fixed the problem yet, it's way too hot in Finland for debugging & coding (been ~30C for couple of weeks, and it seems to be continuing for few more weeks), computer & monitor warm our apartment too much for that (this weather is so exceptional in Finland almost nobody has air conditioning).

[Eero Tamminen]

I commited a while ago a quick fix to Hatari source for this issue when VDI-mode is NOT in use. I'll think about better fix later.

[Faucon2001]

Thanks Eero, I’ll tive a try.

[Faucon2001]

I have tested the new build. It improves a bit vs the previous one.
TOS 4.04 falcon Mode, boots on IDE image and use C:\newdesk.inf as expected.
TOS 2.06 Mega STE Mode, and ACSI image boots using the standard INF and not the one on C:\.
At least I have temporary solution for the time being. Thanks.

[Eero Tamminen]

I have tested the new build. It improves a bit vs the previous one.
TOS 4.04 falcon Mode, boots on IDE image and use C:\newdesk.inf as expected.
TOS 2.06 Mega STE Mode, and ACSI image boots using the standard INF and not the one on C:\.

Are you sure about this? Whether INF file is overridden should have nothing to do with machine type or HD image type, only whether you enable VDI mode and whether you're using autostarting.

[ThorstenOtto]

I didn't find good documentation about Falcon screen mode setup in NEWDESK.INF file, so only ST/TT resolutions are currently supported by --tos-res.

It's encoded in the 5th and 6th value of the #E line, in the same way you would pass it to VsetMode. Problem here is that those values don't even exist if the file was written by TOS < 4.x, and apparently the desktop has a bug parsing it, sometimes resulting in a call to VsetScreen with a mode argument of 0x2000.

[Faucon2001]

Are you sure about this? Whether INF file is overridden should have nothing to do with machine type or HD image type, only whether you enable VDI mode and whether you're using autostarting.

Oops, I always use VDI extended mode with TOS 2.06. I didn’t read carefully your post

[Faucon2001]

Hi,
When you change from a configuration using VDI extended mode (large resolution like 1280x960) to a smaller standard resolution like standard mono or RGB color, the screen is not wiped out properly and the old screen remains visible at the top and below the new one. I have found this bug in Hatari 2.1.0 latest build from today, on Ubuntu 16.04.

[Eero Tamminen]

Hi,
When you change from a configuration using VDI extended mode (large resolution like 1280x960) to a smaller standard resolution like standard mono or RGB color, the screen is not wiped out properly and the old screen remains visible at the top and below the new one. I have found this bug in Hatari 2.1.0 latest build from today, on Ubuntu 16.04.

I can't reproduce this on Debian with SDL2 build of latest Hatari Mercurial version, with any of these:
* Switching from 640x480@16 colors VDI mode to 320x208@16 VDI mode
* Disabling VDI mode
* Using TOS v1.x desktop dialog (after reset, VDI resolution is still used)
* In EmuTOS resolution change option is disabled with VDI mode.

Can you provide more detail steps on how to reproduce?

[Eero Tamminen]

I can reproduce this. It doesn't happen on loading Mon030, but starting a program from it.

With Hatari v2.0 (MMU enabled), Mon030 stops at first instruction in the program after loading it with Pexec(3,...) and starting it with Pexec(4,...).

With Hatari Mercurial version, there's exception in Min030 code after Pexec(3,...) finished, on ptestw instruction, like seen in your screen shot.

It happens also when things are run from floppy image, so GEMDOS HD emulation stuff doesn't affect it.

Should I move this subject separately? Or generate a bug ticket?

Emphii, this seems to be fixed in the Hatari Mercurial version with latest MMU updates. Can you confirm?

NOTE: try with TOS v3 or TOS v4, EmuTOS seems to have some unrelated issue (cold boot crashes Hatari).

[Emphii]

I probably need to have it to hand from somewhere?

Btw. I ran in to problem with devpac56 dsp debugger. For some reason it runs ctrl+z always twice, no matter, if you press the keys or choose it from menubar. This happens on 2.0.0 and 2.1.0. I think it does that with other combinations as well, 'coz running code to breakpoint (ctrl+y) bombs and hangs. Just like if I forget to set breakpoint.

[Eero Tamminen]

Does Devpac "dsp debugger" use 56000.ttp? That is buggy, and works only with very low GEMDOS file handle values. Hatari GEMDOS HD emulation must use higher handle values to avoid mixing them with TOS ones.

Christian Zietz provided on hatari-devel mailing list details of the issue and a patched version of 56000.ttp that works around this bug:
https://listengine.tuxfamily.org/lists. ... reads.html

[Faucon2001]

I can't reproduce this on Debian with SDL2 build of latest Hatari Mercurial version, with any of these:
* Switching from 640x480@16 colors VDI mode to 320x208@16 VDI mode
* Disabling VDI mode
* Using TOS v1.x desktop dialog (after reset, VDI resolution is still used)
* In EmuTOS resolution change option is disabled with VDI mode.
Can you provide more detail steps on how to reproduce?

Host System : Ubuntu 16.04 amd64, SDL2.0.8, Hatari build from last week
Emulated system : STE 4MB TOS 1.62, ACSI HDD image and host filesystem
1 - boot this setup in extended VDI mode @ 1280x960 mono. Boot is ok, screen is ok, no issue
2 - From Hatari config menu, load a new configuration without VDI extended mode. Ex: STE low res RGB and reset the emulator
The old screen is not wiped out properly (See picture) :

[Emphii]

Does Devpac "dsp debugger" use 56000.ttp?

I'm not sure, if keyboard commands are related to filehandling, but Devpac uses mon56.prg as a debugger.

I've tried explained situation (starting from newdesk.inf and separately from program folder. The behaviour doesn't change.

[Eero Tamminen]

I'm not sure, if keyboard commands are related to filehandling, but Devpac uses mon56.prg as a debugger.

Ok, I found mon56.prg program from this package:
https://milan.kovac.cc/atari/software/d ... VPAC56.LZH

I haven't done any DSP code development myself. How mon56.prg actually implements DSP single-stepping (^Z)?

(Most of the debugging that 56000UM.PDF specification talks about, is about OnCE, on-chip emulation that seems to require extra HW wired to the DSP.)

At least mon56.prg seem to set trace bit, which means that instruction generates trace exception and DSP jumps to execute trace exception, but that doesn't mean that execution would stop... While I saw trace exception I didn't see any STOP or WAIT instructions, when tracing for them:

Code: Select all

hatari --trace dsp_state,dsp_interrupt --machine falcon --tos tos404.img ./mon56.prg

And when enabling DSP disassembly from Hatari debugger after entering mon56.prg:

Code: Select all

trace dsp_state,dsp_interrupt,dsp_disasm
continue

DSP seems to execute very large number of instructions for each "single-step".

NOTE: I'm not sure whether / how much Laurent has tested DSP trace/stop/wait functionality with native debuggers when writing the 56001 emulation, because Hatari's own debugger can be used for debugging (and profiling) both m68k & 56001.