[https://res-geo.cdn.office.net/assets/mail/file-icon/png/zip_16x16.png]Zbuggy.zip<https://1drv.ms/u/s!AgRHXuUu57Cegk3cUv-cjeHcaeM8?e=4DGjfO>
________________________________
From: M100 <m100-boun...@lists.bitchin100.com> on behalf of runrin
<run....@rin.run>
Sent: Saturday, October 22, 2022 8:27 PM
To: m100@lists.bitchin100.com <m100@lists.bitchin100.com>
Subject: [M100] zbug on archive.org
hi all!
forgive me for not replying to the relevant thread as i just joined the mailing
list a few days ago.
i recently spent a ton of time trying to track down an archived version of
Radio Shack's Assembler/Debugger (23-3823).
i got lucky that it was being discussed here on the mailing list right when i
joined, and i was able to get a copy from the link joshua provided.
i was wondering if it would be okay with joshua if i (or someone else) uploaded
the zbug manual and binary to archive.org so it is easier for others to find.
because it's known as zbug to many people, that doesn't make it easy to track
it down with only the original title.
an archive named "Radio Shack Assembler/Debugger - 23-3823 (ZBUG)" would help a
lot of people find what they are looking for.
i'm sure it's fine, but i figured i'd ask first since it's on joshua's site and
i don't really want to upload it without permission.
-runrin
On October 21, 2022 1:03:40 PM PDT, m100-requ...@lists.bitchin100.com wrote:
Send M100 mailing list submissions to
m100@lists.bitchin100.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com
or, via email, send a message with subject or body 'help' to
m100-requ...@lists.bitchin100.com
You can reach the person managing the list at
m100-ow...@lists.bitchin100.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of M100 digest..."
Today's Topics:
1. Re: Planning out some weekend projects. (ZBUG) (Peter Noeth)
2. Re: zbug (Will Senn)
3. Re: zbug (John R. Hogerhuis)
4. Re: zbug (Will Senn)
________________________________
Message: 1
Date: Thu, 20 Oct 2022 15:57:02 -0700
From: Peter Noeth <petern0...@gmail.com>
To: Model 100 Discussion <m100@lists.bitchin100.com>
Subject: Re: [M100] Planning out some weekend projects. (ZBUG)
Message-ID:
<CADg-nGVVt7XB=3zteauaqkpbu3k5tyqv93bk6yqdhbk-l5g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Joshua,
Thanks for the link, I will check it out. But yes, I also want the
physical package for the full retro experience
If you're just hoping to use the software I have the Tandy
editor/assembler debugger in my bucket[1], along with the manual. I
believe it has been labeled variously "ZBG" or "EDTASM" (as other Tandy
assemblers) as well. The underlying assembler and debugger are the
Microsoft package, I believe.
<snip>
Randy,
I know you have one, as I saw it at Tandy Assembly in 2019 when I was
sharing your display table. I didn't know it before I arrived, but we were
both in competition on that eBay auction. Haven't seen another one since.
I have the physical package with manual, cassette and hard cover/holder.
Didn't know it was rare. I don't want to give it up though. :). Sounds
like it has been archived.
<snip>
Regards,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20221020/a56e39aa/attachment-0001.htm>
________________________________
Message: 2
Date: Thu, 20 Oct 2022 19:11:56 -0500
From: Will Senn <will.s...@gmail.com>
To: m100@lists.bitchin100.com
Subject: Re: [M100] zbug
Message-ID: <7c20fd8d-0005-4f86-d21d-e41b64c05...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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 <twospru...@gmail.com>
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 <will.s...@gmail.com>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20221020/224ea009/attachment-0001.htm>
________________________________
Message: 3
Date: Thu, 20 Oct 2022 17:26:00 -0700
From: "John R. Hogerhuis" <jho...@pobox.com>
To: m...@bitchin100.com
Subject: Re: [M100] zbug
Message-ID:
<CACutKUgSmigXWB_Qe8iVESNreAfQdfJ+XWfhNM-=+edaj3x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <will.s...@gmail.com> 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 <twospru...@gmail.com>
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 <will.s...@gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20221020/11727694/attachment-0001.htm>
________________________________
Message: 4
Date: Fri, 21 Oct 2022 09:13:00 -0500
From: Will Senn <will.s...@gmail.com>
To: m100@lists.bitchin100.com
Subject: Re: [M100] zbug
Message-ID: <2bee1b34-470e-b263-cbe5-daa7c10ae...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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 <will.s...@gmail.com> 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
<twospru...@gmail.com> 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
<will.s...@gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.bitchin100.com/private.cgi/m100-bitchin100.com/attachments/20221021/859f0f68/attachment-0001.htm>
________________________________
Subject: Digest Footer
________________________________
M100 mailing list
M100@lists.bitchin100.com
http://lists.bitchin100.com/listinfo.cgi/m100-bitchin100.com
________________________________
End of M100 Digest, Vol 142, Issue 18
*************************************
![https://res-geo.cdn.office.net/assets/mail/file-icon/png/zip_16x16.png]Zbuggy.zip](https://res-geo.cdn.office.net/assets/mail/file-icon/png/zip_16x16.png]Zbuggy.zip){kind=link}