zyzzle wrote on 2026-09-11, 21:08:The attached contains neopaint unpacked, and it still runs.
The unpacked version runs fine. I was able to register the program using the serial.
zyzzle wrote on 2026-09-11, 21:08:Falcosoft wrote on 2026-09-06, 11:56:The main problem with patching NeoPaint is that it seems it tries to defend itself against patching (I think it's because of the registration related routines).
It's PKLITE packed. You can unpack it and then the disassembled code is clearly valid but the unpacked exe cannot be started anymore. Most likely some kind of CRC check but I could not find exactly where it is.The attached contains neopaint unpacked, and it still runs. But you also need the neopaint.ovr file. It starts just fine, and can be modified.
I'm not sure which offsets in the raw uncompressed binary to attempt to patch in order to get rid of the multiply-by-3 and divide-by-3 code. Perhaps the modifications needed to get 32-bit VESA modes propery displayed are not in the .exe but in the overlay file.
Yep, this one runs perfectly and it is somewhat bigger than the one I got when I used UnPKd.exe to get the unpacked version. Can I ask what unpacker you used to get this?
The main code parts related to VESA modes enumeration and validation are the same but I could not find the relevant 24-bit only drawing routines in either one...
Most likely the drawing routines are really in the Borland Pascal style overlay file.
OK, I have found the drawing routines in the overlay file. The funny thing is there are already implemented 32bpp drawing routines besides the 8,16 and 24bpp routines 😀 So instead of rewriting the drawing routines I simply redirected the callings from the main executable to the 32-bit ones in the overlay. This way I got a working canvas with good shapes and colors but all interface elements became garbled. Also the PXC saving cannot produce proper PCX files anymore... So it seems this is a harder job than we hoped.
Falcosoft wrote on 2026-09-12, 11:54:Yep, this one runs perfectly and it is somewhat bigger than the one I got when I used UnPKd.exe to get the unpacked version. Can I ask what unpacker you used to get this?
CUP386.EXE /7 NEOPAINT.EXE
Falcosoft wrote on 2026-09-12, 15:54:OK, I have found the drawing routines in the overlay file. The funny thing is there are already implemented 32bpp drawing routines besides the 8,16 and 24bpp routines 😀 So instead of rewriting the drawing routines I simply redirected the callings from the main executable to the 32-bit ones in the overlay. This way I got a working canvas with good shapes and colors but all interface elements became garbled. Also the PXC saving cannot produce proper PCX files anymore... So it seems this is a harder job than we hoped.
Very, very strange the 32bpp modes were apparently coded but not implemented?! There's got to be a reason why. The strange misalignment of the interface in your redirected 32bit mode seems to point to some kind of hard-coded memory offsets being used for the interface icons, etc. A very kludgy way of coding. As the program is a flat 16-bit Borland Pascal .exe (I think), there may be a good reason for it, but I can't seem to figure it.
zyzzle wrote on 2026-09-12, 20:32:Falcosoft wrote on 2026-09-12, 15:54:OK, I have found the drawing routines in the overlay file. The funny thing is there are already implemented 32bpp drawing routines besides the 8,16 and 24bpp routines 😀 So instead of rewriting the drawing routines I simply redirected the callings from the main executable to the 32-bit ones in the overlay. This way I got a working canvas with good shapes and colors but all interface elements became garbled. Also the PXC saving cannot produce proper PCX files anymore... So it seems this is a harder job than we hoped.
Very, very strange the 32bpp modes were apparently coded but not implemented?! There's got to be a reason why. The strange misalignment of the interface in your redirected 32bit mode seems to point to some kind of hard-coded memory offsets being used for the interface icons, etc. A very kludgy way of coding. As the program is a flat 16-bit Borland Pascal .exe (I think), there may be a good reason for it, but I can't seem to figure it.
It seems I found some helper routines that calculate the coordinate geometry for 32-bit. It fixed the GUI element position problems but also caused the mouse cursor to draw random colored trails. And the 'colored' GUI icons are still drawn in 24bpp. It's rather frustrating 😀
Falcosoft wrote on 2026-09-12, 22:27:It seems I found some helper routines that calculate the coordinate geometry for 32-bit. It fixed the GUI element position problems but also caused the mouse cursor to draw random colored trails. And the 'colored' GUI icons are still drawn in 24bpp. It's rather frustrating 😀
Wow, that's real progress. As I understand you, 32-bpp images will load OK with full 16.7M colors now, but there are those strange "color" trails which corrupt the image when the mouse pointer is rolled over them. May you further illustrate with a screenshot of a truecolor image loaded into the program (something like a color wheel or something showing the full palette)?
Still, if it's now working in 32-bpp VESA modes and / or Intel vBIOSes with your mods, that pretty much makes it "usable" on modern systems, I'd say. But frustrating there are always snags, now something with the mouse routines corrupting the memory somehow?
Your progress of adapting Neopaint to 32 bits is impressive but I doubt that it will be ever usable. The binary maybe has some code for 32-bit drawing but the application itself is designed for 24-bit and I doubt that it will be ever possible to finish the conversion.
Better approach is to run DOSBOX from DOS or maybe modifying the graphic mode of the card. The graphic card maybe supports the 24-bit modes in hardware but does not have the VESA interface to them.
With modification of the mode setting routine (direct register modification) it could be possible to achieve.
Something similar was used to force to use Intel 910/915 to display in 4:3 ratio - https://high-voltage.cz/_dl/EEEfit_1.0.zip
Laaca wrote on Today, 10:49:Your progress of adapting Neopaint to 32 bits is impressive but I doubt that it will be ever usable. The binary maybe has some c […]
Your progress of adapting Neopaint to 32 bits is impressive but I doubt that it will be ever usable. The binary maybe has some code for 32-bit drawing but the application itself is designed for 24-bit and I doubt that it will be ever possible to finish the conversion.
Better approach is to run DOSBOX from DOS or maybe modifying the graphic mode of the card. The graphic card maybe supports the 24-bit modes in hardware but does not have the VESA interface to them.
With modification of the mode setting routine (direct register modification) it could be possible to achieve.
Something similar was used to force to use Intel 910/915 to display in 4:3 ratio - https://high-voltage.cz/_dl/EEEfit_1.0.zip
Hi,
1. Yep, I came to the same conclusion.
2. I think the situation in case of 24bpp modes are substantially different. I have also written DOS 4:3 aspect ratio correction utility for my T430 (that apparently works with any Intel Sandy, Ivy, Haswell integrated GFX):
download/file.php?id=247684
but the difference is that aspect ratio correction was known to work under Windows, Linux etc. So the mission was to find out how. But 24bpp modes are not supported under any known OS in case of Intel GFX. So the chances are high that support is missing at the hardware level. While 24bpp to 32bpp software emulation with banked frame buffer modes is possible in theory it requires that the VESA program respects the WinASegment and WinSize values reported by the VESA mode. But NeoPaint (and most likely other VESA programs as well) ignores these reported values and always uses 0xA000 and 64KB.
Anyway my theory for a TSR was the following.
1. Reserve 48KB conventional memory as a shadow frame buffer.
2. Report 24bpp mode for the requested 32bpp mode when int10 4F01h is called and also report the segment and size of the reserved shadow frame buffer (instead of 0xA000 and 64KB).
3. Intercept int10 4F05h (bank/window switching) and convert the 48KB 24bpp data to 64KB 32bpp data and write it to the real VGA frame buffer at 0xA0000. Call the original bank/window switching.
If the application draws whole frames this should work.
Aha! I understand your method. It is indeed interresting but it is as you write - the application must draw whole frames. Another possible solution could be to hang on the timer interrupt and update screen after every X milisecond but it would be very CPU demanding.
