Re: [hatari-devel] Reload ROM/floppy on reset

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 04/10/2016 01:38 AM, Vincent Rivière wrote:
On 09/04/2016 22:06, Thomas Huth wrote:
That's maybe doable for ROM images, but I think it's not so straight
forward for floppy (and other writable) images:

Ah, I forgot the question about writable media.

My initial wish was about a developer working on a read-only media, such
as a custom ROM or a game/demo boot floppy. The kind of media which is
never written from the ST side.

For example, I'm currently working on the bootsector of emutos.st.
The Hatari debugger is a key tool to debug that stuff. But working
managing the floppy image in Hatari is a real pain:

Why not just restart Hatari?

"killall hatari && hatari <args>"


I have to go to the UI to eject it, then it loses the path, I have
to browse folders again... And finally rest...

You can script (almost) everything Hatari does.

In the debugger that would be:
------------
setopt --disk-a dummy.st
setopt --disk-a emutos.st
reset cold
------------

You can put it to debugger script and ask debugger
to parse that.

Notes:
* You need to change disk to get previous one ejected
* I got emulation freezes if I use "reset warm" and
  try to get back to debugger after reset. Better
  to do cold reset for now

Often I script my whole debugging session.  I update
the debugger script(s) and re-run Hatari with fast-forward
until the script & debugger provide the require info.
Memory snapshots speed up this process a lot, if all
the data files (TOS, disk images etc) can be kept same.


Btw. If you're on Linux[1], you can use Hatari control
socket and automate things through Hatari console instead
of Hatari command line arguments and debugger scripts.
With hconsole you can give even keyboard input, see:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/file/tip/tools/hconsole/example-commands


	- Eero

[1] If somebody contributes Windows socket support to
Hatari control.c, hconsole and hatari-ui (without embedding)
should work also on Windows.

On the other hand, Steem is much better regarding to this aspect. In the
cross-tools window, I just have to type "make". Then Alt+Tab to switch
to Steem, press the Reset hotkey, and voilà. Actually, I just miss a
debugger with Steem. IIRC, there was a special Steem Debug build, I
should try that.

By looking more closely, Steem sets some kind of lock on the floppy
image, as it can't be deleted while running. However, it can be written,
which can cause the kind of issues you described. But that's not a real
problem. Who is going to write to a floppy while an emulator is running?
No one, except developers who knows what they do.
If really unexpected data corruption is a problem, then there should be
an option to mount floppies as read-only (I look at the UI... it is
already here!). In this case, the whole floppy data could be cached in
RAM, and no need at all to lock the floppy image.

to be really save, you always have to eject the floppy image from the
emulator first before you change it directly in the host.

My wish would be that Hatari automatically does that on reset.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/