Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Quake 2 port for DOS, now with HDA sound! (Announce)

posted by RayeR(R) Homepage, CZ, 01.07.2015, 14:17

> He actually just (coincidentally?) uploaded a new Watcom compile yesterday, and now Tab key (map) works.

I don't like pmode/w, it seems to always crash in v86 mode (emm/jemm). Maybe it could be stripped and subbed with something more friendly than this: http://rayer.g6.cz/1tmp/pmodewcrsh.png
In my case the map key didn't crash it, in WC version map didn't rendered properly but in DJGPP version did. Seems he updated only WC version, I'll try it.

DJGPP version in my case sometimes doesn't start too due instant corruption when UIDE was loaded but in other cases it run well, see below.

> I also tried under my old P4 (EMU10k1) but no sound. But Mpxplay doesn't work there either...

Did you have loaded the SB emulation drivers? In my case it doesn't work with them. The MPX drivers can handle SBL/SBA on it's own so I don't load any sound drivers (is doesn't work on new MBs anyway) and MPX, QuickView, QDOS... detects it and plays well. I know HDA is main stream but I think that dedicated SBA can offer more quality sound than any integrated crap so I prefer it. I didn't tested on my NTB yet...

Yesterday I more investigated the FS corruption by zdoom+UIDE, here's some observations:

* It doesn't depend on what XMM is used, it happens bot with himem and jemmex

* when UIDE is loaded (I use 256MB cache and with shuscdx for CD+DVD drives) and I run zdoom I got instant FS corruption everytime! - it's 100% reproducable. It may happen that zdoom even doesn't start or it happen when it's terminated. Then I type dir and got this:
http://rayer.g6.cz/1tmp/fscorruption.png
If I apply hardreset the corruption on C: drive is not permanent (zdoom create cwsdpmi.swp file on C:) but drive I: where the game is placed usually gets corrupted even with hardreset.

* when I disable UIDE and enable lbacache instead I doesn't see any problem. Even lba cache is faster for compilation (gcc make of qdos):

no udma, no cache:              6:54.91
udma, 256MB cache:              1:02.34
no udma, 8MB smartdrv WB:       0:28.73
no udma, 32MB lbacache TUNW:    0:27.74
udma, 256MB+32MB lbacache TUNW: 0:25.54


* when I enable UIDE together with lba cache the probability and severity of FS corruption is significantly less. Sometimes doesn't happen, sometimes I got few lost clusters but game was mostly playable. It's interesting how lbacache can affect this behavior because it's used more memory for caching - 32+256 that should logically increase probability that a random write from zdoom will hit it. Maybe it's because lbacache holds the data in its 32MB buffed and don't pass it to UIDE so often but what does lbacache differently than UIDE on XMS allocation? Unfortunatelly lbacache doesn't allow bigger buffer to have comparable size. I could try decrease UIDE cache size instead but even if it only decrease the probability of corruption it's still dangerous...

BTW Neozeed noticed on this: "I stopped using UIDE because it was corrupting write behind cacheing in some games (Quake 2 was one of them)"
I don't remember that any other program cause such problem with UIDE which I use for many years...

---
DOS gives me freedom to unlimited HW access.

 

Complete thread:

Back to the forum
Board view  Mix view
15108 Postings in 1358 Threads, 245 registered users, 13 users online (0 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum