Inverted [upside down] text in one screen type of my ORCAD CAD from my old PC

[crestr1]

Question

it emulates all ok until it gets to this type of page, the grey text boxes are correctly placed on the screen but the text in them is inverted and the text across the page top is also inverted. the text is correctly placed in the boxes. Dosbox-x is working perfectly in lots of other assemblers, compilers etc from my 40 years ago PCs. So congrats on some brilliant stuff

Have you checked that no similar question(s) exist?

• [X] I have searched and didn't find any similar question.

Code of Conduct & Contributing Guidelines

• [X] I agree to follow the code of conduct and the contributing guidelines.

[crestr1]

MY System: Kernel: 6.5.0-35-generic x86_64 bits: 64 compiler: N/A Desktop: Cinnamon 6.0.4 tk: GTK 3.24.33 wm: muffin vt: 7 dm: LightDM 1.30.0 Distro: Linux Mint 21.3 Virginia base: Ubuntu 22.04 jammy Machine: Type: Mini-pc System: Micro (HK) Tech product: Venus series v: N/A serial: Mobo: Shenzhen Meigao Equipment model: F7BSC serial: UEFI: American Megatrends LLC. v: 1.09 date: 11/20/2023 CPU: Info: 8-core model: AMD Ryzen 9 7940HS w/ Radeon 780M Graphics bits: 64 type: MT MCP smt: enabled arch: Zen 3 rev: 1 cache: L1: 512 KiB L2: 8 MiB L3: 16 MiB Speed (MHz): avg: 462 high: 1397 min/max: 400/5263:6228:5903:5583:5743:5423:6067 cores: 1: 400 2: 1397 3: 400 4: 400 5: 400 6: 400 7: 400 8: 400 9: 400 10: 400 11: 400 12: 400 13: 400 14: 400 15: 400 16: 400 bogomips: 127763 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm Graphics: Device-1: AMD driver: amdgpu v: kernel pcie: speed: 16 GT/s lanes: 16 ports: active: HDMI-A-1 empty: DP-1, DP-2, DP-3, DP-4, DP-5, DP-6, DP-7, HDMI-A-2 bus-ID: c4:00.0 chip-ID: 1002:15bf class-ID: 0300 Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: amdgpu,ati unloaded: fbdev,modesetting,vesa gpu: amdgpu display-ID: :0 screens: 1 Screen-1: 0 s-res: 3840x2160 s-dpi: 96 s-size: 1016x571mm (40.0x22.5") s-diag: 1165mm (45.9") Monitor-1: HDMI-A-0 mapped: HDMI-A-1 model: Lenovo L28u-35 serial: res: 3840x2160 hz: 60 dpi: 157 size: 620x350mm (24.4x13.8") diag: 712mm (28") modes: max: 3840x2160 min: 640x480 OpenGL: renderer: GFX1103_R1 (gfx1103_r1 LLVM 15.0.7 DRM 3.54 6.5.0-35-generic) v: 4.6 Mesa 23.2.1-1ubuntu3.1~22.04.2 direct render: Yes

[crestr1]

And yes I've spent hours trying settings (F12+C) in video and TTL attributes, It could be reading the font memory backwards because of an indexing issue.

[joncampbell123]

Question

it emulates all ok until it gets to this type of page, the grey text boxes are correctly placed on the screen but the text in them is inverted and the text across the page top is also inverted. the text is correctly placed in the boxes. Dosbox-x is working perfectly in lots of other assemblers, compilers etc from my 40 years ago PCs. So congrats on some brilliant stuff

Have you checked that no similar question(s) exist?

• [X] I have searched and didn't find any similar question.

Code of Conduct & Contributing Guidelines

• [X] I agree to follow the code of conduct and the contributing guidelines.

Is it using S3 XGA acceleration?

[crestr1]

A serious thank you for the quick comment. at one stage i turned on s3 as the graphic driver and it would not restart, In command mode it gave a message that it did not exist. maybe I've missed something that makes it available. I still have the 40 year old PC running, I stoked it up to see if the software licensing dongles on the printer port were the issue.

[crestr1]

This is the log i get as this ORCAD screen in invoked

LOG: Flush STDIN LOG: 3519653 ERROR MOUSE:Unhandled videomode 6B on reset LOG: pixratio 1.000, dw false, dh false LOG: Aspect ratio: 800 x 600 xToY=1.333 yToX=0.750 LOG: menuScale=2 LOG: X11 main window is 1600 x 1200 maximized=0 LOG: XRandR CRTC 0: pos=(0,0) size=(3840,2160) outputs=1 LOG: Our window lies on this CRTC display (window pos=(1918,518) size=(1600,1200) match=(2718,1118)). LOG: Goes to output 0: name='HDMI-A-0' size_mm=(620 x 350) LOG: Screen report: Method 'XRandR' (3840.000 x 2160.000 pixels) at (0.000 x 0.000) (620.000 x 350.000 mm) (24.409 x 13.780 in) (157.316 x 156.754 DPI) LOG: font texture id=2 will make 128 x 256 LOG: X11 main window is 1600 x 1200 maximized=0 LOG: XRandR CRTC 0: pos=(0,0) size=(3840,2160) outputs=1 LOG: Our window lies on this CRTC display (window pos=(1918,518) size=(1600,1200) match=(2718,1118)). LOG: Goes to output 0: name='HDMI-A-0' size_mm=(620 x 350) LOG: Screen report: Method 'XRandR' (3840.000 x 2160.000 pixels) at (0.000 x 0.000) (620.000 x 350.000 mm) (24.409 x 13.780 in) (157.316 x 156.754 DPI) LOG: 3523437 ERROR MOUSE:Unhandled videomode 6B on reset LOG: 3523926 ERROR MOUSE:Unhandled videomode 6B on reset AL

[joncampbell123]

Can you provide your dosbox.conf and setup? Every copy I can find has every excuse in the book not to start up to the screen in your screenshot such as CFG files it requires that are never installed.

[crestr1]

Also problem on mouse takeover but i notice this has been well reported. but if i can do anything to offer help tests I'd be happy to do so.

[crestr1]

My config attached TONY's Config.txt DosBox-x Installation.txt

[crestr1]

there is something called s64d maybe this is the graphics driver I can use I'll try it. it is called s64dmode.exe i think i gets an argument for screen size following its invocation

[Torinde]

Can you upload the program itself somewhere?

[maron2000]

VGA640.drv and VESA800.drv seems to work. S3 chipset drivers doesn't work or maybe I have to change DOSBox-X settings. Same version? (v4.40)

[maron2000]

Just for your interest, 1024x768 S3 chipset driver.

[crestr1]

Marvelous work M2k my drivers attached UTIL.ZIP loaded it in the end of the config file and all its diagnostics and tests work when i go into the tests later when the system is up have a horrible feeling what i have is s3 related but it handles a range of monster screen sizes.

[crestr1]

If you have a running version m2k how did you handle the printer port and the dongles ? I've gotta use a USB to centronics port i guess

[crestr1]

in my ORCAD setup it was originally using s31024 perfectly

[crestr1]

Thanks JC, was ambiguous apparently its the emulation of the S3 class drivers. A classic pointer problem picking up a pointer to the wrong end of the text bit pattern data - is my guess

[joncampbell123]

I'm wondering if this has anything to do with Windows-style bottom-up bitmaps vs the CAD program using top-down bitmaps.

Remember that in OS/2 and Windows, bitmaps encode the bottom-most scanline first, rather than the top-most scanline. They're encoded "upside down".

[joncampbell123]

The only possible explanation I can think of is that the CAD program is relying on the XGA Rectangle command (which coincidentally is the same command you draw images with) obeying the x-y axial bits regarding which way the pixels are drawn. The current code assumes that the guest wants to draw images left to right, top to bottom, which is only correct for Windows. Maybe the CAD program expects to run the same command with bit 7 clear (draw by decrementing Y instead of incrementing) and that's why the letters are upside down.

I'm making a simple quick change to the code, if the nightly build succeeds, try it out and see if my guess is correct.

EDIT: Debugging shows Windows will always use 101b (+X +Y)

[crestr1]

This also may be a problem to do with failure to set flags in the call to the s3 driver to marry it to the font set. This family of screen graphic drivers was extremely powerful and had lots of operating modes suggesting non-trivial setup handshakes would be needed Be nice if we had some source code for an s3 driver. Or even code for opening TT font sets which to keep them small probably ran initialization housekeeping that may have actually computed (or realized) the character bitmaps according to a font call argument set.

Be interested in exactly what happens if M2k was kind enough to set 800x600 S3 in his machine

[joncampbell123]

The -Y drawing direction bit might explain why the text appears to be both upside down AND drawn as if drawn from the baseline the wrong way (notice in your screenshot the text looks like it's hanging upside down off the blue bar instead of sitting in the blue bar), so my guess might be correct. The next build triggered by the latest commit should show if I'm right. When the executables show up, try it against the CAD program.

[maron2000]

The flipping of text is fixed, but the entire glitch is not yet fixed. (using s31024.drv) As mentioned above, vesa800.drv (800x600) works fine.

[joncampbell123]

Can you please provide a ZIP file of the dosbox.conf and the CAD software you are running?

Although I found a copy on The Internet Archive, the installer and installed files are incredibly fussy and I haven't actually gotten it to do anything despite trying.

[joncampbell123]

"BPINT 10 4F"

Right away the program assumes video modes. Mode 0x204. Which in the current code is meant to match Windows 95 S3 driver modes, but apparently this was coded against another revision of the S3 card where the modes were different.

I don't think the program intended to use 800x600 16-color (4-bit) packed mode.

[joncampbell123]

Before running ORCAD, run this command:

VESAMOED -mode 0x204 -fmt LIN8

[joncampbell123]

Although I wonder if this is a case where the CAD program is purposely using the 4bpp packed mode and XGA acceleration is meant to work in it. Hold on, let me check.

[joncampbell123]

The Trio32/Trio64 appear to support 4bpp packed XGA acceleration:

[joncampbell123]

I assume the CAD program has been written to do EVERYTHING through XGA acceleration because it appears to be using the older bank mode, not a linear framebuffer.

[joncampbell123]

Actually, yes, the mode list in the ESP explicitly says 16 color. The cursor doesn't appear properly if forced to 256-color mode. So, disregard the VESAMOED command, unless you're fine using the program with a completely black almost invisible cursor. So the only way for this to work is to code XGA emulation to support 4bpp packed.

[joncampbell123]

Also the 1280x1024 mode appears to have a problem where the upper left corner of the screen is evidently where the cursor is storing the video memory it's occupying, and that's kind of a bug too.

[joncampbell123]

OK. When the latest commit is built into a daily binary, go ahead and try it out. It should render correctly now.

[crestr1]

Thanks JC my version was from snapcraft and is, by the look of things, old. I was trying to avoid a hub pull and remake and the attendant tool probs that often come with this. I'll do a pull and remake if you think it's a better way to go to put us all on the same page. I'm using Mint which was a bit iffy about the snap download.

[maron2000]

The nightly builds (MinGW since VS has some technical problems as of now) using s31024.drv are working fine. Tested on Windows 11 23H2.

[crestr1]

Did a pull, and new make on current on git, text trouble issue gone. now need to be getting into testing operations. Need to get my usb mouse to control the internal cursor which works ok but only with the keyboard arrow keys tried the options under video unsuccessfully. going with the initial config file with just the C drive startup allocations at EOF. see attached: dosbox-x.conf.txt

[joncampbell123]

The CAD program reads only relative mouse motion, so you'll need to CTRL+F10 (CTRL+SHIFT+F10 on Linux) to capture the mouse (using the same mapper shortcut releases the mouse). The mapper shortcut is kept the same as any other DOSBox fork.

[joncampbell123]

DOSBox-X sends only absolute cursor info for interfaces that provide absolute position (some INT 33h calls), but no relative motion. It sends relative motion only if you capture the mouse to the guest window.

Some programs use INT 33h or mouse interfaces in a way that they only respond to relative motion of the mouse.

I'm aware of other forks that try to map movement within the window as some kind of relative motion (DOSBox Staging) but it's not useful and the motion in the guest never matches the host.

[crestr1]

Screen run-away in size, slight horizontal sizing attempt made. tried to increase width a little and the screen suddenly massively elongated.

[crestr1]

4dos not starting

[joncampbell123]

Screen run-away in size, slight horizontal sizing attempt made. tried to increase width a little and the screen suddenly massively elongated.

Is your desktop Wayland-based?

[joncampbell123]

The reason I ask is that based on my experience testing on Ubuntu, which uses Wayland, is that the window manager interferes with the window resizing logic of DOSBox-X and things like that can happen (at least with GNOME 3 desktop). I'm not sure why.

[crestr1]

Desktop Gnome, its cinnamon mate,and it appears to be something trying to resolve an aspect ratio problem

Any comment on the 4dos not starting ?

[joncampbell123]

The 4DOS issue is new to me. If that's not already an issue, go ahead and open one for that.

[crestr1]

Here we have dosbox-x start log and follow on log to make the ORCAD drawing, second log shows lots of plotting problems

Dosbox-x start log.txt LOG continues into ORCAD dwg.txt

[crestr1]

another screenshot showing the missing bits of the plotting the F1 to 500ma path and all the 10 links to JP1 are missing from a quick eyeball of the plot

[crestr1]

This really is looking good it even works with 2400 x 1200 S3 and better if you give it a bigger workspace manually marvelous work JC, this could be potentially better that on the original DOS PC.

[joncampbell123]

I see it's using draw modes that the XGA emulation doesn't yet support, and only because Windows never used them.

Between this CAD program and the S3 acceleration mode in "Line Wars", there are some S3 XGA rendering modes that need to be added to improve emulation.

[crestr1]

Will this be safe and ok to keep up with you: cd dosbox-x git pull make clean make install

[joncampbell123]

Will this be safe and ok to keep up with you: cd dosbox-x git pull make clean make install

That should be fine for incremental changes, otherwise use ./build-debug

[crestr1]

Some the missing plots parts: seems we need to plot small circles, using probably a series of very small diagonal movements of the plot point. see attached from my DOS system

[crestr1]

Component Library attached

ALOG.LIB.zip

[crestr1]

Same problem here too: all holes are missing from this PCB layout