[hatari-devel] WinAUE wide chars usage and what to do with it?

[Eero Tamminen]

Hi,

(commenting just on the minor stuff)

On maanantai 17 tammikuu 2011, LAURENT SALLAFRANQUE wrote:
> I've probably removed too quickly some code that I should have kept
> from WinUae source to let hatari compile :
> - mainly in custom.c which is used for cycle_exact emulation
> - memory.c (for prefetch, I haven't understood yet what the new
>   parameters are for)
> - mmu.c (the c++ "try/catch" is probably not well implemented).
> I've kept on my disk the original source if someone need it.
> 
> I've always tried to keep in mind the following point : changing as
> little as possible the original Amiga code.

When counting number of separate modifications, most of them seem to
be changing WinUAE wide character strings to ASCII strings.  If we want to
significantly reduce the patch size, I think it would make sense just to
define/typedef TCHAR as wchar_t and use wide characters instead of patching
all strings in WinAUE.

wchar_t and functions to convert wide chars are in C99 spec.  To convert
such strings to ASCII[1], one can use wcstombs() and wcslen().   The code
for this isn't very pretty and it requires --std=c99, but it works.

[1] Actually to multibyte strings. I assume this means at least on Linux
    UTF-8[2], not UTF-16 or UTF-32, so with the strings used in WinAUE they
    should be same as ASCII (UTF-8 is same as ASCII for chars <127).

[2] This can be tested with the attached small program.  At least in Debian
     Testing it works fine.


> I don't know if WinUae's
> team has planed to make major changes in the main core part of their
> emulator in the next months, but maybe we can clean their code and adapt
> it to our needs. If we need to upgrade later, we can patch our code
> after applying "diffs" into their code and adapt the diffs into hatari.
> Anyway, the level of quality they reached may be suffisant for our own
> needs.
> 
> 
> For point b) :
> 
> I think we should first fix winUae'core to run at correct Atari's
> frequencies. Then, add again the pairing patch and the few Atari's
> specific code in newcpu.c For the pairing patch, does it apply also to
> the Falcon, or is it 68000 specific (as it impacts the cycles counting)
> ?
> 
> Then, test for any regression in the emulator (saving/restoring a
> snapshot, GUI param interface, command line options, ...).

I don't think there's any large isssues here.  You've already updated
CPU core snapshot stuff, added System dialog for WinAUE and command
line options for the new stuff.  Some of this could be fine tuned and it
needs to be documented but I think that's it. :-)


Btw. regarding save/restore, what's this UAE_NEWCPU_H stuff:
---------
#ifdef UAE_NEWCPU_H
                regs.prefetch_pc = regs.pc + 128;
#endif
        }

#ifdef UAE_NEWCPU_H
        MemorySnapShot_Store(&regs.prefetch, sizeof(regs.prefetch));  /* 
prefetch */
#else
        uae_u32 prefetch_dummy;
        MemorySnapShot_Store(&prefetch_dummy, sizeof(prefetch_dummy));
#endif
--------
?

Is it used with the new WinUAE core, the current AUE core, some old AUE core
we don't anymore use or Thomas' earlier aborted attempt at updating to
WinAUE?



	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wchar-test.c
Type: text/x-csrc
Size: 652 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110117/e0bcc2b5/attachment.c>