DOS ain't dead

Hello! I've recently fallen down a rabbit hole of playing around with CGA graphics with the intent of making a space shooter game that doesn't look terrible in CGA, and runs without lag on vintage PCs.

Anyway, it seems like the best method is to do my video writes once vertical retrace starts so that the writes occur when the screen isn't being drawn, and also has the benefit of being a good timer for the game to allow it to be speed-independent.

I have some simple code that works great on DosBox-X, but when I tried to run it on FreeDOS running under VirtualBox, it runs at the speed of light (clearly the code to wait for vertical retrace doesn't work there).

So, my question is: is this a good way of doing things, and is this code the best way to accomplish it?


// If a retrace is in progress, wait for it to end.
// Wait for a new retrace to begin, then exit.
void wait_vsync() {
    while( inp(0x3DA)&0x08 ) { // Wait for retrace to complete
    }
   
    while( !(inp(0x3DA)&0x08) ) { // Wait for next retrace to start
    }
}


I can also share the source (Open Watcom compiler) and binary if that would be helpful, though it doesn't look like I can upload them here. Thanks in advance for any advice!

> Hello! I've recently fallen down a rabbit hole of playing around with CGA
> graphics with the intent of making a space shooter game that doesn't look
> terrible in CGA, and runs without lag on vintage PCs.
>
> Anyway, it seems like the best method is to do my video writes once
> vertical retrace starts so that the writes occur when the screen isn't
> being drawn, and also has the benefit of being a good timer for the game to
> allow it to be speed-independent.
>
> I have some simple code that works great on DosBox-X, but when I tried to
> run it on FreeDOS running under VirtualBox, it runs at the speed of light
> (clearly the code to wait for vertical retrace doesn't work there).
>
> So, my question is: is this a good way of doing things, and is this code
> the best way to accomplish it?
>
>
> // If a retrace is in progress, wait for it to end.
> // Wait for a new retrace to begin, then exit.
> void wait_vsync() {
> while( inp(0x3DA)&0x08 ) { // Wait for retrace to complete
> }
>
> while( !(inp(0x3DA)&0x08) ) { // Wait for next retrace to start
> }
> }
>
>
> I can also share the source (Open Watcom compiler) and binary if that would
> be helpful, though it doesn't look like I can upload them here. Thanks in
> advance for any advice!

What OS are you booting the machine to ?

What happens if you boot the machine directly into FreeDos
rather than running in VB ?

---
--
http://glennmcc.org/

> What OS are you booting the machine to ?
>
> What happens if you boot the machine directly into FreeDos
> rather than running in VB ?

I'm developing on a MacBook, so I don't really have a way to boot to DOS natively. That is indeed what I am wondering though - if it is somehow an issue with running it in DOSBox, or if I would also encounter the issue if I ran it natively.

> > What OS are you booting the machine to ?
> >
> > What happens if you boot the machine directly into FreeDos
> > rather than running in VB ?
>
> I'm developing on a MacBook, so I don't really have a way to boot to DOS
> natively. That is indeed what I am wondering though - if it is somehow an
> issue with running it in DOSBox, or if I would also encounter the issue if
> I ran it natively.

Well, it's just my own admittedly biased opinion,
but, it seems to me that the only proper environment for developing and testing
of a program intended for 'vintage PCs' with CGA graphics
would be a vintage PC with an actual CGA graphics card booted directly into DOS.
(how else could one possibly determine that said program
will actually run as intended on the intended machines ?)

---
--
http://glennmcc.org/

> Well, it's just my own admittedly biased opinion,
> but, it seems to me that the only proper environment for developing and
> testing
> of a program intended for 'vintage PCs' with CGA graphics
> would be a vintage PC with an actual CGA graphics card booted directly into
> DOS.
> (how else could one possibly determine that said program
> will actually run as intended on the intended machines ?)

For sure. I can at least get a head start with what I have now, and test and tweak as needed when I have the hardware to do so (and/or find willing testers with vintage hardware). What actually put the idea in my head is learning about the HP_200LX pocket computer, which is apparently a fully XT-compatible system that runs DOS, and can do CGA graphics (on a 4-tone B&W LCD screen). Eventually I'd like to pick up one of those when I find a good deal, and I wanted to see if I could make something fun to run on it.

Hello KarlG,

> learning about the HP_200LX pocket computer, which is apparently a fully
> XT-compatible system that runs DOS, and can do CGA graphics (on a 4-tone
> B&W LCD screen). Eventually I'd like to pick up one of those when I find a
> good deal, and I wanted to see if I could make something fun to run on it.
>

(1) Welcome!

(2) While waiting for a true CGA graphics system, perhaps you can try your code on Jeff Parsons's PCjs. Apparently PCjs does a crazy good job at emulating weird quirks of historical graphics adapters.

(3) As far as I know, there is no "standardized" interval at which vertical retraces need to happen. What is true on an actual CGA monitor may not be true on a newer VGA monitor, et vice versa. And of course virtual machines may throw all your assumptions out of the window. So it may be that your PC's display refreshes itself every 500 μs or so, or it may be every 100 μs, or (?) even every 1 μs...

My guess is that, yes, reading port 0x3da is a good thing to do to avoid ugly artefacts. But to be truly speed-independent, your program should probably also use a separate timing mechanism, whether via IRQ 0, or (if available) via IRQ 8, or something else.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> Hello KarlG,
>
> (1) Welcome!

Thank you!

> (2) While waiting for a true CGA graphics system, perhaps you can try your
> code on Jeff Parsons's PCjs. Apparently
> PCjs does a crazy
> good job at emulating weird quirks of historical graphics adapters.

Thank you for this, too! It has already been helpful. It appears to run at the expected speed on the original IBM PC with CGA and 256K of RAM, which is encouraging.

> > (2) While waiting for a true CGA graphics system, perhaps you can try
> your
> > code on Jeff Parsons's PCjs.
> Apparently
> > PCjs does a crazy
> > good job at emulating weird quirks of historical graphics
> adapters.
>
> Thank you for this, too! It has already been helpful. It appears to run at
> the expected speed on the original IBM PC with CGA and 256K of RAM, which
> is encouraging.

For the record: Jim Leonard aka Trixter has written a "CGA Compatibility Tester" in Turbo Pascal. Can be found at https://github.com/MobyGamer/CGACompatibilityTester.

---
Forum admin