|Re: [hatari-devel] emutos-ram and GEMDOS drive emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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:
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
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.
 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
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.