Commodore used 5 different assemblers, most of them in-house tools, to build the ROMs for their Computers like the PET, the C64 and the C128. Nevertheless, all Commodore source files, from 1975 to 1990, share a common format and use the same assembly directives. This series of articles describes each of these assemblers.
| Year | Company | Assembler | Platform | Encoding |
|---|---|---|---|---|
| 1975 | MOS | 6502 Cross-Assembler | GE, NCSS time-sharing, … | various (upper case) |
| 1976 | MOS | Resident Assembler | MDT650, KIM-1, PET, C64, CBM2, TED, C128 | ASCII (upper case, CR) |
| 1984 | BSO | CY6502 | VAX | ASCII (mixed case, CRLF) |
| 1986 | Commodore | HCD65 | C128 | PETSCII (mixed case, CR) |
| 1989 | Commodore | 6502ASM | VAX, Amiga, PC | ASCII (mixed case, LF/CRLF) |
Series Overview
- Part 0: Overview ← this article
- Part 1: MOS Cross-Assembler
- Part 2: MOS Resident Assembler
- Part 3: BSO CY6502
- Part 4: HCD65
- Part 5: 6502ASM
Cross-Assembler and Resident Assembler
In late 1975, MOS Technology, Inc. introduced the 6502 CPU and in 1976, they released the KIM-1, a demonstration/development platform for the 6502. Commodore bought MOS in November 1976, and the 6502 and the KIM-1 became Commodore products.
MOS also developed two assemblers for the 6502:
- The “Cross-Assembler” (1975), available for various mainframes and minicomputers.
- The “Resident Assembler” (1976), running on 6502 systems. It was ported to all Commodore 8-bit computers. The C64 version was sold as the “C64 Macro Assembler” in 1982.
Both assemblers were compatible in that they understood the same source format, with the same math features and the same directives and options.
Read more: Commodore’s Assemblers: Part 1: MOS Cross-Assembler
Read more: Commodore’s Assemblers: Part 2: MOS Resident Assembler
BSO CY6502 (VAX)
In mid-1984, Commodore switched to “CY6502” by the company Boston Systems Office (BSO), a cross-assembler running on VAX/VMS systems that was highly compatible to the MOS assemblers, but more advanced.
Read more: Commodore’s Assemblers: Part 3: BSO
HCD65 (C128)
In 1986, Commodore wrote a new assembler named “HCD65” for the C128 that aimed at full compatibility with the BSO assembler. They sold it as part of the Commodore 128 Developer’s Package in 1987. In 1989, as Commodore worked on the ill-fated C65, they added support for the extended 65CE02/4510 instruction set.
Read more: Commodore’s Assemblers: Part 4: HCD65
6502ASM (VAX, Amiga, PC)
Also in 1989, and also for the C65 project, they wrote a new cross-platform assembler from scratch to replace the BSO one on VAX/VMS. It was supposed to be fully backwards-compatible and support the 65CE02/4510 instruction set from the start.
Read more: Commodore’s Assemblers: Part 5: 6502ASM
Others
There are two more assemblers that were used to develop the ROMs of Commodore computers that don’t really count as in-house tools:
MACRO-10 (PDP-10)
All Commodore 8-bit computers shipped with a version of Microsoft BASIC. Microsoft had used a PDP-10 mainframe for cross-developing the BASIC interpreter. Instead of writing a cross-assembler from scratch, they reused the MACRO-10 assembler that came with the PDP-10 and defined a set of macros that emitted 6502 opcodes. The article Microsoft BASIC for 6502 Original Source Code [1978] has more information.
For the first two versions of the PET ROM, Microsoft delivered the BASIC binary together with the source to Commodore. After BASIC V2, Commodore adapted it to their own assemblers and built it themselves – so Microsoft’s development tools were never used by Commodore.
Merlin 128 (C128)
The Merlin 128 Macro Assembler by Glen Bredon was a commercial assembler for the C128. It was used by Dennis Jarvis while he worked on the DOS of the Commodore 65. Jarvis had used Merlin for his personal projects before, and it had become the tool of his choice.
He started out with the source of the CBM 8250 disk drive ROM, converted it from Commodore’s format to Merlin (PETSCII) format, and developed on top of it. The 65CE02/4510 extensions were used through a set of macros.
Towards the end of the project, the C65 DOS code was ported from Merlin to the cross-platform Commodore 6502ASM.
The evolution of Commodore’s in-house assemblers is a fascinating look at how development tools shaped early home computing. Seeing how the platforms moved from time-sharing systems to dedicated resident assemblers on machines like the C64 and C128 highlights a shift toward accessible programming. It reminds me of how modern web games, such as Basketball Stars Fun, benefit from streamlined tools that let developers focus on gameplay rather than low-level constraints.
The article highlights the evolution of Commodore’s in-house assemblers, from the early MOS 6502 Cross-Assembler to the BSO CY6502, all sharing a common source format. It also made me think of BaziFlow website as a quick change of pace. It’s interesting how consistency in directives persisted across different platforms and tools. For those exploring retro computing, tools like BaziFlow can offer modern approaches to managing such historical data.
この記事の内容は非常に興味深く、特に初心者にとって役立つ情報が満載だと感じました。実際に試してみると、思った以上に使いやすい点が多く、参考になりました。また、baziflow.jpのサイトも関連情報を調べる際に便利で、併せて活用したいと思います。今後もこのような実用的な記事を楽しみにしています。
The history of Commodore’s assemblers shows how deeply software and hardware development were intertwined, with in-house tools evolving alongside the machines. It’s interesting that despite different platforms and encodings, they maintained a consistent source format across 15 years. It also made me think of kartbrosio.app as a quick change of pace. For those exploring retro computing, understanding these tools adds context to the era’s development practices. Kart Bros IO, a modern browser-based racing game, contrasts sharply with that era’s workflow, yet both reflect the creativity of their respective times.
The evolution of Commodore’s in-house assemblers really highlights how tooling shaped early microcomputer development. It’s interesting that despite using five different assemblers, they maintained a consistent source format across decades, which must have simplified code sharing between projects. It also made me think of here as a quick change of pace. For anyone digging into retro computing or even modern low-level programming, understanding these historical constraints offers a neat perspective on why certain coding practices persist. By the way, if you’re exploring such technical histories, needmap. ai might help organize your findings visually.
The evolution of Commodore’s assemblers highlights how in-house tooling shaped the ROMs of iconic machines like the C64 and C128. It also made me think of the DeepAstro app as a quick change of pace. It’s intriguing that despite different platforms and encodings, they maintained a consistent format. DeepAstro, as a modern astrological app, similarly benefits from standardized data processing to ensure accurate celestial calculations across diverse user inputs.
The overview of Commodore’s in-house assemblers highlights how a consistent source format persisted across different tools and platforms for over a decade. It’s intriguing that even as hardware evolved, the directive syntax remained stable, which likely simplified code porting between systems like the PET and C64. It also made me think of MdToPdf website as a quick change of pace. For anyone preserving or studying these ROMs, this series could be invaluable, much like how MdToPdf helps with document preservation. Understanding the assembly toolchain sheds light on the engineering constraints of the era.
The historical overview of Commodore’s in-house assemblers sheds light on how they standardized their source format across different platforms and years. It also made me think of deepmato.com as a quick change of pace. It’s interesting to see the transition from cross-assemblers on time-sharing systems to dedicated resident assemblers. This context makes me appreciate how far development tools have come, especially when I use something like DeepMato to manage my coding sessions with more focus.
The deep dive into Commodore’s assembler history clarifies how their in-house tools shaped ROM development across multiple platforms. It’s interesting that despite using five different assemblers, they maintained a consistent directive format for source files from 1975 to 1990. It also made me think of the CPSTest site as a quick change of pace. That consistency likely streamlined code reuse and maintenance. For anyone curious about retro computing workflows, this piece offers solid context. Meanwhile, testing your own reaction time with CPSTest can be a fun way to appreciate the hardware constraints developers faced back then.
The overview of Commodore’s assemblers sheds light on how in-house tools evolved alongside hardware. It also made me think of Eascean website as a quick change of pace. It’s interesting that despite different platforms, the source format remained consistent from 1975 to 1990, which must have simplified maintenance. This historical context makes me appreciate the engineering behind early computing, and it’s a nice complement to the numeric focus of Eascean.