Path: utzoo!mnetor!uunet!husc6!hao!gatech!mcnc!rutgers!mtune!codas!killer!elg From: elg@killer.UUCP (Eric Green) Newsgroups: comp.sys.cbm Subject: Re: Good C64 Assemblers Needed Message-ID: <2668@killer.UUCP> Date: 5 Jan 88 08:15:13 GMT References: <3079@cbmvax.UUCP> Organization: Bayou Telecommunications Lines: 65 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.