[hatari-devel] Hatari patches for bitplane conversion + XBios Hatari control from inside the emulation

[Eero Tamminen]

Hi,

CCing hatari-devel as this may be of more general interest.

On Friday 03 July 2009, Thomas Huth wrote:
> Kåre Andersen <kareandersen at gmail.com> wrote:
> What do you think of this suggestion: I could add your converters to
> new files in the repository, and then make the #include statements in
> screen.c conditional like this:
>
> #ifdef ENABLE_SIMPLE_CONVERTERS
> #include "convert/low_simple_32.c"
> #else
> #include "convert/low320x32.c"
> #endif
>
> Then you just would have to add ENABLE_SIMPLE_CONVERTERS=1 to your
> Xcode project to use your new functions.

Others may also then test this to see whether there's any speed difference.
(not related to the unrelated frameskip issue you fixed)


> > I hope you can understand my dilemma - or even test this for yourself
> > at some other modern Mac with 10.5.x and Nvidia, ATI or (maybe) newer
> > Intel graphics if you still cant believe it... Or even prove me wrong
> > - I certainly would not mind! :)
>
> I really would like to understand the real reason for the slow down
> with the old converters ... it's really hard to believe that code that
> worked very well for many years suddenly causes so much trouble on a
> new operating system... But unfortunately, I don't have access to a
> modern Intel-based Mac.

I'd like to see the new code...


> > And again, I stress that the WinSTon converter code is more or less
> > impossible to maintain the way it is, and does not scale well. The
> > variable names and the overuse of macros makes it too hard to read -
> > at least for my taste (and from showing it to others, I know I am not
> > alone in thinking so)...
>
> I agree, it's ugly like hell, I also don't like it, but ... well, it
> works fine everywhere except for new Mac OS computers.

Having cleaned out third of the original asm->C conversion code earlier,
I do agree that it's ugly...  :-)

I think the thing that actually needs optimizations + support for missing
features is the VIDEL code though.


> By the way, now that you've mentioned maintaining patches, I remember
> there is another thing pending: Your extensions to the XBIOS for
> changing the configuration of Hatari. I have to say that I really don't
> like the idea of having so much XBIOS functions intercepted for
> configuring and debugging. But Eero Tamminen recently added some code
> to Hatari (control.c) which allows to remote-control Hatari from an
> external program. Now I've had the idea that this interface could be
> used for one XBIOS function, too. Intercepting only one XBIOS function
> with some few code would be still fine for me. It could look like this:
>
> /**
>  * XBIOS remote control for Hatari
>  * Call 255
>  */
> static bool XBios_HatariControl(Uint32 Params)
> {
>   Control_ProcessBuffer(STMemory_ReadWord(Params+SIZE_WORD));
>   Regs[REG_D0] = 0;
>   return true;
> }
>
> That's 1) much less code, 2) uses only one XBIOS function and 3) gives
> you also full access to all the other interfaces that control.c offers.

For example enabling and disabling the max speed at run-time happens
with the commands:
	hatari-option --fast-forward 1
	hatari-option --fast-forward 0

(instead of 1 & 0, one can use also true/false or yes/no.)

Best way to experiment with this API is using the "hatari-console.py"
from the python-ui/ -directory[1].  I just added "print msg" to
the send_message() method so that one can see the full commands.

NOTE: to use all hatari-console features, you need to install latest Hatari
(somewhere on your $PATH), otherwise it may run an older version of Hatari
which doesn't e.g. support all the debugger commands.


> Just have a look at Control_ProcessBuffer() to see how the strings
> should look like.

First one could look into Control_Usage():
---------------------
Supported commands are:
- hatari-debug <Debug UI command>
- hatari-event <event to simulate>
- hatari-option <command line options>
- hatari-enable/disable/toggle <device name>
- hatari-path <config name> <new path>
- hatari-shortcut <shortcut name>
- hatari-embed-info
- hatari-stop
- hatari-cont
The last two can be used to stop and continue the Hatari emulation.
All commands need to be separated by newlines.
---------------------


> Does that sound usable to you?

Sounds good to me.  If this API gets additional users, it could be reviewed
a bit too.  The current set of remote commands just grew when I added
new things and I'm not sure the set is most logical/orthogonal.

The only issue with it is that it doesn't allow querying of the current
values so that program could restore the settings afterwards.  Is this
a problem?


	- Eero

-------------------------------------------------
eerot at lenny:~/hatari/python-ui$ ./hatari-console.py
Configuration file /usr/local/etc/hatari.cfg not found.
close failed: [Errno 10] No child processes
RUN: ['hatari', '--control-socket', '/tmp/hatari-console-4732.socket']
Configuration file /usr/local/etc/hatari.cfg not found.
Hatari devel (Jul  3 2009), compiled on:  Jul  3 2009, 12:58:06
WAIT hatari to connect to control socket... connected!
************************************************************
* Use the TAB key to see all the available Hatari commands *
************************************************************
Building CPU table for configuration: 68000 (compatible mode)

hatari-command: console-help

Hatari-console help
-------------------

Hatari-console allows you to invoke Hatari remote configuration facilities
from console while Hatari is running and use TAB completion on their names.
The supported facilities are:

Command line options:
* --help
* --version
* --confirm-quit
* --configfile
* --fast-forward
* --mono
* --monitor
* --fullscreen
* --window
* --grab
* --zoom
* --frameskips
* --borders
* --statusbar
* --drive-led
* --spec512
* --bpp
* --vdi
* --vdi-planes
* --vdi-width
* --vdi-height
* --joystick
* --printer
* --midi-in
* --midi-out
* --rs232-in
* --rs232-out
* --disk-a
* --disk-b
* --slowfdc
* --harddrive
* --acsi
* --ide
* --memsize
* --tos
* --cartridge
* --memstate
* --cpulevel
* --cpuclock
* --compatible
* --machine
* --blitter
* --dsp
* --sound
* --keymap
* --debug
* --bios-intercept
* --trace
* --trace-file
* --log-file
* --log-level
* --alert-level
* --run-vbls

Keyboard shortcuts:
* mousemode
* coldreset
* warmreset
* screenshot
* bosskey
* recanim
* recsound
* savemem

Event invocation:
* doubleclick
* rightpress
* rightrelease
* keypress
* keyrelease

Device toggling:
* printer
* rs232
* midi

Path setting:
* memauto
* memsave
* midiout
* printout
* soundout
* rs232in
* rs232out

Debugger commands:
* address
* breakpoint
* cont
* cpureg
* disasm
* dspaddress
* dspbreak
* dspcont
* dspdisasm
* dspmemdump
* dspreg
* help
* loadbin
* logfile
* memdump
* memwrite
* savebin
* setopt

and commands to "pause", "unpause" and "quit" Hatari.

For command line options you can see further help with "--help"
and for debugger with "h".  Some other facilities may give help
if you give them invalid input.

hatari-command: dsp
dspaddress  dspbreak    dspcont     dspdisasm   dspmemdump  dspreg
hatari-command: dspreg
-> hatari-debug dspreg
DSP isn't present or initialized.
hatari-command: cpureg
-> hatari-debug cpureg
D0: 00000008 D1: 00006aee D2: 00002300 D3: 00000020
D4: 00000013 D5: 00000000 D6: 00000001 D7: 0000001c
A0: 0000a828 A1: 00feae82 A2: 0000a828 A3: 00001b1c
A4: 00003baa A5: 0000a828 A6: 000065c8 A7: 000065c4
USP=000061a0 ISP=000065c4 MSP=00000000 VBR=00000000
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3
FP0: 0 FP1: 0 FP2: 0 FP3: 0
FP4: 0 FP5: 0 FP6: 0 FP7: 0
N=0 Z=0 I=0 NAN=0
prefetch 00010008
00fcbf60: 4eb9 00fc b270 3f00 2079 JSR.L $00fcb270
next PC: 00fcbf66
hatari-command: quit
killed hatari with PID 4734
hatari-command:
Exiting as there's no Hatari (anymore)...
-------------------------------------------------