VOGONS

Common searches


First post, by Scali

User metadata
Rank l33t
Rank
l33t

I was experimenting with tweakmodes in CGA, and found that composite mode apparently had some hardcoded width value, since the scanlines were shifted.
I have located the bug in vga_draw.cpp.
In the function VGA_CheckScanLength(void), there is the following code:

case M_CGA16:
vga.draw.address_add=80;

That is never going to work for tweakmodes, obviously. Replace that with this, and things should be fine:
case M_CGA16:
vga.draw.address_add=vga.draw.blocks;

The weird thing is... the code works properly when composite is not enabled, even though, judging from this, it shouldn't. Haven't found that code yet. Seems odd. For all other modes, the address_add is calculated off vga.draw.blocks anyway, which is properly calculated from the CRTC-values, and as such, responds correctly to tweaks.

Edit: Found why it worked in regular CGA modes...
The 4-colour 320x200 mode is M_TANDY4, not M_CGA4 as I assumed. And the code for M_TANDY4 was already correct.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 3 of 18, by Scali

User metadata
Rank l33t
Rank
l33t
truth5678 wrote:

Codeholio already properly fixed that CGA issue: https://github.com/joncampbell123/dosbox-x/co … 060be1886ec617b.

Sorry, I don't keep track of each and every custom branch of dosbox. In the official SVN it is not fixed yet.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 4 of 18, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Relax, store away the flame thrower, truth merely pointed it out as a reference for the developers.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 5 of 18, by Scali

User metadata
Rank l33t
Rank
l33t

Well, I am not sure what 'properly fixed' implies... Is my fix not 'proper'?
Anyway, whatever the case may be, hopefully the fix will be merged into the main SVN soon.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 6 of 18, by truth_deleted

User metadata

Codeholio fixed the above issue last summer and it is in both his dosbox-X and also in Ykhwong's build of dosbox (http://ykhwong.x-y.net). Codeholio has made hundreds of patches, including to the video emulation, and he tests against actual hardware, so it is reasonable to test against his build where there is an issue. Dosbox-X is located in this patches subforum.

Reply 7 of 18, by Scali

User metadata
Rank l33t
Rank
l33t

Well, yes, I'd have to look into composite some more. There's this huge discussion thread on it, also discussing proper support for all palettes.
I don't think that went into the mainline of Dosbox yet... certainly not yet in the latest release (0.74).

But with all these huge threads it's difficult to keep track of things.

I have tested Dosbox-X for the DMA issue in Crystal Dream. The Goldplay workaround detects what the demo tries to do with DMA, but it doesn't fix the issue... It stops after playing for about 1 second.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 9 of 18, by Scali

User metadata
Rank l33t
Rank
l33t
Scali wrote:

I have tested Dosbox-X for the DMA issue in Crystal Dream. The Goldplay workaround detects what the demo tries to do with DMA, but it doesn't fix the issue... It stops after playing for about 1 second.

Small update: originally I thought the problem was PIC-related, since you get the following messages during the demo:
PIC:ICW4: 1f, special fully-nested mode not handled
PIC:ICW4: 1d, special fully-nested mode not handled
PIC:ICW4: 1f, special fully-nested mode not handled

However, as I tried to debug it further, it seems that the SB should be in autoinit DMA mode, but for some reason it is not recognized as such by DOSBox.
I will have to investigate the actual code of the demo to see what mode it tries to set, and why it works on a real SB, but not in DOSBox.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 10 of 18, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

A comment from h-a-l-9000 regarding Triton's Fasttracker, which has similar audio options to their Crystal Dream demo:

h-a-l-9000 wrote:

they use a hack so they need not much different code for both soundblaster and LPT-soundplayer. There they set the DMA transfer size to 1 and swap the data at that location continually. You can safely use soundplayer (stereo) as output as it will be the same quality under these circumstances (turn the rate down if it takes too much CPU).

I think it's useful info about what Triton did, and a plausible explanation for why they did it -- also points out that the SB options (when fully supported) probably won't sound better than the soundplayer options, in case that comes as news to anyone.

Reply 11 of 18, by Scali

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

I think it's useful info about what Triton did, and a plausible explanation for why they did it -- also points out that the SB options (when fully supported) probably won't sound better than the soundplayer options, in case that comes as news to anyone.

Well, Crystal Dream is a very early demo, and the SB routines are very buggy. The detection routine did not even work on real hardware with a fast 486 or Pentium, so I fixed that earlier: http://scalibq.wordpress.com/2012/03/14/oldsk … ol-demo-fixing/

It still didn't work on DOSBox though... The thing you describe is true... but DOSBox-X already has a 'goldplay' mode to work around that.
As I dug further, I found that the autoinit functionality is not entirely the same as on a real SB. DOSBox seems to handle various commands exactly the same. It sends 0x14, which DOSBox handles the same as 0x15 and 0x91. Apparently real hardware works slightly differently.
Hacking the code a bit, I could make it work.
But then I wanted to try it with DOSBox-X and its 'goldplay' mode. And when inspecting its code, I noticed that the problem with command 0x14 was already analyzed earlier, and a workaround was implemented in DSP_PrepareDMA_Old():

if (sb.dma.force_autoinit) autoinit = true; […]
Show full quote

if (sb.dma.force_autoinit)
autoinit = true;

/* Hack for Crystal Dream and any other bozo implementation that spams the DSP
* with command 0x14: if we're already playing audio, don't setup audio playback
* again. the reason this is important is that this setup process sets the mode
* to DMA_MASKED, which gives the mixer callback an opportunity to insert silence
* and cause popping and crackling. */

So, DOSBox-X, when you enable both goldplay and force-autoinit, will play Crystal Dream correctly. It doesn't need my fix, since my fix is because a real DSP responded too slowly on a fast CPU. I have replaced the whole init code with a more reliable routine based on an example in the SB documentation. The emulated DSP in DOSBox responds immediately. My fixed version works fine though.
It just looks like DOSBox-X won't play in stereo with SB Pro though (it does on real hardware, as you can hear in my capture).

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 13 of 18, by Scali

User metadata
Rank l33t
Rank
l33t
truth5678 wrote:

Is this commit helpful in addressing the last point about SB Pro stereo support?
https://github.com/joncampbell123/dosbox-x/co … 272c87e6e99845c

I downloaded the latest version of the code yesterday, so this code should already have been in there. I will have to trace through it a bit to see what Crystal Dream tries to do exactly, and why it doesn't trigger stereo.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 14 of 18, by Scali

User metadata
Rank l33t
Rank
l33t
Scali wrote:
truth5678 wrote:

Is this commit helpful in addressing the last point about SB Pro stereo support?
https://github.com/joncampbell123/dosbox-x/co … 272c87e6e99845c

I downloaded the latest version of the code yesterday, so this code should already have been in there. I will have to trace through it a bit to see what Crystal Dream tries to do exactly, and why it doesn't trigger stereo.

Okay, just ran through the code snippet you posted in the debugger... and noticed my mistake: that workaround is specifically for SBPro1/2 configurations, and I accidentally had my configuration set to SB16 (the default).
Changing to sbpro2 made it play in stereo, as it should.

Edit: Here is a link to a discussion with Codeholio when he was fixing that issue: DOSBox-X branch

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 15 of 18, by Scali

User metadata
Rank l33t
Rank
l33t
truth5678 wrote:

Codeholio fixed the above issue last summer

Well, either he didn't fix it properly, or there is a bug elsewhere... If I run my code with my patched DOSBox, it works. If I run it on DOSBox-X, I just get a black screen.
The code works fine on a real IBM 5160 with real IBM CGA card.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 17 of 18, by Scali

User metadata
Rank l33t
Rank
l33t
truth5678 wrote:

Report bugs in dosbox-x to the dosbox-x thread. The purpose of this forum is to advance emulation, not to try to prove others wrong or right.

I'm just giving an update because I didn't actually test the DOSBox-X code yet for this issue. You claimed it was 'fixed properly' in DOSBox-X. I'm just giving an update that it is in fact NOT working correctly in DOSBox-X, despite what was said earlier in this thread.
This is not about proving others wrong or right, but about giving correct info, should other people find this thread later.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/