joncampbell123 / doslib Goto Github PK

According to this document:

http://www.hackipedia.org/browse/Computer/Platform/PC,%20NEC%20PC-98/Collections/Undocumented%209801,%209821%20Volume%202%20(webtech.co.jp)/io_pci.txt

NEC PC-9821 Pentium systems have the same CF8h and CFCh PCI I/O ports as IBM PC/AT Pentium systems.

Therefore, hw/pci could be brought to PC-9821 if the support code for Type 2 and PCI BIOS were marked off by #ifndef TARGET_PC98.

I recently acquired some Windows 95-era PC-98 laptops, so I will also be able to verify the information is correct and that my code doesn't cause problems.

Sparky's got my sample IMF code working, great!

It might help game dev if a tool were developed to read MIDI and generate IMF.

IMF as a music format is ideal because playback is as simple as counting timer ticks and writing raw values to the OPL3 chip from the file.

Much of the work already done in hw/adlib to play midi could be re-used to do so.

Copying over the music notes is easy. Making instruments sound like they should is the harder part.

An alternative "cheaters" method might be to add OPL3 logging to DOSBox-X, then play the MIDI in Windows 3.1, and record whatever their MIDI driver is writing to the chip :)

• See if the box drawing character test in sjis3.c behaves the same on real hardware as it (currently) does in DOSBox-X. The "standard" JIS code points should be invisible, and the proprietary NEC code points should form a box.

I was unable to get REMSRV to respond over the UART on one PC-9821 laptop.

Running 8254.EXE shows it isn't cycling.

However writing anything to 75h or reprogramming fully 75h and 77h allows it to cycle again.

Perhaps this is related to the time I couldn't get any serial communications to work.

As seen in DOSBox-X.

Is this a bug in DOSBox-X or in the sndsb library?

On SB Pro hardware or with sbtype=sbpro2
How to repro: Bring up TEST.EXE, play a file that needs hispeed mode (22KHz stereo or 44.1KHz mono) and play it. It plays correctly. Then play a file that does not need hispeed mode (11KHz mono). Then play a file that needs hispeed mode. In DOSBox-X, the second hispeed play mode plays at non-hispeed sample rate instead of the normal speed. The only workaround is to use the menu UI to reset the DSP, then restart playback.

is it possible to add a cool and powerful MODE X VGA library?

File upload/download with old PC and 386 systems with MS-DOS 5.0 is near impossible if the system is idle at the DOS prompt. MS-DOS is always busy.

Temporary workaround is to run a UI that doesn't read constantly from DOS I/O, like EDIT.COM, then perform file I/O.

Can this be resolved somehow?

LMSW bit 0 enables protected mode. It is known that on 386 and higher processors, the machine status word is just the low 16 bits of the 386 CR0 register. On the 286, you were allowed to set the bit to enter protected mode, but you were not allowed to leave protected mode without a reset (clear the bit).

The purpose of the program is to show, on the CPU it is run, whether LMSW is allowed to set the bit, and whether it is allowed to clear the bit.

Obviously the program must return safely, so if LMSW cannot clear the register, it should write CR0 to clear it.

It is possible that by the 486 and Pentium era (1996), LMSW no longer enforced the set-only behavior and allowed clearing the bit.

The reason for this test: joncampbell123/dosbox-x#2549

Asking PLAYMP3.EXE to play an MP3 file that is zero length or very small triggers an assertion failure when you start playing.

I plan on adding a new DOSLIB library to support PAS and PAS16 cards.
I'm well aware the Sound Blaster part of the card works with the SNDSB library, but I would like the PAS library to support the rest of the card as well. I plan on writing the library to expose both low level programming and programming through the MVSOUND.SYS driver. Another part of the library would support the mixer, and another part the SCSI interface.

A long and painful search across the internet seems to show that nobody has this documentation anymore. All I can find are snippets from the Linux kernel that talk to specific parts of the card, and most of it just a long list of I/O reads and writes without explanation, which is most frustrating.

If anyone has the lost documentation, please contribute it here. Much progress could be made if I don't have to reverse engineer the SDK object files and DOS driver and guess from what scant source code is available.

EDIT: I'm aware someone on the Vogons forums posted a Media Vision development guide, however that only covers the Sound Blaster and Adlib FM parts of the card! What about all those other mystery I/O ports that alias atop port 0x388 to control the mixer, SCSI interface, etc.?

EDIT: Hellooo? Github? This is a hyperlink!

ftp://ftp.oldskool.org/pub/misc/Hardware/Media%20Vision/Thunderboard/Thunder%20Board%20Programmer's%20Reference.pdf

Building: dos86l
Using: /dos/fdos/watcom
Allow list: win200l win300l win312l
%write tmp.cmd -fr=nul -fo=dos86l/.obj -i=.. -i../../.. -s -zq -zl -zu -zw -zc -nt=_TEXT -nc=CODE dboxmpi.c
/dos/fdos/watcom/h/nt/winnt.h(6332): Error! E1156: Assembler error: 'Cannot use 386 register with current CPU setting'
/dos/fdos/watcom/h/nt/winnt.h(6332): Error! E1156: Assembler error: 'Cannot use 386 operand size with current CPU setting'
/dos/fdos/watcom/h/nt/winnt.h(6333): Error! E1185: Invalid register name 'eax' in #pragma
/dos/fdos/watcom/h/nt/winnt.h(6334): Error! E1185: Invalid register name 'eax' in #pragma
/dos/fdos/watcom/h/nt/winnt.h(6336): Error! E1156: Assembler error: 'Cannot use 386 register with current CPU setting'
/dos/fdos/watcom/h/nt/winnt.h(6336): Error! E1156: Assembler error: 'Cannot use 386 operand size with current CPU setting'
/dos/fdos/watcom/h/nt/winnt.h(6337): Error! E1156: Assembler error: 'Cannot use 386 register with current CPU setting'
/dos/fdos/watcom/h/nt/winnt.h(6337): Error! E1156: Assembler error: 'Cannot use 386 addressing mode with current CPU setting'
/dos/fdos/watcom/h/nt/winnt.h(6338): Error! E1185: Invalid register name 'eax' in #pragma
/dos/fdos/watcom/h/nt/winnt.h(6339): Error! E1185: Invalid register name 'eax' in #pragma
/dos/fdos/watcom/h/nt/objidl.h(158): Warning! W135: Shift amount too large
/dos/fdos/watcom/h/nt/objidl.h(159): Warning! W135: Shift amount too large
/dos/fdos/watcom/h/nt/objidl.h(160): Warning! W135: Shift amount too large
/dos/fdos/watcom/h/nt/objidl.h(162): Warning! W135: Shift amount too large
Error(E42): Last command making (dos86l/dboxmpi.obj) returned a bad status
Error(E02): Make execution terminated

I just noticed that merely using int86/int86x() functions adds 780 bytes, 768 of which is (3 x 256) bytes consisting of INT xxh; RET for each possible interrupt.

So the solution, at least for MS-DOS 16-bit builds, is to not use these functions!

The dos86l build of DOSAMP hangs on startup when run on an old 486 33MHz system with a Pro Audio Spectrum 16 card.

I don't know yet if it's related to the PAS, or the old 486.

This is a "old" 486 that is known to throw an invalid opcode on access to CR4 and does not have the CPUID instruction (pre-Pentium), not a "new" 486 that contains backported Pentium features (post 1992 version).

HIMEM.SYS was devised at a time when 286 or higher systems had extended memory.

Therefore it is inappropriate to use 32-bit 386 instructions to read/write CPU registers when talking to HIMEM.SYS.

It is only appropriate to use 32-bit registers when using extended functions designed for use with 386 or higher.

This issue makes it impossible to write and test HIMEM.SYS calls on 286 systems.

The tiny model of the Sound Blaster test program compiles to a .COM executable that is 62.5KB large. Because of how .COM executables work, that barely leaves any room for stack. Not surprisingly, running it immediately triggers a "stack overflow" error message.

Some serious trimming to what is included into the program needs to happen if it is to become usable.

Please what is purpose of linux-ow.sh and owenv.sh script files?
I don't understand why it has complete messy INCLUDE environment variable.
Why OW tools setup is for 32-bit Windows if you compile for different targets?
It results in following wrong message in shell scripts

"# why is this even necessary? why does dumbshit Watcom insist on including the WINNT headers for Windows 3.1 builds?"

It is caused by previous wrong OW setup.
in other files <os>_INCLUDE variables are used and wrongly combined with INCLUDE variable.

Such OW setup can cause some hiden mistakes etc.

You should handle cross-compilation one way only, don't mix multiple mechanism.

• full handling by <os>_INCLUDE and INCLUDE variables
• full handling by command line -I option

By example OW build system is fully cross-compilation system and it uses "full handling by command line -I options" for flexibility.
It requires to ignore all ..INCLUDE variables, it is ensured by using -x compiler option.
I thing for your project you could use aproach with <os>_INCLUDE and INCLUDE variables

I tried to compile DOSLIB on my Ubuntu 18.04 (minimal system).
It doesn't work due to shell scripts refere to /usr/bin/bash shell which doesn't exist on my Ubuntu in this location.
It can be a problem on other Linux/Unix which doesn't have Bash shell in this location.
It could be fixed by using default shell /bin/sh, but I am not sure how many Linux/Unix define it.
I think on GNU Linux is mostly used Bash as default shell. Also if Bash specific features are used in scripts then it need not work on systems without Bash.

Need to add a conditional build mode to DOSAMP that announces everything it's doing to STDERR and a file. This debug build should help diagnose one of the possibly thousands of reasons DOSAMP would crash or have problems.

Open Watcom Make Version 2.0 beta Jan 16 2016 17:32:51 (64-bit)
Copyright (c) 2002-2015 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
%write tmp.cmd -fr=nul -fo=dos386f/.obj -i=.. -i../.. -dHAVE_CONFIG_H -e=2 -zq -mf -d0 -bt=dos -oilrtfm -wx -fp3 -3r -dTARGET_MSDOS=32 -dMSDOS=1 -dTARGET86=386 -DMMODE=f -q blocksrt.c
bzlibprv.h(25): Error! E1055: Unable to open 'stdlib.h'
bzlibprv.h(28): Error! E1055: Unable to open 'stdio.h'
bzlibprv.h(29): Error! E1147: Too many errors: compilation aborted
Error(E42): Last command making (dos386f/blocksrt.obj) returned a bad status
Error(E02): Make execution terminated

.....

my watcom stuff is different.... but i inly want to compile 16 bit stuff ww

https://www.thurrott.com/windows/windows-10/67367/upgradegate-microsofts-upgrade-deceptions-undermining-windows-10

I am putting this notice here that I will not support or develop support for Windows 10 in DOSLIB (or DOSLIB2). Do not open issues or report bugs for issues with Windows 10, they will be removed, closed, and deleted. Do not submit patches/changes to fix issues with or support new features in Windows 10, they will be ignored and dropped.

Issues and patches related to running in emulators, MS-DOS/FreeDOS, Windows 3.x/9x/ME, and Windows NT/2000/XP/Vista/7/8 are still welcome.

Though Tandy systems are normally associated with PCjr and CGA like video modes, later Tandy systems have VGA graphics, though they still have the sound chip.

The existing code assumes that if INT 1Ah reveals the Tandy 3-voice chip, that it's Tandy graphics.

The VGA library needs a better way to detect Tandy systems (if one is available), and it needs a way to distinguish between Tandy graphics and a Tandy with VGA graphics.

Test case found:

Compiling the hw/isapnp project in tiny model initially failed because the devnode_raw array was declared far.

Watcom C generates OMF records putting it into it's own segment. That segment is NOT part of DGROUP. But that is not obvious from the FIXUP record.

LNAMES (from 11): [11]: "test13_DATA" [12]: "FAR_DATA"
OMF record type=0x98 (SEGDEF: Segment Definition Record) length=6 offset=755 blocksize=0
SEGDEF (5):
    Alignment=PARA(3) combination=PRIVATE(0) big=0 frame=16 offset=0 use0
    Length=4096 name="test13_DATA"(11) class="FAR_DATA"(12) overlay=""(1)

..

FIXUPP[95]:
    seg-relative location=16BIT-SEGBASE(2) frame_method=by-TARGET(5)
    target_method="EXTDEF"(2) target_index="_devnode_raw"(11) data_rec_ofs=0x5F(95)
    target_displacement=0 ledata_rec_ofs=0x1539(5433)+3 absrecofs=0x18F(399)

..

OMF record type=0xb6 (LPUBDEF: Local Public Names Definition Record) length=18 offset=14413 blocksize=0
PUBDEF (2):
    [2] "_devnode_raw" group=""(0) segment="test13_DATA"(5) offset=0x0(0) typeindex=0 LOCAL

The tool currently assumes all EXTDEFs are in the same DGROUP. Here is a case where an EXTDEF refers to a PUBDEF (publicly defined symbol). OMFSEGDG already gathers symbols in the first pass, so it has the ability in the second pass to determine where the symbol is and whether or not it is part of DGROUP.

Current code requires writing the PIT 0 counter to put it into a mode where the wait functions and counting/delay code can time properly, because DOSBox-X and most motherboards put it into a mode that counts down by 2 (throwing off our code).

What would be nice is if the 8254 library had a variable to track the PIT mode so that it can follow along if it knows the timer is in that PIT mode (count by 2) instead of requiring the host program to reprogram the PIT timer. It would also be nice if the 8254 library at probe time could automatically detect that PIT 0 is in this mode.

Here's a disappointing revelation.

Apparently Windows 95's EMM386.EXE doesn't like it when 16-bit DOS applications try to use RDTSC. It seems to hang the system (or perhaps it's in an infinite Invalid Opcode exception loop). 32-bit DOS programs (under DOS4GW/DOS32) are not affected.

I would like to know if this has been a consistent problem across MS-DOS through Windows 98 SE, or if it's just the particular version of Windows 95 I'm testing right now (4.0.1111 Windows 95 SP1).

Until then, I'm going to have to have RDTSC-related code disable itself unless known versions of MS-DOS and EMM386.EXE are running :(

I'm thinking of adding a build mode to the sndsb library so that there are normal builds, and profiling builds. The profiling builds would profile and log each DSP read/write, reset procedure, and how long each took to execute. DSP writes would also block until the DSP signals not busy, and log that as well (so it would log how long it waited for DSP ready, and how long the DSP was busy after writing the byte).

The main loop would also writing profiling data on the speed/timing of the DMA transfers and the timestamp of each IRQ.

The main loop would periodically call a function to dump the profiling data from RAM to disk. In this way, we can get a feel for how long DSP commands take on actual hardware.

cd src/lib/doslib/hw/cpu
./make.sh build all dos86l
common.mak(85): Error(E21): Extension(s) (.C.OBJ) not defined
common.mak(86): Warning(W20): Command list does not belong to any target
common.mak(92): Error(E21): Extension(s) (.ASM.OBJ) not defined
common.mak(93): Warning(W20): Command list does not belong to any target
Error(E02): Make execution terminated
Error(E42): Last command making (src/lib/doslib/hw/cpu/dos86l/cpu.lib) returned a bad status
Error(E02): Make execution terminated

buildall.sh returns same error

https://twitter.com/greatcodeholio/status/1253761853408161792

Apologies in advance, since this issue isn't really that on point and covers two areas but I've spent an entire weekend messing with this and not made a lot of progress.

I'm looking at Windows 3.1 VxD development out of interest, so I can eventually go on to write a better, open source display driver for VirtualBox and QEMU that can support arbitrary resolutions, but I'm having a real hard time getting the build system working. I've seen demos of Windows 3.1 running at arbitrary resolutions so I believe this should be possible to implement.

When I tried to build the project, after examining the linux-ow.sh script and making sure I had everything it expected (watcom in /usr/watcom, etc), running ./buildall.sh in the root of the project gave me the following output:

$ ./buildall.sh 
'buildall.sh' -> 'asminc/buildall.sh'
'buildall.sh' -> 'bootsect/buildall.sh'
'buildall.sh' -> 'i13geom/buildall.sh'
Error(F38): (dos86t/boot1.img) does not exist and cannot be made from existing files
Error(E02): Make execution terminated

I spent a lot of time trying to figure out how the build system is supposed to work and didn't make much headway, since it is overly confusing, so I decided to instead hyperfocus on just the parts I was interested in, in the hope that I would understand what's going wrong with the build system. I've spent the weekend cannibalising the ps2mouse driver to try to get it to build. I've created a makefile based on the original makefile to bypass the build system, and so far it's somewhat building. I eventually landed on this error when building ps2mouse.c:

ps2mouse.c(219): Error! E1121: Procedure 'bios_get_config' has invalid return register in #pragma

The openwatcom documentation alludes to the return value being incompatible with the declared return value, but the function didn't seem necessary to the code so I just commented it out.

After that, the C side of the code seems to compile fine, though I now am stuck with the following errors when linking:

Error! E2028: __GETDS is an undefined reference
Error! E2052: file dllentry.obj(dllentry.asm): relocation at 0001:0001 not in the same segment
file ps2mouse.obj(/path/to/doslib/windrv/ps2mouse/win3x/ps2mouse.c): undefined symbol __GETDS
file inthndlr.obj(/path/to/doslib/windrv/ps2mouse/win3x/inthndlr.c): undefined symbol __GETDS

So I guess I have two questions:

1. Is the ps2mouse driver actually buildable or is it a WIP
2. Am I missing something in regards to getting the normal build system to work. The only documentation I've found on it is to just run buildall.sh, and there has to be something I'm missing because other people don't seem to be having any issues getting it to build.

I love this thing i'm just having a problem with memory, when i install VGA240 i can't start wolfenstein because of insufficient memory, is there anyway to load everything in high memory?

There are a lot of calls in the Win386 VxD world in Windows 3.1 (and many more in Windows 95, 98, ME).

I have simplified entering calls by making a *.vxddef list that you compile into a header. It makes it easier, but there is still a lot to be done.

All you need to help with this is a DOSBox-X setup to run Windows 3.1, and a copy of the Windows 3.1 DDK.

Mount the ISO image within the DOSBox-X virtual machine (or unpack it into a directory, whichever is appropriate for your setup).

Bring up Windows 3.1, then use the Run command to run WINHELP.EXE. Go to File, Open, and then navigate to the drive letter or folder the Windows 3.1 DDK exists. Go into the DOCUMENT directory, and then open VDAG31WH.HLP. You'll know you have the right HLP file if the title is the "Windows 3.1 Virtual Device Adaptation Guide".

Going down the list in windows/w9xvmm/dev_vxd_dev_vmm.vxdcalls, look up each call by name using the search function, and then use the documentation provided to enter the input and output parameters of the call.

There are two major types of calls: ASM-like calls and C-like calls.

ASM-like calls are defined in terms of filling in registers before the call, and pulling values out of registers after the call. C-like calls are defined as one where you push parameters onto the stack and then get a return value in EAX (or sometimes EDX and EAX).

I was looking at using DSXMENU inside DosBox to make things a little easier for games and apps when starting them from a frontend or bat. The menu itself does everything you need functionality wise, however I was wondering if we can have a simple non navigable text line entry.

For example:

[menu]
menutext=Awesome Game Menu
menuitem=choice_a,Menu item A
menuitem=choice_b,Menu item B
menuitem=choice_c,Menu item C
menudefault=choice_b,10

You can sort of do this with a dummy line menuitem=,Some text but it's still navigable. It would be handy for adding a title to the menu or some sort of hint about which option to select.

If I have setup my own OW environment for testing I can not work with doslib build because it override PATH variable even if it is already setup.

Below is simple fix for linux-ow.sh which ensure that existing OW tools PATH is not changed

    fi
    if [ -d "$HOME/src/open-watcom-v2/rel/binl" ]; then
        export WATCOM=$HOME/src/open-watcom-v2/rel
    elif [ -d "/usr/src/open-watcom-v2/rel/binl" ]; then
        export WATCOM=/usr/src/open-watcom-v2/rel
    fi

++export PATH=$WATCOM/binl:$WATCOM/binw:$PATH

fi

echo "Using: $WATCOM"

export EDPATH=$WATCOM/eddat

--export PATH=$WATCOM/binl:$WATCOM/binw:$PATH

export "INCLUDE=$WATCOM/h/nt;$WATCOM/h/nt/directx;$WATCOM/h/nt/ddk;$WATCOM/h"
export HPS=/

I think it would be neat if TEST.EXE could be used to poke at the undocumented commands, including the DMA detection one.

I just wasted an evening trying to get 8MB of system files to a PC-98 laptop over floppy with PKZIP only to find out that there exist two problems between InfoZIP:

InfoZIP does not signal directories in a way that PKUNZIP recognizes. At least in DOSBox, PKUNZIP -d attempts to create an empty file for a directory entry, then go on to complain that it can't create files within the subdirectory. NOTE: It's also possible this is not a PKUNZIP problem but a DOSBox problem with FCBs, so verify first.

InfoZIP's volume spanning works only with InfoZIP. PKUNZIP will complain about inconsistent headers and CRC errors, and fail to extract the contents properly at all. The funny thing is the MS-DOS build of InfoZIP will also fail to extract the spanning ZIP archive with complaints about lseek.

Since the ZIP format is simple enough, and DOSLIB already contains a DOS port of the zlib library, it might be better if DOSLIB were to include it's own very simple ZIP archiving tool with support for volume spanning in a way PKUNZIP supports. The other reason is that I would like assurance from the ZIP archiver not to corrupt non-UTF-8 encodings like Shift-JIS when using it to transport to/from PC-98. The PKUNZIP complaints are reproducible under DOSBox-X so testing should be easy.

I've developed the Sound Blaster library into quite a useful library, now it's the Gravis Ultrasound's turn. There's a lot to play with, considering the onboard RAM, DMA, on/off bits, 14 to 32 voices, and lots of undocumented hardware quirks and I/O ports. Perhaps we can figure out the UltraMAX part as well. Perhaps we can figure out the part that SBOS uses to signal NMI when Sound Blaster I/O ports are involved. Perhaps we can figure out whether or not those IRQ enable bits matter.

Add to TEST.EXE a mode where the code will record 5 seconds of the DSP status port (0x22C) and then write it to a file. This mode should work whether the card is playing audio or not. Then we can use the recording to determine the busy cycle rate and width of each pulse, and how regular it is, for documentation.

An option should be provided to also record the DMA position, in case we want to correlate busy cycles with DMA activity to determine if they're related.

Wrap IBM PC/XT/AT-specific code in #ifndef TARGET_PC98, so it is not present for PC-98 targets.

PC-9821 is documented to have the same PCI control registers CF8h-CFFh as IBM PC/AT, so that code will stay.

Then, wrapped in #ifdef TARGET_PC98, add this reset code according to a FreeBSD site:

https://people.freebsd.org/~kato/pc98-arch.html

Though according to Undocumented 9801/9821, the author got the meaning of the bits backwards. But the goal is to reset the system.

I have some base code in place to detect PC-98 and makefile targets for PC-98. All I have so far are "is this PC-98" detection routines and support for PC speaker and 8254 timer on PC-98. All I have for reference are emulators. If anyone out there who has actual PC-98 hardware can help me with testing and development, that would be cool.

EXE files define the stack location and initial stack pointer, so it is possible to define symbols in the stack and resolve them.

COM and DRV however cannot know in advance the position and location of the stack. Attempts to emit symbols to the stack must fail with an error.

For some reason, 16-bit real mode builds fail DMA detection routine on an old Am386SX-20MHz motherboard with Sound Blaster 2.0 card. The same DMA detection works in 32-bit protected mode version.

http://www.oldlinux.org/Linux.old/docs/interrupts/int-html/rb-4534.htm

According to the 8514 display driver example in the Windows 3.1 DDK, there is an entry point you can call to execute user-mode code (ring 3) at kernel level (ring 0).

This could be a lot of fun. Add support functions to take advantage of it.

Also see if this exists in Windows 95 and later.

TMODESET is able to capture each VGA plane on every other VGA/SVGA hardware I have, but on an IBM PS/2 model 30, TMODESET.EXE's planar capture only seems to hold every 4th byte.

Now if it turns out that's actually how the PS/2's VGA hardware formats the data in memory, that's perfectly fine, but it's not clear whether that's the case or whether additional register work is needed to capture the contents of each 64KB VGA plane as-is without translation.

do a clean and make of the project ^^

Since "huge" 16-bit pointers in Watcom are essentually "large" model pointers with runtime code to increment pointer, perhaps it would be best to just have the VRL render code run as "large" model at all times. Then Sparky4 would see better performance in his sprite rendering.

Alternatively Sparky4 should probably consider dumping the huge memory model and use large instead, but I'm not sure he'll do that.

Even though the code to detect it is quite reliable, it might be a good idea if the user could specify NOT to use the undocumented DSP commands on Gallant SC-6000 cards.