Re: [hatari-devel] emutos-ram and GEMDOS drive emulation

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 03/07/2016 01:34 AM, Vincent Rivière wrote:
> I noticed that emutos-ram did not work with Hatari GEMDOS drive emulation.
>
> emutos-ram can be downloaded at the standard EmuTOS download place:
> https://sourceforge.net/projects/emutos/files/emutos/0.9.5/
>
> For memories, a first TOS is loaded from ROM. Then emutos-ram is loaded
> from disk and starts as a second OS. So Hatari needs to initialize the
> GEMDOS drive emulation a second time. But it doesn't.
>
> The attached patch, as a quick proof of concept, shows that the
> situation can be easily fixed.
>
> 1) Hatari must allow to initialize the GEMDOS emulation a second time

GEMDOS emulation requires Hatari cartridge image.  That invokes
GEMDOS initialization through "free" invalid opcode $a.

As far as I can see, there should not be any problems in
doing the init multiple times, *if* they really are system
initialization. [1]


> 2) The value of act_pd must be read from the current OS pointed by
> 0x4f2, not necessarily from the ROM header.

And this should be improvement on what the code currently does.

I also tested that both changes work fine with all TOS versions
for 1.00 to 4.04, including KaosTOS.


[1] One reason why additional invocations are currently prevented
could be that invalid opcode may get triggered also by something
else (than cartridge code), and then:

* LineA variable initialization (needed for VDI mode)
  doesn't anymore get correct values from A0 & D0.
* Systembase value used for basepage may then also be bogus.

According to Nicolas comment in uae-cpu/newcpu.c,
Transbeauce 2 demo does use that opcode, but it uses
it for protection, so it doesn't run with GEMDOS HD
emulation...


Thomas/Nicolas, any comments on this?


> I don't plan to work on a better patch, but this could be a starting
> point if someone wants to cleanly fix this.


	- Eero