The Official Aztec C Online Museum (2009)(aztecmuseum.ca)
aztecmuseum.ca
The Official Aztec C Online Museum (2009)
http://aztecmuseum.ca/
10 comments
Hmm... I thinks this is what I used to learn C - on an Amiga.
Oh, the memories...
... most of them about waiting for the disk to finish reading just to run out of memory thanks to Intuitions.h being such a beast. I think one of my first real C programs was a pre-processor and minimiser for the amiga UI header files.
Oh, the memories...
... most of them about waiting for the disk to finish reading just to run out of memory thanks to Intuitions.h being such a beast. I think one of my first real C programs was a pre-processor and minimiser for the amiga UI header files.
I remember trying to use a C compiler on my Amiga but IIRC it was such a pain to use with only one floppy drive and no hard drive (and 512KB RAM). My mom wouldn't buy me a second floppy drive (let alone a hard drive) because she thought this computer thing was just a toy, so I switched using assembly.
Programming the Amiga with a good macro assembler was actually a surprisingly good experience. The official documentation of the various system libraries was clearly explained in terms of the underlying ABI, almost as if it was expected for people to reach out to assembly to write applications.
Programming the Amiga with a good macro assembler was actually a surprisingly good experience. The official documentation of the various system libraries was clearly explained in terms of the underlying ABI, almost as if it was expected for people to reach out to assembly to write applications.
2MB Fast RAM expansion with reset-proof RAM disk. In the morning, load all the diskettes. After that...vroooom! :-)
HD-based Unix systems were a bit of a let-down, to be frank...
HD-based Unix systems were a bit of a let-down, to be frank...
I had Lattice (later SAS/C) myself. Luckily I had a hard drive (30 megs!), which was a total luxury for the time, 1989-90 or so.
I recently started working on a single-board Z80-based computer, running CP/M. I wrote a couple of simple programs in Z80 assembly, including a text-based adventure game, and other utilities.
It was so cool to be able to run the Aztec compiler in-situ, on the computer itself, and I'm glad the official sources have been preserved.
There are a lot of online archives of random .zip files for CP/M, but few are as well documented as the Aztec collection.
It was so cool to be able to run the Aztec compiler in-situ, on the computer itself, and I'm glad the official sources have been preserved.
There are a lot of online archives of random .zip files for CP/M, but few are as well documented as the Aztec collection.
The thing I liked about Aztec C was that they gave you the source code for their libc. You could easily write and integrate your own I/O drivers for stdin and stdout. It really made embedded C development easy.
I worked at this company as a support engineer in the summer between high school and college. It was a blast.
This was the first compiler I paid for as a grad student circa 1986. It was wonderfully useful, well documented. Tech support always responded to my letters and emails. And they sent me updates for years. I loved Aztec C.
Does anyone have numbers on how the backend compares to CC65 for performance on the 6502?
I've always felt the the 6502 architecture wasn't really amenable to C (mainly due to the limited stack). A quick glance at the site with an eye toward accommodations made for the platform turned up the interesting hybrid architecture of the compiler suite. You can see it detailed in the section "1.6 C65 and CCI, The Speed Versus Size Dilemma"[0].
Basically, there's an optional compiler that emits a p-code (rather than 6502 machine code) that's interpreted by a VM to make 16 and 32-bit operations more space efficient. This is highly reminiscent of SWEET16[1]. Also makes me think of the Apollo Guidance Computer and the "Interpreter"[2].
This looks like a lot of fun. I'd like to get this running on my Apple IIgs!
[0] http://aztecmuseum.ca/docs/AztecC_minimanual.txt [1] https://en.wikipedia.org/wiki/SWEET16 [2] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...
Basically, there's an optional compiler that emits a p-code (rather than 6502 machine code) that's interpreted by a VM to make 16 and 32-bit operations more space efficient. This is highly reminiscent of SWEET16[1]. Also makes me think of the Apollo Guidance Computer and the "Interpreter"[2].
This looks like a lot of fun. I'd like to get this running on my Apple IIgs!
[0] http://aztecmuseum.ca/docs/AztecC_minimanual.txt [1] https://en.wikipedia.org/wiki/SWEET16 [2] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...
> This looks like a lot of fun.
Used it on a //e. It's not. It's painfully slow - slower than the BASIC in ROM.
It also messes with page zero, which makes it impossible to use the ROM routines (which could have made character output not ludicrously slow - it feels like a 1200 bps terminal)
Used it on a //e. It's not. It's painfully slow - slower than the BASIC in ROM.
It also messes with page zero, which makes it impossible to use the ROM routines (which could have made character output not ludicrously slow - it feels like a 1200 bps terminal)
Interesting. I didn't get the feeling that they were targeting embedded 6502 but, rather, the Apple II platform. To that end I'd think being "friendly" to the ROM routines would have made good sense (since they get all that functionality "for free").
I guess I'll fire it up in an emulator first to see if it's worth hitting the real hardware with it. Thanks for the heads up!
I guess I'll fire it up in an emulator first to see if it's worth hitting the real hardware with it. Thanks for the heads up!
I did a PoC with it and we gave up on C for an Apple II port of an educational Mac game (which was written in C). We went with @plutus' GraFORTH. It was easier (and more pleasant) to reimplement everything in Forth than to persuade Aztec C to create minimally reasonable 6502 binaries.
I had a good use for these old compilers- in this case I ended up using code from the Zortech-C library to reduce memory usage for ARM embedded. It turns out that the float to ascii conversion functions for printf from the Zortech-C library are much smaller than the ones in newlib. I'm sure they are less accurate, but I don't care for this application. Same for strtod. Also they are faster.
I put the code here:
https://github.com/jhallen/joes-sandbox/blob/master/snippets...
I see the Aztec ones for x86 are hand assembly..
I put the code here:
https://github.com/jhallen/joes-sandbox/blob/master/snippets...
I see the Aztec ones for x86 are hand assembly..
Ahh, the memories. Aztec C on an Apple II with a giant Corvus 5 MB drive (whoosh, whoosh, whoosh goes the drive head). It’s where I learned “:wq”, thanks to Z!
Why does everyone use ":wq" instead of "ZZ", is the latter not everywhere or one more thing to learn?
It was very cool that they built a mini Unix toolset as part of the compiler suite so you had kinda-sorta unix on DOS, Mac OS MPW shell, Amiga....
It was a rare privilege for a 20 year old in the 80s to see code that beautiful and tight.