• Please review our updated Terms and Rules here

What are you guys using for retroprogramming?

All I've been doing lately is short 8086 assembly programs, so it's FASM in DOSBox for me. A single command gets me an executable plus a nicely-formatted listing file, for use alongside the internal DOSBox debugger if needed, and at the moment this meets my requirements.

However, I'll probably need something more "serious" soon so this thread is useful for me as well. :)
 
I use a mix of Turbo Pascal 7 in DOSBox along with Native NASM. Being about to use the native NASM to compile for the 8086 target it great, I kind of wish there was a Pascal compiler that was worth a damn that could be run native for that target but it's just not to be. (sorry FPC)

For editing I use Flo's notepad 2, a Scintilla based editor that I use for EVERY programming language I deal with... BECAUSE it has zero integration to the compilers, none of that tab based nonsense, and I can turn off the annoying illegible acid trip of colour syntax highlighting.

But then most "features" of IDE's and editors just piss be off for being steps BACKWARDS in usability and functionality. From the illegible useless BS of ever-changing rainbow colours, to shoving everything into one window when I'm running multiple displays, to "autocompletion" rubbish I end up wasting more time correcting than it "saves" me from just typing my damned code in the first place -- SO much of what's popular in programmers editors just pisses me off.
 
I don't speak of it much but currently I'm using an old version of Adventure Game Studio on my 486 to make 486 oriented graphcial adventure games and a Five Nights at Freddy's clone/fangame of sorts. Im a bit of a hack as I'm using gaming engines...but....

COMPUTER - my 486 system (486 DX4-100 SV8 w/ Writeback, 512K L2 Cache, 64MB of RAM, 20GB/15GB HDD, Win95/WFWG 3.11/DOS 6.22)

- Adventure Game Studio 2.3.1 (for DOS)
- Graf-X II (for DOS) for the pixel art
- Cakewalk 5 (for Sound Effects/Digital Audio/MIDI)
- Ahead NERO (to burn/archive to CD)

The 486 allows me to run the game on DOS and Windows 95, and host for up-port using my Core 2 Duo (so it'll run on Windows 10 as well). I've always been a fan of how Vblank software has been trying to port Retro City Rampage to darn near anything with a CPU on it.

I'm aso making a remake of my high school Text Adventure on my Tandy 1000 using "Create Interactive Adventures" (really old Text Adventure toolkit), and I also picked up Game Maker for DOS and a early 3-D gengine for the 286 and 486 to play around with. I'm also messing in AGI Studio for DOS a bit. Now weather I'll ever actually finish anything soon is anyone's guess. But I'm trying.
 
I kind of wish there was a Pascal compiler that was worth a damn that could be run native for that target but it's just not to be. (sorry FPC)

Were you aware of FPC's recent 8086 support? They even support a Huge memory model with customizable pointer renormalization, although of course the pointer manipulation required for Huge means execution speed takes a small hit. There's also a Tiny memory model that lets you create .COM files. As for the code generation quality, I haven't checked, but I would not expect it to be worse than TP (TP was optimized for compilation speed, not execution speed).
 
commodore 64/128:
- cc65: although it comes with a nice C compiler, I only use its assembler (very nice assembler)
- test using vice ~90%
- test using real hardware ~10% (ssd + ultimate 1541)

tandy/pcjr:
- nasm
- test using dosbox-x ~50%... good for basic stuff, nice debugger. but not very accurate
- test in real machine ~50%, using the worst possible workflow (?). involves 3 machines: host, target, and intermediate machine which has a 5 1/2" floppy (scp + mcopy)
 
The most irritating feature among the modern IDEs that I have used is brace/quote/comment auto-closure. The next irritating thing has to be the shortcut Ctrl-Up and Ctrl-Down to swap adjacent lines. it doesn't save any time but simply annoys me and causes hard-to-find bugs as lines are accidentally swapped when I type my codes, and } (for code block) or " (for string quotes) appear immediately as I begin to declare a block of code or a new string, where I totally don't want them to show up.

Maybe over time the geniuses who develop those IDEs run out of things to add, and that's why they start to introduce annoying and useless features ...
 
Last edited:
Currently doing development with C and assembly using Watcom C/C++ 10.0 and Borland Turbo Assembler 4. I work on my 486 DX2-66, using the Aurora Text Editor to write code (which I spent endless hours customizing to my liking and made a custom plugin to integrate with WMake).

Toyed around with Turbo Pascal 7 recently and had quite a bit of fun, might do a project with it in the future. That or QuickBASIC, which is what I started programming with as a kid.
 
Were you aware of FPC's recent 8086 support? They even support a Huge memory model with customizable pointer renormalization, although of course the pointer manipulation required for Huge means execution speed takes a small hit. There's also a Tiny memory model that lets you create .COM files. As for the code generation quality, I haven't checked, but I would not expect it to be worse than TP (TP was optimized for compilation speed, not execution speed).

Was UTTERLY useless for my purposes since it's more of a hack than a legitimate target for it. To 'fix' it for what I'd want/need it for would have been more work than saying "screw it" and just using TP7 or going to pure NASM.

The minimum library 'out of box' for their 'tiny' target being 32k being the biggest obstacle. 33k for a "hello world" .COM file is epic /FAIL/ at targeting 8088/8086 with Pascal.... like... Microsoft style.

I tried spending some time hacking together a smaller build, but walked away from it as it just wasn't worth the effort to gut out all the damned "polyfills' to try and make DOS behave like it has Posix system calls available... which is basically how FPC on non *nix builds seems to be put together.

Of course had a thread over on FPC's forums about that a few year ago where the responses ranged from "why would you ever need that" to "hundreds of people have already done it"... leaving me asking "so where are they and could one of them explain it?"
 
The most irritating feature among the modern IDEs
On the whole this is why I hate IDE's, RAD's and their ilk, preferring to type my code into a flat text editor and then using the command line for builds. Admittedly my 'mental block' that makes me completely unable to learn 'visual programming' likely contributes to this.

That way all the useless annoying crap like auto-complete, illegible acid trip of colour syntax highlighting, shoving everything into one tabbed window, and so forth either doesn't exist, or can be turned off.

Hell, colour syntax highlighting pissed me off the first time I encountered it with Turbo Pascal 4. It has NOT seen improvements since then. Never understand how people can use that since the rainbow-stripe of text ends up utterly illegible thanks to the constantly shifting colours!

But then maintaining legible colour contrasts by calculating for Y is part of my day job.
 
I also avoid IDEs if I can. You have to learn a particular IDE, even if you know the programming language. Some of them are real monstrosities--Eclipse is one such.

I do use an editor that colors various elements so I can easily pick out leaving off a bracket or quote.

But it's all CLI for me.
 
While I personally can't stand Eclipse, I do find IDEs (particularly visual studio) very useful, especially for large code bases. Being able to peek at or jump to the definition of any symbol in your code base is one such feature that makes it worth it to me.

But yeah I don't think I've ever saved any time from brace auto completion.
 
I only do 16-bit x86 assembly programming using Notepad++ for editing code and NASM as the assembler. I don't do much testing on real hardware as I simply don't have it (nor the space for it) but I do simple testing and debugging using the debugger in Bochs and also good old DOS DEBUG.

The next irritating thing has to be the shortcut Ctrl-Up and Ctrl-Down to swap adjacent lines. it doesn't save any time but simply annoys me and causes hard-to-find bugs as lines are accidentally swapped when I type my codes

I find that feature useful but in Notepad++ you have to press ctrl+shift+up/down so it's not so easy to do by accident. It's convenient when reordering instructions or entire procedures as it saves you from having to cut and paste code but I can imagine it being less useful when programming in a HLL.

That way all the useless annoying crap like auto-complete, illegible acid trip of colour syntax highlighting, shoving everything into one tabbed window, and so forth either doesn't exist, or can be turned off.

Hell, colour syntax highlighting pissed me off the first time I encountered it with Turbo Pascal 4. It has NOT seen improvements since then. Never understand how people can use that since the rainbow-stripe of text ends up utterly illegible thanks to the constantly shifting colours!

But then maintaining legible colour contrasts by calculating for Y is part of my day job.

In Notepad++ you can customize pretty much everything, including the fonts used as well as what colours to use for syntax highlighting. So it doesn't have to be an acid trip. Here's what my colour scheme looks like;

EDIT: Why do I even bother... the image conversion on this forum is so retarded it's not even funny. Anyway, this is the XML-file in case anyone wants to try it (just rename it to .xml and drop it in the themes folder, then load it in Notepad++ with Settings | Style Configurator...);

View attachment Krille.txt
 
I also avoid IDEs if I can. You have to learn a particular IDE, even if you know the programming language. Some of them are real monstrosities--Eclipse is one such.

I do use an editor that colors various elements so I can easily pick out leaving off a bracket or quote.

But it's all CLI for me.

A modern IDE with auto-completion is a must for me, since there are too many methods and properties to remember when doing modern stuff such as .NET. Sometimes the method name can also be too long to type manually. Unless of course I am doing assembly language where there are only a handful of important keywords, making the use of an IDE unnecessary.

As for syntax highlighting, I was impressed the first time I saw it in Turbo Pascal 7. Colorful strings and comments. To me, this is very useful since you can use it to visually detect an unclosed quote or comment block.

The best IDE to me is still Visual Studio, even with irritating brace auto-completion. Next is IntelliJ IDEA which I use for Android programming. XCode has to be the worst IDE I think - it simply crashes very often, especially with large projects.
 
Last edited:
I still use Forth for almost all the stuff I do. When I was on a machine that could still do real DOS, I used FPC Forth to write and debug my code. If I needed a standalone code, I'd make the minor modification to the I/O to make it compatible with Tom Zimmers TCOM. That generated *.COM files that no longer needed the bulky FPC. I used to write a number of utilities using TCOM. I had things like HEXBIN and BINHEX. I'd even written a Forth for the 80186. I used it on a board that was designed to keep track of trucks with a GPS. It had several RS232 ports. I'm not sure why it had so many RS232 ports but it was a poor design for a vehicle as the electrical systems are noisy in a truck and particularly not good with RS232. Starter motors can cause 50 to 60 volt ground spikes. Its RS232 MAXIM chips took it tough. When I got it, 3 of the 5 were blown. Another fellow took a modem that used a 80186 and put my Forth on it. He reported back that it worked. He planned on using the modem as a controller for some robotic use.
Now I don't write standalone applications for the PC end. Nothing I do needs it. It only takes a second to compile something like an 8080 assembler written in Forth, with the fast machines we have today. If I need some special macro or such, I have the source code right there to modify. I'm doing things for the project using WIN32Forth. I've used it to write code for my 4004 setup. I wanted a way to duplicate 1702A EPROMs. The SIM4-01 setup can read and write 1702As but the process is slow because the serial is at 110 baud, using BPNF format. 5 of the 7 minutes to program is just running the serial. I wrote code that can do it in 2 minutes, if you are just duplicating, rather than dealing with file data. When programming from files, I convert from Intel HEX or binary to BPNF format on the fly.
I'm currently bringing up a 6502 machine. It is a Rockewell ICE box but missing pieces. Being Rockwell, the ROMs have Forth in them. The trick is to modify the boot to go to the forth interpret rather than the code that runs the ICE board.
I've been playing with a Gotek. I use the Win32Forth to flash the STM32F105 chip of the Gotek. I don't need any special tools from ST Micro. The Forth I have is my EDI. I'd like to make the Gotek do a 32 hard sector 8 inch disk. I've gotten a EFORTH running on it so that I don't need to program in ARM assembly so much or in C that I really don't enjoy. I have done some C code for an Arduino. I made a pendulum clock timer and a simple pong game for a OLED display. I'd started to make the code for a Planimeter. I plan on using a old PC roller ball mouse for measuring. The optical mice are not accurate enough but it looks like the roller ball will be. I've got the reading of the mouse done, all I need to do now is make the mechanical arms for holding the mouse. ( if you don't know what a planimeter is you might have fun looking it up ).
I have a Forth running on CP/M on my IMSAI to Forth on a 72MHz STM32F105.
It runs on my laptop, I use it for special terminal use, like a flash loader for the STM32 part or an assembler for my 6502 stuff. In the case of the Rockwell system, it is an assembler, disassembler, Forth decompiler, a terminal program and debug tool, all in one.
I recently used it to write code for my 6502 KIM-1 debug kit. I wrote things like a RAM test that depends on the 6502 internal registers only, also to the code to program the flash on the 6532 to 6530 adapter I designed. I did these in assembly but Forth was my EDI.
I've used the Arduino EDI. It is slow and remotes one from the applications, making development slow and debugging hard. Its only advantage are the libraries ( although, bloated and buggy ). If I didn't already know what the hardware was suppose to do, I doubt I would make much progress using their tools.
Dwight
 
Last edited:
The best IDE to me is still Visual Studio, even with irritating brace auto-completion. Next is IntelliJ IDEA which I use for Android programming. XCode has to be the worst IDE I think - it simply crashes very often, especially with large projects.

You miss my point. VS might be good, but I program primarily C (I'm a low-level systems guy) and that doesn't help you with other ISAs, such as ARM, which is slowly taking over the world. Given the variation in IDEs for various platforms, I'm perfectly content with a simple editor. Beats a keypunch all to hell...

FWIW, I use joe as my editor.
 
I dunno about you but I use VS for ARM code all the time.

The IDE has been slowly moving away from being compiler specific in more recent versions, I use VS with Watcom, Clang and MSVC compilers.
 
Ah, that's Visual Studio Code, not Microsoft Visual Studio for Windows. My misapprehension.

If it's so popular, why the push for Eclipse for ARM development? I hate the bloody thing.
 
I was talking about VS for windows, it may not fit into your workflow (doesn't run on linux) but many people do find it useful. I write all my ARM code using VS on windows with LLVM/Clang cross compiler integration. It's not as popular as eclipse for ARM, but I have no idea why.

I still use Forth for almost all the stuff I do.

Interesting, I've never had much experience with Forth but I looked into it after reading your post and I'm quite intrigued. I may start messing around with it a bit.
 
Last edited:
Back
Top