Forgot to mention that for DOS I plan to use TASM and Turbo C++ 3.0 IDE. I will use C rather than C++. For Windows I am intending to use Visual C++ 6

I've been doing exactly this for many years, not so much for games, but I do a lot of development. I have done a lot of DOS software that:

- Talks to Hardware directly EG: ImageDisk

- Does simple VGA graphics EG: MicroCad

My main DOS/Win9x system is a P3/500 with an ATI video card, an SB16 and a NE2000 compatible network card.

Just a few thoughts:

>>I will swap between the roles by using a HDD caddy.
Exactly what I do - for above mentioned system it's still IDE - but for newer systems I use SATA carriers.

If you have IDEs, great for old systems, but they are hard to come by these days, if you can build SATA that's the way I'd go.

>>Starting from games that will run on a 4.77Mhz 8088 ..
This is probably trickiest, most newer CPUs will do 8088 instructions, but "true" performance is not easy, there are various "slowdowm" programs which work to different extents, but I've never had super good luck with them.

IMHO The best way to evaluate operation on slow 8088 is with a virtual machine. I tend to like DosBox because of it's direct interface with the host filesystem, but it doesn't do below a 386. I also use PCem sometimes which does do 8088, but is a bit harder to move stuff on/off - For small stuff, I boot 1.44m floppy disk images which I can read/write files from/to on the host using my own FDI (Floppy Disk Image) tool. For bigger stuff I DDLINK between the host an VM.
The few times when I *really* want to test on actua 8088 hardware, I use the only 8088 system I still have, a "Poqet PC" - much harder to get files on/off of (You have to do a serial connection)

>>... be able to transfer them to my NuXT system for testing on semi-authentic hardware. Will use floppy disk for this.
Even though I use floppies a LOT - I don't recommend using them one an everyday basis for "sneakernet" - given how hard good media and drive parts are to get these days... I put as little wear and tear on them as possible.

You could use a GoTek floppy emulator which will look like a floppy to the system, but uses a USB "stick" for storage - front panel buttons let you select from many floppy images stored on a single stick, and you can swap sticks.

GoTek provides software to read/write the "virtual" floppies on a modern system, but I find that the firsts image on the stick can be accessed from Windows on a file basis directly.

Another option: Use DDLINK - this is a file transfer program that will work over Lan (no network SW required, only a "packet driver"), Serial or LPT.

It also runs well under DosBox which lets you move files to/from modern systems over Lan or Serial.

RetroPCCupboard wrote on 2026-05-24, 09:27:

Forgot to mention that for DOS I plan to use TASM and Turbo C++ 3.0 IDE. I will use C rather than C++. For Windows I am intending to use Visual C++ 6

I still use mainly C (& ASM). For DOS, I mainly use my own Micro-C compiler (has a lot of useful DOS/hardware libraries) and Turbo-C when I need it.

I also use VisualC++ for Winblows , IIRC I mainly use "4.0 Express" because I found that the later versions of express more limiting and had things removed
(egL I can compile DosBox under 4.0 express but not under 6 express)

DaveDDS wrote on 2026-05-24, 11:02:

My main DOS/Win9x system is a P3/500 with an ATI video card, an SB16 and a NE2000 compatible network card.

Nice. Yeah, I am sure that is plenty for DOS and early Win9x. I basically want overkill specs to minimise time spent waiting for it to compile.

DaveDDS wrote on 2026-05-24, 11:02:

Just a few thoughts: […]
Show full quote

Just a few thoughts:

>>I will swap between the roles by using a HDD caddy.
Exactly what I do - for above mentioned system it's still IDE - but for newer systems I use SATA carriers.

If you have IDEs, great for old systems, but they are hard to come by these days, if you can build SATA that's the way I'd go.

I have quite a few IDE HDDs, yeah. My caddies are IDE also. Nothing to stop me using IDE to SATA or IDE to CF inside the caddies.

DaveDDS wrote on 2026-05-24, 11:02:

>>Starting from games that will run on a 4.77Mhz 8088 ..
This is probably trickiest, most newer CPUs will do 8088 instructions, but "true" performance is not easy, there are various "slowdowm" programs which work to different extents, but I've never had super good luck with them.
>

Yeah, my intent is not to try to run 8088-era games on this machine. But I would like to write my own games that will run on 8088 at acceptable speed, and on faster systems will auto-adjust. I believe the way to do this is to use the programmable interrupt timer. But I havent tried yet.

DaveDDS wrote on 2026-05-24, 11:02:

IMHO The best way to evaluate operation on slow 8088 is with a virtual machine. I tend to like DosBox because of it's direct interface with the host filesystem, but it doesn't do below a 386. I also use PCem sometimes which does do 8088, but is a bit harder to move stuff on/off - For small stuff, I boot 1.44m floppy disk images which I can read/write files from/to on the host using my own FDI (Floppy Disk Image) tool. For bigger stuff I DDLINK between the host an VM.
The few times when I *really* want to test on actua 8088 hardware, I use the only 8088 system I still have, a "Poqet PC" - much harder to get files on/off of (You have to do a serial connection)

Very good points. I was trying to stay away from emulation though.

DaveDDS wrote on 2026-05-24, 11:02:

>>... be able to transfer them to my NuXT system for testing on semi-authentic hardware. Will use floppy disk for this. Even tho […]
Show full quote

>>... be able to transfer them to my NuXT system for testing on semi-authentic hardware. Will use floppy disk for this.
Even though I use floppies a LOT - I don't recommend using them one an everyday basis for "sneakernet" - given how hard good media and drive parts are to get these days... I put as little wear and tear on them as possible.

You could use a GoTek floppy emulator which will look like a floppy to the system, but uses a USB "stick" for storage - front panel buttons let you select from many floppy images stored on a single stick, and you can swap sticks.

GoTek provides software to read/write the "virtual" floppies on a modern system, but I find that the firsts image on the stick can be accessed from Windows on a file basis directly.

I hadn't considered floppy wear to be honest. Is it that much of an issue? I have a couple of hundred blank floppies. Some new in box. Various brands. I also have quite a few floppy drives. Some are new.

I do have a couple of unused goteks also.

DaveDDS wrote on 2026-05-24, 11:02:

Another option: Use DDLINK - this is a file transfer program that will work over Lan (no network SW required, only a "packet driver"), Serial or LPT.

It also runs well under DosBox which lets you move files to/from modern systems over Lan or Serial.

I won't be able to put a network card in my NuXT, as I'm planning to have it in a low profile case. It will be on the other side of the room to the dev PC. Access to the rear of the PCs will be hard. Just thinking though, that the NuXT does have two IDE channels on it. One is linked to onboard CF reader, which I will boot from. I could use the other channel with an IDE to CF or IDE to SD, and add a USB reader/writer to the dev machine.

DaveDDS wrote on 2026-05-24, 11:10:

I still use mainly C (& ASM). For DOS, I mainly use my own Micro-C compiler (has a lot of useful DOS/hardware libraries) and Turbo-C when I need it.

I also use VisualC++ for Winblows , IIRC I mainly use "4.0 Express" because I found that the later versions of express more limiting and had things removed
(egL I can compile DosBox under 4.0 express but not under 6 express)

Ok. Great. I have Visual Studio 6 from when it came on MSDN in my early dev days.

I used VB6 for front end stuff and C++ for windows services.

I have never used Turbo C or Turbo C++, but I obtained a boxed version with manuals from ebay.

RetroPCCupboard wrote on 2026-05-24, 14:32:

DaveDDS wrote on 2026-05-24, 11:02:

>>... be able to transfer them to my NuXT system for testing on semi-authentic hardware. Will use floppy disk for this. Even tho […]
Show full quote

>>... be able to transfer them to my NuXT system for testing on semi-authentic hardware. Will use floppy disk for this.
Even though I use floppies a LOT - I don't recommend using them one an everyday basis for "sneakernet" - given how hard good media and drive parts are to get these days... I put as little wear and tear on them as possible.

You could use a GoTek floppy emulator which will look like a floppy to the system, but uses a USB "stick" for storage - front panel buttons let you select from many floppy images stored on a single stick, and you can swap sticks.

GoTek provides software to read/write the "virtual" floppies on a modern system, but I find that the firsts image on the stick can be accessed from Windows on a file basis directly.

I hadn't considered floppy wear to be honest. Is it that much of an issue? I have a couple of hundred blank floppies. Some new in box. Various brands. I also have quite a few floppy drives. Some are new.

It's a concern more because getting new diskettes can be very difficult.

It's enough of a concern (to me) that even though I have literally 1000s of unused 3.5" floppies (My company sold software on floppy disk "bacl in the day", I had a system set up with a "Victory autoloader" to be able to run 100s of shipable discs a day! - still have a few boxes [>1000/box] ) - I am careful with them and the drives they are used in...

... And it really depends of how much you are going to be using/putting wear on them. With some diskettes age can become a factor as well.

If you do decide to keep the plan of using actual floppy discs, make sure the keep the drive heads spotlessly clean!

I do have a couple of unused goteks also.

IMHO better way to "sneakernet" these days!

I won't be able to put a network card in my NuXT, as I'm planning to have it in a low profile case. It will be on the other side of the room to the dev PC. Access to the rear of the PCs will be hard. Just thinking though, that the NuXT does have two IDE channels on it. One is linked to onboard CF reader, which I will boot from. I could use the other channel with an IDE to CF or IDE to SD, and add a USB reader/writer to the dev machine.

There are low-profile network cards (yeah - good luck finding one) - DDLINK can also transfer via parallel (not great if across room - I've done it with a 25' cable that I just run direct across when I need to do a transfer), or Serial (slower, but much easier to do over a distance).

IDE to CD or IDE to SD sounds like a good option, but... most classic PS OSs can't mount/unmount hard drives making t tricky to insure all OS buffers are flushed to the drive before you remove it and drive gets properly recognized/initialized when you reinsert it - depending on how often you do this, it might just be easier to shutdown/restart.

I have never used Turbo C or Turbo C++, but I obtained a boxed version with manuals from ebay.

Turbo-C was pretty much the firsts C compiler I ever had for DOS-PC (IIRC it was 1.5 later I updated to 2.0) and it worked well with not too many "annoyances"...
but honestly since I created Micro-C and it's PC/DOS edition, I almost never use TC now!

DaveDDS wrote on 2026-05-25, 18:23:

DDLINK can also transfer via parallel (not great if across room - I've done it with a 25' cable that I just run direct across when I need to do a transfer), or Serial (slower, but much easier to do over a distance).

I am reconsidering now. I may put both machines next to each other. Problem is that in this location I have 1 monitor, and one keyboard/ mouse. I use a KVM to switch machines. Not sure if that will be a hassle for transfers via DDLINK. Will I have to switch between machines back and forth to transfer? ?

DaveDDS wrote on 2026-05-25, 18:23:

Turbo-C was pretty much the firsts C compiler I ever had for DOS-PC (IIRC it was 1.5 later I updated to 2.0) and it worked well with not too many "annoyances"...
but honestly since I created Micro-C and it's PC/DOS edition, I almost never use TC now!

Sounds interesting. I will have to check it out. You've excluded memory heavy datatypes, which would suit targetting my NuXT. Looks like it may be perfect for writing a simple game for it or even just messing around on it. I assume its faster than Turbo C at compiling on a 8088.

Socket A Thunderbird – 1400Mhz Abit KT7A-RAID motherboard 256Mb RAM (one stick) Geforce 4 MX460 Soundblaster Live! for Windows S […]
Show full quote

Socket A Thunderbird – 1400Mhz
Abit KT7A-RAID motherboard
256Mb RAM (one stick)
Geforce 4 MX460
Soundblaster Live! for Windows
Soundblaster 16 for DOS with Dreamblaster S2
HDD caddy to swap between Win98 SE, Win2K and Win98SE Dev
Large Tower ATX Desktop PC

Here are the modifications I would make to this:
1. Go to 512MB RAM
2. Add a network card (3C905 is probably your best bet, considering you have to use your only ISA slot for the SB16)
3. Do you really need the SB Live? I'm assuming you have some reason for wanting it in Windows. If not, the SB16 will work just as well. You can use it for both.

1) Fast compile times

The Athlon will give you this no matter what.

2) Able to natively write to the graphics card in DOS (CGA/EGA/VGA). Including the ability to scroll smoothly like Commander Keen. I am not bothered about supporting composite CGA modes

Well, this is not a high bar. If you want help with the smooth scrolling stuff, I've been deep in the weeds on that for a while and I can show you how it works.

3) Able to test my early games locally, but be able to transfer them to my NuXT system for testing on semi-authentic hardware. Will use floppy disk for this.

I would suggest, instead of the floppy, using a tool such as ETHERDFS: https://etherdfs.sourceforge.net/

5) Ability to make sound with Adlib / Soundblaster

I've done a lot of Adlib music code if you're interested in tips there as well.

I have some suggestions for the software setup.

I don't think HDD caddies are necessary at all.

I would set up a dual boot between a dedicated DOS partition and a Win98SE partition. No reason to have separate installations for games vs. development. Use BOOTMGRX from BTTR Software to wrangle the MBR for the installation process and create the boot menu to switch between them.

As for the compiler, Turbo C will work fine, but I recommend Open Watcom.

You can do all of your DOS development from within Windows, of course. You don't even really need a DOS install if you don't want it. It's just nice to have a dedicated DOS environment to work in sometimes.

Don't bother with slowdown tools. They will not give you an accurate picture of the speed of your program.

I have found the best environment for DOS development to be a modern Linux computer. I edit the code using my text editor of choice, then using DOSBox Staging (with a default cycle count of 200000) I compile using Open Watcom, and run quick tests by adjusting the cycle count to the ballpark ranges for various machines. ~300 cycles for an 8088 4.77 MHz. ~600 for a Turbo XT. ~1000-1500 for a 286. ~2000-3000 for a 386. Etc. Then I run more in-depth tests using a range of machines I have configured in 86Box, all the way from original IBM XT to 486DX2/66, with various video cards.

There are monitor riser sized SFF sandybridge machines going for $50 to $100 now, such that it might not be a terrible idea to have a retro setup like a Phil's 36 in 1 MMX system with a vintage IDE on it and send compiles to the "monitor riser" with GCC or Clang or something configured to right targets. I think PMMX is getting just quick enough to consider VNC or something to get "on" the SFF from Win98, over decent enough network connection.

RetroPCCupboard wrote on 2026-05-26, 16:43:

I am reconsidering now. I may put both machines next to each other. Problem is that in this location I have 1 monitor, and one keyboard/ mouse. I use a KVM to switch machines. Not sure if that will be a hassle for transfers via DDLINK. Will I have to switch between machines back and forth to transfer? ?

No, in fact it sh0uld work perfectly in your setup.

DDLINK operates as a client and a server. You start the server first, then the client can connect to it.

All interaction is performed from the client. The server shows what's going on, but the only interaction you do with it from the keyboard is to press ESC to terminate it. (which you can also cause to happen remotely - in fact you can make it terminate with any EXIT code you specify, which means you can run it from a .BAT file which can do "other stuff" on command)

Sounds interesting. I will have to check it out. You've excluded memory heavy datatypes, which would suit targetting my NuXT. Looks like it may be perfect for writing a simple game for it or even just messing around on it. I assume its faster than Turbo C at compiling on a 8088.

Oh yeah, it compiles very quickly, and runs fine on an 8088 (and also produced code which will run on an 8088)

It may not be what some would consider a "full" development suite, but it is very capable - pretty much all my other software is written/built with Micro-C
(ImageDisk, DDLINK, all my DOS tools, Micro-C itself and more...)

And... probably doesn't matter in this case, but it's very small - complete dev. environment fits easily on a single bootable floppy with room to spare.

DaveDDS wrote on 2026-05-27, 02:39:

No, in fact it sh0uld work perfectly in your setup.

DDLINK operates as a client and a server. You start the server first, then the client can connect to it.

All interaction is performed from the client. The server shows what's going on, but the only interaction you do with it from the keyboard is to press ESC to terminate it. (which you can also cause to happen remotely - in fact you can make it terminate with any EXIT code you specify, which means you can run it from a .BAT file which can do "other stuff" on command)

Sounds great. Is this the cable I would need?

https://ebay.us/m/ePrl3m

DaveDDS wrote on 2026-05-27, 02:39:

Oh yeah, it compiles very quickly, and runs fine on an 8088 (and also produced code which will run on an 8088) […]
Show full quote

Oh yeah, it compiles very quickly, and runs fine on an 8088 (and also produced code which will run on an 8088)

It may not be what some would consider a "full" development suite, but it is very capable - pretty much all my other software is written/built with Micro-C
(ImageDisk, DDLINK, all my DOS tools, Micro-C itself and more...)

And... probably doesn't matter in this case, but it's very small - complete dev. environment fits easily on a single bootable floppy with room to spare.

Sounds perfect. I will check it out once I have the PCs set up

RetroPCCupboard wrote on 2026-05-28, 10:03:

... Sounds great. Is this the cable I would need?

https://ebay.us/m/ePrl3m

I think that would work - I believe when I created DDLINK ... I follower the LapLink cable pinout ... but I've never had an actual LapLink cable so I can't say for certain.

I do include diagrams to make both/either serial null-modem and parallel data-transfer cables.

The technique I used to make the parallel cable is just - two board/panel mount DB-25 connectors mounted back-to-back on top of each other -- with just short jumper wires moving signals around between them - this "adapter" is about 3/4 long and I just place it on the end of a 25-pin <> 25-pin cable (which I have lots of) to connect the two PCs together. (I can post a photo if you want to see)

Turns out I've already posted a photo on my serial null-modem and parallel data-transfer "adapters":

Re: Make a unidirectional parallel printer port bidirectional?

The actual adapters are covered so you can't see the wiring, but beside them I've placed and uncovered null-modem one so you can see how the connections were made.

DaveDDS wrote on 2026-05-28, 11:28:

I think that would work - I believe when I created DDLINK ... I follower the LapLink cable pinout ... but I've never had an actual LapLink cable so I can't say for certain.

I do include diagrams to make both/either serial null-modem and parallel data-transfer cables.

Ok. Thanks. I will buy the cable and see if it works. I don't really fancy making custom cables. Haha.

I think it might be more fun to modify the source to DDLINK to have an option for using laplink cables. It is open-source isn't it?

RetroPCCupboard wrote on 2026-05-28, 12:37:

I think it might be more fun to modify the source to DDLINK to have an option for using laplink cables. It is open-source isn't it?

I've posted all my sources on my site now (retirement project)

But I'm pretty sure it will already work with a LapLInk cable.

DaveDDS wrote on 2026-05-28, 13:08:

RetroPCCupboard wrote on 2026-05-28, 12:37:

I think it might be more fun to modify the source to DDLINK to have an option for using laplink cables. It is open-source isn't it?

I've posted all my sources on my site now (retirement project)

But I'm pretty sure it will already work with a LapLInk cable.

Thanks. I will let you know if not.

This is the ouput of: DDLINK ?L

Which shows the LPT cable pinout

1DDLINK requires a "bidirectional data-transfer" parallel cable:
2
3             DB25-DB25
4    ---------------------------
5    GND        25-25        GND
6    D0          2-15        ERROR   \
7    D1          3-13        SLCT     > Must be wired
8    D2          4-12        PE       > between  BOTH
9    D3          5-10        ACK      > ends (two wires)
10    D4          6-11        BUSY    /

If you search "Laplink cable" and look at images you can find some that show the cable wiring... and it seems to match up.