Reply 1400 of 2397, by hail-to-the-ryzen
Tried that and other tests. Can you enter a game from quick start?
Tried that and other tests. Can you enter a game from quick start?
I posted too soon. As soon as you start a game it appears to page fault within 5 seconds.
I'm not clear what's the cause here but it doesn't seem to be related to recursive pagefault fallbacks in CPU_CALL related to TSS or CPU_SwitchTask. As far as I can tell, no page fault occur in either place.
I saw one point at a MOV AL,[ESP+EBP*8] and another at a FILD WORD PTR [...] but I'm not sure of the cause.
It could just be that the game has race conditions between the main thread and audio playback that show up if the cycle count is too low.
That makes sense to me. I appreciate your time and effort with running the game demo. That prior guess I made must be a side-effect of testing. It only happened once whereas the fault inside W95 is consistent. I even tried to edit binaries at some point.
I recall now I traced one of the error's location to an accessory function in the game binary, too. I also did run pcem in interpreter mode but it doesn't fault.
Unfortunately, the last version of DOSBox-X still not support the sound for Rude Breaker.
I tried different settings for pc-98 fm board/irq/io port.
No problems with Neko Project II.
wrote:Unfortunately, the last version of DOSBox-X still not support the sound for Rude Breaker.
I tried different settings for pc-98 fm board/irq/io port.
No problems with Neko Project II.
The sound (support) is also ok with ePC-9801VM (Common Source Code Project)/T98-Next/Anex86/Virtual98/MAME[MESS]
The recent XMS improvements may have a role in the exit problem in the recent dosbox-x mingw32 builds. Maybe this would provide a guide to the code regions to test:
+++ dosbox-NEW//src/ints/xms.cpp
@@ -102,7 +102,6 @@ struct XMS_MemMove{
#pragma pack ()
#endif
-static int xms_local_enable_count = 0;
Bitu XMS_EnableA20(bool enable) {
Bit8u val = IO_Read (0x92);
@@ -205,22 +204,7 @@ Bitu XMS_MoveMemory(PhysPt bpt) {
destpt=Real2Phys(dest.realpt);
}
// LOG_MSG("XMS move src %X dest %X length %X",srcpt,destpt,length);
-
- /* we must enable the A20 gate during this copy.
- * DOSBox-X masks the A20 line and this will only cause corruption otherwise. */
-
- if (length != 0) {
- bool a20_was_enabled = XMS_GetEnabledA20();
-
- xms_local_enable_count++;
- XMS_EnableA20(true);
-
- mem_memcpy(destpt,srcpt,length);
-
- xms_local_enable_count--;
- if (!a20_was_enabled) XMS_EnableA20(false);
- }
-
+ mem_memcpy(destpt,srcpt,length);
return 0;
}
@@ -277,16 +261,6 @@ static bool multiplex_xms(void) {
}
-Bitu XMS_UpdateEnableFromLocalCount(void) {
- bool newstate = (xms_local_enable_count != 0);
- Bitu res = 0;
-
- if (XMS_GetEnabledA20() != newstate)
- res = XMS_EnableA20(newstate);
-
- return res;
-}
-
INLINE void SET_RESULT(Bitu res,bool touch_bl_on_succes=true) {
if(touch_bl_on_succes || res) reg_bl = (Bit8u)res;
reg_ax = (res==0);
@@ -310,22 +284,12 @@ Bitu XMS_Handler(void) {
break;
case XMS_GLOBAL_ENABLE_A20: /* 03 */
- SET_RESULT(XMS_EnableA20(true));
- break;
case XMS_LOCAL_ENABLE_A20: /* 05 */
- xms_local_enable_count++;
- SET_RESULT(XMS_UpdateEnableFromLocalCount());
+ SET_RESULT(XMS_EnableA20(true));
break;
case XMS_GLOBAL_DISABLE_A20: /* 04 */
- SET_RESULT(XMS_EnableA20(false));
- break;
case XMS_LOCAL_DISABLE_A20: /* 06 */
- if (xms_local_enable_count > 0) {
- xms_local_enable_count--;
- SET_RESULT(XMS_UpdateEnableFromLocalCount());
- } else {
- SET_RESULT(0);
- }
+ SET_RESULT(XMS_EnableA20(false));
break;
case XMS_QUERY_A20: /* 07 */
reg_ax = XMS_GetEnabledA20();
No, the XMS improvements are needed to keep EMS and XMS aware DOS applications from crashing or corrupting themselves.
The primary reason was to keep Windows 3.1 from crashing at startup or during install.
I fixed the exit problem in the MinGW build by adding SDL_Quit() just before the exit(0) call in E_Exit()
XMS drivers when copying extended memory need to do so with the A20 gate on, or else they will copy the wrong data. There is no requirement for the DOS program making the call to have enabled the A20 gate. Windows 3.1's installer (SETUP.EXE) in fact will happily load and store from extended memory while leaving the A20 gate off.
The same addition to EMS emulation is required because EMS emulation is based on the EMM386.EXE model of mapping pages from extended memory, which then needs the A20 gate on in order to map the right pages.
I had no doubt on your commits. I was only pointing out a problem spot I experienced where adding portions of the XMS commits to vanilla dosbox xms code. I didn't look further since dosbox-x further added many improvements to the A20 emulation, so I didn't verify whether the problem was incompatibility between builds or in the commit itself (much less likely scenario).
DOSBox-X - PC98 mode
Dear TheGreatCodeholio,
DOSBox-X should support the mouse in PC98 mode?
Example: Chaos Strikes Back
If yes, please can you tell me the correct settings (DOSBox.reference.conf) or upload the .conf file?
If the game uses the mouse via INT 33h, it should already be supported.
If it's like most games that talk directly to the mouse hardware, support is not quite there yet. NEC tied the bus mouse hardware to a 8255 PPI chip and DOSBox-X doesn't fully emulate that yet.
wrote:If the game uses the mouse via INT 33h, it should already be supported.
If it's like most games that talk directly to the mouse hardware, support is not quite there yet. NEC tied the bus mouse hardware to a 8255 PPI chip and DOSBox-X doesn't fully emulate that yet.
Thanks for the answer, TheGreatCodeholio
I think the Chaos Strikes Back (.fdi) support directly the mouse hardware.
It is a pity.
wrote:wrote:If the game uses the mouse via INT 33h, it should already be supported.
Can you tell me a title (game) which support the mouse via INT 33h for a double check, please?
wrote:The PC-98 port of "Marble madness" appears to be one (and so far only that I've found) game on the PC-98 platform that uses INT 33h
I tried Marble Madness.fdi.
I am not able to mount the disk, maybe my lines are wrong.
[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
IMGMOUNT c "c:\Emulator\PC DOS\DOSBox-X\Software\Floppy Disk\Marble Madness.fdi" -t floppy
C:
DOSBox-X - PC98 mode
Marka I/バイオひゃくパーセント (Bio 100%) - Floppy Disk
Looks good.
Sound is nice.
wrote:I tried Marble Madness.fdi. I am not able to mount the disk, maybe my lines are wrong. [autoexec] # Lines in this section will b […]
wrote:The PC-98 port of "Marble madness" appears to be one (and so far only that I've found) game on the PC-98 platform that uses INT 33h
I tried Marble Madness.fdi.
I am not able to mount the disk, maybe my lines are wrong.
[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
IMGMOUNT c "c:\Emulator\PC DOS\DOSBox-X\Software\Floppy Disk\Marble Madness.fdi" -t floppy
C:
OK, I created a new floppy disk image.
The INT 33h is working.
No sound (soundboard is not installed)
wrote:The PC-98 port of "Marble madness" appears to be one (and so far only that I've found) game on the PC-98 platform that uses INT 33h
I've found another one.
Photo Genic by Sunsoft