Favourite assemblers?
Larry Anderson & Diane Hare
Colin Ward wrote:
>
> Hi all...
>
> Years ago I used to use Speedy Assembler, which was written and sold by
> "Your Commodore" magazine. It was very good but unfortunately, took up
> *way* too much memory. I've recently started using Turbo Assembler. What
> is the assembler of choice these days, not including cross assemblers?
>
>
Being in the US, I've never heard of Speedy Assembler, but what I've
used have been pretty good.
Started out with SuperMon which is a very basic code-on-the-fly
assembler, it's greeat for quick work and it is part of alot of freezer
carts. As far as assembler/editors I got Lew Lasher's EA
(Editor/Assembler) off of Quantum Link, still a great program, written
back in 85, you code on a word processor like area and then save your
text and activate the assembler portion to assemble the file, produces
very readable code has labels, etc. After that I went to Merlin 128
(produced by Roger Wagner Publishing), same format like EA but you can
assemble from the stuff in memory, it had a better (faster and in 80
columns!) text editor, macro libraries, and a whole slew of stuff I've
never used! I still have and use all three now and again depends on the
computer (64, 128, PET, VIC, Plus/4, etc) and the project I'm working
on.
Never liked the BASIC type ones (like PAL or BUDDY) line numbers and
colon separators (to concatenate commands) make the code more
unreadable.
Larry Anderson
Todd S. Elliott
Colin Ward wrote:
> Years ago I used to use Speedy Assembler, which was written and sold by
> "Your Commodore" magazine. It was very good but unfortunately, took up
> *way* too much memory. I've recently started using Turbo Assembler. What
> is the assembler of choice these days, not including cross assemblers?
>
people who select that particular assembler work on it totally in
exlcusion of other assemblers and begin to develop a relationship. "My
Buddy," I would often caress, trying to coax some kick-butt code. :)
A little of history is in order: My first assembler was the Simple
Assembler produced by Richard Mansfield in the First Book of Machine
Language. It was decent, but very limited. Then I got LADS, also by
Richard Mansfield. That was better. The assembler was small, and I could
make coresident programs for the purposes of debugging, etc. The
disadvantage is that I had to use the BASIC editor, and create a BASIC
program of assembly code. Another disadvantage is that it did not have
temporary labels. It was THE assembler for me during my early computing
years from 1985 to 1992. I've dabbled in an another assembler during
that time, the FAST assembler, written by Yves Han in Gazette. Sadly, it
did not live up to its name and was of limited value.
Sometime in 1993, I was exposed to Buddy. Needless to say, we became
fast buddies. :) Ok, enough puns for now. Buddy has significant
advantages; One, it has a separate editor, and is output in plain
PETASCII, which I can translate into ASCII and print out on my inkjet
printer or other IBM compatible printers for crisp output. Two, it is in
80 columns. Very nice feature, indeed. The editor is nearly complete,
with provisions for search/replace, block copy/cut/paste, etc. Last, it
had temporary labels (-, +, /) which ultimately led me to divorce LADS
now and forever. :)
There is a Turbo Assembler, which I've tried once or twice. It didn't
impress me too much, mainly because it ran in 64 mode. But I do know
that the current coders' camp is divided into two: The U.S. coders, a
vast majority of them use Buddy 64/128, while the Euro coders, the vast
majority of them use TurboAss. There is a significant disadvantage when
it comes to using Turboass. (IMHO, of course.) It does not use standard
PETASCII for the users' source code files. Rather, it uses some
tokenized variant, and this reduces the porability of the code to other
platforms for later editing or printing. I'm sure users have already
figured out workaround solutions for this, but nothing can beat the
simplicity of Buddy's built-in PETASCII format.
In short, you tread in deep waters, fellow coder... Some impassioned
loyaties to a particular assembler is perfectly rational. :)
-Todd Elliott
Colin Ward
Hi all...
Years ago I used to use Speedy Assembler, which was written and sold by
"Your Commodore" magazine. It was very good but unfortunately, took up
*way* too much memory. I've recently started using Turbo Assembler. What
is the assembler of choice these days, not including cross assemblers?
I posted something like this yesterday but I think that my crappy
newsreader stuffed up, so excuse it if it pops up somewhere later...
/----------------------------------------------------------------------\
[Hitman/Code HQ - 6502/68000/80386 & now 65816 (16 bit 6502!) ]
[Assembly Lover since 1987! Proud member of Team AMIGA ]
[OS coding/Hardware hitting/Demos/Games/Modules - c64, Amiga & PC ]
[I'm a pogrammar.. I'm a programor... I'm a progemmar... I write code. ]
\----------------------------------------------------------------------/
Jason Compton
Larry Anderson & Diane Hare (foxn...@goldrush.com) wrote:
: Never liked the BASIC type ones (like PAL or BUDDY) line numbers and
: colon separators (to concatenate commands) make the code more
: unreadable.
ED-Buddy works in an editor rather than BASIC, and you're not REQUIRED to
use colon separators, it's just an option if you want to tightly pack a
certain stock routine into a single line...
--
Jason Compton jcom...@xnet.com
Editor-in-Chief, Amiga Report Magazine (847) 741-0689 FAX
AR on Aminet - docs/mags/ar???.lha WWW - http://www.cucug.org/ar/
The sands of time were eroded by... the river of constant change.
Tony Postmayer
> Years ago I used to use Speedy Assembler, which was written and sold by
>"Your Commodore" magazine. It was very good but unfortunately, took up
>*way* too much memory. I've recently started using Turbo Assembler. What
>is the assembler of choice these days, not including cross assemblers?
I don't really know what's going on these days. When I used to do
Commodore development I worked just about exclusively on the 64/1541
using an assembler called PAL. It had some features that I thought
were pretty handy. It's been out of production for some years now,
however. And it does not run in 128 mode, only 64.
PAL becomes memory resident, taking up about 4k or 5k. It's source
files are saved in the BASIC format, which lets you use your favorite
BASIC editor (such as SYSRES) to work on the source. It will assemble
directly to memory. This really speeds up the development process for
small to medium sized projects since everything can be co-resident in
the 64k machine - assembler, editor, source, and object.
Well, that's my story. I expect you'll get a similar one about every
other assembler that's ever been programmed. They seem to be the kind
of tool that one gets attached to, to the exclusion of all else.
Tony -
Niclas Karlsson MATE
"Todd S. Elliott" <ey...@erols.com> writes:
>There is a Turbo Assembler, which I've tried once or twice. It didn't
>impress me too much, mainly because it ran in 64 mode.
Well, Turbo Assembler is definitely the assembler of choise for me :-)
Fact is, though, that I've only made a few things with it (a huge-char
dycp comes to mind ;-) since most of my productive work was done on the
built-in monitor of my trusty old Power Cartridge. :-) Admittedly the
code was somewhat unstructured, but then who cared at the time :-)
Nicke
--
<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>
<_>-<_> Niclas Karlsson <_> What's the use of Magic <_>-<_>-<_>
<_>-<_> EMail: nkar...@aton.abo.fi <_> If it can't save a Unicorn <_>-<_>
<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>-<_>
Mike Neus
In article <3324B2...@goldrush.com>, foxn...@goldrush.com says...
>
>Colin Ward wrote:
>
>very readable code has labels, etc. After that I went to Merlin 128
>(produced by Roger Wagner Publishing), same format like EA but you can
>assemble from the stuff in memory, it had a better (faster and in 80
>columns!) text editor, macro libraries, and a whole slew of stuff I've
>never used!
I second the vote for Merlin. Merlin has everything built into one package.
Once it is loaded all features are availible. The linker is quite powerfull
too.
> Never liked the BASIC type ones (like PAL or BUDDY) line numbers and
>colon separators (to concatenate commands) make the code more
>unreadable.
Ditto. Using the BASIC editor is very combersome for entering source code.
You end up with a big mess that is difficult to read and find what you were
looking for. What a pain. I'll never go back after using a dedicated editor
like Merlin's.
Po-Ching Lives!
>*way* too much memory. I've recently started using Turbo Assembler. What
>is the assembler of choice these days, not including cross assemblers?
*I* use a machine language monitor when I write code. Call me crazy,
but I just can't get used to assemblers. I either write BASIC code
and dub it into ML using Diabolo, or straight-up ML in the FastLoad
monitor. (Yeah, I'm strange. :-)
Cameron Kaiser
cka...@ucsd.edu
www.sserv.com
Asger K. Alstrup Nielsen
"Todd S. Elliott" <ey...@erols.com> writes:
>There is a Turbo Assembler, which I've tried once or twice. It didn't
>impress me too much, mainly because it ran in 64 mode. But I do know
>that the current coders' camp is divided into two: The U.S. coders, a
>vast majority of them use Buddy 64/128, while the Euro coders, the vast
>majority of them use TurboAss. There is a significant disadvantage when
>it comes to using Turboass. (IMHO, of course.) It does not use standard
>PETASCII for the users' source code files. Rather, it uses some
>tokenized variant, and this reduces the porability of the code to other
>platforms for later editing or printing. I'm sure users have already
>figured out workaround solutions for this, but nothing can beat the
>simplicity of Buddy's built-in PETASCII format.
I'm from the European camp that advocates TurboAss (TA). The reason for this
lies exactly in the tokenized format. TA preprocesses the input and keeps it
in tokenized format which implies the main advantage that is very important:
Assembly is fast. TA can output and input in PETASCII format natively, so that's no argument
against TA. It can also print natively.
However, TA has several serious disadvantages:
1) Memory footprint. TA basically uses $9000-$ffff + whatever your source
needs (from $8fff downwards) This is not a problem if you have a REU and
use a REU enhanced TA: source in one bank, object code in another. If you
do that, you have a pretty nifty tool (as I did :-).
2) Source code limits. No more than 4096 lines of code (and there is no
#include directive), so big projects are cumbersome at best to do. Well, I
hacked my TA to allow 8192 lines, but that comes at the cost of reduced
memory for other stuff, because TA preallocates a byte for every potential
line of code. And 8192 is not enough for a word processor (as I did :-)
3) Slow loading and saving. Loading and saving is done using byte read and
write, so unless you have some turbo that works at the single byte level
(Dolphin dos or similar parallel system, or JiffyDOS), loading and saving
is very slow (i.e. a normal fast loader/saver won't help one bit).
4) No macro support. A TA version with macros exist. However, the memory
footprint for that version is $8000-$ffff, so half of the memory is
dedicated to TA.
5) No means of making "layout" of your code. All lines are indented the same,
so you can't impose structure on your code by using different indentations.
Looking at those misfeatures, it seems strange that TA is so popular in the
European camp. However, on the plus side, we have several factors that make up
for the defiances (somewhat):
1) Basic still works. It's no problem to write a small basic program if you
happend to need a sinus table. And TA has native commands for converting
such a table in memory to a .byte block.
2) Very good editor. It supports block move, copy, delete, export and import.
In general, it's very fast to use. The F-keys are bound to navigation
commands.
3) Syntax highlighting: Errorneous lines are shown in red as soon as you
leave the line.
4) It's fast.
5) It's relatively easy to hack. I think most serious hackers made their own
version of TA with this or that little feature that was essential to them.
6) It's a standard in the European demo scene.
7) TA (and source code) survives resets. No need to save so often, if you
feel confident that you won't ruin memory (and most hackers are confident
despite several "opps!" experiences :-)
8) Remembers cursor position across resets and saves.
So in short: TA is a dedicated "hackers" assembler: it's fast and suits
the needs for a demo writer exceptionally because the development cycle
is easy:
1) Hack away at the source.
2) Compile and run it with two keypresses (fast, fast).
3) Let your program end with jmp $9000 when you press C= and you are back
in TA at the same point you were before the test run.
4) Go to 1) until program is complete.
No time is wasted with irrelevant things, and it encourages rapid prototyping,
because it's fast to see if the thing works.
However, when it comes to implementing big and modular systems, TA sucks big
time.
>In short, you tread in deep waters, fellow coder... Some impassioned
>loyaties to a particular assembler is perfectly rational. :)
:-)
I think all 6502 hackers wished to have the ideal assembler that had all the
major goods from TA (speed, good integrated editor with highlighting, reset
safety) combined with the goods from a powerful assembly engine with macro and
include support without arbitrary size limits. Many hackers started
implementing such a thing (as did I :-), but nobody succeeded.
Today, it's much more convinient to use a cross-development system. I even
worked on a game 100% pc based: Assembler in one window, emulator in another.
Ironically, that was the ultimate development platform in many ways, because
then you can run a test program and work on the source at the same time,
without moving your hands from the keyboard.
Greets,
Asger Alstrup
Pontus Berg
On Tue, 11 Mar 1997 00:08:57 GMT, co...@leprechaun.com.au (Colin Ward)
wrote:
> Years ago I used to use Speedy Assembler, which was written and sold by
>"Your Commodore" magazine. It was very good but unfortunately, took up
>*way* too much memory. I've recently started using Turbo Assembler. What
>is the assembler of choice these days, not including cross assemblers?
Most people do use some sort of version of the TurboAssembler .
prefereably supporting the REU. There two main versions; the normal one
and the one with macros. If you want the docs which then also includes
the differences between them, I'd suggest you go to my homepage and
press the c64 button ...
Aka: Bacchus of FairLight
Phone/Fax: +46-70-5246010 / +46-70-6126010
URL: http://hem.passagen.se/bacchus
Fido: 2:201/411.71 UIN: 109686
Pontus Berg
On Mon, 10 Mar 1997 23:20:36 -0500, "Todd S. Elliott" <ey...@erols.com>
wrote:
>There is a Turbo Assembler, which I've tried once or twice. It didn't
>impress me too much, mainly because it ran in 64 mode. But I do know
>that the current coders' camp is divided into two: The U.S. coders, a
>vast majority of them use Buddy 64/128, while the Euro coders, the vast
>majority of them use TurboAss.
I agree with this!
>There is a significant disadvantage when
>it comes to using Turboass. (IMHO, of course.) It does not use standard
>PETASCII for the users' source code files. Rather, it uses some
>tokenized variant, and this reduces the porability of the code to other
>platforms for later editing or printing.
Hang on - you totally miss a few things out! It uses it's own format
internally and this format is also saved. The format is "precompiled" as
the mnemonics are saved as they'd be if assembled. You CAN load and save
standard Petscii as well if you want that but the files gets to be some
3x longer!
It of course prints as well directly from the assmbler - I've done that
MANY times! (<- + 4 and then give the questionmark as an option). You
can of course print to file or to screen as well ...
>I'm sure users have already
>figured out workaround solutions for this, but nothing can beat the
>simplicity of Buddy's built-in PETASCII format.
It's coded that way from scratch - plain Petscii is highly limited and a
total waste of space - internally and on disk!
>In short, you tread in deep waters, fellow coder... Some impassioned
>loyaties to a particular assembler is perfectly rational. :)
I strongly agree! The choice of favourite tool is a religion. However -
I'd like the discussion to be made on grounds of facts - not belief! ;-)
XmikeX
"Todd S. Elliot" <ey...@erols.com> said :
>There is a Turbo Assembler, which I've tried once or twice. It didn't
>impress me too much, mainly because it ran in 64 mode. But I do know
>that the current coders' camp is divided into two: The U.S. coders, a
>vast majority of them use Buddy 64/128, while the Euro coders, the vast
>it comes to using Turboass. (IMHO, of course.) It does not use standard
>PETASCII for the users' source code files. Rather, it uses some
>tokenized variant, and this reduces the porability of the code to other
>figured out workaround solutions for this, but nothing can beat the
>simplicity of Buddy's built-in PETASCII format.
Hello Todd,
I'm not sure what sources (pun) you have consulted but in my own personal
experience I have found that the remaining C64 -demo- scene coders (USA,
Canada, Europe, etc) are loyal 'TurboAss' fans. To be sure, it has its
limitations but one of them is NOT the ability to manipulate PETSCII sources.
It can do so quite readily back and forth, r/w SEQ...no prob. If you pick
up the TurboAss REU version released recently by Style you will find a
comprehensive documentation and command summary included within the archive.
(I believe the Style home page has it, follow your friendly neighborhood
CaBoom! lists on Jim Brain's Commodore page).
XmX
Randall W Winchester
In article <5g2goc$m...@flood.xnet.com> jcom...@typhoon.xnet.com (Jason Compton) writes:
>ED-Buddy works in an editor rather than BASIC, and you're not REQUIRED to
>use colon separators, it's just an option if you want to tightly pack a
>certain stock routine into a single line...
My vote goes to EDBUD, the text editor version of Buddy 128. I
started with Lew Lasher's EA. Lew was a Boston Computer Society
member and wrote EA very early on, probably early to mid 1983. It was
a wonderfully fast assembler for the 64. I tried to port it to 128
mode once, but lacking good source code, I finally gave up.
Buddy 128 is a great package though. I wrote all of my KeyDOS code
using it. It's fast, reliable and produces good code.
If coding for GEOS, geoProgrammer is the only way to go! The
geoDebugger is a real eye popping piece of work!
BTW, there are new GEOS downloads on my web page. Stop by for a visit.
Randy
************************************************************************
* Randy Winchester * ra...@mit.edu * PO Box 1074, Cambridge, MA 02142 *
* (617) 253-7431 * http://web.mit.edu/randy/www/antigrav *
************************************************************************
Jason
Colin Ward:
> Years ago I used to use Speedy Assembler, which was written and sold by
> "Your Commodore" magazine. It was very good but unfortunately, took up
> *way* too much memory. I've recently started using Turbo Assembler. What
> is the assembler of choice these days, not including cross assemblers?
Assembler of choice? Well, Turbo is the most commonly used, but personally
I've got Zeus 64 by Crystal Computing. Sort of. I've ripped it apart,
removed the lousy monitor, allowed the Action Replay fastload and DOS
wedge to stay working inside the assembler and added a 2Mhz assembly for
C128 and wrote my own serial transfer tools to allow me to cross assemble
to my C64B should I need it.
It's not the worlds greatest assembler, but I'm still rather fond of it,
I began using it in 1985 and still use it for just about everything in
conjunction with the assembler/monitor in the Action Replay VI pro.
I recently heard that Martin Galway used to use it too... =-)
--
Jason =-)
_______________________________________________________________________
TMR / / / / / / / /\
/ /__/ / / /__/ / / / /__/ Email: t...@cosine.demon.co.uk / /
/ /\_/ / /__ / / / / __// Cosine Homepage: / /
/ /__/ / / / / / / / / / http://www.cosine.demon.co.uk / /
/_____/_____/_____/__/__/__/_____/_____________________________________/ /
\_____\_____\_____\__\__\__\_____\_____________________________________\/
Daniel B
Po-Ching Lives! wrote:
>
> In <5g2b86$1...@reader1.reader.news.ozemail.net> co...@leprechaun.com.au (Colin Ward) writes:
>
> >is the assembler of choice these days, not including cross assemblers?
>
> but I just can't get used to assemblers. I either write BASIC code
> and dub it into ML using Diabolo, or straight-up ML in the FastLoad
> monitor. (Yeah, I'm strange. :-)
I've only used ML monitors when writing my code. There are several
advantages: no memory restrictions and you can test your program
immediately without any waiting. There is only 64k available at the
same time, so there is really no need for assembler. :)
If I had owned a PC or Amiga or similar back then, I would
probably be coding on the PC and running it on the C64.
...if the emulators (preferably CCS64) would include a complete
and c64-invisible machine code monitor, like the ones found in any
of the last cartridges (Expert, AR VI), we would have a perfect
development environment! :)
//D
--
(Anti-bot-campaign) Remove first part of domain for correct email
address.
Stephen Judd
In article <5g2b86$1...@reader1.reader.news.ozemail.net>,
Colin Ward <co...@leprechaun.com.au> wrote:
>
> Hi all...
>
> Years ago I used to use Speedy Assembler, which was written and sold by
>"Your Commodore" magazine. It was very good but unfortunately, took up
>is the assembler of choice these days, not including cross assemblers?
Turbo Assembler is very popular among the demo crowd. Most versions you
will find have been modified by them, and as such it is written around
the needs of demo programmers, for the most part. Turbo has this nice
property that it is free.
Buddy is also popular. It has some nice syntax conventions and has the
nice property that it is available: you can buy it from CMD.
I use Merlin 128. It has a very nice 80-column programming editor and
some very useful features, in particular a linker. This makes efficient
development of enormous programs possible -- I am currently working on
a program that is nearing 400 blocks worth of source code (not source
and data, just source!). It is very difficult to find though (although
I keep hearing this rumor that it is still sold by Roger Wagner Publishing,
*shrug*).
Some people just use an ML monitor. Naturally developing sophisticated
or lengthy programs in such an environment is very difficult, but I certainly
use them from time to time for writing small programs.
Finally, many people use cross-assemblers, but you said not to include
them :).
When you get down to it, though, people generally use the system which
they are comfortable with and which meets their needs. Chances are also
good that their assembler is simply the one they tried first! This
is somewhat emblematic of the 64 community in general, I think (not
much need to upgrade or shop around if the current system comfortably
meets my needs).
In other words, just about any decent assembler will work fine. :)
Good code and programming skill can overcome any assembler (or hardware)
limitation.
-Steve
P.S. Here is my absolutely favorite feature of the Merlin 128 editor: if
you press 'Home' it remembers what line you are on. Later, from
another line, you can press C=-Home and immediately go back to that
line. I can't tell you how often I wish for that key combination
in vi :). The second-most useful feature is that you can search
for label occurences (i.e. a text search limited to the label field).
Pontus Berg
On 11 Mar 1997 22:03:38 GMT, als...@diku.dk (Asger K. Alstrup Nielsen)
wrote:
>I think all 6502 hackers wished to have the ideal assembler that had all the
>major goods from TA (speed, good integrated editor with highlighting, reset
>safety) combined with the goods from a powerful assembly engine with macro and
>include support without arbitrary size limits. Many hackers started
>implementing such a thing (as did I :-), but nobody succeeded.
There are projects going on doing this! Ralph (AKA:Paradroid/Sharks) has
a version of hte macroassembler which uses the REU for source and so on.
It goes up to some 24000 lines, uses the REU for blittering back and
forth. Even the screen updates are done using the REU for faster action.
>Today, it's much more convinient to use a cross-development system. I even
>worked on a game 100% pc based: Assembler in one window, emulator in another.
>Ironically, that was the ultimate development platform in many ways, because
>then you can run a test program and work on the source at the same time,
>without moving your hands from the keyboard.
I still want to be able to port the result to the c64 for real, but I'm
still to find a system I like in the porting part. 64Asm 1.1 is great
and I actually had indications that the last remaining flaws would be
removed in a last effort from the coder. The editor I use, I have
configured with an extensive config file which allows syntax
highlighting for 64ASM mnemonics and pseudoops! The colourmarkings of
TurboAssembler is then rather close!
Pontus Berg
On 12 Mar 1997 01:25:44 GMT, ju...@merle.acns.nwu.edu (Stephen Judd)
wrote:
>When you get down to it, though, people generally use the system which
>they are comfortable with and which meets their needs. Chances are also
>good that their assembler is simply the one they tried first! This
>is somewhat emblematic of the 64 community in general, I think (not
>much need to upgrade or shop around if the current system comfortably
>meets my needs).
I first tried macroFire. Never liked it much but it was better than
monitors - I'll give it that!
>P.S. Here is my absolutely favorite feature of the Merlin 128 editor: if
> you press 'Home' it remembers what line you are on. Later, from
> another line, you can press C=-Home and immediately go back to that
> line. I can't tell you how often I wish for that key combination
> in vi :). The second-most useful feature is that you can search
> for label occurences (i.e. a text search limited to the label field).
I guess we are bound to enter the "Hey, XXX can do that as well" :-)
"<-" + "m" for mark followed by 0-9 and then "<-" + "g" followed by the
bookmark you'd like to go with it. Mind that they are saved with the
file if you save in the original format!
kfer...@aol.com
> Years ago I used to use Speedy Assembler, which was written and >sold by
>"Your Commodore" magazine. It was very good but unfortunately, >took up
>*way* too much memory. I've recently started using Turbo Assembler. > What
>is the assembler of choice these days, not including cross assemblers?
No one has mentioned TSDS, even after Kevin Pickell was
mentioned in the group several weeks back.
Read files off disk into the REU for the first pass, read from REU
on the second pass.
Not the speediest, but worked with a HD (LT Kernel).
It could handle 35000 lines of assembler, about 400K of
source files.
I do miss the days.
Kelly
Radioactive Warrior
Question concerning Turbo Assembler's size ($9000- ).
Could the program be put into a cartridge ROM thus leaving the total
64k RAM free for source code? Anyone have the specifics of absolute
memory locations and what they do?
just wondering,
Radioactive Warrior
Todd S. Elliott
Asger K. Alstrup Nielsen wrote:
> I think all 6502 hackers wished to have the ideal assembler that had all the
> major goods from TA (speed, good integrated editor with highlighting, reset
> safety) combined with the goods from a powerful assembly engine with macro and
> include support without arbitrary size limits. Many hackers started
>
Thanks for the comphrensive summary on Turbo Assembler. It was quite
interesting. It would have been nice if the 'ideal' assembler had these
features:
- REU Support. This includes the entire package surviving a system
reset, i.e., through the Action Replay cart. That way, quick
prototyping can be done, over and over until the bugs are worked out.
- 80 Column Editor w/ cut/paste, search/replace, standard editor stuff,
etc. Maybe syntax highlighting would be nice, as well as identing.
- Memory/disk assembling, as well as multiple source file assembling.
Include multiple disk support. (i.e., read input source at device 9,
and output the object files into device 10 or whatever.)
- Symbol table management.
- Macro support. (I've never been a fan of macros, but some
well-designed ones could merit my consideration, and they are just
invaluable in GEOS programming.)
- Incremental linker. This is very handy for large projects.
- Usual goodies for pseudo ops, i.e., temporary labels, conditional
assembly, etc.
- Option for ASCII output for cross-platform file management.
- Allows creation of hybrid BASIC/ML programs. i.e., 10 sys(2099) ML
code starts here...
Whew. Unless I've missed something, where can I find such a beast? :)
Until then, I'm sticking with Buddy 128.
-Todd Elliott
dcm
Colin Ward wrote:
>
> Hi all...
>
> "Your Commodore" magazine. It was very good but unfortunately, took up
> *way* too much memory. I've recently started using Turbo Assembler. What
> is the assembler of choice these days, not including cross assemblers?
>
it was neat being able to program in any modification I wanted.
> I posted something like this yesterday but I think that my crappy
> newsreader stuffed up, so excuse it if it pops up somewhere later...
>
> /----------------------------------------------------------------------\
> [Hitman/Code HQ - 6502/68000/80386 & now 65816 (16 bit 6502!) ]
> [Assembly Lover since 1987! Proud member of Team AMIGA ]
> [OS coding/Hardware hitting/Demos/Games/Modules - c64, Amiga & PC ]
> [I'm a pogrammar.. I'm a programor... I'm a progemmar... I write code. ]
> \----------------------------------------------------------------------/
--
From: White Plains, New York, USA.
Pontus Berg
On Fri, 14 Mar 1997 15:31:37 -0500, "Todd S. Elliott" <ey...@erols.com>
wrote:
>Asger K. Alstrup Nielsen wrote:
>> I think all 6502 hackers wished to have the ideal assembler that had all the
>> major goods from TA (speed, good integrated editor with highlighting, reset
>> safety) combined with the goods from a powerful assembly engine with macro and
>> include support without arbitrary size limits. Many hackers started
>>
>Asger-
>
>Thanks for the comphrensive summary on Turbo Assembler. It was quite
>interesting. It would have been nice if the 'ideal' assembler had these
>features:
>
>- REU Support. This includes the entire package surviving a system
> reset, i.e., through the Action Replay cart. That way, quick
> prototyping can be done, over and over until the bugs are worked out.
ActionReplay + REU? You mean the special solution which requres you to
patch the software of the AR and so on?
>- 80 Column Editor w/ cut/paste, search/replace, standard editor stuff,
> etc. Maybe syntax highlighting would be nice, as well as identing.
All 80 column editing I've seem on the 64 is not something I'd like to
spend hours and hours in front of!
>- Memory/disk assembling, as well as multiple source file assembling.
> Include multiple disk support. (i.e., read input source at device 9,
> and output the object files into device 10 or whatever.)
Well you could include stuff in the macro version...
>- Symbol table management.
>- Macro support. (I've never been a fan of macros, but some
> well-designed ones could merit my consideration, and they are just
> invaluable in GEOS programming.)
Again, there is a special version for this!
>- Incremental linker. This is very handy for large projects.
>- Usual goodies for pseudo ops, i.e., temporary labels, conditional
> assembly, etc.
Again, the marco version ...
>- Option for ASCII output for cross-platform file management.
>- Allows creation of hybrid BASIC/ML programs. i.e., 10 sys(2099) ML
> code starts here...
Bah, it's not all that troublesome to write the ten rows needed the
include this first in the program!
>Whew. Unless I've missed something, where can I find such a beast? :)
>Until then, I'm sticking with Buddy 128.
Well, the macro version should be out there somewhere... You could try
asking the guys in Style for a beta of theirs!
Pontus Berg
>Question concerning Turbo Assembler's size ($9000- ).
>Could the program be put into a cartridge ROM thus leaving the total
>64k RAM free for source code? Anyone have the specifics of absolute
>memory locations and what they do?
First of all, cartridges reside at $8000 and go to $a000 whereas the
normal TurboAss is $9000 - ~$cf00 (depending on the version - the page
$cf00 is for a settingstable)...
First of all - it was written tio run from RAM. If it's copied to a big
cart you'd have to fix a lot of things in it:
* add effective memory swapping for reading and writing under the cart
* repositioning the pointers
* effectively split it up in two sections (the assembler part is split
from the editor as it is today, but the editor itself is also too big)
for each $2000 byte bank of the cart.
So it's not prtepared for it, and it's not an easy task - but everything
COULD be done.
Marko Mäkelä
>>>>> "Pontus" == Pontus Berg <Bac...@hem.passagen.se> writes:
Pontus> ActionReplay + REU? You mean the special solution which
Pontus> requres you to patch the software of the AR and so on?
You won't need to patch the firmware on the AR, but the hardware.
Prlink works with both AR and REU connected. Read its documentation
how this can be done.
And speaking of assemblers, I prefer DASM, which is an excellent macro
assembler written in C. Every time I compile the source, I just
transfer the whole binary to the target system (VIC20, C64, C128, C16,
PET) using prlink (40-50kB/s) and test it there.
Marko
Colin Ward
Marko....@HUT.FI (=?ISO-8859-1?Q?Marko_M=E4kel=E4?=) wrote:
Yes, DASM is nice, I will admit. I wrote a sprite ripper using DASM and
the A64 package on my Amiga 1200 a little while back. DASM supports macros
and local variables, as you know. Macros are nice for when you must
increment a ZP pointer in various places in your code. I'd rather have
IncZP <Name> rather than 3 or 4 lines of code cluttering up the screen
every time.
But as nice as the DASM/Cygnus Editor/A64 emulator combination is, the
fact is, it's *not* a c64! It's nice to sit down in front of a *real* c64
with a *real* c64 editor and assembler, with all of their limitations and
difficulties. It's a part of the experience of c64 programming, IMHO.
Marc Walters
Pontus Berg (Bac...@hem.passagen.se) wrote:
: On Tue, 11 Mar 1997 00:08:57 GMT, co...@leprechaun.com.au (Colin Ward)
: wrote:
:
: > Years ago I used to use Speedy Assembler, which was written and sold by
: >"Your Commodore" magazine. It was very good but unfortunately, took up
: >*way* too much memory. I've recently started using Turbo Assembler. What
: >is the assembler of choice these days, not including cross assemblers?
: Most people do use some sort of version of the TurboAssembler .
: prefereably supporting the REU. There two main versions; the normal one
: and the one with macros. If you want the docs which then also includes
You might like a look at my REU version of PAL Assembler:
-Standard MOS terms
-BASIC keyword patches (AUTOLINE, OLD, RENUMBER, FIND, etc)
-Assemble object code to any 64K bank (preloaded with test data if needed)
-swap in any 64K bank, test code, swap back to assembler
-store different versions of source in different banks
-more than one command per line, eg LOOP lda #0:sta $d020,x:inx ;colour:dex
(Turbo Ass allows only one instruction per line, neat but time consuming
to read through)
Marc Walters
dd...@hunterlink.net.au
Pontus Berg
On Mon, 17 Mar 1997 00:51:19 GMT, co...@leprechaun.com.au (Colin Ward)
wrote:
>>And speaking of assemblers, I prefer DASM, which is an excellent macro
>>assembler written in C. Every time I compile the source, I just
>>transfer the whole binary to the target system (VIC20, C64, C128, C16,
>>PET) using prlink (40-50kB/s) and test it there.
>
> Yes, DASM is nice, I will admit. I wrote a sprite ripper using DASM and
>the A64 package on my Amiga 1200 a little while back. DASM supports macros
>and local variables, as you know. Macros are nice for when you must
>increment a ZP pointer in various places in your code. I'd rather have
>IncZP <Name> rather than 3 or 4 lines of code cluttering up the screen
>every time.
>
> But as nice as the DASM/Cygnus Editor/A64 emulator combination is, the
>fact is, it's *not* a c64! It's nice to sit down in front of a *real* c64
>with a *real* c64 editor and assembler, with all of their limitations and
>difficulties. It's a part of the experience of c64 programming, IMHO.
I assume the "i" key of your c64 keyboard works ;-)
(Mind needs slamming even after cleaning it!)
TODD ELLIOTT
Pontus Berg wrote:
Oops, accidentally deleted the part about the AR v6 and the REU, where Mr. Berg
queried about what needed to be done with that particular setup. I just want to
clarify this point further than what Marko Makela already remarked.
Most assemblers do not implement direct REU access; instead they rely on RAMDOS.
This is not good, for two reasons. One, it means that I have to load in an
intermediary program every time I run the assembler, and there may be a
potential resource conflict as to memory, etc. Two, If I need to prototype a
program that uses the REU's registers, there is a good chance that I will lock
up the machine or mess up RAMDOS, and accordingly, the critical stuff stored
there. So, protoyping quick programs in this manner quite possibly can lengthen
assembly times and frustration. Also, it needs to work with AR v6 as well,
because it isn't battery backed up, and only a reset from the cartridge can
preserve the contents for quick debug/run/codefix/debug cycle. When I'm
satisfied that all is well, then I'll dump the RAM contents to disk-based media.
>>- 80 Column Editor w/ cut/paste, search/replace, standard editor stuff,
>> etc. Maybe syntax highlighting would be nice, as well as identing.
>
> All 80 column editing I've seem on the 64 is not something I'd like to
> spend hours and hours in front of!
>
Well, there could be a version of such an assembler that recognizes the c128
features from within the c64 mode. It could switch on 2Mhz for assembly and
utilize the 80 column chip for editing. This is done in Novaterm v9.6 and as
well as in CKit '94 (used as buffer).
>>Whew. Unless I've missed something, where can I find such a beast? :)
>>Until then, I'm sticking with Buddy 128.
>
> Well, the macro version should be out there somewhere... You could try
> asking the guys in Style for a beta of theirs!
>
I'll pass. There are possibily two good versions for the c128: Buddy 128 with
its eventual ability to produce 65816 code and as well as Karma 128, a
relatively new assembler by Brett Tabke.
<- .sig begins here ->
Todd Elliott - tell...@ubmail.ubalt.edu
University of Baltimore School of Law
C128D Nirvana Enthusiast!
Pontus Berg
On 18 Mar 97 13:37:01 -0500, telliott@ubmail (TODD ELLIOTT) wrote:
>Most assemblers do not implement direct REU access; instead they rely on RAMDOS.
They are? I've never seen such an assembler myself, which is not
doubting your claim, but from a quite extensive experience I guess I can
feel very confident in saying - NONE of them are based on the
Turboassembler!
I also know for a fact that this is not valid for ProfessionalPDS
either!
Are you refering to any special ones that I'm not aware of?
>>>- 80 Column Editor w/ cut/paste, search/replace, standard editor stuff,
>>> etc. Maybe syntax highlighting would be nice, as well as identing.
>> All 80 column editing I've seem on the 64 is not something I'd like to
>> spend hours and hours in front of!
>Well, there could be a version of such an assembler that recognizes the c128
>features from within the c64 mode. It could switch on 2Mhz for assembly and
>utilize the 80 column chip for editing. This is done in Novaterm v9.6 and as
>well as in CKit '94 (used as buffer).
2MHz assembly on the 128 isn't too uncommon on the TurboAssembnler
clones either. One of the more obvious improvements to be made. However
none I know of supports the 80 column screen.
I've said it before and I'll say it again - I want a ISA or PCI card in
the PC that is a full C64 but with memory which can be accessed from the
PC as well!
Jan Lund Thomsen
[ <Tue, 11 Mar 1997 00:08:57 GMT> Colin Ward :]
> Years ago I used to use Speedy Assembler, which was written and sold by
>"Your Commodore" magazine. It was very good but unfortunately, took up
>*way* too much memory. I've recently started using Turbo Assembler. What
>is the assembler of choice these days, not including cross assemblers?
I'm surprised noone has even mentioned "Professional Assembler", by Masters
Design Group/Digital Marketing. Like the majority of European programmers I was
introduced to the defacto standard Turbo Assembler (after a brief encounter
with the basic editor driven Profi Assembler) and was instantly hooked despite
it's huge memory footprint.
However, Professional Assembler blew my socks off! My love for TA shattered in
an instant. PA always occupies $CF00-$FFFF, the rest of its memory usage can be
customized on startup (for my utility development I usually had basic at
2801-2900, source at 2A00-AF00, and buffer at B000-C800). Furthermore it has a
great editor, tokenized file format, fast 2-pass assembly, macros, local and
global labelling and loads more.
I was told that a "PDS" version featuring REU support also exists, but I never
got my hands on a copy. I'm also searching for any documentation on the normal
or PDS version(s).- even in german. Please email me if you have any of this.
-----------------------------------------------------------------------------
Jan Lund Thomsen (aka Qed/Triangle 3532) Lystrup, Denmark
C64/RPG/INWO/Warner Bros/Disney/Anthro/Comics-addict and all-around nice guy.
--- Email: kw...@pip.dknet.dk ---- WWW: http://www.pip.dknet.dk/%7Epip781/ ---
Oliver Klee
In Professional PDS, there is a switch (pseudo opcode) for 2 MHz.
Mike Neus
In article <33591daf...@news.dknet.dk>, kw...@pip.dknet.dk says...
>However, Professional Assembler blew my socks off! My love for TA shattered
in
>an instant. PA always occupies $CF00-$FFFF, the rest of its memory usage can
be
>customized on startup (for my utility development I usually had basic at
>2801-2900, source at 2A00-AF00, and buffer at B000-C800). Furthermore it has
a
>great editor, tokenized file format, fast 2-pass assembly, macros, local and
>global labelling and loads more.
>
>I was told that a "PDS" version featuring REU support also exists, but I
never
>got my hands on a copy. I'm also searching for any documentation on the
normal
>or PDS version(s).- even in german. Please email me if you have any of this.
Sounds nice indead. Where does one find it, and is there a C128 version?
--
Because the junk mailers of the world think my address is
their play thing, my e-mail address will not be revealed.
Thank the junk mailers for ruining the internet.
Pontus Berg
On 26 Mar 1997 12:06:45 GMT, Oliver Klee <kl...@informatik.uni-bonn.de>
wrote:
>In Professional PDS, there is a switch (pseudo opcode) for 2 MHz.
Did you have PDS online? I have dug up a version from my old disks, but
it doesn't feature any of the example files, nor docs!
Jan Lund Thomsen
[ <26 Mar 1997 18:40:52 GMT> Mike Neus :]
>Sounds nice indead. Where does one find it, and is there a C128 version?
I haven't seen it online anywhere (if anyone know about Professional Assembler
and/or related stuff (docs, example sources) being available anywhere, please
reply.) As for a C128 version, I doubt one was made ... perhaps Oliver Klee of
MDG can give an official ruling on this?