• Please review our updated Terms and Rules here

What are you guys using for retroprogramming?

PgrAm

Experienced Member
Joined
Sep 28, 2011
Messages
276
Location
Toronto, Canada
Hey guys,

I feel like I don't hear enough about how other retro-programmers work, I was wondering what you guys were all using for your retro-programming needs.

What hardware are you targeting?
What kind of compiler/interpreter software do you use?
Do you program on old-school systems themselves or do you use a modern editor?
And (hopefully without starting a flame war) what language(s)?

Right now, I'm writing for an old AST 286 PC machine.
I use the OpenWatcom Compiler.
I use a modern PC with Visual Studio as my editor.
And I use C++ and some 8086 assembly, with a dash of a custom scripting language.

How about you guys?
 
Last edited:
I target various different platforms...

MS-DOS, 808x-486:
- OpenWatcom IDE on modern Windows for C/C++ and inline asm code
- MASM on modern Windows
- TASM on DOS
- Notepad++ as editor
- I test with DOSBox or real hardware (IBM 5150, PCjr, or generic 8088, 286 or 486 clone), depending on kinds of tests I want to do

Windows 9x, 486-Pentium II-ish:
- Visual C++ 6.0 on modern Windows for C, C++ and inline asm
- MASM on modern Windows
- DirectX

Commodore 64:
- Kick Assembler on modern Windows
- Notepad++ as editor
- VICE for most testing, use X1541 cable to transfer to disk on a real system for final tests

Amiga (OCS, ECS, AGA):
- SAS/C for C/C++ code
- DevPac for 68k assembly
- Notepad++ as editor
- WinUAE for testing (I have some Amigas, but none of them work quite right at the moment, so real hardware is not currently an option)

So in general, C/C++ is more or less a common factor. I also have some libraries that are re-usable between the different platforms.
Commodore 64 is the odd one out: because of the platform limitations I use pure assembly only.
For 8088 stuff I also do certain stuff in pure assembly.
For slightly more high-end stuff I tend to use pure C with inline assembly, and for the most 'high-end' platforms I may use C++ features as well.
 
I use DOSEMU or WINE on 64-bit Ubuntu for most things retro. I also keep a copy of XP around on VirtualBox for more platform-demanding work. Most of my DOS programming is done in MASM 6.x or MSVC.

Increasingly, that's getting to be smaller part of my work, however.

Testing, on the other hand, is done on the real iron.
 
Amiga (OCS, ECS, AGA):
- SAS/C for C/C++ code
- DevPac for 68k assembly
- Notepad++ as editor
- WinUAE for testing (I have some Amigas, but none of them work quite right at the moment, so real hardware is not currently an option)

How is SAS/C in terms of standards compatibility? I've always wanted to try programming for my A500 but I never know which compiler to start with. Ideally I'd like to port one of my DOS games to Amiga
 
Last edited:
NDP Fortran-77 4.4 (Microway), PharLap ASM386/386link, PharLap 8.0 DOS extenders for protected mode. I also use the Microway C/C++ v4.6 compiler. RM-Fortran-77 V2.43 and IBM Macro for realmode. Wordstar 6.0 for editing.
PharLap uses up to 4GBytes of RAM. It's very fast on a Vortex DX running 800Mhz, even faster on an Core I3.
 
How is SAS/C in terms of standards compatibility?

As well as can be expected from any late 90s C/C++ environment I suppose.
C++ is limited (things like namespaces and templates weren't fully supported yet). Regular C is okay, you get the usual ANSI C support. But don't expect 'modern' features such as stdint.h support. Of course, you can easily create your own header for it. That's what I did.
If you want to run it on a real Amiga, having at least 2 MB is a requirement, and of course a hard disk.
It runs fine in WinUAE though, so I just compile there, at warp speed :)

SAS/C is a descendent of Lattice C++, as was Visual C++ before the .NET versions (so up to and including version 6.0). You'll find some of the same quirks in SAS/C as in MSVC++ 6.0.
 
My current project is a mixture of python in windows, Turbo Pascal, and Turbo Assembler. I do most of the coding in Windows via DOSBox and then send to a real x86 system for testing. For performance/timing-sensitive projects, I use TP and TA directly on the target hardware.
 
My targets are usually 8088 class machines - good old 16 bit DOS compatibles. I target the smaller machines figuring that if my code runs well there, it runs basically anywhere.

I use two different environments:

Turbo C++ for DOS 3.0 running on a 80386-40 machine. It gives me C, C++, and inline assembly which was enough to do all of my early mTCP work. The compiler can create 16 or 32 bit code. The level of C++ was quite primitive though; I generally use it as "C with classes" as it's basically a 1993 compiler.

My preferred environment is Open Watcom 1.9 running on Windows, which gives me C, C++, and a good assembler. It cross compiles for DOS. For even more productivity I Cygwin to get a more Unix-like environment. The compiler has some decent optimizations; it makes Turbo C++ look primitive. But the run-time can be quite bloated. I test using DOSBox, VirtualBox, VMWare, and then I move the binaries onto real hardware for testing. This environment is much faster than on the original hardware, and I'm not limited to any one IDE's toolset.

Sometimes I'll develop in gcc/g++ and then port to Watcom.


Mike
 
At one time, DJGPP (DJ Delorie's version of 32-bit C++ for x86) was a hot tool. Anyone still use it?

It gets mentioned a lot of the FreeDOS lists and FreeDOS users generally gravitate to it because it frees them from segment handling. But it also excludes 8088 and 80286 class systems, so I'm not a fan.
 
edit code on linux and use openwatcom with dosbox for compilation, then once large features implemented, test on my real dos box. bulk of testing done on dosbox on linux. Makes it easy to target 16bit 8086 or pmode 586 stuff. Ill often test with my watcom 10.6 too, sometimes its better than openwatcom2... even tho its the same codebase.

when I mess with c64, I edit code on linux, cross compile with cc65 and use vice for most stuff then move it to my c128dcr..

for amiga stuff I crosscompile with vbcc, test with fsuae then move to real hardware...
 
At one time, DJGPP (DJ Delorie's version of 32-bit C++ for x86) was a hot tool. Anyone still use it?

I've used it before, It seemed to be pretty good. I bet it's at least a little better optimizer than Watcom but the major downfalls for me were no 16bit support and the fact that being based on GCC it uses AT&T syntax for asm which I can't stand, Watcom is also more convenient in that it can cross compile from modern windows.

Anyone else use OpenWatcom V2? The C++ library is improved and there are a few other nice enhancements. It's also nice that you can actually get in touch with the devs who I've found to be super helpful.
 
Last edited:
I find that I can do both 16 and 32-bit non-windows development using DOSEMU under linux. I include a call to Japheth's HXDOS in my autoexec.bat file. Since I'm basically a CLI guy anyway, it's perfect--and I have access to all of the linux facilities without having to leave the DOS environment.
 
Turbo Pascal would be my language of choice, because that's what I used back in the 80s and 90s.

For developing on the actual hardware (in my case, Sergey's Xi 8088 design), I use a KVM-over-IP.
 
My current project is a mixture of python in windows, Turbo Pascal, and Turbo Assembler. I do most of the coding in Windows via DOSBox and then send to a real x86 system for testing. For performance/timing-sensitive projects, I use TP and TA directly on the target hardware.

What's the Python part of your workflow for? A while ago I did some looking into using Python for DOS stuff (actually got it set up on one of my machines - PythonD 2.4 via DJGPP - it was a bit convoluted to get going) but figured without a general purpose compiler it wasn't very useful for what I wanted to do. I assume you're not using Python code directly in your DOS/IBM PC projects?
 
I seem to find myself writing code to target 8088 machines a lot lately. Mostly I write in assembly language (using TSEPro as my editor) and build my programs on a modern Windows machine using yasm or nasm (each has bugs so I occasionally have to try the other if I hit such a bug). Increasingly I'm generating code with my own tools written in modern C++ (which are very special-purpose at the moment but I hope will become more generally useful in the future - one of my plans is to write my own assembler/compiler). These modern tools usually run on Windows and are written using Visual Studio.

When my code gets so complex that writing it in assembly makes my brain hurt, I have gcc-ia16 to fall back on but I haven't written much using that yet (and yes I agree that AT&T assembly syntax sucks but it'd be a lot of work to switch). I've written my own emulator for testing gcc-ia16 which is much faster than testing on the actual machine, and which can automatically gather certain performance metrics.

For running my programs I transfer them over to my XT by using my XT Server (actually usually a local program that bypasses the webserver part of it but still copies code to the machine over the keyboard port and skips the memory test). This is completely programmatic so I don't need to interact with the XT at all - handy when I want to run hundreds of thousands of testcases.

For debugging I often turn to the DOSBox debugger, but it's not a great fit with the rest of my workflow. I'm working on a cycle-exact emulator which will be a much better solution. In the meantime for cycle counting I have the ISA Bus Sniffer (essentially a special-purpose logic analyser).
 
I've used it before, It seemed to be pretty good. I bet it's at least a little better optimizer than Watcom but the major downfalls for me were no 16bit support and the fact that being based on GCC it uses AT&T syntax for asm which I can't stand, Watcom is also more convenient in that it can cross compile from modern windows.

From what I recall, DJGPP was mainly popular because it was the first widely available 32-bit DOS extender environment.
OpenWatcom then took over, because its 32-bit compiler had much better optimization.

Anyone else use OpenWatcom V2? The C++ library is improved and there are a few other nice enhancements. It's also nice that you can actually get in touch with the devs who I've found to be super helpful.

I haven't actually used it yet (last time I looked there was no official release yet, so I stuck to 1.9, the last 'official' release). However, I found a very nasty bug in OpenWatcom 1.9... That is, when you use any code with floating point types (even when compiling for FPU emulation), it will pull in a part of the runtime library that detects an FPU.
I found that this code locks up on any 8088 system without an FPU installed. This is because the code executed an FWAIT during the execution, and the 8088 implements that differently from any later CPU. The 8088 actually waits for the FPU to signal that it's done. So when there is no FPU, the signal can never be generated on the bus, and you've just locked up the system (and of course no emulator mimics this behaviour, so you don't see it unless you test on real hardware).

I've modified the sources of the library for 1.9 and rebuilt them, to fix this problem (get them here: https://www.dropbox.com/s/u4ljysjnv52ks3m/Watcomclibc8088.zip?dl=0, and here is the modified source file that I built with: https://www.dropbox.com/s/uc7048n3thgzrq7/ini87086.asm?dl=0). I also reported it to the V2 team, since they had the same problem. They picked it up quickly and added the fix to the codebase.
 
Last edited:
You'll be happy to know it runs perfectly on the PCjr (and can even be configured to use 40x25 if the PCjr is hooked up to a TV). However, since it was meant for systems with hard drives, it is only practical to use on a system with a jrIDE installed.

Keeping this reply back on-topic: I did not code directly on the PCjr for that specific project, but I did use mTCP to copy code over to the PCjr to test. I have coded a few things directly on the PCjr however -- same tools (Turbo Pascal/Assembler), but I caved and used a normal keyboard with an adapter, rather than use the PCjr native keyboard.
 
Back
Top