6 ms·

Great article. Some petty nitpicking: > "Just use LHA format archives. It’s the standard compression tool on Amigas and even though there are modern (and techn

Great article. Some petty nitpicking: > "Just use LHA format archives. It’s the standard compression tool on Amigas and even though there are modern (and technically better) alternatives ..." LZX had supplanted LHA already by 1994. > "a 7Mhz 68000 16-bit CPU" It's a "16/32"-bit CPU, since it provides 32-bit operations/immediates and 32 bits worth of data- and address registers. For all practical accounts of programming the CPU it's a 32-bit machine, no matter the bus shoveling data 16 bits at a time behind the scenes. > "... but all of what follows is in the context of developing a systems tool in C as that's the language of AmigaOS" Not sure how to interpret this. You're in no way locked to C if you want to program for AmigaOS. You can load and interact with all of the libraries etc. of AmigaOS in Pascal, E and what-have-you, since there are headers available for almost any language you may want. Even assembly, which for the Amiga is/was a far more common choice for OS-friendly applications than people think.

mark_round 3y ago
Nitpick away, always glad to include corrections! > LZX had supplanted LHA already by 1994. True, but LHA always felt like more of the standard and tools were readily available and present on most systems. Sort of like how Bzip2/XZ and so on are technically far superior, yet a gzipped tarball is still the universal standard on Unix systems. A quick glance through AmiNet shows the majority of packages there are still using LHA as standard. Even stuff targetting a "modern" Amiga tends to use LHA - grepping the Os4Depot full package list shows: grep -c '.lha' FULLINDEX.readme 4110 grep -c '.lzx' FULLINDEX.readme 37 > For all practical accounts of programming the CPU it's a 32-bit machine True. I'll update the article to include that - I guess I'm really thinking of things like the 68020 processor (and CD32 which proudly proclaimed "32-BIT" in big letters on the case :) > You're in no way locked to program for AmigaOS in C. Also true. From what I can see, calling & opening the libraries from Assembly is remarkably similar to e.g. C, but from browsing the leaked OS source (not that I'd ever advocate for that sort of thing ;) ) it was all originally in C. I wanted to dive in and get a better understanding of the code as it was originally written hence my experiments targeting C. Plus, I knew enough C from my old University days to get up to speed in a short enough timespan. With no memory protection, crashing my Amiga because I forgot to free some DOS object or other was a common occurrence - if I was attempting this in Assembly, I'd probably still be working on a basic proof-of-concept! Although I really admire the skills of those developers who did choose that language to write system utilities, not to mention the magic of the demo-scene. It's just a bit beyond my abilities/time constraints at the moment!
- vidarh 3y ago
  It wasn't all originally in C. AmigaDos infamously was originally BCPL, hence the nasty legacy of BPTR and BSTR types all of the places. EDIT: To those unfamiliar, which I'm guessing is most people here, BPTR's are regular pointers shifted two bits down... BSTR's are BPTR's to a BCPL string, more commonly known as a "Pascal string" (single byte length as the first byte). The reasoning for this is language simplicity (too much... I hate it, to be clear): What in C would be array[index] is famously pretty much syntactic sugar for *(array + index). In BCPL it's !(array+index) or array!index. But whereas C is typed enough that C knows that (array + index) requires scaling index to the size of the elements of the array, BCPL is type-less. So if "index" is 1, array + index will add 1 to the address even if "array" holds 32 bit values. Since every value is typically the size of a pointer (otherwise the typeless goes straight out the window), on M68k the elements are 4 bytes. So to make (array + index) work, pointers needs to be left-shifted two bits. Then you can right-shift them two bits for any operations explicitly treating them as pointers (like "!")... And then everyone having to ever interface with your code from any other language will hate you for all time.
  - amiga386 3y ago
    Just to add some more flavour: AmigaDOS in AmigaOS 1.x was a port/adaption of TRIPOS [0] to 68000 by MetaComCo. This was because the intended disk OS/API, "CAOS", was nowhere near ready for the Amiga's 1985 launch. [1] It's the conventions of TRIPOS that commands go in "c" / "C:", libraries go in "l" / "L:" and scripts go in "s" / "S:", which is why these directories and standard assigns are on Amiga disks... but AmigaDOS "libraries" are limited to filesystem handlers, real Amiga libraries are found in the "libs" / "LIBS:" directory. Even the standard filesystem was from TRIPOS. It had 488 bytes of data and 24 bytes of metadata per 512-byte disk block! There was a lot of wailing and gnashing of teeth trying to use AmigaDOS 1.x. Charlie Heath and others started the AmigaDOS Replacement Project (ARP, retroactively renamed "AmigaDOS Resource Project" to not sound so nasty) which rewrote all the standard C: commands in assembler and C, using a common arp.library, which also added one of the earliest "standard" filesystem requesters. [2] Commodore took this onboard. Commodore created FastFileSystem (FFS) to replace the retroactively-named "Old Filesystem" (OFS) in time for AmigaOS 1.3. FFS removed _all_ per-diskblock metadata and let you lay down contiguous runs of 512-byte blocks! Commodore rewrote AmigaDOS and its commands in C and assembler for AmigaOS 2.0, retaining BCPL only where absolutely needed to keep filesystem handlers working. They also added a new asl.library with a standardized filesystem requester. In short, ARP was completely successful in getting Commodore to ditch BCPL AmigaDOS for one written in C. [0] https://en.wikipedia.org/wiki/TRIPOS https://en.wikipedia.org/wiki/TRIPOS [1] https://web.archive.org/web/20190420095854/http://www.thule.no/haynie/caos.html https://web.archive.org/web/20190420095854/http://www.thule.... [2] http://aminet.net/package/misc/antiq/ARP_13 http://aminet.net/package/misc/antiq/ARP_13
amiga386 3y ago
> LZX had supplanted LHA already by 1994. Firstly - no it didn't. Sorry for nitpicking the nitpick, but the first public release of LZX was February 5, 1995. Secondly, "LZX supplanted LHA" is an opinion with varying levels of support. LZX did take the Amiga community by storm, with its higher compression ratios, solid archiving and built-in support for unpacking LhA files, faster than LhA could. Many people started recompressing their archives with LZX... but also many people didn't. Some Amiga magazine coverdisks (e.g. AUI) started using DiskSpare and LZX to get as much on a disk as possible... others stuck with normal disks and LHA. The majority of Amiga software archives are on Aminet, which is still getting uploads today. Aminet standardized on LhA, not LZX. Just as a random non-Aminet example, the WHDLoad homepage offers you its software in either LHA or LZX format, your choice. Wouldn't it be LZX only by now if LZX supplanted LHA in 1994? What the OP said rings true; LhA files are ubiquitous on the Amiga, and also it's possible to portably unpack and create them on other systems. LZX is very popular, but I wouldn't personally say it supplanted LHA, even though I have hundreds of LZX archives.
deaddodo 3y ago
> It's a "16/32"-bit CPU, since it provides 32-bit operations/immediates and 32 bits worth of data- and address registers. Eh, you're getting into some real crafty wordplay here. If you want to be technical it's a 16-bit processor with compound operations at 32-bit, in the same way a Z80 is an 8-bit processor that does 16-bit compound operations. Yeah, if you redefine the terms, you can make it mean exactly what you want. This is exactly what Atari did to label the Jaguar a "64-bit" machine, after all. It doesn't change what people meant at the time when they used the nomenclature (the native operating size of the ALU).
- daneel_w 3y ago
  How is it "real crafty wordplay"? 16/32-bit is Motorola's own designation, and that's the width of the registers and the ISA's immediates. When programming the 68k you work directly with 32-bit longwords instead of having to manually herd multiple 16-bit words to achieve the same. Register-combining instructions like those in the Z80 do not exist in the 68000, nor are they necessary. Your comparison is invalid. Perhaps you have no experience programming the m68k family.
  - deaddodo 3y ago
    I literally wrote an m68k emulator core, along with multiple z80 variants. I'm intimately familiar with the internals of both, thanks. To reiterate my point, with sourcing (to counter your glib dismissals): > The design implements a 32-bit instruction set, with 32-bit registers and a 16-bit internal data bus.[4] The address bus is 24 bits and does not use memory segmentation, which made it easier to program for. Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.[5] For this reason, Motorola termed it a 16/32-bit processor. Highlighted portion italicized, source: https://en.wikipedia.org/wiki/Motorola_68000 https://en.wikipedia.org/wiki/Motorola_68000 When people refer to bit-width around the generation aforementioned (8-bit to early 32-bit), this is what they are referencing. This is because many CPUs operated on different bus sizes throughout the architecture. What people using the term care about is it's native arithmetic capabilities. Unless you want to run around calling ARM11s "16-bit CPUs" because they support THUMB. As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency.
sgt 3y ago
> LZX had supplanted LHA already by 1994. What's your background as an Amiga user? As someone who started using Amiga around 94 until 2000, I can't remember seeing many usages of LZX. It was always LHA.
- daneel_w 3y ago
  I got my first Amiga in early 1992 and the Amigas stayed as my main computer systems up until as late as 2000 or 2001. For most of my years with the Amiga I was part of what's called the "demoscene", mainly as a coder but also doing a bit of music now and then, and for a couple of years I also ran a scene focused (non-warez) public BBS. I also spent a few years in the warez scene as a "trader", slinging warez between BBSes. For me, LZX was the dominant archive format during the latter half of my Amiga days, whether it was scene productions, warez, or stuff sourced from magazine CDs etc. Most things archived with LHA that I came upon were things that originated from the early part of the 90s and before.

mark_round 3y ago

Nitpick away, always glad to include corrections! > LZX had supplanted LHA already by 1994. True, but LHA always felt like more of the standard and tools were readily available and present on most systems. Sort of like how Bzip2/XZ and so on are technically far superior, yet a gzipped tarball is still the universal standard on Unix systems. A quick glance through AmiNet shows the majority of packages there are still using LHA as standard. Even stuff targetting a "modern" Amiga tends to use LHA - grepping the Os4Depot full package list shows: grep -c '.lha' FULLINDEX.readme 4110 grep -c '.lzx' FULLINDEX.readme 37 > For all practical accounts of programming the CPU it's a 32-bit machine True. I'll update the article to include that - I guess I'm really thinking of things like the 68020 processor (and CD32 which proudly proclaimed "32-BIT" in big letters on the case :) > You're in no way locked to program for AmigaOS in C. Also true. From what I can see, calling & opening the libraries from Assembly is remarkably similar to e.g. C, but from browsing the leaked OS source (not that I'd ever advocate for that sort of thing ;) ) it was all originally in C. I wanted to dive in and get a better understanding of the code as it was originally written hence my experiments targeting C. Plus, I knew enough C from my old University days to get up to speed in a short enough timespan. With no memory protection, crashing my Amiga because I forgot to free some DOS object or other was a common occurrence - if I was attempting this in Assembly, I'd probably still be working on a basic proof-of-concept! Although I really admire the skills of those developers who did choose that language to write system utilities, not to mention the magic of the demo-scene. It's just a bit beyond my abilities/time constraints at the moment!

vidarh 3y ago
It wasn't all originally in C. AmigaDos infamously was originally BCPL, hence the nasty legacy of BPTR and BSTR types all of the places. EDIT: To those unfamiliar, which I'm guessing is most people here, BPTR's are regular pointers shifted two bits down... BSTR's are BPTR's to a BCPL string, more commonly known as a "Pascal string" (single byte length as the first byte). The reasoning for this is language simplicity (too much... I hate it, to be clear): What in C would be array[index] is famously pretty much syntactic sugar for *(array + index). In BCPL it's !(array+index) or array!index. But whereas C is typed enough that C knows that (array + index) requires scaling index to the size of the elements of the array, BCPL is type-less. So if "index" is 1, array + index will add 1 to the address even if "array" holds 32 bit values. Since every value is typically the size of a pointer (otherwise the typeless goes straight out the window), on M68k the elements are 4 bytes. So to make (array + index) work, pointers needs to be left-shifted two bits. Then you can right-shift them two bits for any operations explicitly treating them as pointers (like "!")... And then everyone having to ever interface with your code from any other language will hate you for all time.
- amiga386 3y ago
  Just to add some more flavour: AmigaDOS in AmigaOS 1.x was a port/adaption of TRIPOS [0] to 68000 by MetaComCo. This was because the intended disk OS/API, "CAOS", was nowhere near ready for the Amiga's 1985 launch. [1] It's the conventions of TRIPOS that commands go in "c" / "C:", libraries go in "l" / "L:" and scripts go in "s" / "S:", which is why these directories and standard assigns are on Amiga disks... but AmigaDOS "libraries" are limited to filesystem handlers, real Amiga libraries are found in the "libs" / "LIBS:" directory. Even the standard filesystem was from TRIPOS. It had 488 bytes of data and 24 bytes of metadata per 512-byte disk block! There was a lot of wailing and gnashing of teeth trying to use AmigaDOS 1.x. Charlie Heath and others started the AmigaDOS Replacement Project (ARP, retroactively renamed "AmigaDOS Resource Project" to not sound so nasty) which rewrote all the standard C: commands in assembler and C, using a common arp.library, which also added one of the earliest "standard" filesystem requesters. [2] Commodore took this onboard. Commodore created FastFileSystem (FFS) to replace the retroactively-named "Old Filesystem" (OFS) in time for AmigaOS 1.3. FFS removed _all_ per-diskblock metadata and let you lay down contiguous runs of 512-byte blocks! Commodore rewrote AmigaDOS and its commands in C and assembler for AmigaOS 2.0, retaining BCPL only where absolutely needed to keep filesystem handlers working. They also added a new asl.library with a standardized filesystem requester. In short, ARP was completely successful in getting Commodore to ditch BCPL AmigaDOS for one written in C. [0] https://en.wikipedia.org/wiki/TRIPOS https://en.wikipedia.org/wiki/TRIPOS [1] https://web.archive.org/web/20190420095854/http://www.thule.no/haynie/caos.html https://web.archive.org/web/20190420095854/http://www.thule.... [2] http://aminet.net/package/misc/antiq/ARP_13 http://aminet.net/package/misc/antiq/ARP_13

amiga386 3y ago

> LZX had supplanted LHA already by 1994. Firstly - no it didn't. Sorry for nitpicking the nitpick, but the first public release of LZX was February 5, 1995. Secondly, "LZX supplanted LHA" is an opinion with varying levels of support. LZX did take the Amiga community by storm, with its higher compression ratios, solid archiving and built-in support for unpacking LhA files, faster than LhA could. Many people started recompressing their archives with LZX... but also many people didn't. Some Amiga magazine coverdisks (e.g. AUI) started using DiskSpare and LZX to get as much on a disk as possible... others stuck with normal disks and LHA. The majority of Amiga software archives are on Aminet, which is still getting uploads today. Aminet standardized on LhA, not LZX. Just as a random non-Aminet example, the WHDLoad homepage offers you its software in either LHA or LZX format, your choice. Wouldn't it be LZX only by now if LZX supplanted LHA in 1994? What the OP said rings true; LhA files are ubiquitous on the Amiga, and also it's possible to portably unpack and create them on other systems. LZX is very popular, but I wouldn't personally say it supplanted LHA, even though I have hundreds of LZX archives.

deaddodo 3y ago

> It's a "16/32"-bit CPU, since it provides 32-bit operations/immediates and 32 bits worth of data- and address registers. Eh, you're getting into some real crafty wordplay here. If you want to be technical it's a 16-bit processor with compound operations at 32-bit, in the same way a Z80 is an 8-bit processor that does 16-bit compound operations. Yeah, if you redefine the terms, you can make it mean exactly what you want. This is exactly what Atari did to label the Jaguar a "64-bit" machine, after all. It doesn't change what people meant at the time when they used the nomenclature (the native operating size of the ALU).

daneel_w 3y ago
How is it "real crafty wordplay"? 16/32-bit is Motorola's own designation, and that's the width of the registers and the ISA's immediates. When programming the 68k you work directly with 32-bit longwords instead of having to manually herd multiple 16-bit words to achieve the same. Register-combining instructions like those in the Z80 do not exist in the 68000, nor are they necessary. Your comparison is invalid. Perhaps you have no experience programming the m68k family.
- deaddodo 3y ago
  I literally wrote an m68k emulator core, along with multiple z80 variants. I'm intimately familiar with the internals of both, thanks. To reiterate my point, with sourcing (to counter your glib dismissals): > The design implements a 32-bit instruction set, with 32-bit registers and a 16-bit internal data bus.[4] The address bus is 24 bits and does not use memory segmentation, which made it easier to program for. Internally, it uses a 16-bit data arithmetic logic unit (ALU) and two more 16-bit ALUs used mostly for addresses,[4] and has a 16-bit external data bus.[5] For this reason, Motorola termed it a 16/32-bit processor. Highlighted portion italicized, source: https://en.wikipedia.org/wiki/Motorola_68000 https://en.wikipedia.org/wiki/Motorola_68000 When people refer to bit-width around the generation aforementioned (8-bit to early 32-bit), this is what they are referencing. This is because many CPUs operated on different bus sizes throughout the architecture. What people using the term care about is it's native arithmetic capabilities. Unless you want to run around calling ARM11s "16-bit CPUs" because they support THUMB. As to what Motorola opted to call it, I couldn't care less about marketing speak regarding notoriously fuzzy buzzword CPU-capabilities; I care about technical capabilities and consistency.

sgt 3y ago

> LZX had supplanted LHA already by 1994. What's your background as an Amiga user? As someone who started using Amiga around 94 until 2000, I can't remember seeing many usages of LZX. It was always LHA.

daneel_w 3y ago
I got my first Amiga in early 1992 and the Amigas stayed as my main computer systems up until as late as 2000 or 2001. For most of my years with the Amiga I was part of what's called the "demoscene", mainly as a coder but also doing a bit of music now and then, and for a couple of years I also ran a scene focused (non-warez) public BBS. I also spent a few years in the warez scene as a "trader", slinging warez between BBSes. For me, LZX was the dominant archive format during the latter half of my Amiga days, whether it was scene productions, warez, or stuff sourced from magazine CDs etc. Most things archived with LHA that I came upon were things that originated from the early part of the 90s and before.