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 >*************************************
