• Please review our updated Terms and Rules here

Why do you do this? (retro-coding)

carlos12

Experienced Member
Joined
May 10, 2020
Messages
183
Location
Madrid, Spain
Why do we program for systems that most people consider "obsolete"? I would love to know your opinions and feelings about this.

For me, a few reasons would be:

- Because it's fun
- It's rewarding (and frustrating some times...)
- If you use that computer on the present moment and it's useful for a given task, it's not obsolete at all
- Although great programs and games were made on it's time (for example, circa '81 to '92 for the IBM PC/XT), we always can make new products, enjoy them and share them.
- Because it keeps us young ;)
- Because for many of us is not retrocoding anymore as we were already doing it 30-40 or whatever the years before (although, of course, new coders are always welcome!)

In my case I'm right now programming the game I wished to program or play for the PC and clones when I was a teenager. Unfortunately, back then I didn't have the knowledge and documentation needed to do it. It's a long path as it is a huge task for a one person team (thankfully I'm using a lot of code written by many people, so I don't have to reinvent the wheel for many tasks, thank you all, and we can also help each other on this forum so we are not that alone...).

It's also difficult to find time and energy while having a day work but, as I say before, it's also very rewarding also. For me, it's one of the best hobbies that exist.
 
There's another aspect of retro coding.

If you're using original tools on original systems, you're now back in a time when 80x25 (or even less) is your window to the world. Where "cut and paste" are awkward at best.

My short term memory is...lacking nowadays. I can barely remember a phone number to type it in to my phone in one go. You need to keep a lot more context in your head using old school tools.

Consider the venerable Turbo Pascal. You start working on a program of any size, and it becomes very important to remember the function and procedure call arguments. A large program is not easily navigated in TP, and you no longer have things like auto-complete to fill those gaps. When you're used to an editor window with 100 lines of 100 column text that you can fly through with a flick of a scroll wheel compared to 80x25, that 20% of the screen space.

It's a different world.

It gets better if you're using vintage hardware and vintage speed. Watching the compiler tick-tick-tick away. 10s to compile 120 lines of code. Plus, with CP/M, the clunky, unfamiliar command line, no tab complete, no history!

Even realod TP is awkward.

A> TURBO
Y (load error messages)
W (working file)
PROG.PAS
E (to edit it)

Far cry from just "vi prog.pas".

A lot of folks don't do this. They use modern tools, GHz processors, 30" displays to write their code for their 2MHz systems.

Not the same thing, frankly.

Currently I'm working with Turbo, using z80Pack with the simulator running at 4MHz. What's missing is that the I/O is too fast vs a floppy system. Be interesting to get that more to vintage speeds as well. ("Floppy handling" using z80pack is...frustrating. Not at all like having physical media in hand and shoving it in to drives.)
 
I am still supporting computer hardware and software that was designed, installed and commissioned in the 1980s. It will probably be supported in some way, shape or form for another 10 years too! Rock on Coral-66...

Dave
 
My main reason: because you can tinker with it down to the CPU itself. If an IC breaks down in a XT (clone), I can replace it. If an IC in a modern PC, I'm quite sure I cannot do anything but replace the motherboard.
Tinkering with an 8088 or 80286 is done. I never heard of anybody creating a BIOS for a Pentium or better system.

An exception that comes to my mind is Linux. But that started in the 386 era and grew along when the CPUs got better and bigger. But how many people are helping to develop it? Hundreds? Thousands? Or even more? I am working on my own OS from scratch that should run on an 8088 equipped computer. o it should run at least on a IBM PC or compatible and a Commodore CBM-II with 8088 card. A lot of work but also a lot of fun (otherwise I wouldn't do it). When should it be finished? I have no idea but I I hope before I die :)
 
It is a challenge ...

Last week I was able to serve NTP timestamps from an SNTP server running on a PCjr. The timestamps were within 2 milliseconds of what the publicly available large NTP server pools were serving. The project involved a little soldering to connect a GPS, a bit of interrupt handling code to detect when the GPS was signaling the start of each second, and some seriously tight code because a 4.77Mhz machine from 1983 was not designed for such a task.

And it came with some great bragging rights too. I have the worlds first and only stratum 1 PCjr time server. :)

http://www.brutman.com/DOS_Time_Server/DOS_Time_Server.html
 
I am still supporting computer hardware and software that was designed, installed and commissioned in the 1980s. It will probably be supported in some way, shape or form for another 10 years too! Rock on Coral-66...

Dave

did any CORAL stuff get saved at TMOC? I know we talked to someone there who was into it ten years ago.
 
I agree with the challenge. There are only so many resources to go around and thus it becomes somewhat a puzzle. Another thing I like to do is write something in C and take it from 8080 to DOS to WIN32.
 
I am still supporting computer hardware and software that was designed, installed and commissioned in the 1980s. It will probably be supported in some way, shape or form for another 10 years too! Rock on Coral-66...

Dave

Unless we really break it !
 
For me I think it's something about minimalism: what can be done with less memory, less processing power and less screen real-estate. It often requires a lot of lateral thinking and can lead to some quite interesting puzzles to solve. I also like having more control over the machine and not having to work with so many layers of abstraction.
 
A lot of folks don't do this. They use modern tools, GHz processors, 30" displays to write their code for their 2MHz systems.

It is true that using modern tools to create code for a vintage machine isn't he same thing. However, it allows us to concentrate on the parts that we find must fun and interesting and limit the parts we don't enjoy so much. That said, I enjoy both: I regularly use the machine language monitor, VICMON, on the VIC-20 as well as use an assembler on Linux to create code for the Vic. Under CP/M I actually enjoy entering and editing code using ED and generally find it a lot easier to stay vintage than on the Vic. But even there in the past some games for the Vic and similar machines would have been developed on more powerful machines and transferred across for testing, so it isn't entirely abandoning the old methods.
 
Where do you rank on the 1337-o-Meter if you're using a modern computer to connect to a public-access Unix system dating back to 1987 and using vim to code for your faux-minicomputer stack-machine project that you plan to implement in TTL at some point? Asking for a friend.
 
Under CP/M I actually enjoy entering and editing code using ED and generally find it a lot easier to stay vintage than on the Vic.

Never did well with CLI based character editors (CP/M ED, edlin, teco). Unix ed (which is a line editor) is more my style. And ED, with it's buffer management, my poor Pooh brain never quite wrapped around it. Maybe if I say a robust editing session on video once talking me off the ledge.

Not sure I'd wish developing anything disk heavy on a 1541 on anybody, nor an Atari 810 disk drive.

I had the OSS C Compiler for the Atari back in the day. Classic, multiphase workflow pre-processor->compiler->assembler->linker. All hitting the floppy hard.

It was awful. Cars would rust before your eyes as you waited for "hello.c" to compile. ACTION! (which was all in RAM) was just night and day in usability.
 
One thing I enjoy about retro programming is that the programming landscape doesn't shift constantly under your feet, which is nice for a leisure pastime. I can start a project and leave it lying around for a couple of years without much hassle. I don't think you'd experience the same thing with a program written for the modern Web, for example, but to be fair I haven't done very much of that.

One of these days I'll get around to writing a program that uses the Apple Lisa ToolKit, for example. It could be a decade from now, but that doesn't matter, nobody's releasing updates so far as I know.
 
One thing I enjoy about retro programming is that the programming landscape doesn't shift constantly under your feet, which is nice for a leisure pastime. I can start a project and leave it lying around for a couple of years without much hassle.

So true. It such a pain going back to projects to make a change just to find the environment has changed. Particularly if you have switched between lots of different programming languages over time and they've continued to become more complex.

I've almost got to the point now where I've toyed with creating a system that is simple, well-documented, easy to re-implement and port so that I can future proof work that is important to me based around a retro system. The main thing that holds me back is what to do with multiple character sets if I'm switching between human languages. I don't fancy implementing UTF-8 but there isn't anything else that really competes with it.
 
I've almost got to the point now where I've toyed with creating a system that is simple, well-documented, easy to re-implement and port so that I can future proof work that is important to me based around a retro system.
Hah, I've toyed with the idea myself...and then my coworker told me about SerenityOS, which seems to have already gone and done it XD Gonna be interesting to watch that one... (Actually, I've been toying with the idea of rolling up a simple time-sharing OS for the homebrew-CPU project I'm gradually scheming out, and making it public-access...but that's a good ways down the line yet ;D)
 
I like coding for DOS & Windows 3.1x because that is my favorite era of computing and I enjoy the challenge of writing programs from this timeframe. I'm also hoping that I'll eventually write something very useful that the entire retro-community appreciates. Lastly, I'm also hoping that, since I'm still learning C/C++, that programming for older systems will give me a greater appreciation for, and understanding of, the C programming language. I'd like to put any knowledge learned to use by switching careers from IT Support to software development.
 
For me I need the constraints, otherwise nothing actually gets done or when it is done you don't like it because you think you could have done so much more with the graphics or sound or whatever. If, working on a modern PC, you want to do a project solo (or a small 2-3 person team) you can set limits but where to actually set them is murky and the temptation to push those limits is always there.
 
I like coding on the machines I originally used and didn't have have the money to afford. Boyle's law applies to computer science.... I like the mental stimulation of working in small places with limited resources and seeing what can happen. I'm going back further to machines that were around and poplular in the 1960's and 1970's. RT-11 and Fortran next on the list :).
 
If you need a job which forefills a sense of completion, then any form of programming regardless of system will untimately offer that, especially if you're in a job which doesn't offer a light at the end.
 
When bringing up CP/M on my IMSAI with an original Digital Systems disk drive, I used a current laptop to write the minimal code to get a serial connection working that I could use to download code into the IMSAI's memory. Once I was able to get a minimal CP/M running. I used the laptop as a serial terminal and down load pre-assembled code. In CP/M I wrote the needed drivers and got my disk system working. I'd have done more on the laptop but it was easier to use the IMSAI then to continue loading code by serial.
Some times one has to use a newer machine. An example was for the 4004 project I did. There really isn't much available for the 4004. Most of the simulators for the 4004 on github have bugs and are not easy to instrument as a actual piece of equipment. I wrote my own simulator, assembler and disassembler for that project. I was able to debug a poor listing and get an actual reproduction instrument to work ( the listing dropped many of the right edges of letters ).
One uses what one needs to complete a project. Working on an old machine is desired but not always the best option to complete a project. I still enjoy the challenges.
Dwight
 
Back
Top