• Please review our updated Terms and Rules here

What are you guys using for retroprogramming?

8-bit retro-programming

8-bit retro-programming

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?

I've been playing with some compilers that run in the CP/M (2.2) environment. Since I've finally got a stable, fast (16 MHz) homebrew Z80 SBC, with some usable tools (editors, file transport to/from the SBC, etc.), sixteen "disk" drives (on compact flash) and the time (what else is there to do on these cold, rainy, dark winter days?).
Perhaps some of you folks might find this interesting??

A piece of code that computes a Mandelbrot set and displays it using ASCII characters has been making the rounds as sort of a benchmark for small systems. It involves a fair measure of floating point calculation, so it is somewhat compute intensive, but not so much so that it takes hours to run. Typical output looks something like this:

[sorry, couldn't get the fixed width font to work properly.]

I decided to re-code the original program (written in BASIC) to test out some of the classic compilers/interpreters that were popular in the old Z80 CP/M community. I've written some BASIC and C, but it has been many years since I've written FORTRAN or PL/I. Never wrote Pascal before now (IMO Pascal is "begin ... end;" hell!). So, there may be some bad coding going on here. In particular, I had a difficult time trying to figure out how to get F80 to write out a single character with no CR/LF, so I buffered a line of the output (above), and coughed it out as a single ASCII string.

Many of the compilers/interpreters were a challenge in themselves. There are often multiple versions available. Sometimes I was unable to get some of them to work at all (corrupt old files taken from my collection of old 8" and 5.25" diskettes??). Many lack good documentation, so it was hard for me to figure out how to run some of them. The table below gives the results for the ones that I was able to get working with my re-write of the program. There may be optimizers for some of these compilers (or optimization options), but I made no attempt to do any of that. Again, the documentation that I was able to find was often not very good, so figuring out optimization might have been difficult to do.

compiler/ time code
interpreter version (secs) size
------------ ------- ------ -----

Hitech C v. 3.09 20 7,808

MS F80 v. 2.7 26 12,672

MS F80 v. 3.44 27 12,928

DRI PL/I-80 v. 1.0 29 8,832

Borland TP v. 3.0 39 8,704

DRI MT+ Pascal v. 5.6.1 32 25,728

MS BASCOM v. 5.2 29 9,472

Nevada FORTRAN v. 3.0 70 725 *

MS MBASIC v. 5.21 71 n/a

BASIC-E v. 2.1 68 n/a **

_________________________________________

* Nevada FORTRAN produces a .OBJ file which is run by using their FRUN.COM program. It may well be that the .OBJ file is a tokenized version of the FORTRAN
code? It is not a stand alone .COM file, so difficult to compare with the other compiler generated executables.

** 2 step process: tokenizes the BASIC source, and then executes the tokenized file in interpretive fashion. Time given is for execution phase only.
_________________________________________

Clearly, Hitech C is the overall winner for both code size and speed. [As a frame of reference, my homebrew 18.4 MHz 68000 runs a cross-compiled C version (output from GCC) in about 13 secs.] However, the other compiled versions (FORTRAN, PL/I, BASIC, and Pascal) seem to be clustered right around 30 secs., with not a whole lot of execution speed variation. They perform similarly, and relatively well! I did not expect that. I found it surprising that Turbo Pascal had the slowest execution time of all the compiled code, although it produced a fairly compact .COM file. There is, however, lots of variation in code size amongst the other compiled code. The one outlier is Nevada FORTRAN. I have no idea how it works, internally, so it is difficult to categorize. It may be a hybrid between compiler and interpreter, and that may account for the execution time that is more like that of the interpreters. And finally, it probably ought to be no big surprise that the execution speeds for the BASIC interpreters (last 2
lines in the table) are quite a bit slower.

I'd like to see how FORTH would compare with the above times, and I know that there are at least Algol and Modula2 compilers available for CP/M 2.2. BUT, it would probably take me longer than the current lock-downs will persist, to figure out how to code this application in those languages.

P.S. -- Couldn't resist! I've been playing with a new (very tiny) microcontroller from Adafruit, called the QTPy. It is a 32-bit ATSAMD21E18 Cortex M0+ CPU running at 48 MHz, and only about the size of a postage stamp. The native firmware is CircuitPython, so I coded this application in Python. It runs in about 9 seconds on the QTPy. I wasn't able to find a CHR$ work alike in Python, so I had to do a character lookup from an ASCII string in order to print out the ASCII display.
 
If you want to use ASCII art (like your tables, or the output), you can put the content into [ CODE ] and [ /CODE ] tags (without the spaces). That should give you a fixed-width font from the forum software.

Apart from that, thanks for the comparison!
 
I use Codeblocks IDE on my Windows box with OpenWatcom to build real mode dos games supporting Tandy graphics. I use dosbox to test and then test on a Tandy 1000 HX and TL every once in a while.

OpenWatcom was able to compile my cpp Sprite code into assembly better than I could by hand. It has some extremely fast optimizations like registers for function arguments. That would be very tedious to hand code.
 
I'm new to programming in general and I'm having fun programming for real mode DOS. I have Microsoft Visual C++ 1.52, Symantec Visual C++ 7.52, Borland C++ 5.02, and Digital Mars C++ 8.57. I'm trying to find which one works best for my needs as I write a set of utilities which seems daunting given that I'm new. This should cover everything from DOS 3.3 to Windows 9x and perhaps later.

I started out programming on a Pentium 60MHz under Windows 3.11 but got sick of the resource exhaustion after a few compiles, so I decided that NT would be a better platform. Now I'm programming on a Pentium 66MHz upgraded to a Pentium 133MHz OverDrive with 128MB of RAM running Windows NT 3.51. Solid as heck. I perform my testing on my various retro machines including a PS/2 50Z, PS/2 55SX, AMD DX/4 100, Cyrix 5x86 100, a 486-to-Pentium Overdrive 83MHz and the aforementioned Pentium 60MHz.

Once I complete my DOS utilities, I want to write some for Windows 9x/2K/XP and for that I have a copy of Microsoft Visual Studio 2005, however the system I program on had a motherboard malfunction and it needs to be replaced.

I would love to do some assembly programming but I just want to focus on C/C++ until I get the hang of it.
 
Welcome to the forum, @OzzFan !

Vintage programming is something that I have been meaning to do more of. I spent a lot of time, many years ago, coding graphics applications for MS-DOS.

- Alex
 
I write MS-DOS games in assembly:
The coding part is done on a modern PC using Emacs. I use DOSBox to assemble and test my code.
 
BASIC-PLUS on RSTS, or BASIC-11 on RT-11.

Eventually BASIC-PLUS-2 on TOPS-20. Once I find a prebuilt TOPS-20 disk image.

All on simulated hardware running on simh.

I'd like to do some rudimentary data acquisition (like reading temperature sensors and binary inputs) but haven't had the time.
 
Most times I do DOS development on a 32-bit Windows XP virtual machine inside VirtualBox running on Linux Mint 20.x MATE. ;)
Compiler are: DJGPP, OW, NASM or other assembler dialects, Turbo Pascal.
Editors: Notepad 2e, FED, TP IDE.
Testing is done in Windows XP NTVDM itself, VirtualBox/Bochs/ibm-pce/PCem/Fake 86 VM running whatever DOS is needed, and sometimes on a real DOS machine, e.g., Highscreen Handy Organizer palmtop.
 
I use Sublime Text 3 for code editing since it's quick, has good syntax highlighting and I use it already for other "modern" projects.

DOSBox for building if I'm using a 16-bit complier/assembler (MASM 5 for example) since it can share a hot drive mounting point with the host computer. Just hit Save in text editor, switch over to DOSBox window and build, and the output is there for both environments to use.

I also use PCE/ibmpc for testing since it aims to be a hardware level emulator of a PC, and uses bare-metal ROMs for BIOS, video, HD, etc. Most importantly it has an excellent machine-level debugger and ability to inspect the state of the ISA, such as PIT, PPI, DMA, video, etc. It's 8088/XT only so if that's not your target it won't help you out there.
 
Hi,

I haven't seen anyone mention the Apple II or IIgs. That's what I have most recently targeted using cc65 for the Apple II and the period correct Orca/M for the Apple II and IIgs (Although the IIgs is 16-bit - 65816). Like almost everyone else, I also use a modern PC (VS Code, gnu make) and mostly emulators for dev. Orca runs on a modern machine in a special emulator called GoldenGate which lets you invoke the 65xx native command line tools from the modern command line.

I have also used cc65 to target other 8-bit machines such as the Atari 800 and Oric Atmos. cc65 will even target the Commander X16 which is a machine that the 8Bit guy and friends were making but it seems that projects has gone adrift. I made some games for it though, obviously only for the emulator :)

Stefan
 
If you want a real "Beginner" case where there's some actual coding going on....

I dabble a bit in the very old Adventure Game Studio 2.3.1 for DOS, doing development mostly on my 486 DX4-100 desktop "Creeping Net 486". Though I also use my plethora of other 386/486 machines to run and test and do development. All of the actual coding though, is done using a 32-bit DPMI apparently opening up the script files in DOS Edit. It uses a C type context (which I'm trying to learn on my DFI MediaBook laptop which has Borland on it). I'm totally fine with this, it's an environment I'm very familiar with.

Graphics are done in Graf-X II for DOS, one of the old beta versions that lacks gradients and fonts, so I'm having to "Mark Ferrari" it - doing dithering and gradients manually. Though after hearing about how Monkey Island was done in Deluxe Paint and has Color Cycling capabilities.....maybe I should look into using that for the graphics part.

Sound is done using Voyetra Sequencer Pro, or Cakewalk Pro Audio on the 486 Desktop.

Testing is done on any one of my "Creeping Network". So far I've gotten AGS games to run on a 486 DX-33 at a decent speed, which is surprising since the min-req say DX4.
 
Back
Top