[M100] Keep getting DS ERROR when loading via serial.

2022-10-21 Thread r Gi
I am repeatedly getting a DS ERROR most of the time when I try to load a
program. It happens a short time after starting the upload. Any help would
be appreciated


Re: [M100] zbug

2022-10-21 Thread Will Senn
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: 5
END: 51999
EXE: 5
?OM ERROR

Indicating an out of memory error (no protected memory is available at 
5). The clear will fix this:

CLEAR0,5000
LOADM"X.CO"
TOP: 5
END: 51999
EXE: 5

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  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  and 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  clears memory sufficiently to run ZBG and
runs it...

at the # prompt, I typed:

ASM S.DO S.CO  /WE

and watched it do it's magic with no errors. Then I ran the 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.