Eero Tamminen wrote: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 wrote: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.
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.
You do not have the required permissions to view the files attached to this post.
--
Emphii/Extream
Plain 14MB F030 with 2GB (was 4GB) CF-modification (mem from Lynxman,thx man)
2x SVI Spectravideo 328 MK2+SVI-904 Data Cassette station+SVI-606 Game Adapter
SVI Spectravideo 728 MSX+SVI-767TP
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?
--
Emphii/Extream
Plain 14MB F030 with 2GB (was 4GB) CF-modification (mem from Lynxman,thx man)
2x SVI Spectravideo 328 MK2+SVI-904 Data Cassette station+SVI-606 Game Adapter
SVI Spectravideo 728 MSX+SVI-767TP
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.
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:
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?
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).
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.
Faucon2001 wrote: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.
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.
Eero Tamminen wrote: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
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.
Faucon2001 wrote: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?
Last edited by Eero Tamminen on Sun Oct 28, 2018 10:26 pm, edited 1 time in total.
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.
--
Emphii/Extream
Plain 14MB F030 with 2GB (was 4GB) CF-modification (mem from Lynxman,thx man)
2x SVI Spectravideo 328 MK2+SVI-904 Data Cassette station+SVI-606 Game Adapter
SVI Spectravideo 728 MSX+SVI-767TP
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.
Eero Tamminen wrote: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) :
Eero Tamminen wrote: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.
--
Emphii/Extream
Plain 14MB F030 with 2GB (was 4GB) CF-modification (mem from Lynxman,thx man)
2x SVI Spectravideo 328 MK2+SVI-904 Data Cassette station+SVI-606 Game Adapter
SVI Spectravideo 728 MSX+SVI-767TP
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:
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.