Mail Archive - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Previous | Next

From: Crown (all posts)
Date: 1998-05-21
Subject: EMU bugs

Hi,

Zsolt:
I've found some bugs in EMU v0.43.

Thanks for the 512x384 mode. :)
There is a small problem with it, that in this mode, the keyboard handling in the interface (loading, debugger, etc...) is a bit fast. I mean, it doesn't have the normal repeat mechanism. In the other modes this works ok. I like fast keyboard response, and always set it to the fastest rate,
and to the lowest delay values, but this is too fast even for me. :-)
Another keyboard issue (this also applies to Minus4), is when you load a file, the enter key which was pressed during the interface, goes through to the emulator as a Plus4 key press. Somekind of separation would be nice here, for example that key is not available for the emu until it's released..

Vesa 2.0 issue: my video card doesn't supports 360x240x8 bit, still I can start the EMU with /3, it turns on I guess somekind of 640x480x8.
>From this I think, that either your video mode checking routine is buggy,
or you simply took the mode number used by SDD for the video modes,
and you simply turn it on without checking if it exists or not.
If the last is the case, note that under Vesa 2.0 the mode numbers are not fixed, you have to query the Vesa interface for the available video modes, and you have to find in this list the mode which fits your resolution requirements. Different vendors can use different mode numbers for the same resolution, so it's not guaranteed that your prg would run on all cards.

I also noted that you increment $ff1d when the value of $ff1e changes from
$e2 to $0. Well this is not the case. $ff1d increments when $ff1e changes from $c2 to $c4.

Also I think you classify the line types not correctly, the emulator was in line $d0, in fast mode, and still a CPU instruction took twice the time it should.

I also noted, that the conditional branch instruction are emulated as
2 cycle instruction even when the branch was taken. These instruction family takes 2 cycles when the branch is not taken, 1 more cycle when the branch is taken, and even 1 more if the branch is taken, and the branch target is crossing a 256 byte page boundary.

Tibor Biczo / Crown of GOTU