Minimal multitask configuration for Hatari

[OL]

Hello Cyprian,

I have test again the configuration working fine last time (since my computer was shutdown so absolutely no change) and now it crash exactly as you!

This is quite strange, but there is even more strange:

I do F12, choose Emutos as ROM restart, reset machine, no more crash
Do again F12 choose your ROM 1.62, reset machine no crash too!

Better, I stop Hatari, launch again it, select your config and no crash too!

Totaly crazy.

thanks

[Cyprian]

maybe this application is buggy?

[OL]

maybe this application is buggy?

I think there is something Hatari don't like in your Hatari configuration, I have launch my configuration and your to compare, there is in your option
in CPU "cycle exact, slower", I have the same but as I can see in your configuration it is not take into account (I have verified I have exactly same exe and dll), in your configuration the speed is very very fast compare to my configuration, this something that surprised me this morning when I try new test, how is possible to go so fast with 8Mhz system, it is not, so there is an issue here in Hatari, I try to do exactly same Hatari configuration option with no success.
In your configuration I have already mention double click not work, while it work fine for me.

I restart this morning my computer, modify at start your config with TOS206 no crash but it not solved speed and mouse issue.

So I propose you to do for you a configuration from scratch for Windows and send you. I can't now but I try to do it for tomorrow.

Olivier

[Cyprian]

do you see ">>" between "FS and "REC" on the statusbar? If yes, press "Alt Gr" and "X" - this combination switch between normal/max speed

[OL]

do you see ">>" between "FS and "REC" on the statusbar? If yes, press "Alt Gr" and "X" - this combination switch between normal/max speed

Yes I see this, and if I do AltGr X, now Hatari looks work fine, with correct speed, double click and no crash!

Is it the same for you?

Olivier

[Eero Tamminen]

In general, "fast forward" (AltGr-X) shouldn't affect anything in emulated environment, it should appear faster only to host (as it skips VBL waits).

However, there's one thing where that does change things, which is that emulation running faster means that user input arrives at different rate than normally. Are you doing double clicking with (single) middle mouse button click, or by doing real double click with left mouse button? Latter will be impacted by fast forward, former shouldn't.

If crash happens only when you try to do real double click with fast forward, in normal mode you can try repeating it by doing clicks slower and with longer delay between the two clicks.

[OL]

Hello,

real double click is absolutely impossible. Crash is not link to double click.
I'm not able to reproduce all time crash, today impossible, no idea why, but probably nothing link to configuration

Very strange

Olivier

In general, "fast forward" (AltGr-X) shouldn't affect anything in emulated environment, it should appear faster only to host (as it skips VBL waits).

However, there's one thing where that does change things, which is that emulation running faster means that user input arrives at different rate than normally. Are you doing double clicking with (single) middle mouse button click, or by doing real double click with left mouse button? Latter will be impacted by fast forward, former shouldn't.

If crash happens only when you try to do real double click with fast forward, in normal mode you can try repeating it by doing clicks slower and with longer delay between the two clicks.

[Eero Tamminen]

Well, it's not just double clicks, all input from host naturally appears slower on the fast-forwarded emulation. With double click you would just have been able to check the issue easier (by comparing manual double-click and the middle-button emulation for it).

[paulwratt]

Hows this going Olivier, any updates?

[ThorstenOtto]

Are you doing double clicking with (single) middle mouse button click, or by doing real double click with left mouse button? Latter will be impacted by fast forward, former shouldn't.

But thats a bug in Hatari then. Double-click time should not be affected by emulated speed. The time between double-clicks is checked by the hz200 timer, if that timer suddenly runs too fast then there is something wrong.

I have the same problem here, with fast-forward i'm not able to do double-clicks. Most of the time i'm also not able to do single-clicks, since the desktop now thinks i want do drag files because, after the double-click time, the mouse-button is still reported as pressed. That makes fast-forward absolutely unusable.

[OL]

Hows this going Olivier, any updates?

No update as I consider it is not relative to the configuration but an option incompatible with system (Mint?, MyAES?) as it is only in this condition I see such issue, I not consider I should fix it, just not use this option I have not really understand, for me Hatari is a good emulator very helpful to simulate a real Atari computer and should stay like this.

If there is update it will be to fix some MyAES issues, I'm in audit code and I have found some bugs since last update, but there is still one bug known under firebee but unfrotunately I'm not able to reproduce today, when it will be fixed I will do an update of this configuration.

Olivier

[Eero Tamminen]

Are you doing double clicking with (single) middle mouse button click, or by doing real double click with left mouse button? Latter will be impacted by fast forward, former shouldn't.

But thats a bug in Hatari then. Double-click time should not be affected by emulated speed. The time between double-clicks is checked by the hz200 timer, if that timer suddenly runs too fast then there is something wrong.

hz200 still runs at same speed *within the emulation*.

What fast forward does, is remove the VBL wait that keeps host and emulation time in (approximate) sync i.e. emulation will runs faster, but only *in relation* to the host system.

(Some of the reasons why the sync is approximate, is because audio is buffered by libSDL / the host OS, your host and original Atari monitors are likely to have slightly, or in case of monochrome, not so slightly, different refresh rates etc.)

I have the same problem here, with fast-forward i'm not able to do double-clicks. Most of the time i'm also not able to do single-clicks, since the desktop now thinks i want do drag files because, after the double-click time, the mouse-button is still reported as pressed. That makes fast-forward absolutely unusable

Unusable for what? Main use-case for fast-forward is fast-forwarding the boring, *non-interactive* parts like TOS, application & games startups, and speed-viewing (non-interactive) demos.

While it can be used with interactive use-cases, obviously there are things that don't work so well when one disables host<->emulation sync.

GEM desktop should work fairly OK though:
* although TOS would interpret user's single click as dragging, items are kept as selected when the mouse button is released, so it's fine, and
* double clicking can be done with middle click (which Hatari emulates as something that TOS will interpret as double click)

For things that don't work so well, like text input, one can temporarily toggle/disable fast-forwarding, with AltGr-X.

(For text, input, one could also disable key repeat in fast-forward mode from Hatari options, but IMHO temporarily disabling fast-forwarding is just much more convenient.)

[wongck]

Unusable for what? Main use-case for fast-forward is fast-forwarding the boring, *non-interactive* parts like TOS, application & games startups, and speed-viewing (non-interactive) demos.

This is an excellent idea to skip boring stuff like a movie.
If you want to "see" the part you fast forwarded, then you have to slow down.

May be people using it like an accelerator?

[ThorstenOtto]

Unusable for what? Main use-case for fast-forward is fast-forwarding the boring, *non-interactive* parts like TOS, application & games startups, and speed-viewing (non-interactive) demos.

Unusable for GEM applications. I know that this is not the primary purpose for Hatari.

While it can be used with interactive use-cases, obviously there are things that don't work so well when one disables host<->emulation sync.

But it should. There are no reasons why this should not work. Basically, hatari with fast-forward should behave similar to Aranym. Otherwise i don't see a reason why you need a JIT compiler, as long as you are not running a 486 from the dates of Ataris, every PC should be able to emulate a 32Mhz Atari without it.

hz200 still runs at same speed *within the emulation*.

Nope it doesn't. Or more precisely, is runs at a speed that reflects the actual execution speed relative to the emulated 8/16/32Mzh. But that is IMHO wrong, a timer is a timer, it should run at 200hz, independent of the CPU. If you would use it to measure the CPU freq, currently it would always calculate the emulated CPU speed, even in fast-forward mode. You can try the attached program to see the effects.

[Cyprian]

Unusable for what? Main use-case for fast-forward is fast-forwarding the boring, *non-interactive* parts like TOS, application & games startups, and speed-viewing (non-interactive) demos.

Unusable for GEM applications. I know that this is not the primary purpose for Hatari.

FastForward is dedicated for games/demos and also for skipping time consuming calculation part in GEM application (e.g. rendering, booting, etc).

While it can be used with interactive use-cases, obviously there are things that don't work so well when one disables host<->emulation sync.

But it should. There are no reasons why this should not work. Basically, hatari with fast-forward should behave similar to Aranym. Otherwise i don't see a reason why you need a JIT compiler, as long as you are not running a 486 from the dates of Ataris, every PC should be able to emulate a 32Mhz Atari without it.

hz200 still runs at same speed *within the emulation*.

Nope it doesn't. Or more precisely, is runs at a speed that reflects the actual execution speed relative to the emulated 8/16/32Mzh. But that is IMHO wrong, a timer is a timer, it should run at 200hz, independent of the CPU. If you would use it to measure the CPU freq, currently it would always calculate the emulated CPU speed, even in fast-forward mode. You can try the attached program to see the effects.

that would destroy the main purpose of the FastForward idea

and actually there is no JIT in Hatari.

[Cyprian]

And just to clarify that FastForward subject.

"Fatal Error" message shows without that FastForward mode. I use FF only for booting process and as soon as the Desktop shows, I press "Alt GR" + "X" to toggle into normal mode.

[ThorstenOtto]

that would destroy the main purpose of the FastForward idea

It wouldn't. I'm only talking about timers here, not about CPU emulation. But of course it might be possible that it would interfere with timings of demos, when skipping their splash screen or whatever.

But at least the recent change of reporting the current Gemdos time from the internal timer instead of the host should be thought of again. That timer will not be accurate if interrupts are missed, and when using fast-forward, then create a file, that file will have a timestamp in the future, which is definitely a bug.

and actually there is no JIT in Hatari.

Hm ok. I thought there is, because its using the WinUAE emulation, but maybe that part just isn't used.

[Cyprian]

that would destroy the main purpose of the FastForward idea

It wouldn't. I'm only talking about timers here, not about CPU emulation. But of course it might be possible that it would interfere with timings of demos, when skipping their splash screen or whatever.

exactly, in case of demos, timers should be precisely synchronised with the CPU.

as I mentioned, in case of Hatari you are able to change CPU clock from 8 to e.g. 32Mhz or switch to Aranym, Gemulator, STEmulator, MagicPC/Mac etc.

[ThorstenOtto]

you are able to change CPU clock from 8 to e.g. 32Mhz

Yes but that means it will never run faster than a TT with 32Mhz. And Hatari is not *only* dedicated to games and demos, otherwise features like custom vdi resolutions, gemdos emulation, NatFeats etc wouldn't be needed.

or switch to Aranym, Gemulator, STEmulator, MagicPC/Mac etc.

Gemulator is a hardware solution. For MagicMAC i would need a MAC. MagicPC unfortunately does not work on my current machine (no idea why, tried it already sometimes). If you mean Steem with STEmulator, then that has the same restrictions as Hatari, and more. And if you ever looked at the sourcecode of Steem, you would not even mention it... I do use Aranym regularly, though. But Aranym only emulates a Falcon, and i need Mint to access the hosts filesystem, and sometimes i want to test some other TOS versions, too. Sometimes it would just be nice to have another alternative, because it is hard to tell wether it was your's fault or the emulator's.

[Eero Tamminen]

every PC should be able to emulate a 32Mhz Atari without it.

I guess you haven't tested any Falcon stuff.

My 3G Hz Intel i3 isn't fast enough to emulate Falcon (=16MHz CPU + 32Mhz DSP) at acceptable speed with more DSP intensive games & demos when using Hatari's (default & more accurate) WinUAE CPU core...

you are able to change CPU clock from 8 to e.g. 32Mhz

Yes but that means it will never run faster than a TT with 32Mhz. And Hatari is not *only* dedicated to games and demos, otherwise features like custom vdi resolutions, gemdos emulation, NatFeats etc wouldn't be needed.

GEMDOS HD emulation is very useful with games and demos. NatFeats support is there mainly for helping in their development, debugging etc. VDI resolution support is only (GEM) application specific feature in Hatari.

Aranym does have additional NatFeats features which are useful for applications, such as VDI & VFAT APIs, but those need extra drivers on the emulation side, so they aren't suitable for Hatari use-cases.

[paulwratt]

would it not be better (in this case) to provide timer="normal" as sub option for fast-forward (defaults to timer="fast-forward"or "sync"). I can see where sometimes it might be useful

Paul

[OL]

I prepare a new version of minimal multitask configuration, all looks work correctly now, but I try to have more memory for applications so I want remove most accessory (I can have up to 1.4Mo of free memory for 4Mo configuration), but I have an issue if I remove mintsetter.acc, Mint system send message on Pexec:

fork_proc1: kmalloc (26364) fail, out of memory?

with mintsetter application are launch correctly. Any idea of the reason?

Olivier

[OL]

Hello,

I just update the mini configuration

http://myaes.lutece.net/telechargement/myhatari.zip

no more Pexec issue now and I don't know why, if you have issue in 4Mo memory try reinstall accessory in ACC folder renaming them from .ac to .acc

In it there is final MyAES 0.97, I don't think there will have any more fix before I propose to download on MyAES website in some days.


Olivier

I prepare a new version of minimal multitask configuration, all looks work correctly now, but I try to have more memory for applications so I want remove most accessory (I can have up to 1.4Mo of free memory for 4Mo configuration), but I have an issue if I remove mintsetter.acc, Mint system send message on Pexec:

fork_proc1: kmalloc (26364) fail, out of memory?

with mintsetter application are launch correctly. Any idea of the reason?

Olivier

[OL]

Hello,

fix for Yopla display correctly under STLow (fix in Yopla and MyAES) - new archive updated

Olivier

Hello,

I just update the mini configuration

http://myaes.lutece.net/telechargement/myhatari.zip

no more Pexec issue now and I don't know why, if you have issue in 4Mo memory try reinstall accessory in ACC folder renaming them from .ac to .acc

In it there is final MyAES 0.97, I don't think there will have any more fix before I propose to download on MyAES website in some days.


Olivier

I prepare a new version of minimal multitask configuration, all looks work correctly now, but I try to have more memory for applications so I want remove most accessory (I can have up to 1.4Mo of free memory for 4Mo configuration), but I have an issue if I remove mintsetter.acc, Mint system send message on Pexec:

fork_proc1: kmalloc (26364) fail, out of memory?

with mintsetter application are launch correctly. Any idea of the reason?

Olivier

[OL]

The fix for Yopla was not good at all finally, there was possible issue redraw with icon in some case

I have updated the archive there is some other small fix.

Olivier

Hello,

fix for Yopla display correctly under STLow (fix in Yopla and MyAES) - new archive updated

Olivier

Hello,

I just update the mini configuration

http://myaes.lutece.net/telechargement/myhatari.zip

no more Pexec issue now and I don't know why, if you have issue in 4Mo memory try reinstall accessory in ACC folder renaming them from .ac to .acc

In it there is final MyAES 0.97, I don't think there will have any more fix before I propose to download on MyAES website in some days.


Olivier

I prepare a new version of minimal multitask configuration, all looks work correctly now, but I try to have more memory for applications so I want remove most accessory (I can have up to 1.4Mo of free memory for 4Mo configuration), but I have an issue if I remove mintsetter.acc, Mint system send message on Pexec:

fork_proc1: kmalloc (26364) fail, out of memory?

with mintsetter application are launch correctly. Any idea of the reason?

Olivier