[Coco] Re: Newbie help: Barden Bubble w/ Portal-9
rtaylor at bayou.com
Tue Jan 27 13:56:48 EST 2004
At 09:39 AM 1/27/2004 -0500, you wrote:
>Theodore (Alex) Evans wrote:
>>On Jan 26, 2004, at 7:39 PM, <jimcox at miba51.com> wrote:
>>>I just assumed that since the code was listed in Bardens book that it
>>>would run if EDTASM+ plus were installed in the CoCo, and so I thought
>>>Portal-9 would do the same.
>>I personally can confirm from experience that under EDTASM+ the code runs
>>exactly as published. Of course as pointed out, if you want to save it
>>as a binary, you need to supply a load address when you load it off
>>either cassette or disk.
>I guess I should point out that one of the features of EDTASM+ is in
>memory assembly in addition to assembly to disk. The IM switch is intended
>for ZBUG use which permits running the ml program from within EDTASM+;
>among other things.
>When EDTASM+ does an in memory assembly, it automatically places the code
>in a safe location so that EDTASM+ and system code is not over written.
And there's another issue with his examples; they're not all meant to be
loaded and executed. Some are to examine the listing to see what the
opcodes are, etc. To generate a listing with Portal-9, type in "-l" in the
'assembler options' field. To see the symbols list, use "-s". You can use
"-l -s" to do both. "-sa" lists all symbols, including local labels.
If you still want to be able to LOADM and EXEC an example from Barden's
book that is missing an ORG statement, just add something like ORG 16384
for the 1st line of the source before you build.
Here's what's happening:
In the left panel under the "assemble file as, type:" field, choosing
"multi-record" tells the assembler to create a program file that BASIC can
LOADM. Actually, "single-record" can do the same, but you lose the ability
to embed uninitialized variables/tables in your program. That's a whole
other subject. Make a habit of choosing "multi-record" any time you are
building a program or game that is meant to be LOADMed from BASIC.
In your source code, the ORG psuedo op tells the assembler to create a
program file that BASIC knows WHERE to LOADM.
No ORG at all more-or-less tells BASIC to LOADM your program at address 0,
which will almost always crash your CoCo since that is a system area.
If you just absolutely want to assemble your program to have an origin of
0, it might run correctly if you've stuck to the position-independent rules
of coding, so doing something like a LOADM "GAME", 16384 would cause your
game to load at address 16384. The value of 16384 is added to the value of
0 (the origin you specified, or didn't specify). The LOADM
"program",offset syntax always adds "offset" to any ORG (origins) of your
Oh, and a multi-record file can have multiple origins. That's the whole
idea, to let the loader (LOADM) have the ability to load around memory
areas, or even jump to new addresses during the load process. You can
actually create a mini-movie that plays on the 32x16 VDG screen if you
build a large program that keeps loading 512 bytes of data at address 1024
(the screen) over and over until the end of the file. I confirmed this
little gig many years ago during my hand-assembly days. :)
I hope this doesn't add confusion to what is really a very simple concept.
More information about the Coco