C128 Developers Kit

[Neglectoru]

Back when I had a C128D, I had two assemblers that I loved.  One was the C-64 "Assembler 64" package, the other was the C128 Developers Kit, both from Commodore.  I was able to recover the disk images for assembler 64, but for the life of me, I can't find the C128 assembler, and I can't find it online.

I remember that the assembler was called HCD65. and it included other utilities, such as a full screen (80 column) editor, and some fast load source code.  It either came on a 1571, or a flippy.

Does anyone still have this assembler?  I'm interested largely in historical reasons, but I'd love to assemble some of my old source code again, and I'm pretty sure it is in HCD65 format.

[airship]

Just to give this thread a 'bump', I'd love to find the HCD65 assembler, too. There's still code out there on the Intertubes for it.

[nikoniko]

Ah, the Holy Grail. The source code which came with it is readily available, but the tools are nowhere in sight. Perhaps it could still be ordered from here? ;P

[bacon]

I think I found it on the net a few years back. When flipping through my 128 disks last week I saw a disk labeled "128 dev pack". Could be it. I'll upload it somewhere when I get the time.

[airship]

I've seen the Sprite Editor online somewhere, too. But never the Assembler itself.

Bob Baker reviewed it for INFO, but I asked him just a couple of weeks ago and he doesn't have it anymore.

[bacon]

Looked through my disks yesterday, and it's there. I've even written HCD65, Linker, and Editor on the label so I'm sure it's the disk you're looking for. Didn't have time to upload it yesterday but I'll do it tonight.

[bacon]

I have sent the d64 with the editor, assembler, linker and a few other utilities to Lance so he can include it in the archive.

[airship]

Thank you! Thank you! Thank you! This will be cool.

[Blacklord]

I have sent the d64 with the editor, assembler, linker and a few other utilities to Lance so he can include it in the archive.

Temporary link to the file is here pending it being moved over the weekend to the main site.

cheers,

Lance

[airship]

Grabbed this and installed it tonight. I'm excited about just having it. I don't know if there are better tools out there than this, but it's great to have them just to see what the initial developers for the C128 had to work with.

Thanks!

[hannenz]

does anyone have a documentation for the c128 dev. pack that discusses a little more than the few lines in the builtin "help", especially on usage of the asssembler, pseudo-opcodes etc.
I have a copy of the source code of Ramdos here which i would like to patch (doesn't support the concat command, i'd like to fix that), the code is about ~10.000 lines in hcd65 format, so i don't want to retype it in my preferred assembler's syntax and before i start modifying it i would like to have a little more info about the assembler i will use...

[BigDumbDinosaur]

does anyone have a documentation for the c128 dev. pack that discusses a little more than the few lines in the builtin "help", especially on usage of the asssembler, pseudo-opcodes etc.
I have a copy of the source code of Ramdos here which i would like to patch (doesn't support the concat command, i'd like to fix that), the code is about ~10.000 lines in hcd65 format, so i don't want to retype it in my preferred assembler's syntax and before i start modifying it i would like to have a little more info about the assembler i will use...

Why would you need to "retype it in my preferred assembler's syntax?"  There's only one MOS Technology assembler syntax standard, y'know.  In any case, if you feel the need to rejigger the source code, well, that's what computers are for.  In the UNIX world in which I live, restructuring the source code into something odd like what you apparently want to do would be no big deal.  I'd just run it through sed or awk.

Also, if you have the source code you have the list of pseudo-ops supported by the assembler and what they do.  At about 10,000 lines, that's not too much code through which to read.  It'll give you something to do while seated in the bathroom.

[BigDumbDinosaur]

Grabbed this and installed it tonight. I'm excited about just having it. I don't know if there are better tools out there than this, but it's great to have them just to see what the initial developers for the C128 had to work with.

Thanks!

The HCD65 assembler was actually pretty good, although not particularly fast on long programs (it took about 16 hours to assemble a major project of mine with close to 100K of source lines).  In 1988, Fred Bowen sent me the source code for it and I rewrote parts of it to optimize disk access on the Lt. Kernal.  That substantially speeded up the file handling part but did nothing to enhance compute-bound performance.  I seem to recall that I had identified a bottleneck in the code that managed the symbol table but never did anything about it.  I had too much to do at the time and tinkering with an assembler wasn't on the list.  In any case, there are limits to what eight bits at 2 MHz can do...

[hannenz]

does anyone have a documentation for the c128 dev. pack that discusses a little more than the few lines in the builtin "help", especially on usage of the asssembler, pseudo-opcodes etc.
I have a copy of the source code of Ramdos here which i would like to patch (doesn't support the concat command, i'd like to fix that), the code is about ~10.000 lines in hcd65 format, so i don't want to retype it in my preferred assembler's syntax and before i start modifying it i would like to have a little more info about the assembler i will use...

Why would you need to "retype it in my preferred assembler's syntax?" 

because "my preferred assembler won't understand lines like...

Code Select Expand


error .macro %n,%s,%a,%b,%c,%d
%s = %n
.ifb <%d>
.ifb <%c>
.ifb <%b>
.byte %n,"%a",0
.else
.byte %n,"%a %b",0
.endif
.else
.byte %n,"%a %b %c",0
.endif
.else
.byte %n,"%a %b %c %d",0
.endif
.endm

just as a small example

There's only one MOS Technology assembler syntax standard, y'know. 

Yes, I know. But thats true for syntax on ML/ Opcode/ Mnemonic level, not on assembler level; you know each assembler has its own pseudo-ops, ways of handling symbols, macros and the like...
and i know of what i speak, since i have written assemblers on my own, y'know...

In any case, if you feel the need to rejigger the source code, well, that's what computers are for.  In the UNIX world in which I live, restructuring the source code into something odd like what you apparently want to do would be no big deal.  I'd just run it through sed or awk.

well, that's a good idea, i agree (being a Linux user); but sed or awk can't tell me how hcd65 handles macro calls. but you are right that retyping would be a really bad idea when having the right tools at hand; i did never even think about typing one line by hand, i just wanted to give the point when i talked about "retyping".

Also, if you have the source code you have the list of pseudo-ops supported by the assembler and what they do. 

i don't get you here... could you please tell me what you mean??! if i had the list of pseudo-opcodes, i wouldn't have asked, y'know...

At about 10,000 lines, that's not too much code through which to read.  It'll give you something to do while seated in the bathroom.

yeeah, that's right indeed, maybe i should take a little bath right now
but seriously: no chance of having some docs about hcd65?! to make the patch i would like to understand the original code as good as possible, and that's an easier task, if having the right docs at hand instead of figuring out all that sometimes quite unusual syntax; i'll give you some more examples of lines which i can hardly follow without knowing exactly what the assembler does:

Code Select Expand

.subttl "READ BYTE"

Code Select Expand

com_def .macro %c,%r
.byte %c
.dbyte %r-1
.endm
;
commands
com_def 'S',scratch_command
com_def 'R',rename_command
com_def 'C',copy_command
com_def 'N',new_command ;<4.1 fab>
com_def 'M',m_command ; m-w,m-r ( used only for dev change )
com_def 'I',init_command
com_def 'U',u_command
com_def 'V',validate_command
.ifdef rel_flag
com_def 'P',position_command
.endif
.byte 0
ok, the most things i don't understand seem to concern the different macros, the original authour has setup. the unnamed labels in "10$"-syntax, i have found out by myself, too.
nevertheless, if someone knows a source of some docs, i'd appreciate to have a look at it. if not, i'll make my way anyway, but it could save me from haemorrhoids staying to long in the bathroom
thanks in advance.

[hydrophilic]

I don't have a list of psudo ops, but the syntax seems very similar to the CBM Assembler for the C64.  Based on that I will make an educated guess.  For example,

Code Select Expand

com_def 'S',scratch_command
should assemble to

Code Select Expand

.byte $53, $C0, $7F
assuming that 'scratch_command' assembles to $C080.

If the com_def macro was changed to

Code Select Expand

com_def .macro %c,%r
.byte %c
.word %r-1
.endm

Then it would assemble instead to

Code Select Expand

.byte $53, $7F, $C0
still assuming that 'scratch_command' = $C080.

And I think

Code Select Expand

.subttl "READ BYTE" is only for printed listing of a file (Subtitle).

I hope this helps.

Edit
Here is a list of directives from C64 Assembler.  I know it is not the same as HCD65 but maybe it will help until some real docs are found.

.BYTE generates one for each argument seperated by commas or a sequence of bytes for a string enclosed in single quotes.  Examples
.BYTE 1, $F, @3, %101, 7
.BYTE 'ABCDE'
.WORD is used to reserve and set a 16-bit value (two bytes).  Any expression except strings may be used.  The 16-bit value is stored low byte first.
.DBYTE is used to reserve and set a 16-bit value (two bytes).  Any expression except strings may be used.  The 16-bit value is stored high byte first.
Equal(=) is the EQUATE directive and is used to reserve memory, set the program counter, or assign a value. Examples
HERE *=*+1 ;reserve one byte
* = $200 ;set program counter
MB = NB + %101 ;assign value
.PAGE is used to cause an immediate jump to the top of page on the output listing or reset the title printed at the top of the output listing.  Examples
.PAGE 'THIS IS A TITLE'
.PAGE
.SKIP is used to generate blank lines in a listing.  Examples
.SKIP 2 ;skip two blank lines
.SKIP ;skip one line
.OPT is used to control the output fields, listings, and expansion of strings.  The options available are ERRORS, NOERRORS; LIST, NOLIST; GENERATE, NOGENERATE.
ERRORS, NOERRORS: used to control creation of seperate error file
LIST, NOLIST: used to control generation of listing file
GENERATE, NOGENERATE: used to control listing of strings in .BYTE directive.  The first two characters will always be printed, and subsequent characters will be printed if GENERATE is used.
Default setting is
.OPT LIST, ERRORS, NOGENERATE
.END should be the last directive in a file but is optional
.LIB allows the inclusion of a source file.  Processing of the original source file resumes when .END or EOF is encountered in the named file.  A file called by .LIB may not contain another .LIB but may contain a .FIL
.FIL can be used to link another file during assembly.  It terminates assembly of the file containing it and transfers source reading to the file named.  There are no restrictions on the number of files that may be linke with .FIL but caution should be used to avoid circular references.

And then we get to macros.  The syntax seems to differ in this regard.  On the C64 Assembler the syntax is
(label) .MACRO macroname param1, param2, ...
text of macro
.MND

It looks like HCD65 uses
macroname .MACRO param1, param2, ...
text of macro
.ENDM

And C64 Assembler doesn't support conditional directives like .IF, .ELSE, etc.
/Edit

[hannenz]

i thank you very much for this information

[BigDumbDinosaur]

As I said, the HCD assembler supports the standard MOS rules, including macros, etc.  I don't like most of these alternative assemblers because it's apparent their authors knew little or nothing about MOS standards.  How typical in the Commodore world.

Anyhow, in the HCD assembler, local labels within a subroutine take the form N$, where N is an integer, such as 10$, 20$.  Local labels are bounded by standard labels, e.g.:

Code Select Expand

SPRNT   STX PTR
        STY PTR+1
        LDY #0
10$     LDA (PTR),Y
        BEQ 20$
        JSR BSOUT
        INY
        BNE 10$
20$     RTS
;
SOUT   ...start of new routine...

The 10$, 20$ sequence ends at SOUT and subsequent usage of the same local label names is without regard to the previous usage.

[BigDumbDinosaur]

Also, if you have the source code you have the list of pseudo-ops supported by the assembler and what they do.

i don't get you here... could you please tell me what you mean??! if i had the list of pseudo-opcodes, i wouldn't have asked, y'know...

<Smile>  The instructions needed to implement the pseudo-ops are part of the source code itself, right?  Therefore, reading the HCD assembler's source code will tell you what those pseudo-ops are and what they do.  I seem to recall that Hedley Davis (the assembler's author) was fairly generous with his comments.  In any case, the HCD assembler supports all of the pseudo-ops and macro functions that were supported in the C-64 MADS package (plus conditional assembly), which was fully MOS-compliant.  Try not to spend too much time on the toilet with it.  <Grin>

[nikoniko]

He said he had the source to RAMDOS, not the HCD65 assembler, and I doubt Fred Bowen is still fulfilling requests for source code.

Sorting through a raw disassembly of HCD may be illuminating, but if he has to share his toilet I imagine it might require a few trips.

[BigDumbDinosaur]

He said he had the source to RAMDOS, not the HCD65 assembler, and I doubt Fred Bowen is still fulfilling requests for source code.

Sorting through a raw disassembly of HCD may be illuminating, but if he has to share his toilet I imagine it might require a few trips.

My apologies.  I thought he said he had the HCD65 source code.  Guess my vision is fading like my hairline.  You're right.  His butt would be incredibly sore by the time he had read through a raw disassembly.  Heck, my hemorrhoids would be swollen to basketball size if I did that.  <Grin>

[hannenz]

that's true, i don't have the hdc sources at hand, and now i know what you meant (and you know what i meant, too), good to know that we are on the same level now.
i must admit, i semm not to know too much about the MOS standard, shame on me. i thought it just covers the spelling of the mnemonics and addressmodes, LDA ($xx),Y for example, but didn't know that it covers macros and higher level assembler syntax as well. I'll do my homework and start off google right after i have finished these lines.
Thanks for the comments on unnamed labels, now things start to get more and more clear

ah, one other thing: i had a funny experience last night. As i said i have the source code of RAMDOS, (which is -  ilooked it up again, i exaggerated, 6000 lines, not 10000) in one big file which is ~ 420 disk blocks long. I copied it onto a 1582 disk along with the hcd compiler to try to assemble it on the real machine. It didn't work because there seem to be a bunch of crap characters at the end of the source, so i stated the editor and - not thinking too much - tried to load the source file, which of course ended up with a "insufficient memory error", well, right. i see that it is not possible to load ~100 K into 64K memory, but so i had to think: i believe that the developpers of RAMDOS used a c128 too and i think they used the DevKit (not sure, just a guess), so how did they do it?? Were there everela source files joined up to this one large ? the code looks like "in one flow", don't think so... or has the editor some feature to use more than one RAM bank?? or did they simply use another editor...??!
that little exp. leads me to another question: is there (yes, i ask again ) a documentation on the EDITOR?? i found out that it resembles the DEC EDT, and a quick google research brought me to even find out how to load something into the editor, but again: some more info would be cool. I can't believe that there is no secondary information available to such a sophisticated development environment, like the c128 DevPack. There must have been some docs coming with the package right back then...?!

[bacon]

AFAIK Commodore used a cross-assembler on a VAX. The DevKit was made to work like and use the same source code format as the VAX cross-assembler but it was not used internally at Commodore; it was meant for outside C128 developers who didn't have access to a large computer. So RAMDOS was most likely developed on the VAX just like the C128 KERNAL, which would explain the size of the file.

[hannenz]

aaaah. that's one thing i ever wanted to know: "how did they do it"... i've just read the wiki page of "VAX", it's very interesting! (seems to be a powerful "little" beasty...)

[airship]

I actually saw the VAX room when INFO Senior Editor Tom Malcom and I visited Commodore in West Chester. I remember it as dark, lit only by monitor screens, with sitar music playing quietly in the background. But I admit I may have romanticized that memory over the years. Bryce Nesbitt and Dave Haynie were there.

On the same visit, Henri Rubin demonstrated his Amiga 3000 for us, pulling down separate screens running AmigaDOS, Unix, and MS-DOS (on a Bridgeboard). It was the coolest computer-related thing I have ever seen.

[hannenz]

yeeeeeeeeah. i believe.