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 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.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 and ZBUG.CO loaded onto my 32K RAM >>> m100. I then ran 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 is 8K >>> on disk, after getting it on to the disk, I'm left with about 12K. I >>> deleted ZBUG.BA, 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 >>> >> >
