VOGONS


First post, by carangil

User metadata
Rank Newbie
Rank
Newbie

I've been wanting to run DOSBOX in weird places, sometimes those that don't have a working SDL port. I've found a few people randomly asking online if DOSBOX can be used without SDL. I've also thought it would be cool to have DOSBOX more like a library anyone can build their own UI around, and without dependence on SDL, lightweight DOS emulation can easily be incorporated into any project.

I've spent some time the last couple days hacking around gui/sdlmain.cpp, getting DOSBOX to always render to a 32-bit color buffers (literally just char[] of the correct size) without using a SDL surface. I also abstracted the keyboard interface a bit, and now I have a fork of dosbox that doesn't need SDL for video or keyboard... I don't even SDL_Init VIDEO anymore. The buffers are currently being displayed (and keyboard events generated) by using a PixelToaster window. The intention isn't to port DOSBOX to PixelToaster, but rather port DOSBOX to a simple interface that just periodically says "HERE's a new framebuffer" or "got any keys/mouse for me?" For now I am ignoring ( commented out) joysticks, as that is a lot of SDL code, and I've never been that into them... This is mostly at the proof of concept phase... If someone really wants joysticks and find this interesting, they can do the work.

I'm moving onto sound today, and again it's going to be a simple "Here's some audio" kinda interface. I think keyboard/display/sound is a nice minimum working proof of concept... everything else can be commented out stubs. There are a handful of small things like GetTicks that I need to work out, but reading the time isn't exactly hard.

My eventual goal is to port DOSBOX to DOS, without using HX extender. If I don't have SDL, but get a 32bit linear framebuffer, then the interface I made up above should be able to copy into the real framebuffer no problem. For sound I will need to grab the ac97 and hda drivers for MPXPLAY, but I think HX extender did the same thing.

Another idea I have (this one is a bit of a stretch) is I'm also considering porting it to be a command in the iPXE bootloader. WHY? It has a fairly complete runtime, and can set VESA or UEFI graphics up on lots of video cards already, and has filesystem drivers and extensive network support... (No sound, but again that's solvable and not necessary for a proof of concept) Why would I want to shove DOSBOX into a bootloader? Just because... it will be DOSBOX directly booting off of a modern UEFI PC, with no linux kernel sitting underneath it, and with significantly less stuff going on than booting freedos and running HX (plus freedos can't do uefi partitions...) If this works, then that makes iPXE-DOSBOX a DOS-compatible operating system for modern PCs.

Reply 1 of 26, by BitWrangler

User metadata
Rank l33t++
Rank
l33t++

*makes minor encouraging noises to see where this goes*

Now something I could blow into a "useless" PXE network boot ROM would be innnnnteresting. The beauty/curse of SDL is not having to deal with hardware direct though, where modern GPU implementations may have dropped mode support for a lot of lower VGA and other modes. In other words, on barer metal, you're gonna be effectively writing your own sound, video and input drivers for every piece of hardware you want to implement it on.

Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.

Reply 2 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie

That's the cool thing, is most of the hard work is already done outside SDL. If you set only GFX_CAN_32, DOSBOX internally converts all video modes to 32 bit color. I have everything rendering to a buffer that is just 4*w*h bytes, which is a format suitable for bitblting to a VESA linear framebuffer, an opengl texture, windows GDI, etc. I'm not worrying about sub-VESA hardware... if you PC can't display 32bit color and needs a 15 or 16 bit (or 8-bit and HWpalette) support, its probably something old enough that can just run DOS and make use of various PCI card sb emu options.

For sound its all mixed internally in the emulated soundblaster, so a simple callback asking for audio is enough. That's what SDL, openal, or even real sound blaster IRQs give you already... so almost any existing PCM audio interface will work.

When I was looking I did find a somewhat 'parallel' project, where someone is trying to port SDL to DOS... https://discourse.libsdl.org/t/porting-sdl-to-dos/27361 that could also probably be used to make DOSBOX work on DOS.

Anyways, I know iPXE is a strech, but reading the keyboard, writing to VESA, and using drivers from for MPXPLAY seem all very doable from freedos with suitable hardware (or qemu/virtualbox). And iPXE creates a linear framebuffer, can read the keyboard, and is in protected mode where I can have a lot of RAM... The hard part might be is iPXE is all in C, and I don't know if its using a standard C library or something weird... there might not be a suitable out-of-the-box cpp library to run there...

And yes, when I play around with DOS coding, I usually run watcom from DOSBOX, so I don't see any reason why I shouldn't be able to test DOSBOX inside DOSBOX, since we have 32-bit color VESA support, SB support (which mpxplay has drivers for too).

Current Goals:
- Video without SDL (DONE)
- Keyboard input without SDL (DONE) ( sdlmain and sdlmapper don't use SDL anymore! except for GetTicks)
- Sound output without SDL (in progress, just going to write to a unix named pipe that aplay can read )
- Replace GetTicks
- Disable things like IPX or physical CD-ROM
- Build and Run without linking SDL
- Build on DOS w/ dummy drivers that just writes the framebuffer to a file every second or so, and writes audio to wav files. To prove it works in 'isolation' with no actual I/O apart from filesystem access
- Hookup the abstracted framebuffer to VESA output, and read the real keyboard
- DOSBOX on DOS!
- Mess with sound.

Reply 3 of 26, by javispedro1

User metadata
Rank Member
Rank
Member

When I was looking I did find a somewhat 'parallel' project, where someone is trying to port SDL to DOS... https://discourse.libsdl.org/t/porting-sdl-to-dos/27361 that could also probably be used to make DOSBOX work on DOS.

Yeah, I was precisely thinking that porting SDL(1) may be simpler than extricating dosbox from it, albeit dosbox itself would still need some retouching, so I'm unsure.

Also, UEFI. People have ported major C++ codebases to UEFI ( Qt: https://github.com/efidroid/qtbase/ ), and you can also run an UEFI payload after PXE. Would not be pure DOS, though 🙁

Anyway, this is crazy talk. I like it! 😀

Reply 4 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie

I don't need pure DOS... Dosbox on freedos is an interim stepping stone to booting dosbox straight from uefi... I would consider dosbox on uefi to be its own OS. Even if all I have is raw read/write block access via a BIOS or UEFI boot services call, dosbox (because of imgmount) already knows how to read/write FAT all by itself...

Reply 6 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote on 2022-02-12, 08:08:

It can read/write FAT16, but FAT32 support is not complete. Meaning you'd be stuck with 2G partitions max.

I would be happy with a handful of 2Gb partitions and maybe a few CUE/BIN read off using a readonly driver from elsewhere...

Hey, so I got SDL and a lot of other dependencies out. Some functionality is gone (like ipx networking, and a few silly things), but I got my linker down to this:

g++ -g -O2 -mno-ms-bitfields -o dosbox dosbox.o cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/mame/libmame.a hardware/serialport/libserial.a -lm -L/usr/lib -lz -lX11

-lX11 is for pixeltoaster's sake... on a real abstract port there will be no window (its just for testing), and I will blit into the framebuffer.
-lm is just basic math
-lz is just zlib

The next thing I may remove is the serial port, since I don't feel like fiddling with whatever calls I need to make that work in real DOS at the moment. After all that, I'll see how far I can get building in openwatcom or djgpp. At least djgpp has gettimeofday and usleep, which I wrapped as replacements for SDL_GetTicks and SDL_Delay.

For sound, I write to a file. On linux, I did a mkfifo, and had aplay reading the pipe at the right sample rate, and all sounded fine. (There was a noticable latency, but that is aplay and the pipe) but no stuttering or glitches.

I also have no mouse support, because pixeltoaster has no mouse grab function (its pretty basic), but the internal calls should all be intact... For real DOS, I would just take the mouse deltas and buttons and feed them through.

So, for now, I have a functional DOSBOX with super generic video and sound. 32-bit graphics output with no scaling and 44100 16-bit stereo sound. Just about anything powerful enough to run dosbox should be able to handle outputting that somewhere.

After I can get it running in straight DOS, I'll clean it up, and make a dosbox-core library that is just plain c++ with only the math and zlib dependencies, and provide simple video/sound/key/mouse interfaces, and DOS will be the example platform.

I'm really hoping DOSBOX will run inside of itself...

pop.jpg
Filename
pop.jpg
File size
265.14 KiB
Views
2893 views
File license
Fair use/fair dealing exception

Reply 7 of 26, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Have you checked how big the memory footprint is?
The size of the static memory variables in DOSBox is more than 20MB, and that's before dynamic allocations (which includes the main emulated physical memory). Given DOSBox can only emulate 63MB of RAM max I doubt you'll fit DOSBox inside DOSBox...

Reply 8 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote on 2022-02-13, 02:50:

Have you checked how big the memory footprint is?
The size of the static memory variables in DOSBox is more than 20MB, and that's before dynamic allocations (which includes the main emulated physical memory). Given DOSBox can only emulate 63MB of RAM max I doubt you'll fit DOSBox inside DOSBox...

On freedos or uefi that won't be a problem. DOSBOX in DOSBOX is filed under the 'useless stunt' category. In DOSBOX, is there any reason why cwsdpmi's swapfile functionality wouldn't work? If the swap file is on the host's /tmp and I'm running tmpfs, there's some overhead but perhaps the stunt will work and not thrash the host's actual disk.

Right now I'm trying djgpp and watcom inside dosbox, and they are way slow to compile simple programs (I'm just at the Hello World in VESA stage), and when I start adding in the dosbox sources, I might not even have the ram to do it 'self hosted.' I need to install the linux cross-compiler, OR better yet, finally dig my windows 98 machine out of the closet w/ Borland C++ and univesa, etc.

Reply 9 of 26, by digger

User metadata
Rank Oldbie
Rank
Oldbie

You might want to look into the uefidoom project, which is a Doom port to a UEFI payload, making use of the standard UEFI framebuffer and Intel HD Audio. This effectively makes Doom a modern-day PC booter game. 😁

You might be able to reuse some of this code to allow your fork to boot directly on modern UEFI-based systems. (Of course the Intel HD Audio support would limit it to x86 and x86_64 architectures, but an integrated generic USB Audio Class driver might be a good architecture-neutral alternative to consider for such a port.

Then, there is the bareDOOM project, which builds on barebox, which is a cross-platform bootloader that supports most common architectures. That might be an even more flexible basis than targeting UEFI support directly.

Yes, I know, the whole point of DOSBox is to be able to play all DOS games, not just Doom. But Doom is a popular open-sourced game that has been ported to just about any imaginable platform (from Internet-connected fridges to digital cameras). So Doom forks like these would likely provide some useful reusable code that you can use in your project as well.

By the way, your "SDL-less dumb framebuffer" approach reminds me of that of the Advanced Mac Substitute, a 68K Macintosh emulator that includes integrated API-level compatibility with classic Mac OS, without requiring any ROMs, particularly this part:

The frontend is a generic bitmapped terminal abstraction which has been ported to four platforms so far: macOS / OS X, X11, Linux framebuffer, and VNC/RFB.

When I think about it, this might actually be the better way to go for the upstream DOSBox project. Right now, the upstream/mainline DOSBox project is being held back by an insistence on sticking with SDL 1.x, just for the sake of remaining portable to old operating systems for which likely no SDL 2.x port will be developed. Separating the SDL support from the core engine like this would indeed make it more flexible, more portable, and both more backwards- and forwards-compatible.

So yeah, great initiative! 🙂

Reply 10 of 26, by BitWrangler

User metadata
Rank l33t++
Rank
l33t++
carangil wrote on 2022-02-14, 18:19:

On freedos or uefi that won't be a problem. DOSBOX in DOSBOX is filed under the 'useless stunt' category.

There's no real practical purpose, but it seems like a validation check that would be reassuring, like having a compiler compile itself.

Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.

Reply 11 of 26, by LightStruk

User metadata
Rank Member
Rank
Member
carangil wrote on 2022-02-10, 17:01:

I've been wanting to run DOSBOX in weird places, sometimes those that don't have a working SDL port. I've found a few people randomly asking online if DOSBOX can be used without SDL. I've also thought it would be cool to have DOSBOX more like a library anyone can build their own UI around, and without dependence on SDL, lightweight DOS emulation can easily be incorporated into any project.

I understand the appeal of running DOSBox on bare metal and relying purely on UEFI or BIOS services. That said, if the issue is that your desired platform or OS lacks SDL support, then I strongly encourage anyone in this situation to add that support to SDL rather than removing SDL from the application.

  • SDL ports do not need to support every feature and flag of SDL. A rudimentary port that just gets input, sound, and a plain framebuffer Surface working is less challenging than coming up with a first-class SDL target, while still being usable.
  • Even a rudimentary SDL port to an exotic platform is more useful than removing SDL from a single application. Suddenly, thousands of applications can now potentially run on that platform.
  • Maintaining support for that exotic platform is much easier. DOSBox, at least with all of its forks, is a lively project with lots of development going on. SDL is comparatively sleepy. Keeping an SDL target current will be much easier over time than keeping a DOSBox fork current.
  • A new SDL target with its new drivers is a well-contained and modularized project. Removing SDL from a program is a messy diff that has to replace a lot of SDL constants, functions, and assumptions.

Reply 12 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie
LightStruk wrote on 2022-02-15, 15:48:

I understand the appeal of running DOSBox on bare metal and relying purely on UEFI or BIOS services. That said, if the issue is that your desired platform or OS lacks SDL support, then I strongly encourage anyone in this situation to add that support to SDL rather than removing SDL from the application.

I think adding SDL back in, but though a more generic interface would be nice and clean. DOSBOX does have some interesting integration, like outputting 8-bit color to SDL and giving SDL a palette... to make use of HW palette support. I wonder if it makes sense to keep supporting machines that have an optimized 8 and 16 bit path, since most anything that old is a bit slow for DOSBOX, and newer things want 32bit. (Though this is said by someone trying to port it to DOS... )

Last edited by Stiletto on 2022-02-18, 01:54. Edited 1 time in total.

Reply 13 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie
carangil wrote on 2022-02-15, 19:32:
LightStruk wrote on 2022-02-15, 15:48:

I understand the appeal of running DOSBox on bare metal and relying purely on UEFI or BIOS services. That said, if the issue is that your desired platform or OS lacks SDL support, then I strongly encourage anyone in this situation to add that support to SDL rather than removing SDL from the application.

I think adding SDL back in, but though a more generic interface would be nice and clean. DOSBOX does have some interesting integration, like outputting 8-bit color to SDL and giving SDL a palette... to make use of HW palette support. I wonder if it makes sense to keep supporting machines that have an optimized 8 and 16 bit path, since most anything that old is a bit slow for DOSBOX, and newer things want 32bit. (Though this is said by someone trying to port it to DOS...)

maybe the DOS port can have wackier things like putting VESA in the right mode and just copying the virtual framebuffer data to the real one without 'rendering' it to a scaled bitmap first. Or if you have a real sound blaster, send it the OPL commands. I have a board fast enough to run dosbox and has an ISA slot...

Last edited by Stiletto on 2022-02-18, 01:54. Edited 1 time in total.

Reply 15 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie

I seem to have this working, no sound support yet apart from writing to a file. But, I have a pure dos version of dosbox. I didn't use any compiler optimization flags, and I'm using a vesa library that came with djgpp, and I'm converting 32-bit to 24-bit framebuffer layouts with a very naive for loop; I should make it directly render to 24-bit I suppose, or find a way to make a properly padded framebuffer. It is dead slow... With prince of persia you an watch it paint the intro. And my DOS dev machine in a k6, which isn't very fast to begin with (though the proper windows build of dosbox can run 286/386 speed on some games.)
I also didn't hook up the keyboard... I just have the autoexec section mount a folder and start a game that has some graphics and sound for an intro.

I guess if I get some faster screen copy routines, hook up the keyboard, compile with optimizations and also shoehorn in the soundy bits of mpxplay, there may be a working true dos port of dosbox at some point.

Reply 16 of 26, by ViTi95

User metadata
Rank Member
Rank
Member

Compiler optimizations and a faster backbuffer to VRAM algorithm will make it much faster. Avoid at all costs transfer huge amounts of data to the video card, a 8-bit palletized mode will always be faster than a 15 o 24 bit mode. Also precalculated LUTs for backbuffer format conversions give mayor performance uplifts.

https://www.youtube.com/@viti95

Reply 17 of 26, by carangil

User metadata
Rank Newbie
Rank
Newbie

Does this still matter much on newer hardware? My eventual target is a modernish multi-ghz system. My dev system is a k6 because that's my classic win98/dos gaming machine, and it was much easier to run djgpp there in a DOS window (while using a gui text editor, and transfering files from my server with scp) than it was to try to run a pure freedos VM... (If only I could mount it on the host while the guest is running... DOSBOX is actually super useful for casual DOS game development because the filesystem is really the host) I suppose I can run a windows xp VM and do a similar workflow w/ mounted network drives, but I already had this DOS system handy. (And nothing stops me from taking the binary and testing it on a bigger machine.)

I took a break from this project after I got some success, but am ready to jump back into it soon. (Sorry to anyone if it is a bit of a tease.)

Reply 18 of 26, by leileilol

User metadata
Rank l33t++
Rank
l33t++
LightStruk wrote on 2022-02-15, 15:48:

A new SDL target with its new drivers is a well-contained and modularized project. Removing SDL from a program is a messy diff that has to replace a lot of SDL constants, functions, and assumptions.

That sounds nice in theory, but there's another problem in recent years - SDL2 stans that'll lecture you about modern code and OSes (i.e. the importance of 64-bit catalina and debian) and condescend about anything SDL1 related regardless of project/platform goals who see SDL1 as "dead outdated code that must be replaced by SDL2 at all costs". 😜

apsosig.png
long live PCem

Reply 19 of 26, by LightStruk

User metadata
Rank Member
Rank
Member
leileilol wrote on 2022-02-25, 01:24:
LightStruk wrote on 2022-02-15, 15:48:

A new SDL target with its new drivers is a well-contained and modularized project. Removing SDL from a program is a messy diff that has to replace a lot of SDL constants, functions, and assumptions.

That sounds nice in theory, but there's another problem in recent years - SDL2 stans that'll lecture you about modern code and OSes (i.e. the importance of 64-bit catalina and debian) and condescend about anything SDL1 related regardless of project/platform goals who see SDL1 as "dead outdated code that must be replaced by SDL2 at all costs". 😜

The maintainers of libSDL have every reason to want to leave SDL 1.x behind. They have to make SDL2 work for current titles on current systems. Maintaining SDL 1.x is a drain on limited resources.

If there's still significant demand for maintaining SDL 1.x and for adding retro targets to SDL1, then the community would benefit from coalescing around a single fork of SDL 1.x. There are a bunch of title-specific forks of SDL 1.x on GitHub, but no torch-bearer that is trying to organize all of the disparate efforts into a single version as far as I can tell. If the upstream org does not want to merge substantial new code or fixes from the community, well, that's why it's open source! The community can leave upstream behind if necessary.