pete@umbc3.UMD.EDU (Pete Hsi ) (12/23/87)
Hello! I am in search of a good C64 assembler package and am soliciting for your reviews of such. In particular, I am looking at the _Commodore_64_Macro_Assembler_Develpment_ System_. Any others? Tell me what you use, have used, good/bad points, features, or anything else you feel is relevant. Thanks in advance --Pete ARPA: pete@umbc3.umd.edu Bitnet: pete@umbc
seven@nuchat.UUCP (David Paulsen) (12/27/87)
In article <650@umbc3.UMD.EDU>, pete@umbc3.UMD.EDU (Pete Hsi ) writes: > I am in search of a good C64 assembler package and am soliciting for your > reviews of such. > > In particular, I am looking at the _Commodore_64_Macro_Assembler_Develpment_ > System_. I've used the CBM MAE since I first heard of it, about 1983. In four+ years I've used Merlin, French Silk, and the Symass assembler from Transactor, but have always come back to the Commodore Assembler system. Why? 1. It's disk based. This is probably the #1 feature, the big reason to go out and buy it. You can assemble files to go ANYWHERE in memory, not just where your assembler/editor ain't. 2. It reads standard SEQ files. I can create source code using just about any of my word processors, the editor it comes with, Sysres, or source files I've downloaded off bulletin boards. 3. The format isn't wierd. It conforms to standards set back in the mid 70's when the CBM MAE and PAL were real big for the Commodore PET/8032 computers. You're not restricted in what your source code looks like (i.e. there's no fixed "label", "opcode", "operand", and "comment" fields.. The assembler won't go nuts if you left-justify all your code. 4. It'll handle hex, decimal, octal and binary. Pretty standard, but some assmblers restrict you to hex only. Plus it'll do arithmetic calculations. 5. You can link source files together. Your source can be as big as your disk drive permits. Now, the bad things: 1. It's disk based. SLOW, if you've got a 1541 as your primary drive. However, it's extremely friendly towards disk drives; I've never found one it wouldn't work with from the 4040 I use to the wierd after market hard drive my friend uses. 2. There's something wrong with the macro functions. At least, I tried to use them four years ago and gave up after severely mangling my code a few times. I've been substituting the .LIB function ever since, with no problems. 3. There's undocumented "features" galore... the syntax for chaining files is not the way it's printed in the manual, though it's close. .LIB works, but again is not documented correctly. All in all, it's the most flexible assembler I've ever used... and I daresay the cheapest. Safeway Superstores around where I used to live were blowing them out last year for $9.95. You know, getting rid of "that awful Commodore software!" :-) I paid almost fifty bucks for mine back in '83. I'm fortunate enough to have a copy of an upgraded version of CBM/MAE by Commodore of Canada that provides for longer-than-eight-character labels, and puts the object code directly on your disk without having to go thru the after-loader. I've also got some pretty fancy editors, but the one that comes with the MAE development kit is quite good. > > Thanks in advance > --Pete > ARPA: pete@umbc3.umd.edu > Bitnet: pete@umbc -- David Paulsen - CHARTER MEMBER, WILLIAM WINDOM FAN CLUB ..uunet!nuchat!seven "It had a maw that could swallow a DOZEN starships!" --Commodore Matt Decker, chewing on the scenery again
hedley@cbmvax.UUCP (Hedley Davis) (12/29/87)
In article <493@nuchat.UUCP> seven@nuchat.UUCP (David Paulsen) writes: >In article <650@umbc3.UMD.EDU>, pete@umbc3.UMD.EDU (Pete Hsi ) writes: >> I am in search of a good C64 assembler package and am soliciting for your >> reviews of such. >> >> In particular, I am looking at the _Commodore_64_Macro_Assembler_Develpment_ >> System_. > One thing to note: There is a new product for the C128 called the DEVPACK. It has, amoungst other things, a new assembler, editor, and many other tools. This is for the C128 only, but we beleive that the C128 is a preferable machine to develope software on if for no other reason than the fact that it has an 80 column screen. The assembler on the DEVPACK is very solid. Its been beta tested thoroughly, and we use it in house from time to time. One other comment: As the assembler is disk based, it is disk intensive. One thing that really helps is the 1750 REU with a resident RAMDOS. Copy your source files to ramdisk, and the sucker will really fly. Hedley
seven@nuchat.UUCP (David Paulsen) (01/02/88)
In article <3043@cbmvax.UUCP>, hedley@cbmvax.UUCP (Hedley Davis) writes: >In article <493@nuchat.UUCP> seven@nuchat.UUCP (David Paulsen) writes: ->In article <650@umbc3.UMD.EDU>, pete@umbc3.UMD.EDU (Pete Hsi ) writes: ->> I am in search of a good C64 assembler package and am soliciting for your ->> reviews of such. ->> ->> In particular, I am looking at the _Commodore_64_Macro_Assembler_Develpment_ ->> System_. > As the assembler is disk based, it is disk intensive. One > thing that really helps is the 1750 REU with a resident RAMDOS. > Copy your source files to ramdisk, and the sucker will really fly. > Hedley Sounds great... I'd really like to do this with my 1700, but I don't have a copy of RAMDOS yet! (As Sam Kinison would say: "Ohhhhh OHHHHHHHHHHHHHHH!!!") Since I'm not fortunate enough to have DEVPACK yet, I'm still using my Commodore _Macro Assembler Editor_ to write stuff for the 128, which is a total hassle. Seems like I'm ALWAYS rebooting my machine & nuking my programming environment. Does RAMDOS come with a version for the 64 side of my 128 so that I can run the CBM/MAE at high-speed. That would definitely ease the pain a bit... -- David Paulsen - CHARTER MEMBER, WILLIAM WINDOM FAN CLUB ..uunet!nuchat!seven "It had a maw that could swallow a DOZEN starships!" --Commodore Matt Decker, chewing on the scenery again
elg@killer.UUCP (Eric Green) (01/04/88)
in article <500@nuchat.UUCP>, seven@nuchat.UUCP (David Paulsen) says: > In article <3043@cbmvax.UUCP>, hedley@cbmvax.UUCP (Hedley Davis) writes: >>In article <493@nuchat.UUCP> seven@nuchat.UUCP (David Paulsen) writes: > ->In article <650@umbc3.UMD.EDU>, pete@umbc3.UMD.EDU (Pete Hsi ) writes: > ->> I am in search of a good C64 assembler package and am soliciting for your > ->> reviews of such. >> thing that really helps is the 1750 REU with a resident RAMDOS. >> Copy your source files to ramdisk, and the sucker will really fly. Hedley mentiones the DEVpack. Has it been released? If so, my check is in the mail.... The RAMdisk driver appears to be fairly slow for sequential text I/O, apparently because it has to flop the entire 8K(?) RAMdos into memory for each call to chrin or chrout. I get better performance with a SFD-1001 with any decent IEEE card (or even not-so-decent ones like the Skyles IEEE-Flash, an excercise in overpriced cheapness -- an EPROM, a PIA, and a couple of popcorn TTL). I get about the exact same performance with a 1571 or 1581. What the RAMdisk driver IS good for, is loading. Since this is only a single Kernal call, the RAMdos only has to be swapped in once, and kazoom, instant loading. I copy my assembler, editor, linker, and other utilities to my 1750, off of a boot disk, then shove my source disk into the 1571 and hack away. There's also other inanities with the RAMdos... for example, if your program crashes and you must reboot, and there was a file open on the 1750, that file is gone, kapoof. Very irritating if that file was your latest source code, and the reason it was open, was that your assembler was reading it and somehow ended up in never-never land. For my assembler, I'm currently using CASM 2.1 (as posted to the net eons ago), using the Spinnaker Power-C/128 package (Proline's C-Power/128 repackaged). It is a bit slow, even with the speedups I've made to it (great having the sources, huh?). Takes a couple of minutes to compile a 1,000 line file. I recently fired up my old Commodore Macro Assembler to create some patches for an existing program, and it was so much faster as to be ridiculous... but, when you're up to REAL projects, 5K lines, 10K lines, or ore, no way are you going to assemble the whole thing all at once whenever you make a trivial bug fix... we're talking about 5 minutes per 5K, even with the fastest C-64 drives (8050's with IEEE-Flash). Waiting a couple of minutes, then spending 30 seconds linking the object files together, is much more effective under such circumstances. Here's how to use the RAMdisk with C-Power/128: monitor l "shell2",08 a 1528 nop a 1529 nop a 152a nop s "shell3",08,1400,31a4 The above nop's out the part of the initialization which changes the i/o vectors to Power-C's own i/o routines (which, amongst other things, handles their own RAMDISK driver, which doesn't know about the 1750, alas). The only problem is that the Commodore RAMdisk driver gets blasted out of memory whenever you hit run/stop-restore. With a 1571, that's no real problem... I have both the RAMdisk driver and shell/shell3 on my workdisk, so I can just "bye" and reboot in seconds. One of these days, I'll have to track that down and fix it, too. The motivation just isn't there, though... since I'm only using C-Power as an environment to run my assembler from, I haven't had much opportunity to hit run/stop-restore. Then change the program "shell": 1 graphic clr : rem otherwise, shell3 overloads it, due to RAMdisk driver and where it says "shell2", change that to "shell3". If you've ever done "C" development with C-Power, one of the irritances is the amount of time it takes to link in the library, at least, off of a 1571 or SFD-1001 or other "traditional" Commodore drive (the 1581, with its full-track buffer, should be faster). This is due to the amount of time it takes for the drive to search through all those directory sectors, sequentially, looking for all those itsy bitsy library files, and the seek time as the head grinds back and forth between the directory track and file tracks. I libraried together all those itsy bitsy files with Library-128. Then, when I want to do "C"-work, I unlibrary them onto the RAMdisk -- Library works at least as fast as Fred's copy program, and the 1571 doesn't grind back and forth as described above, since it's all one file. Linking off the RAMdisk is pretty quick... it still takes a few seconds, but compared to all that grinding, it's a dream (that's one of the reasons I have the 1750 on my 128, instead of the IEEE-Flash/SFD-1001 combo I had before). After all, RAM has no seek time :-). > Sounds great... I'd really like to do this with my 1700, but I don't have a > copy of RAMDOS yet! (As Sam Kinison would say: "Ohhhhh OHHHHHHHHHHHHHHH!!!") I downloaded my copy from GENIE. > Since I'm not fortunate enough to have DEVPACK yet, I'm still using my Commodore > _Macro Assembler Editor_ to write stuff for the 128, which is a total hassle. > Seems like I'm ALWAYS rebooting my machine & nuking my programming environment. > Does RAMDOS come with a version for the 64 side of my 128 so that I can run > the CBM/MAE at high-speed. That would definitely ease the pain a bit... There IS a 64 version, apparently, but I didn't find it on GENIE. Maybe I should try Q-Link (which I haven't used much, since they raised their rates to about the same as GENIE's). I solve the reboot hassle simply by having two machines :-}. Because I'm doing the opposite -- developing on the C-128, for the C-64. Is ANYBODY fortunate enough to have DEVPACK yet? I WANT IT!!! If anybody can tell me how to get it, you'll have my eternal gratitude... too bad a gumbo doesn't keep too well when shipped via UPS, or you'd have more than that :-). URGH.... 100 line tomes are SOOO long... -- Eric Lee Green elg@usl.CSNET Snail Mail P.O. Box 92191 {cbosgd,ihnp4}!killer!elg Lafayette, LA 70509 "There's someone in my head, but it's not me...." -PF
hedley@cbmvax.UUCP (Hedley Davis) (01/05/88)
In article <2650@killer.UUCP> elg@killer.UUCP (Eric Green) writes: > >The RAMdisk driver appears to be fairly slow for sequential text I/O, >apparently because it has to flop the entire 8K(?) RAMdos into memory for each >call to chrin or chrout. Ouch. Well almost. When reading or writing a file with no other disk accesses in between ( like checks of error channel or other accessing other files or commands ), the RAMDOS actually only has to setup a single byte access per call to CHRIN/CHROUT. Every 256 of these fast accesses it has to do the swap to set up the next page. The CHRIN call, in the case of no chkout, and the page is set properly, takes 137 clock cycles ( I just measured it ). This is pretty puny. The first version did do a full swap per byte, but considering that the DOS is 8K, and you have to swap twice per call, and each swap moves 8 K in and 8 K out yeilding 32K bytes of movement per call. The fastest you could do that on a C64 would be about 30 times a second. >I get about the exact same performance with a 1571 or 1581. You must be kidding. I don't know how you write code, but I tend to use several small files as opposed to one big one for source. This tends to keep things modualar, not to mention speeding up the load/edit/write cycle considerably. Also, using devpack, the source files all end up at the end of the directory. Try writing a program to just open and close 5 files at the end of a 30 file diskette. Run it on both. The RAMDOS doesn't really spend alot of time banging its head around trying to find the file. ( Its alot faster ). We've assembled BASIC for the C128 using the DEVPACK. Basic has two 1571 diskettes of source code in about 138 files. This takes about 3 hours from diskette. Once loaded into the RAMDISK, it takes about 40 minutes. Note that this leaves lots of time to copy the files to the ramdisk. Hedley
elg@killer.UUCP (Eric Green) (01/05/88)
in article <3079@cbmvax.UUCP>, hedley@cbmvax.UUCP (Hedley Davis) says: > In article <2650@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >>The RAMdisk driver appears to be fairly slow for sequential text I/O, > > Ouch. Well almost. [...] The CHRIN call, > in the case of no chkout, and the page is set properly, takes 137 clock > cycles ( I just measured it ). This is pretty puny. CASM isn't so well behaved. It inputs a line, processes it, prints it to screen (if so desired), writes the object code to disk for that line (depending on pass flags, etc.). Alas. Wish I had a DEVpack :-}. All in all, I think that the RAMdos is written about as well as it could be, considering the machine it runs on :-}. The only problem I have with it is the open-file error... quite irritating when a file opened for READ is zapped by a validate command, when such doesn't happen on a 1571 or 1581. Especially irritating when that file is my latest source. >>I get about the exact same performance with a 1571 or 1581. On READS. On a Commodore 128, 1571, with maybe 20-25 files on the disk. WRITES are much faster than a 1571. LOADS, there's no comparison... I type "as", and presto, 30K gets pulled off 1750 into RAM faster than I can say "voila!". Thinking about it, I probably WOULD save time by copying my stuff to RAMdisk. In the short run. Probably give me ulcers, in the long run... I don't have a UPS (Uninterruptable Power Supply), plus, if it starts assembling and I decide I don't want to do that anymore (remembered something else, for example), I have a bad habit of hitting the reset button and letting my autoboot set the RAMdisk back up etc... which would zap my input file. > You must be kidding. I don't know how you write code, but I tend to use > several small files as opposed to one big one for source. Well, it varies. "toolbox" routines are usually small files, e.g. a generic block-move subroutine. But there's some routines that simply don't make much sense split up into smaller files... e.g. the C-128 disk routines end up at about 1300 lines of assembler (quick look at the Abacus disassembly). For another example, in one of my past programs, output was sent to a print-a-line routine, which sent it to a print-a-character routine, which analyzed it and did expansions when appropriate, calling the appropriate routine... that ended up at just a tad over 1200 lines. Splitting it into multiple files would have been ridiculous, because things such as "are we at beginning or end of line" and other state-related questions were of relevance. Also, keeping track of a jillion tiny files becomes a pain when you don't have a "make" routine. > the end of the directory. Try writing a program to just open and close > 5 files at the end of a 30 file diskette. Agree. That's why I put my C-Power library in RAMdisk. IT consists of about a HUNDRED tiny files.... talk about an amazing speedup! But othrwise... well, I usually just change one file at a time, and then link it with all the other objects. The amount of time to link together objects is pretty tiny unless you're writing a mega-epic. > We've assembled BASIC for the C128 using the DEVPACK. Basic has I was off the net for about 2 weeks. Have I missed something? Has the elusive DEVPACK been released? Has it even been ANNOUNCED? Prices set? Ordering information given? What the heck is going on with this elusive DEVPACK???? -- Eric Lee Green elg@usl.CSNET Asimov Cocktail,n., A verbal bomb {cbosgd,ihnp4}!killer!elg detonated by the mention of any Snail Mail P.O. Box 92191 subject, resulting in an explosion Lafayette, LA 70509 of at least 5,000 words.