[Coco] Re: Newbie help: Barden Bubble w/ Portal-9

[Roger Taylor]

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:
>>
>>>Roger:
>>>
>>>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.
>>>Jim
>>
>>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 
program.

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.



----------
Roger Taylor