Late 70s and 80s: forget BASIC, we had Pascal and C
retrofun.pl
retrofun.pl
https://worldofspectrum.net/pub/sinclair/books-pics/p/Pascal...
Pascal on 8 bit was just too damn slow compared to the alternatives to be very useful and compile times were horrendous. Even the university students that had access to Pascal compilers for the most part only used them to turn in their assignments and avoided it for everything else.
I did a little contest with a friend: we both wrote a chess program, he wrote his state of the art with a ton of optimizations in Pascal, I wrote mine in assembler. His program never stood a chance against a very simplistic implementation that only had minimax and a greedy (strictly material based) evaluation routine.
Good times :)
Compiling a simple snake, or tetris game, takes about two seconds. CP/M with turbo pascal is pretty fast.
I started my journey with ZX Spectrum BASIC, then z80 assembly, before jumping to MS-DOS and x86 assembly. Learning C, and other languages, didn't start until my 16-bit days.
(Though I have a memory of receiving a FORTH system for the ZX Spectrum I don't think I did anything useful with it, or fully understood it given that I was about 15 at the time.)
When I was in 8 bit territory the best I could get was 360K floppies and running any kind of serious compiler required multiple floppy swaps to get the passes in. 6809 with 64K RAM was the best 8 bit system that I had, the next best was a BBC Model B with a very much maxed out Solidisk (more than maxed out, we ran more banks than were officially supported).
The board uses an USB-stick for storage, formatted as a FAT filesystem which makes exchanging files between this and another system easy - though of course you can transfer files over the serial port.
The biggest issue is that the board has only 62k of RAM so I'm stuck with CP/M 2.2, rather than 3.0 which requires paging-support. Still I can run infocom games, BASIC, Turbo Pascal, and other retro things.
My code repository contains a link to a youtube channel where the board was discussed, and where I found it randomly. But sadly the upstream site of the provider and the (useful) forums it hosted are gone unless you use the wayback machine:
By the mid 1980s they came out with an operating system called OS-9 which was a multitasking OS inspired by UNIX.
https://en.wikipedia.org/wiki/OS-9
You could get a few languages for that, including a C compiler. A lot of people were using C on CP/M so I would type in programs from Byte magazine. I wrote a FORTH (in assembly language) for OS-9 that was subroutine threaded and unusually had a C like API to access files instead of the block based I/O most FORTHs had.
By the late 1980s I had a 80286 machine and wrote a lot of Assembly, C and Turbo Pascal. I thought Turbo Pascal was better than C but switched to C when I got to college because it was portable to the Sun workstations they had. By the time I got to grad school I got a 486 and switched to Linux.
Personally I liked 8086 assembly a lot and even though the segmentation scheme it used could be awkward I thought it was fun to code.
I think earlier versions of Pascal had only fixed length space padded strings.
Yeah, 6809 and 8088 (arguably an 8-bit CPU) supported C just fine. The other 8-bits, not so much. I wish the CoCo had been a better computer than it was (crappy keyboard, not a real serial port, terrible video). My Atari 800XL was better except for its CPU.
The thing about the CoCo was that Radio Shack sold an absurd number of peripherals for it.
I got a "multi-pak" which would let me plug in four devices to the cartridge slot and I had a real UART for it. The built-in sound was awful but you could get an Orchestra-90, a speech synthesizer cartridge, etc. Most of the hardware and software at the time supported hardware flow control which made the bit-banger serial report more reliable than you might think at low speeds.
The video was a real problem, I think a lot of software didn't get ported to the Coco because everybody thought 40 column text was bad enough, who wants to deal with 32? For instance I never saw the Infocom games being available for the Coco although I found out just recently that Infocam had made a Z-Machine interpreter for it. Eventually they came out with a Coco 3 that had 80 column text and high resolution modes with a lot of colors but it was getting late at that point.
E.g. Oasis Software had White Lightning FORTH ad Basic Lightning[1] and a few others. I never tried the FORTH version, but Basic Lighting and the successor Laser Basic and Laser Basic Compiler started with a bunch of BASIC extensions and eventually added compilation on top of that. The extensions did things like install raster interrupts to virtually increase the number of sprites and provide sound routines, as well as add pre-emptive multitasking(!) on the C64. If I remember correctly, 3-5 BASIC tasks + sprite animations could run concurrently - I don't recall seeing much point, because around then I started with assembler and cycle-counting raster interrupts was suddenly where it was at.
I vividly remember the demo programs the screenshots on the page linked below are from, though...
Who'd want Pascal when you had stuff like that, though? My introduction to Pascal came on my dads boring and slow ITT XT PC, mostly out of curiosity as to how anyone could use a machine that was so obviously inferior to my Amiga - monochrome, no bitmap graphics, no proper sound, less memory (I had a 512KB expansion, for a full megabyte)... Of course it had a harddrive, but it also costs 3 times as much... But I did end up experimenting with Turbo Pascal and some dBase for a while.
[1] https://www.jimbrooks.org/archive/programming/forth/WhiteLig...
On the IBM PC, Turbo Pascal was cheap and hugely popular in the late 80's and early 90's for hobbyists. Mind-blowingly faster than BASIC and you could mix in assembly. Lots of demos and games (and BBS doors) were written in Pascal.
http://archive.gamedev.net/archive/reference/listed82.html?c...
Plus, don't forget hobbyists would 'borrow' software from each other, you'd get a free (possibly older version) of a compiler with a book...
I think I paid $69 for Turbo Pascal (spent all my birthday money in 1992), previous to that I had an old version of Microsoft Quick Pascal that was only $14.95 from Surplus Software. As well as Turbo C 1 that came with a book from SAMS publishing.
Me... I saved and bought a pascal compiler for my C=64.
Me, and most of my friends pirated Turbo Pascal and had a blast with it. This was the early 90s mind you. Rapid Windows GUI prototyping, inline assembly and compile to .EXE, way better than qbasic / gwbasic of before. And it took years for Visual Basic to catch up (if it ever did).
Because the BASIC interpreter lives in ROM, that's "free". Some of the 4096 bytes is house keeping data for the system, but most of it can be used by your program and your data. Whereas Pascal doesn't live in the ROM, so if we're going to run Pascal software the entire Pascal runtime must fit in RAM before our program and data.
By the late 1980s I had a computer with 128kB of RAM, and sure that might have been a good place to try Pascal, if I'd been aware of Pascal, but I was not.
I feel like Pascal was a nice gateway into C from Fortran/BASIC, but it arrived so late I'm not sure it was really efficient in terms of learning.
I was in a computer club and I remember a big bearded guy from IBM (one of the club founders) introducing a new programming language called "C", and thinking "why bother, when you can just code in assembly?"
My experience was with the Apple ][.
Instead of Pascal or C, almost everyone went from Applesoft Basic straight to assembly, with LISA being the tool of choice. (Laser Systems Interactive Symbolic Assembler - https://en.wikipedia.org/wiki/Lazer%27s_Interactive_Symbolic... written by Randy Hide, a noted Apple 2 expert who also wrote this guide: http://www.appleoldies.ca/anix/Using-6502-Assembly-Language-...)
We had 1Mhz. One "core". 48kilobytes of addressable ram (actually less, once the buffers for video space were subtracted). That's an extremely limited space.
Of course the workflow was awful. boot up. Open your editor. Edit your source code. Save to disk. Quit your editor. Run the assembler. No errors? quit and exit to DOS. Reboot & run your new code. (If the program were large, boot to DOS tools disc and copy the code from one floppy to another, then boot that new floppy.) Lather, rinse, repeat.
Applesoft Basic and Assembly were enough for me, until I took my first professional programming job in the 80s and learned Pascal to code for the Lisa and then the Macintosh. I learned C in the late 80s for Windows 2.1, 3.0 and then C++ (beginning with the Microsoft C++ beta compiler distributed on something like 20 5.25" floppy disks. I moved to C# as soon as Microsoft introduced DotNet and others in the decades since, but I never had as much pure joy as the time I spent on my Apple ][. I still have it, and remarkably it still runs 100%, and most of my floppy discs (memorex! gorilla!) still work, even though I used a "nibbler" tool and used both sides. At $5 each (!!) for 80k of storage we had to stretch the budget.
Using MS C (version 3 and onward) on PC and Megamax C on Atari ST were great though. I didn't run into C++ until the 90s on Windows, NT and OS/2.
[0] https://en.wikipedia.org/wiki/Action!_(programming_language)
I learned Pascal on my Atari ST as a 18yo. I had already done commercial games for years in assembly for the ZX Spectrum and had learned m68k, but writing GUI programs for the ST in assembly seemed very annoying. Purchasing the compiler, though... was not really what happened.
I've heard it said that, if they had the C compilers of today back then, the C code might've been good enough -- hardware being constant -- for them to have totally ditched the assembly, but I don't know how true that is.
But then I got an Atari ST with a whopping 1M of RAM, a 10 MB hard drive and Mark Williams excellent C compiler and it was off to the races. That was a real game changer for me.
Languages like C and Pascal really demand that you have a nice, cheap stack. Classically, a function call means pushing all the parameters to the stack, and then the return address, and then jumping to the function, then pulling all the parameters off the stack, and pushing the return value on the stack, then modifying the stack pointer to drop the parameters, and then reading the return address off the stack.
Neither the Z80 or 6502, have instructions that provide an efficient stack, which works with multi-byte data. You end up constantly manipulating the stack pointer (usually for a software-implemented stack) with slow 8-bits-at-a-time arithmetic. Painful.
The PDP-11's instruction set in comparison, provides not just one, but up to seven, flexible 16-bit stacks.
It took many years of compiler progress to change C into the performant language we all know and love/hate today.
Sure, if your dad was an accountant or something, and let you use his PC, you might have access to Turbo Pascal or something, I dunno. But that was a very expensive machine, and market penetration on 16-bit machines was extremely low until the mid80s.
Late 80s, different story.
Few years ago I evaluated FreePascal for writing desktop applications, I ended up instead with the BASIC dialect PureBasic (albeit commercial), better out of the box experience. Pascal is also slightly more verbose than BASIC.
As a kid I wrote my first "professional" product in Applesoft. My family used to rent videotapes (Betamax!) from a little video shop on the corner. They kept records of who rented what on paper cards -- they literally wrote in the customer name and phone # on a paper card and put it in a box. They would go through that box each day and see what was overdue, calling the customer to remind them to return. I was a curious kid so I asked the owner "how do you keep track of everything? Do you really go through all those cards every day to see what is due? Does anything get lost?" I told the owner "I can put all this on a computer and make it so you'll never lose track of who has what" and he said "tell you what, you create that and I'll buy it!"
I wrote a little program in Applesoft basic, using a light pen, that could keep track of the customers and video titles -- what was available, what was out, what was due, and what was overdue. The owner LOVED it! Customers had a "membership" card with a bar code on it.The clerk just had to scan the member card, a barcode for "checkout" (taped to the side of the screen) and then the bar code on the tape. No keyboard. Happy beep meant success. Check-in was the same process. And once a day they could check the "overdue" screen to see who to contact. The customer name, phone number, and name of movie was right there.
They weren't crazy about entering the names of all the tapes and sticking the bar code stickers on them, but once complete business was so much easier & faster.
It took me the better part of the summer to write this and I was paid $200 (a fortune for a 12 year old kid!) and given "free movie rentals for life." The owner was good to his word, and even after he bought a movie rental franchise many years later (maybe Blockbuster?) my family still enjoyed free rentals though the apple 2 was long since retired.
And an older BASIC like BBC BASIC, which was one of the best of its era, still lacks some major conveniences associated with structured programs. It only gained record type support after Richard Russell ported it to modern platforms. The modern dialects are great, but diverge quite a bit from the early ones in that they have become fully structured with OOP support.
What's ultimately driven people over to the current family of languages is that they are making programs that talk mostly to other software, not to I/O. When you add that constraint, you may end up using the language the other software uses for pragmatic reasons. The irony of that is that it really is totally arbitrary.
In the early 80s I wrote a lot of code in (BBC) BASIC and assembly. That was extremely fast to build and run, with optimisations where necessary. For example to use a CP/M machine at the time with turbo pascal, it'd take at least 10 minutes to get the machine up and compile something simple. On the BBC Micro at the time, my preferred machine, there would be working code in under a minute. That was a big gain. They were used for test automation at the time over HP-IB (IEEE-488), eventually replaced with PCs running 16-bit Visual Basic on Windows.
I'm sorry you had such a slow machine to put up with. You didn't get to experience the joy that was Turbo Pascal on an 8 Mhz 286 with 0 wait states. You'd get almost instant compile/run cycles. It was great!
The Macintosh Toolbox had, early on, a reputation for being a little bewildering with a lot of new system libraries to handle (memory management, resource management, UI/TextEdit, DIY event dispatching... it seems strange to explain to people how we would have to manually detect menu events based on location, and then manually respond to menu events), but THINK Pascal gave you a lot of courage.
Really? Of course I'm not talking about embedded system. But PC in the 70s/80s, like Apple II, ZX-80, TRS-80 etc etc.
I guess we, 90s kids, are too spoiled :)
"The original Saboteur! code was written on an actual Spectrum so everything - the source code, assembler program, and object code - had to be in memory at the same time. I'd work on a routine, compile it, then save it. To test it, I'd reset the Spectrum and load the newly compiled routine along with other necessary code, graphics and data. After testing, I'd reset the Spectrum again and re-load my source code and the assembler program. All from cassette! Nightmare!"
Turbo Pascal on CP/Ms breakthrough was bringing a similar experience to a compiled language. So you got fast turn arounds, with better performing code. Turbo did this by compiling from RAM, to RAM, and skipping the link process. The Turbo runtime was already loaded in RAM and used by Turbo itself, so the binary just called already RAM resident routines. When the final COM file was saved, it simply bulk copied the runtime to disk and attached the compiled code at the end. This is one reason why even small programs created large COM files with Turbo, they all bundled the entire runtime.
There's nothing particularly slow about a C compiler, but when you wrap it in reading from disk and writing to disk, or, even worse, writing assembly that then had to be assembled, then stacking on a link step, and turn around craters. The practice of several C files having to be linked together involved yet more I/O. Ostensibly there was a benefit of not having to recompile all of the files all of the time (but note, especially on CP/M at the time there were no timestamps on files, so "make" wasn't a real option to do this), hoping for a net win. Linking also let your program include only the routines it truly needed, reducing footprint. Linkers have lots of benefits, performance during the dev cycle is simply not one of them.
As you started to write larger Turbo programs, utilizing include files, and having to write to disk (because the RAM wasn't enough for your code any longer), and Turbo most certainly slowed down. But still not quite as bad as something like C as, again, there was no real linking phase. I have, I think, a 1200 line Pascal program, in several include files, that builds on a 4Mhz (simulated) Z80 and, yea, you can sit there watching the lines tick by. Doesn't take minutes, but it's definitely a time to get a sip of coffee and catch breath looking out the window.
The Atari series had ACTION, which was a very Turbo like system using a simple Algol-esque language. It, too, had a bundled runtime on the ROM cartridge, with a very fast compiler. I tried a C compiler on the Atari, and tossed it after my first build. It was absolutely horrific. The Atari (along with the Commodores) had notoriously slow disk drives.
Or, if they were serious, they used C. The API for the AES and VDI was developed with C in mind, because it was written in C. Void pointers all over, stuff that Wirth-languages despised.
GEM/TOS bindings for other languages were terrible, I never got Modula-2 to work well for GEM development, it simply didn't ship with bindings for it. I didn't have a C compiler, so to do anything GEM-ish... it was GFA.
But TFA is about the early 80s, and is out to lunch. Only professionals with expensive PCs had access to C and Pascal in the early 80s. Though I guess there were Pascal dialects in the Apple II world, they weren't that commonly used.
It's also a follow-up to an article appreciated on Hacker News that focused on how original BASIC compared to competition (and why The Famous Quote isnt' adequate to the BASIC most of us may know) - https://news.ycombinator.com/item?id=38743062
The section about C, though, I'm sorry to say is littered with flaws and should be rewritten and/or proof-read by someone with more knowledge about the language. Not impressed.
And the Z80A in an Amstrad CPC6128 was clocked with 4MHz, not 3.5MHz like a Speccie. (sorry, couldn't resist)
It's quite common to be mistaken though, because the Z80 in the CPC was not running at full 4 MHz speed (even though it's clocked at 4Mhz). The gate array would set the Z80's WAIT pin for 3 out of 4 clock cycles to create a window for the gate array to read pixel data from memory. This causes the Z80 to fall into a 4-cycle-aligned pattern, meaning that memory access machine cycles were stretched from 3 to 4 clock cycles, resulting in an effective speed of somewhere between 3 and 4 MHz (depending on the instruction mix, but probably averaging somewhere around 3.5 Mhz).
> ... the reason was reentrancy.
...wouldn't passing the return value on the stack also allow reentrancy? Passing args and return values in registers instead of on the stack would definitely be faster, and on 8-bit CPUs, every clock cycle mattered.
But stack is memory. At least in these systems. So I think the problems could rise if we would throw concurrency into the picture, where you also have to synchronize the memory access, maybe?
Well for once, PCs were ridiculously expensive back in the day so that rules out using the PC version of Borland Pascal / C. I had them in school, but we had mostly CP/M based machines and only two PCs. A 286 AT and an 8086 XT. If I recall correctly we had Borland Pascal 5.0 and it worked blazingly fast on both machines. Then some dumbass decided to upgrade to Borland Pascal 6.0 and wiped out 5.0 from the XT machine (lack of space, maybe? but mostly supidity) and replaced it with 6.0. It was horrendously slow. Like I got my first look into today's "enterprise" compile times :) Pressing F5 (or F9 or something to compile, I don't recall the exact key) took about a minute to start showing the compilation dialog. Several more minutes to compile. Compared to instantaneous on 5.0. Rendered the whole thing unusable on the XT.
On the other hand I hated working on school's computers. They were overcrowded, too few for too many students and I always had barely enough time to type the examination programs (I was studying computer science) needed to get my grades, never enough time to fiddle and experiment. Or game.
So for that I used my dear home computer, a ZX-Spectrum compatible clone manufactured locally: http://retroit.ro/wp-content/uploads/2019/12/hc-85-maro-678x...
Initially I did BASIC but as time progressed, I needed more speed and interpreted BASIC was hopelessly slow. I wanted to program TETRIS actually :) So I switched to Pascal, more precisely HiSoft Pascal for ZX Spectrum. Here's the book I learned from, there was no Internet back then so the book was quintesential: https://imgur.com/a/qweDG2E
Actually that's also where I learned and understood memory management. Linked lists, allocation, deallocation. Before C, for me there was Pascal. One thing that blew my mind and didn't understood it until I programmed and ran it with my own hands was recursively referring to the defined structure ... in the very structure. You know the C definition:
typedef struct node { int val; struct node * next; } node_t;
How the heck can you refer to something that's not yet defined in a way, I was thinking.
So, I eventually implemented that TETRIS in Pascal and I've no idea how I did it without a debugger... I guess with print statements and just thinking with pen an paper. Worked well enough although it did crash on occasion and I never figured out why :)
Anyhow, sometime later I got my hands on HiSoft's compiler for BASIC. Very cool thing, you'd load the compiler from cassette then you'd write your program in the regular ZX-Spectrum BASIC and then RANDOMIZE USR <some number> (address of loaded compiler) and the thing would put machine code somewhere in the remaining memory and provide you with the address and size. So you could save the machine code directly on cassette and run it directly next time. And all that in less than 40Kb of memory for BASIC code, compiler code, resulting compiled program and stacks etc. Believe it or not, I rewrote that TETRIS in BASIC and was able to compile and run it. Bonus it never crashed, I guess the BASIC version was inherently more stable.