Forum etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.

Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.

Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.

Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.

"PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.

Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.

Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.

New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.

Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Programming environment, ca. 1983

  • Filter
  • Time
  • Show
Clear All
new posts

    Programming environment, ca. 1983

    Recently, the PCJam came into my field of vision, and I thought that approaching this in a "simulationist" way would be an interesting approach and get me away from the option paralysis of my more contemporary programming work and hobbies (way too many programming languages these days...).

    The game jam suggests Open Watcom and other more contemporary tools, but I thought about doing it as if I "were there", using the tools that would've been available for someone back then. As the game jam only targets CGA, I thought that this would mean that I couldn't get my hands on anything more modern. As the EGA came out in late 1984, that would be my "soft" deadline for the availability of compilers/assemblers. Could add 1-3 years, by pretending my time-slipped alter ego just couldn't afford anything more modern.

    I'm probably not switching to actual '83 hardware (DOSBox instead) and art would be done with more modern tools or by simply copying free assets -- let's assume that's done by a more artistic friend back in '83. Probably going to make a simple, Ultima-ish RPG.

    (For reference, my real-timeline start was Borland C++ 3.1, with only a tiny bit of C64 Basic before that. Did some assembly back then, and some Pascal/Oberon in the mean time. Current professional languages are mostly Java, Perl, JavaScript; no problem learning something new)

    So where would this put me?

    Given the resources, assembly would probably play a role. So MASM 1.x? Not sure whether I'd want to do the whole game this way, but it would be an option.

    Turbo Pascal 1.0 came out in '83, so this might be an option. Also legally available for free, so I wouldn't need to hunt ebay for compilers.

    I only heard bad things about early Microsoft C compilers. Turbo C 2 would be out of the time frame, but bearably so.

    I'd be willing to try other languages, too, if the tooling would be worth it.

    If it's an early compiler, I'd probably also need an extra editor. I don't really want to do edlin, so I might need to "time travel" for that or just do it with some semi-appropriate modern editor externally (JOE with its WordStar mode seems okay, or micro-emacs).

    It's not a simple picture.

    Microsoft C wasn't awful--I still use it for 16-bit code on occasion. But the environment for programming in 1983 wasn't too different from that, in say, 1975. Text editor, compiler/assembler. In 83, although I did some C work, on DOS, it was almost all assembly. But that depends on your system and area of specialization. In 1977, while I worked in assembly, the people on the other side of the building worked exclusively in a dialect of BASIC. Mainframe programmers were even more diverse.

    I did have a co-worker who preferred to do most of his "quick an dirty" stuff in PL/M. The pretty much run-anywhere language then was FORTRAN. If you had a machine with a FORTRAN compiler, regardless of operating system or lack thereof, you could run FORTRAN portably. Observe that in the later CP/M-80 days, DRI was really pushing PL/I for its ISV program. The Unix people were pretty much C-exclusive.


      Turbo Pascal 1.0 may not be up to the task. It's a great system, but doesn't have the flexibility of things like the C compilers, notably because you don't have the link step to help assemble your final executable. I don't even think TP 1.0 made EXEs, just COM files.

      However, your development cycle will certainly be exaggerated by not using TP. That all depends on your hardware, however. 1983 was pretty early in the PC era with lots of things being straight up ports from CP/M and all of those limitations.

      You will have an easier time mixing/matching C and ASM than I think TP and ASM.


        This is a most fascinating subject!

        Back in 1983 (depending on what month of 1983) you had a few options to program for the IBM PC and compatibles. In my opinion, and in my observations, almost all the games published commercially between 1981 and somewhere in 1984 (they could had been developed in 1983 but released in '84) were written in assembly language, specifically the Microsoft Macro Assembler 1.0.

        The high level options available back then had no specific video game library options (actually there wasn't any video game specific library for PC until many, many years after), specially regarding sprite animation, so games were mostly programmed directly on assembly, as direct access to memory and the iron was a requirement if the game had a minimum level of complexity. The graphic libraries available at that time (like GWBASIC's or Turbo Pascal's) were quite limited, business oriented and slow. Another very important factor is that we are not yet in 1988, so they are very few computers that have more than 256 kb of memory: no computer is sold at that time with 512 or 640kb of memory, the memory expansions are expensive... and there's little to none software yet able to take advantage of it. So games are planned to run on very tight systems, having 64-128 kb of ram on average for greater compatibility.

        The processor is also the ubiquitous 8088 at 4.77 Mhz. It's still one year to see the born of the AT (286, much faster processor, but it also will be much, much more expensive) or the Compaq Deskpro (8086 instead 8088, which is slightly faster, and 7.16 Mhz of speed). Nevertheless, the reign of the 4.77 Mhz is far to its end yet. High level languages, specially Basic and C, bloat spectacularly the generated code, and the resulting machine code is generally much slower that an intelligently programmed assembly code. So even when most of high level languages are able to interface with the assembler or insert directly machine op codes, I think it was generally an option to avoid at that moment, as a C program could quickly deplete the little RAM available. A few years after, when most systems will have 512-640 kb of memory, things will start slowly to change. But for this moment in 1983, many games use a single .com or .exe executable that includes in just one 64kb segment both code and data, and in the data were included the graphics and beeper noises/melodies.

        I'm thinking, among others, in PC-MAN, Paratroopers, Burger Time (1982) and Digger, Space Invaders (1983).

        So, what options can we have to program a game like it is 1983? The ones that come to my mind are:

        - IBM Personal Editor. An absolute classic, available since 1981. For editing any kind of text file, including assembly, C or whatever.

        - MASM 1.0 (the above mentioned Microsoft Macroassembler). Indispensable for any high performace-low memory consuming game.

        - Turbo Pascal 1.0 (also above mentioned). This was revolutionary at that time as it was one of the first (maybe the first for PC?) integrated programming environments. On the same program you edited the code and also run or compile. For the first time it wasn't needed to have a separate text editor and a command line compiler+linker. This would speed the development process. Also the programming language was a "serious" structured and powerful one: the Pascal, with its pointer/memory management, plus a few PC and DOS specific functions. It has a quite complete graphic library (but nothing to manage sprites animation, scroll and the like). It also had the option to insert machine op codes (no inline assembly or .OBJ interface yet). Until version 4.0, it generates .com files, therefore restricted to 64 kb code+data.

        - GWBASIC/BASICA + BASCOM (IBM Basic Compiler 1.0). GWBASIC could be used as a quick develop environment with instant result testing. The program finally could be saved on text format (save "program.bas",a) for being compiled with the BASCOM. GWBASIC has commands to send/read data to/from the ports and can load/call/execute external compiled/assembled code.It also has many primitives to draw graphics on the CGA. In fact, games such as DONKEY.BAS (one of Bill Gates gifts to humanity ) were made in BASIC. On the Michael Abrash book Graphics for the IBM PC, published in 1984, there are lots of examples of graphic programming of the CGA in BASIC, including a quite good brick breaking game. The worse thing is that the numbered approach and the lack of real structure keywords make this language very prone to make spaghetti code, very difficult to maintain of expand. This is my least favorite approach.

        - Latice C (bought and rebranded soon by Microsoft, who back then still hadn't finished its own C compiler). I have not many information about this. I assume it can generate OBJ files and it can call assembled procedures but I'd had to check it to be sure.

        - Desmet C. The earliest version I was able to find on the Internet is 2.51, from 1985. It's possible that earlier versions existed back in 1983. The 1985 version has inline assembly and can communicate with assembled procedures produced by it's close cousin, the A88 assembler (with a slightly different syntax to MASM).

        So, if you are planning to make an RPG game, and there will not be an extensive use of graphic animations, you could use your favorite language and use the graphic primitives to draw lines or whatever and simple procedures to load and show static images. If you plan to offer a good deal of animations (as it would be on an arcade type game), I think a lot of assembly would be required, either standalone or supporting the high level language you chose.

        Regarding the developing system, you can use DosBox (I certainly use it too) but in order to test the programs on a like '83 environment, you should lower the cycles to something between 260 and 280 to simulate a 4.77 machine. For later machines, ~550-650 could be more or less an 8086-8 Mhz machine. 800-1200 could be an AT. This is all very approximate. I give these numbers as a reference only and in the wish someone could find them useful.

        For something even closer to the real thing, I would use 86Box, configuring a few virtual machines of the time (IBM PC 1982, IBM XT 1982, Compaq Portable).


          UCSD Pascal has sound support for the speaker within the IBMSPECIAL unit. UCSD Pascal also supports graphic modes and color. Just a choice if you want to try writing code with an IDE available before Turbo Pascal.

          Forth would have been around with a number of implementations for the IBM PC in 1983.


            MASM 1.0 was probably one of the buggiest assemblers I used, bar none. The list of errata that followed it was almost 2 pages long. $99 at the time. It was a bit of a letdown after years of using Microsoft M80, which was really a decent product for the x80 CPUs

            Actually, MASM 1.0 was two assemblers: ASM, non-macro and MASM, the macro assembler. I don't think that Microsoft or IBM used it for production work initially. Still, like farming in a minefield, it can be useful, as long as you knew where the mines were buried.

            Lattice C was the official compiler recommended by Microsoft. It was okay, came on two floppies and was more-or-less straight K&R dialect. It's as close to C90 as a lawnmower is to a pickup truck.

            As far as text editors, I'm not aware of anyone who actually put up with EDLIN for very long. There were many better ones. EDLIN was actually less powerful than CP/M ED.


              Originally posted by krebizfan View Post
              UCSD Pascal has sound support for the speaker within the IBMSPECIAL unit. UCSD Pascal also supports graphic modes and color. Just a choice if you want to try writing code with an IDE available before Turbo Pascal.
              Frankly, UCSD is one of the most powerful system available at the time, especially for large programs.

              Specifically, UCSD had very good support for segments and overlays, even in the early versions of the system. Of course, you can always ad hoc your own overlay system in assembly and C, but UCSDs was "free" and automatic, you just had to be conscientious in using it.

              For a stand alone "boot from floppy" system, this could work fine. But not for something that runs from DOS, as UCSD at the time was it's own OS.

              As for Forth, no doubt there were several available, could always port a FIG source.

              But if you want to be pedantic, you won't have access to F83 (a public domain implementation of Forth-83), one of the best from the era, and is really quite nice (it's a huge system), but likely just outside of your time window. If you're willing to bend a little, it's really powerful if you can wrap your head around it.


                Heh, I still have my 8" JRT Pascal floppy.

                In 1983, there were many (expensive) HLLs available with remarkable capabilities. e.g. MicroFocus COBOL.


                  To the OP: Pretty much all games made in the first two years of the IBM PC's life were done in either assembler or BASIC, so that should answer your question. If assembler is too difficult to learn in the short term, I'd suggest you start reading any number of IBM PC BASIC books (there were nearly a hundred).

                  While UCSD Pascal was available for the PC in 1982, the only game I know of that used it was Wizardry which was released for the PC in April 1984.
                  Offering a bounty for:
                  - A working Sanyo MBC-775 or Logabax 1600
                  - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)


                    I think in 1983, quite a number of firms didn't do software development on IBM PC-based systems. For example, Sorcim (Pascal-M, SuperCalc, SuperWriter, SuperProject, etc.) did most of their work on a VAX 11/730 or CompuPro 8086 boxes. I suspect that the BIOS listing in the 5150 techref was made with a cross-compiler.


                      'President's Choice' ('84) was also UCSD Pascal. Possibly a different version of it, because the code it produced is full of "mov cs,ax" instructions (undocumented, and won't work on >8088 CPUs).

                      Some of the Spinnaker games were written in MVP-FORTH (Facemaker, Story Machine; 1982-3?), and those "101" trivia games published by IBM were in a different FORTH dialect. The whole "threaded code" thing sure makes for an interesting experience when you have to use a debugger...

                      Digger (1983) was written in Lattice C, and in fact the sources are available at

                      As for BASIC, it was not at all uncommon to include machine language routines in BASICA/GW-BASIC programs (interpreted or compiled) to get around the limitations of the language. Not that the interface is convenient or fun in any way, but that's what people had to contend with.
                      Last edited by VileR; April 26, 2021, 11:31 PM.
             :: :: :: blog


                        Originally posted by VileR View Post

                        Digger (1983) was written in Lattice C, and in fact the sources are available at
                        Wow! I didn't know it. Thanks for the info Just downloaded and studying it now...

                        For the OP, I'm posting here the brick game by Abrash written for BASIC, if it serves as inspiration.

                        10 REM Blockbuster - finished version.
                        100 DEFINT A-Z:SCREEN 1,0:COLOR 0,1:KEY OFF:CLS
                        110 CIRCLE(3,3),2,3:PAINT STEP(0,0),3
                        120 DIM BALL(10):GET(0,0)-(5,5),BALL
                        130 LINE(0,0)-(319,199),2,BF:LINE(80,20)-(241,185),0,BF
                        140 FOR I=0 TO 7:FOR J=0 TO 3:LINE(82+20*I,48+J*12)-STEP(18,8),((I-KJ) MOD 2)+L,BF:NEXT J:NEXT I
                        150 NBALLS=3:NBRKS=32
                        160 PX=150:PXINC=0
                        170 LOCATE 2,2:PRINT "Balls left ";NBALLS:IF NBALLS=0 THEN LOCATE 15,13:PRINT "YOU LOST!!!!":GOTO 300
                        180 BX=80:BY=100:BXINC=4:BYINC=4:PUT(BX,BY),BALL
                        190 A$=INKEY$:IF A$="c" THEN PXINC=5 ELSE IF A$="z" THEN PXINC=-5 ELSE IF A$="x" THEN PXINC=0
                        200 OLDPX=PX:PX=PX+PXINC:IF PX<80 OR PX>221 THEN PX=OLDPX
                        210 LINE(OLDPX,181)-(OLDPX+20,181),0:LINE(PX,181)-(PX+20,181),3:OLDPX=PX
                        220 OLDBX=BX:BX=BX+BXINC:IF BX<80 OR BX>234 THEN BXINC=-BXINC:BX=BX+2*BXINC
                        230 OLDBY=BY:BY=BY+BYINC:IF BY<24 THEN BYINC=-BYINC: BY=BY+2*BYINC
                        240 IF BY>175 THEN IF BX<PX-5 OR BX>PX+20 THEN 280 ELSE BYINC=-BYINC:BY=BY+2*BYINC:BXINC=(BX-PX) \2-4
                        260 PUT(BX,BY),BALL
                        270 GOTO 190
                        280 NBALLS=NBALLS-1
                        290 PUT(OLDBX,OLDBY),BALL:GOTO 170
                        300 LOCATE 25,9:PRINT "PRESS ANY KEY TO CONTINUE";
                        310 A$=INKEY$:IF A$="" THEN 310 ELSE CLS
                        320 END
                        The book Graphics for the IBM PC can be read/downloaded here

                        I would like to point that while the highest performance graphics (and a few advanced things like masking the sprites in order to preserve the background) I think they would require assembly, some more BASIC graphic things (pun intended ) can be done directly on high level, either using the language graphic primitives or using some custom ones. The following example is taken from François Gervais book Programmation des cartes CGA,EGA,VGA, published in 1988 or maybe '89. It's written originally for Turbo Pascal 3.0 or higher but I just checked that it works also on TP 1.0. It doesn't use assembly or op codes at all:

                        screen_ptr = ^type_screen;
                        type_screen= ARRAY[0..16383] of BYTE;
                        screen: type_screen ABSOLUTE $B800:0;
                        i : BYTE;
                        virtual_screen: screen_ptr;
                        PROCEDURE show_sprite(x,y,number : BYTE);
                        picture = ARRAY[0..7] of BYTE;
                        height : picture = (13,14,11,10,10,08,10,19);
                        width : picture = (20,20,23,25,23,25,26,30);
                        line : BYTE;
                        FOR line:= 0 TO height[number] DO
                        MOVE(picture_ptr^[80*(25*(number DIV 2)+line)+40*(number MOD 2)],
                        MOVE(picture_ptr^[80*(25*(number DIV 2)+linea)+8192+40*(number MOD 2)],
                        (I've translated the variable names into English and the example is not complete, it lacks, for example, the mode 4 initialization code).

                        It doesn't preserve the background nor can put the sprite on any horizontal position of the screen (only multiples of 4) but it can be useful anyway. An assembly equivalent would be faster but the performance is not that bad.
                        Last edited by carlos12; April 27, 2021, 06:25 AM. Reason: F. Gervais, wrote that name wrong


                          Thanks for all the answers. It's funny that Michael Abrash appears here, too, as my own DOS/C/ASM appearance a decade later was quite heavily based on his ModeX stuff and later books...

                          I've also been reading some 'PC Mag' issues from, and that's been both fun and enlightening. Apparently "many users feel that APL is the most advanced general purpose programming language available today". A review of some Pascal compilers included one I actually knew (Pascal/MT+). BASIC is used for handy tips to the readers, peeking and poking to fix and detect issues.

                          But that's also quite exciting. I've got more room to breathe than some 8 bit home computers, but a different enough software and graphics situation to create some good constraints for the design.

                          I do have to make sure that "different" doesn't make it too complicated, finishing the project is more important than fiddling around with optimization. Which also means, that I probably don't need assembly that much. It would be fun delving into that again, but once we get the display and file access stuff out of the way, it'll just slow me down with the business logic. That's the spot where you often shell out to scripting languages in more modern systems, so I wouldn't want to go beneath the level of C/Pascal. Although with some clever macros and a lot of data-driven logic, that might still be an option. Might need to go through a few guides/books/manuals again before I make my final decision.

                          But unless I'm going to bare metal, I'll probably end up with something compiled -- I like some of the more structured BASICs, but it doesn't seem like one of those would be on the menu (or similar languages like Comal). That brings us down to the compiled languages, where I would be most familiar with C -- which on the other hand might be the reason to give something else a try.

                          So that's probably one of:

                          - Pascal (Microsoft Pascal, Pascal MT/+, Turbo Pascal 1/2, UCSD)
                          - C (Desmet, Microsoft, Lattice)
                          - Forth (F83?)
                          - PL/1 or PL/M (some Digital Research stuff seems to legally available)
                          - Modula-2 (always liked it, never got around to do much with it. Logitech and ETH compilers seem available)

                          I guess it depends a bit on the specific environments/compilers. I guess something with EXE/Overlay support would be useful. Right now, I'm researching my Forth options a bit. I always wanted to get into that a bit more than the basic "calculator" attempts I made in the past, Starting Forth is from '81...


                            C can produce bloated code or C can produce tight code depending on the developer/compiler. One thing I've learned writing C for 8-bit microcontrollers is that there is a cost to the way things are done. This reminds me of an experience I had with Pascal and C back in the late 80's early 90's. I was just messing around writing text to the screen directly and made a small sample program that would move a single character across the screen, one character at a time. In Pascal, you would see it do the move though it was decently fast. In C, it went from here to there and you didn't see the move at all because it was just so much faster. I told myself at the time that Pascal has more overhead to check pointers and such and that must be the reason, but it is really just all about how you do it. In both languages you can drop to assembly without much difficulty (using Borland products), so if something needs optimization, you _can_ optimize it. Sometimes it is a matter of studying the output to see what the compiler did vs. what you thought you asked it to do. I've had the same experience in C where I wanted it to do something, and it was slower than what I wanted so I dropped to assembly (which I'm not super skilled at) to get it done faster. Here is an example - I was messing around with how minimally I could make some screen functions, and the screen has both a character and attribute bytes. It was terribly slow and kludgy to use a memset to set them all and then go back and change all the odd values when you have a 16 bit processor that should be able to do it so quickly, so I wrote the following. If you know assembly you probably have some tips for me on how to improve it even!

                            void memsetw(void *dest, unsigned int val, size_t len)
                                asm mov dx, es
                                asm mov ax, val
                                #if defined(__TINY__) || defined(__SMALL__) || defined(__MEDIUM__)
                                  asm mov di, dest
                                  asm push ds
                                  asm pop es
                                  asm les di, dest
                                asm mov cx, len
                                asm rep stosw
                                asm mov es, dx


                              Having programmed in C for a number of years one you learn is that it's best not to move things around but if you can move pointers around. Of course this is the same thing in ASM.

                              Note: I've never liked Pascal or ASM for the 8088/86. The crazy memory layout always bother me. None of that matters when the compiler can hide that.