TheGreatCodeholio wrote:

It's been a busy week! […]
Show full quote

It's been a busy week!

To answer some questions:

Yes, I will add a keybinding for the Brazilian key to generate that scancode. I'm also up for adding a configuration option in DOSBox on what to do with F13-F24.

The TVGA8900 just arrived at my place according to Ebay, so I might get around to checking to make sure the card works and testing it this weekend.

I'm not sure I implemented the Read Capacity command correctly, because documentation is so sparse on the internet. It might be best at this point to add a test routine in DOSLIB's IDE utility to use the command and see what happens. Not sure if that has anything to do with NT and CD-ROM.

At this time there's no such _EGA_LINE_DOUBLE constant in DOSBox-X, I'll see what differs between DOSBox-X and DOSBox SVN. Expect the two projects' VGA emulation to diverge quite a bit because I think there's a lot about DOSBox's VGA raster emulation that needs to be cleaned up.

The problem with setjmp/longjmp is that if you jump out of a function using C++ objects on the stack those objects are not given a chance to free (unless you jump back). Using setjmp/longjmp with C++ is not a good idea. At the same time I would agree some of the throw/catch stuff is not quite the right way to do things, and I need to clean that up. There needs to be a way for the CPU to decode instructions according to virtual memory with potential for page misses, without page faults and recursion interrupting CPU instructions out of the blue. I think that if CPU instruction decoding were written to be restartable, while using variations of mem_readb() that could return boolean false instead of going through with a page fault, that might allow better design, then the page fault mode would not need to throw an exception the way it does.

nvm, I have fixed it alone 😉

Alright I've been testing a new program in the DOSLIB that attempts to capture the "raw" planar contents of VGA RAM to help verify DOSBox's VGA emulation.

Part of the reason I've been doing this is that this code in the VGA chained emulation really bothers me:

1class VGA_ChainedVGA_Handler : public PageHandler {
2public:
3        VGA_ChainedVGA_Handler() : PageHandler(PFLAG_NOCODE) {}
4        template <class Size>
5        static INLINE Bitu readHandler(PhysPt addr ) {
6                return hostRead<Size>( &vga.mem.linear[((addr&~3)<<2)+(addr&3)] );
7        }

Emphasis on the: ((addr&~3)<<2)+(addr&3)

I have to admit, when I saw that my first response was "WTF??". I thought that chained vs unchained differed by whether or not writes went through the bit planar logic.
But as I tested the program on various ATI, S3, Trident SVGA and even a Compaq I noticed the same pattern that chained 256-color really does mean "4 pixels across 4 8-bit planes which for some reason are stored every 4 bytes in video RAM".

So far the only exception is a Tseng ET4000AX card in one of my test machines. It appears to store each 4th byte sequentially in planar memory instead of every 4th byte on every 4th byte in planar memory.

That also matters to me because there are several DOS demos in the 1992-1993 timeframe that seem to have problems zeroing video RAM properly (you see garbage on the screen in some parts) and I was wondering if it was simply that the demo coders coded some VGA planar hack around the ET4000 to quick-zero RAM, and they never considered other SVGA cards?

What do you think?

The effect I'm describing with chained layout is also visible in the latest YouTube video I posted where I play with the VGA registers on an S3 Virge DX PCI card, notice what happens when you set INT 10h mode 0x13 and then change the CRTC from dword mode into byte mode: 16 pixel groups with 4 pixels of the chained packed pixels and 12 pixels of whatever happens to lie there in VRAM.

I will be posting to Hackipedia.org the snapshots of VRAM and registers taken from various SVGA cards so that you can look at them yourself if it helps.

SA1988: Cool. Will you be posting a patch for me to integrate into DOSBox-X?

Update: I just added code to DOSBox-X that uses an alternate VGA chained emulation for machine=svga_et4000 that acts as described above. It didn't fix as many glitches as I hoped, but it seems to fix the garbage on the screen for the "Optic Nerve" demo. Perhaps the Optic Nerve programmers wrote screen-clearing code that assumes an ET4000.

sure, and can you please do me a small favor? Can you make some diff about the pcap handling from dosbox-x as I plan networking on PCem with the NE2000. 😉

Thank you for providing robust VGA chained emulation for the ET4000! I learned a lot from your video and the process of discovering how the video modes work in real hardware. It also revealed causes of graphical glitches from different modes and parameter settings. It also shows the importance of "standards", such as VESA, which specify how hardware works. I presume that VGA chained mode was not clearly specified by a "standards" committee.

Can I trouble someone for a little more info about getting redbook audio to work in Windows 95? I was able to use Dosbox-X and mount Pitfall but the frame rate is extremely slow and the sound stutters. Here's what I've done, please tell me what I'm missing

- Windows 95A
- VBEMP video driver
- SB16 driver
- CPU type pentium_slow (and auto)
- video output SVGA_S3
- imgmount 2 "./pitfall.img" -size 512,63,25,520 -t hdd -fs none
- imgmount D "./pitfall.cue" -t iso -fs iso -ide 2m
- memsize = 63 (and 128)
- cycles = max
- video output = surface
- [ide, primary]
enable=true
- [ide, secondary]
enable=true

For giggles I tried 95B and 95C but both would crash before even allowing me to test Pitfall.

I also tried to use daemon 3.47 instead of image mounting pitfall via the IDE routine but it would lock.

Thanks!

First off, try using a fixed amount of cycles with the dynamic CPU core (e.g. cycles=fixed 35000). Second, try typing imgmount D ".\pitfall.cue" -t cdrom -ide 2m. At least that's how I got CD Audio to work on a different game, so I can't say for myself with yours. I think at the time I was using Windows 98 and an older revision of DOSBox-X integrated in Taewoong's SVN-Daum build from last January. Note too that I used the default direct3d video output that those builds have.

Hope this helps!

Thanks for pointing out my mistake; I changed the line from ISO to CD-ROM.

I also tried fixed cycles and the results were interesting. At around 12K the CD music stopped skipping. However the game's frame rate slowed to a crawl. I imagine this will be a problem with any game if a fixed cycle rate is required. I don't see any solution to this.

Just so you know, the game will apparently run without DOSBox in Windows 95 compatibility mode as long as you apply the correct patch. There's a link in Game will ONLY work with CD in drive .

Pitfall works great for me. I'm using ykhwong's build from january 27th and a minimal installation of Windows 95B. I followed the instructions described in this topic to build it: Minimal install for DOSBox/95 gaming

Windows 95 appears to recognize only two IDE devices (the HD as primary IDE and 2 CD-ROMs as secondary). I have a game with 6 CDs. Is this even possible:

imgmount d disc1.iso -t cdrom -fs iso -ide 2m
imgmount e disc2.iso -t cdrom -fs iso -ide 2s
imgmount f disc3.iso -t cdrom -fs iso -ide 3m
imgmount g disc4.iso -t cdrom -fs iso -ide 3s
imgmount h disc5.iso -t cdrom -fs iso -ide 4m
imgmount i disc6.iso -t cdrom -fs iso -ide 4s

In 95 only drives D and E are visible. The other 4 mappings are appear in the dosbox console but do not follow through to Windows 95. Am I wishing for the impossible?

apollo18 wrote:

Windows 95 appears to recognize only two IDE devices (the HD as primary IDE and 2 CD-ROMs as secondary). I have a game with 6 CD […]
Show full quote

Windows 95 appears to recognize only two IDE devices (the HD as primary IDE and 2 CD-ROMs as secondary). I have a game with 6 CDs. Is this even possible:

imgmount d disc1.iso -t cdrom -fs iso -ide 2m
imgmount e disc2.iso -t cdrom -fs iso -ide 2s
imgmount f disc3.iso -t cdrom -fs iso -ide 3m
imgmount g disc4.iso -t cdrom -fs iso -ide 3s
imgmount h disc5.iso -t cdrom -fs iso -ide 4m
imgmount i disc6.iso -t cdrom -fs iso -ide 4s

In 95 only drives D and E are visible. The other 4 mappings are appear in the dosbox console but do not follow through to Windows 95. Am I wishing for the impossible?

I suspect that since tertiary and quaternary IDE controllers were uncommon on actual PCs, Windows 95 isn't looking for them. You may have to attach the CDs to those IDE controllers and then ask Windows 95 to scan for new hardware to detect them, or go to "add new hardware" and manually install the standard IDE driver directed at port 0x1E8/IRQ 11 and port 0x168/IRQ 10.

How would I do the former, attach the CDs to the IDE controllers? I tried adding 'Standard Dual PCI IDE Controller' but I couldn't change the port ot 01e8 as Windows said it is invalid. I don't think I'm doing this correctly so can I bug you for a little more info?

apollo18 wrote:

Am I wishing for the impossible?

Surely it's a bit outlandish? I don't think anyone had six CD-ROM drives whenever this game you are trying to play came out. Even then, the game will probably expect you to eject disc 1 and insert the next disc into the same drive when required; I don't think I've ever heard of a multi-disc game that will just let you specify that the next disc is present in another drive.

Also, if this is a well-known game like Phantasmagoria, there's probably some way to avoid using the CDs entirely.

The game does recognize more than 1 CD drive (Dark Side of the Moon). The reason I need to do this is the Control F4 CD switching doesn't appear to be working. The console shows the message that the new disc was loaded and that the cache was reset but it isn't reflected in Windows.

The game has identical file names on each CD so I can't copy the data to a single directory.

Jorpho wrote:

Also, if this is a well-known game like Phantasmagoria, there's probably some way to avoid using the CDs entirely.

Ya think 😉 ? http://sierrahelp.com/Patches-Updates/NewSier … #Phantasmagoria

Um... didn't TheGreatCodeholio spend a lot of time debugging CD disc swapping within DOSBox? Coulda sworn I read that somewhere...

Yes, I read that too, but it hasn't worked using ISOs or BIN/CUE versions of the Cds. The console shows the swap but Windows 95 does not see it. I tried both dosbox-x and the latest daum build.

apollo18 wrote:

The game does recognize more than 1 CD drive (Dark Side of the Moon).

Ah. That'd be a rare one then.

Daemon Tools is still an option, isn't it? I seem to recall it has no particular restrictions on the number of drives that can be added. It's worth a try just to see if it works at all.

The problem with Daemon is the resulting image size would be 4 GB.

I think you misunderstand Jorpho. You can add additional drives with Daemon, each with one of your existing ISOs. This would take up no more space that what you are trying to do, outside of what is required for Daemon itself.