Thanks for the tips, John. After reading Ch. 30 - Loading and Running
Machine Language Programs, 2 excellent pages of Tony Anderson's
Programming Tips, Peeks and Pokes for the Tandy Portable Computers
(1989). I mostly get it...
MAXRAM is 62960 in a 32k system. It's the first (last) available memory
location for our programs and data. I think this is because ROM is the
lower 32k and RAM is the upper 32k. Files and basic programs can grow in
the 32k space between the bottom of RAM (32K) and the top of RAM
(MAXRAM). However, machine language programs have to be placed into
protected RAM between HIMEM and MAXRAM. HIMEM is set to MAXRAM by
default and this necessitates the CLEAR. CLEAR allows us to set HIMEM
and create a partition in RAM at the location we specify lying between
the beginning of RAM and MAXRAM. Everything above HIMEM is protected and
available for our machine language programs and cannot be written into
by BASIC.
HIMEM is set based on how much memory needs to be protected which is
based on the size of the machine code and it's ORG (starting address).
When the .CO is assembled, the ORG determines the starting address of
the program. This is displayed by the assembler. However, it is also
available via LOADM which will try to load the .CO into memory at the
location specified at assembly time. Typing LOADM"PROG.CO" will display
three numbers, TOP, which is the ORG location, END which is the
calculated end of the program in memory, and EXE which is the entry
point of the program and in my super limited experience is probably the
same as TOP, but may not be with fancier code.
So, in sum, CLEAR sets HIMEM, a partition between bottom (32K) and top
of memory (MAXRAM). Everything above HIMEM is protected for machine code
use. Given the default state (HIMEM=MAXRAM) and a program X.CO, taking
up 2,000 bytes, to start at 50,000, LOADM"X.CO" would show:
TOP: 50000
END: 51999
EXE: 50000
?OM ERROR
Indicating an out of memory error (no protected memory is available at
50000). The clear will fix this:
CLEAR0,5000
LOADM"X.CO"
TOP: 50000
END: 51999
EXE: 50000
and no error. The issue with the assembler is that it creates an
additional memory requirement on top of it's own, so if you plan to
create a program that has ORG 48000, you will need to be sure that a)
you set HIMEM to 48000 (or below) and b) that your program doesn't
intrude on another bit of code living above it (say the assembler at
54272 or teeny at 62213).
Whew! Tricky business that. I thought I'd put it in a note for posterity
and anybody experiencing similar issues. Hopefully, I am not too far off.
Later,
Will
On 10/20/22 7:26 PM, John R. Hogerhuis wrote:
How big is the program? You should be able to tailor a clear statement
to reserve exactly as much memory as you need... assuming you change
the origin to make it run from that higher location. So before clear,
you could print HIMEM, subtract the size of your program, and you have
your ORG address. Reassemble to that address. Then clear to that address.
There's also the concept of leaving the program loaded at its run-from
location. Once the program is loaded into cleared space nothing will
mess with it. So you don't actually need the CO file in memory any
more. And of course the assembler could go too. Leaving lots of free
memory.
-- John.
On Thu, Oct 20, 2022, 5:12 PM Will Senn <[email protected]> wrote:
It was definitely an issue with my failure to clear memory. By way
of confirmation, I did the following:
I cold started the M100 and used DL to get TEENY on the M100. I
then used TEENY to transfer ZBG.BA <http://ZBG.BA> and ZBG.CO
<http://ZBG.CO> onto the M100. I also transferred the test prog
S.DO from the Assembler/Debugger Manual:
ORG 0CC00H
HOME: CALL 422DH
SCREEN: MVI A,0FFH
CALL 4B44H
ROW: LDA 0F639H
CPI 8H
JNZ SCREEN
COL: LDA 0F63AH
CPI 28H
JNZ SCREEN
WAIT: CALL 12CBH
EXIT: CALL 5797H
END HOME
Then I entered basic and typed:
RUN"ZBG"
ZBG.BA <http://ZBG.BA> clears memory sufficiently to run ZBG and
runs it...
at the # prompt, I typed:
ASM S.DO S.CO <http://S.CO> /WE
and watched it do it's magic with no errors. Then I ran the S.CO
<http://S.CO> file from the Menu and marveled at the speed with
which it filled the screen with pixels :).
Yay! It's just a bunch of calls to ROM functions, still, it's
assembly language and it works!
Wow, is it a memory hog though - after doing the assembly, I was
left with 500 bytes or so. I realized that a:
CLEAR 0,48000
and running it directly from the menu left me with about 6K,
still! Now, I have something to compare with when I run CZASM and
BYTEIT...
Thanks for the assist Stephen.
xrefs:
M100ZBGASM/01.00.03 1985 and it's manual at
http://public.nachomountain.com/files/m100/
dlplus at https://github.com/bkw777/dlplus
Will
On 10/20/22 6:09 AM, Stephen Adolph wrote:
ZBUG runs uses 52472 to 62475
I think if you want to compile at, say CC00H = 52224 then you
have to have issued a clear command that makes that RAM available.
ex.
Clear 0, 48000
lets you compile at 48000 AND load/run ZBUG at 52472,
..Steve
On Thu, Oct 20, 2022 at 7:00 AM Stephen Adolph
<[email protected]> wrote:
where did you set the start of the assembly to compile to?
possible you are compiling to a protected memory space like
the lower 32k, or a space that overlaps the M100 OS, files, etc.?
On Thu, Oct 20, 2022 at 12:38 AM Will Senn
<[email protected]> wrote:
I get the impression that the TRS-80 Model 100
Assembler|Debugger, aka ZBUGASM can't really be run from
RAM. Has anyone tried it successfully?
I used TEENY and dl to get ZBUG.BA <http://ZBUG.BA> and
ZBUG.CO <http://ZBUG.CO> loaded onto my 32K RAM m100. I
then ran zbug.ba <http://zbug.ba> (which is a basic stub
to clear memory and run the assembler)... fine, it loaded
up the assembler no problem. I then typed in a small asm
example into TEXT from the book, saved it, and tried to
assemble it from ZBUG but got an out of memory OM ERROR.
ZBUG.CO <http://ZBUG.CO> is 8K on disk, after getting it
on to the disk, I'm left with about 12K. I deleted
ZBUG.BA <http://ZBUG.BA>, TEENY.CO <http://TEENY.CO> and
every other file, recleared memory and still get the OM
ERROR when trying to assemble. Seems like it ought to be
enough to do an assembly. The manual does make mention of
loading it from tape if memory's tight, but surely it
would have said that it was required to load it from tape
and not provide instructions for saving to and running
from RAM if it could not be run from memory?
Thanks,
Will
