vicg had sent me a pm a while ago that he had dug out his old hardware and was running without any problems on real DOS, so there shouldn't be any problems with file corruption.

For video only:

With EMS off for the main program (PCB-LARGE option removed), everything ran fine for me at 800x600. That would be Paradise and boards that are ET3000 and ET4000 based with DOSBox pvga1a and et4000 settings, respectively. DOSBox's videoram settings are 512 for pvga1a and 1024 for et4000 (Vasyl's recommendations).

The only thing that worked at 1024x768 was the Orchid ProDesigner II (which is an ET4000 board) setting with the DOSBox et4000 setting (and videoram=1024).

With the PCB-LARGE option installed, I get the EMS memory problem even when running at IBM VGA 640x480 although I was still using the HAL9000 CAD Edition with Vasyl's code.

Check with Vasyl, he had seen what was wrong with the Paradise and ET3000 settings above 800x600. I think it has to do with not supporting dual banks (DOSBox Paradise) and lack of bank switching (PADS-PCB ET3000) so only 64KB are available which limits the video to 800x600 for those drivers.

Hope this helps.

That's right. With "Tseng VGA" selection the driver did not do any bank switching -- that works for 16-color 800x600 but fails for 1024x768 modes that don't fit into 4x64K. Unfortunately, couldn't test it on real hardware, my monitor did not like the video mode for some reason (hmm, 1920x1200 is not a problem but 1024x768 is out of range, go figure). At first I suspected that some Tseng cards had a BIOS call to switch banks but I could not find anything like that in any available documentation.
My PVGA1A implementation is very basic. Originally intended to support very particular game (Wonderland, supports PVGA and VEGA but nothing else), so the functionality is limited. I am thinking about revisiting it and adding whatever is missing. It would be rather tricky at the time I wrote that code first but there were a few architectural changes in DOSBox memory handling that should make it much easier.

Adding this mode to pvga makes it work in 1024x768.
{ 0x05D ,M_EGA ,1024, 768, 128,48 ,8, 16,1, 0xA0000, 0x10000,128 ,800 ,128, 768 ,0 }

I've tried the Tseng 1024x768 setting (30) with real hardware {edit: with ET3000 and 4000} and it didn't work there either. It also still didn't work when switching back to the Orchid II, had to choose IBM and then Orchid II to make it work again.

Maybe some special config.sys settings or DOS version is needed?

😦 Should've checked that... Technically speaking, PVGA1A did not support 1024x768, so I did not put that mode line there. On the other hand, there are only very minor register-level differences between PVGA1A and WD90C00, and the latter supported 1024x768. C00 and later cards were by far more common so this app just assumed the mode as available.

The Numlock issue has something to do with the mapper not being aware of the Numlock state at program start. Capslock has the same issue.
To Reproduce:

Turn capslock on, start DOSBox.
type A -> get A
press capslock
type a -> get A <---
press capslock
type A -> get A
press capslock
type a -> get a

Not a problem of the mapper, but the lower layers (SDL/windows).

Hmm we do get the first capslock depress but I think it disappears in sdl_mapper line 239

1if (!active) return;

.
Active should be true if capslock was on while starting DOSBox (in sync with startup_state_capslock).

Dunno if that startup checking really works, and with the sdl windib
it gets even more screwed up.

At least with usescancodes=true it does. We do get uppercase letters at start. The keycode it gets for 'a' isn't depending on capslock.

In regards to the problem I have with the Numeric keypad operation which is the reason I have the mapper.txt file:

I tried with usescancodes=true and false, but there's no difference.

I always have to toggle the NumLock key 3 or 4 times to get the windowing functions working (NumLock off state).

And even then I have to use the mapper.txt file where I've added the windowing function's code to the keypad's number keys (. to 9, except 5) to get any windowing function rather than numbers.
ex.: key_kp_7 "key 278" "key 263" rather than the original
key_kp_7 "key 263"

Hope you can find the problem.

Forgot to add:

When I use the mapper.txt file with the windowing function's code added to the keypad's number keys, I get the following quirk (which is liveable for me with PADS Perform DOS, but maybe not for others):

The regular navigation keys, the inverted-T cursors and the Insert-Page Down keys, act as number keys when Num Lock is on. They provide the normal navigation functions when Num Lock is off. For example: the inverted-T cursors generate 2, 4, 6, and 8 when the Num Lock is on.

Forgot 3 more things:

I have the same problems with the numeric keypad operation in PADS Perform DOS and when I am testing PADS-PCB v4.08.

For HAL9000:

I've never run PADS-PCB on real hardware, only in DOSBox. But any time I've tried a driver which didn't work, I was able to go directly to any other driver without going through selection 2. 640x480 IBM VGA Graphics Adapter to get it working again.

For the case of real hardware, vicg will have to report.

One thing I haven't mentioned just in case it's an issue for anyone:

PADS (PCB and Perform DOS) REALLY REALLY wants to be installed in C:\PADS.
I wouldn't install it anywhere else even though PADS lets you set an environment variable PPCB (Perform anyway):

rem ** sets PADS Perform defaults **
SET PPCB=C:\PADS;C:\PADS\FILES;C:\PADS\CAM;

This shows PPCB set to the default values.

But don't use it! Install the program in C:\PADS.

Hi all
Been away for a while so just caught up with the discussion. To answer the queries that were tossed my way. PADS-PCB in real DOS is happy to have video drivers changed from any to any other without problems. The only driver I have used extensively in real DOS is the Orchid prodesigner but not above 800x600 as this was all my monitor of the time could cope with! Can't try it now as the Orchid card has since died. Anyone got one in their odments box?
Regarding where to install PADS-PCB. It's only the Pinstall program thats fussy. I have run the prog at various times from D,E,F and G drives. I just let Pinstall stuff it in C:\PADS then copy the whole directory structure to the drive where I want it and give it a pointer in the PATH statement.

For PADS Perform DOS, copying the C:\PADS directory and subdirectories to another drive causes problems and parts of Perform will refuse to run. For example, I had to put PADS on a system where Win XP is on the G: drive. I tried to copy it over from a system where it was on the C: drive and run it, but it didn't work. Even with all the environment variables set, it just didn't like it. I think PINSTALL puts path information in one or both of the PADS config files (DEFAULTS.PAD and DEVICES.DAT). I had to use PINSTALL.EXE and install it from the original floppies to the G: drive and then copy the Files, Cam, Lib, etc subdirectories from the old installation to get all the .JOB and processed files. So you can put it on a different drive, but you have to use PINSTALL and start by installing from scratch.

And you could install it to a different directory if you, again, use PINSTALL and install from scratch. But you have to follow DOS name requirements such as no spaces and the total path cannot get too long.

But the easiest thing to do is put it in C:\PADS.

(Maybe PADS-PCB is less finicky).

vicg

There hasn't been any update recently and I was just wondering if the EMS memory problem with PADS-PCB was ever resolved. If so, did you get it working and what did it take?

vasyl

Did you add the 1024x768 mode 0x05D for the Paradise VGA to your new SVGA code? If so, I thought I might test it out to see what it looks like.

h-a-l-9000

Was there ever any solution to the Numeric Keypad problem I have other than using the mapper.txt file I made?

Hmm somehow your last reply didn't get to my attention.

This is the fix for the greenish pallette in Vasyls build:

1@@ -821,8 +822,9 @@
2 		case 0x10:
3 		case 0x12: goto att_text16;
4 		default:
5-			if ( CurMode->type == M_LIN4 )
6-				goto att_text16;
7+			if ( CurMode->type == M_LIN4 || CurMode->mode > 0x13) {
8+				goto att_text16; 
9+			}
10 			for (i=0;i<8;i++) {
11 				att_data[i]=i;
12 				att_data[i+8]=i+0x10;

Did you add the 1024x768 mode 0x05D for the Paradise VGA to your new SVGA code? If so, I thought I might test it out to see what it looks like.

I had put that mode in my 'Cad Edition' build.

Was there ever any solution to the Numeric Keypad problem I have other than using the mapper.txt file I made?

Not by me.

Yes, I've requested that Vasyl add the fix for the "No palette update for 4bpp SVGA modes / M_LIN4 graphics modes" to his SVGA code so that other builds will have the correct colors at 800x600 and 1024x768 with the et4000 selection instead of the sick green look for some colors.

The reason it's become important for my application is that I need to print in a new notebook PC which doesn't have a parallel port. As you suggested, it looks like I'll need a build with the Virtual Printer patch which means I'll probably be using ykhwong's build to be able to print in PADS Perform DOS in the notebook.
But ykhwong's build (and others) don't have the fix so they have that green look. I hope that Vasyl will incorporate it since it appears to be a short fix.

I had tried the Paradise VGA at 1024x768 before and it never worked. I checked your latest CAD edition and it's the same one I've been using as my standard DOSBox. I also tried ykhwong's latest 10/19 build and it doesn't work either.
At 800x600, both builds work fine.
But at 1024x768, PADS Perform begins to load and displays a status line. Then the cursor moves to the next line and stays in the first column (left of screen). Then it just sits there blinking and PADS never draws or switches into the graphics screen or mode. PADS seems to be running and I can exit "blind" with the proper keyboard sequence and get back to the DOSBox command prompt.

I guess this is another question for Vasyl. Is there a fix for the Paradise pvga1a 1024x768 and do you need a tester? This isn't anywhere near as important for me and my application as the Palette fix since I use the et4000 1024x768 selection, but I'm available for testing.

As for the Numeric Keypad problems, do you know if anyone looked at it further?

I have two basic setups, a desktop PC with Win XP SP2 and a notebook with Win Vista Home Premium. I get problems with the Numeric Keypad on both, although the behavior is slightly different. The mapper.txt file I made helps, but to get the Numeric Keypad windowing functions (NumLock off) I lose the inv-T cursor's normal functions which allow moving a single grid point per press. This turns out to VERY important.

So I was hoping there might be a "real" fix so I can stop using the mapper and get the inv-T cursor's normal function back.

The dosbox devs are probably quite busy with the new GUI feature.
Did you set svgachipset=pvga1a in dosbox.conf too? Works for me.

Actually that capslock thing isn't that hard to figure out, but usually i don't
need any caps/numlock for games so interest in this was/is not THAT great.

h-a-l-9000

Yes, I set the video to:

[vga]
svgachipset=pvga1a
videoram=512

saved and then started DOSBox.

I ran PINSTALL.EXE and configured PADS Perform for the Paradise VGA selection. Then I started PADS Perform.
Note that I tried 800x600 first to confirm that DOSBox and PADS were set for the Paradise VGA. 800x600 worked fine in your CAD Edition and ykhwong's 10/19 build. The colors in your CAD Edition are always correct. But the colors were also correct in ykhwong's build for the Paradise VGA selection, no sick green look (unlike the Tseng et4000 selection).
Then I ran PINSTALL.EXE and set the graphics to 1024x768 Paradise VGA. When I started PADS, I got the problem I listed in my previous post. PADS never gets into the graphics screen. PADS Perform and PADS-PCB do the same thing.

Of course, for me the sick green look for the 1024x768 et4000 selection is the main problem since I'll be using ykhwong's build to get the Virtual Printer on the notebook PC without a parallel port. Vasyl has said he would incorporate the Palette fix to eliminate the sick green look when he has time to work on the SVGA code again. Thank You!

As for the Numeric Keypad problem:

I understand since not many games use the Numeric Keypad windowing functions or inv-T cursors that it would be a very low priority. But if any games show up that use them and are having problems, please remember that there are other applications that need it fixed too. Until then I'll use the mapper and have to do without the inv-T cursors.

I really do appreciate all the help from everyone getting PADS working.
I marvel at the fact that, with DOSBox, PADS Perform DOS is running at 1024x768 in Windows XP and now even in Windows Vista!