I had not noticed that there was no debug.abs! But, HDOS 3 will run HDOS 2.0 applications. So the 2.0 debug will probably work.
Sent from Mail for Windows
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/f474d521-f854-42b5-acce-e9a02150b6a2n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/1808580804.929504.1642453565676%40bellsouth.net.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBBT5%2BSEV4GzPn6MQOgRMacP2SxrBW6dvbbDR4JK1EqmBw%40mail.gmail.com.
You received this message because you are subscribed to a topic in the Google Groups "SEBHC" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sebhc/RlIIVSSDMk0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sebhc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAAjkm7_H%2B-9%3DUvwfhh_fecRz-y9Am5Og%2BUOSDdPbT4sSb%2B4DMA%40mail.gmail.com.
I see RDT.ABS on my HDOS 3 system. This is the Self-Relocating Debugging Tool from Pat Swayne, and is an improved successor to DBUG.
As I understand the evolution of HDOS 3 the authors tried to adopt the best components from HUG and elsewhere to improve the HDOS experience. RDT has a lot to offer over DBUG. For one thing you don’t have to re-ORG your code to debug it as the debugging tool automatically moves itself out of the way into high memory. I’m not an RDT expert and can’t offer a comparison but it is my guess that RDT was the standard HDOS 3 debugging tool
RDT was originally released (including source) on HUG disk 885-1092, which is in Les’ HUG archives. The manual was provided in hard copy only (in the zip-lock baggie along with the floppy). I have a paper copy (I was unable to find a scan of this in any of our archives… Anyone have it posted somewhere?)
I can scan my copy of the doc file (22 pages) if in fact we don’t already have it somewhere… (hmm. I didn’t check but perhaps it’s in the HDOS 3 documentation?)
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBAiAbayWNscD6Ycdn2xh%2BBqLJud14%3DqLaMrnSW6D9cuuA%40mail.gmail.com.
Belatedly read the HDOS 3 manual and discovered (as Joe no doubt already knew) that it does indeed reference DBUG. A whole chapter on it (chapter 9). And I am unable to find DBUG.??? On any of the HDOS3 distribution disks that we have. So the mystery continues.
We do have the source for DBUG.ASM so it could be assembled for HDOS3…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/067201d80c10%244d5696c0%24e803c440%24%40gmail.com.
Quite correct. I should have done more homework before sending that note. My Z67 HDOS3 image was (I believe) constructed by Ken Owen so Ken I guess I have you to thank for including RDT there!
I’ve attached RDT (save it and rename it to RDT.ABS – I presume you have a way to transfer it to the H8?) and the documentation I have. This is a scan of a stained, crooked photocopy but may be all we have (?)… RDT has some nice features and should help you with your task joe!
I have used RDT for debugging HDOS programs and (once you get familiar with it) find it quite powerful! My first experience was when I was trying to figure out why the program FIND.ABS (part of the DiskCat utility) would run and find the data I wanted, but would trash the HDOS system when used requiring a reboot after every use. Using RDT, I discovered that when started, the program modified a couple of RST vectors, that HDOS was using, to perform a new purpose and failed to restore the vectors to entry state on exit. I documented the problem and fix:
* USING RDT LOAD THE ASSEMBLED VERSION OF THIS FILE.
* MOVE IT UP 1K AND THEN LOAD CHECK.ABS. MOVE THIS
* CODE BACK DOWN 1K TO APPEND AT 061367. MODIFY THE
* EXIT POINTS AT 2347H AND 237CH TO JUMP TO RSTORE.
* MODIFY THE WORK AREA POINTER AT 23ACH TO POINT PAST
* THE NEW END OF PROGRAM. SAVE THE REVISED FILE AS
* CHECK,2280,3227,31F7. THE LAST ADDRESS IS THE NEW
* PROGRAM ENTRY POINT AND THE PROGRAM LENGTH BYTE
* IS SET BY THIS EXIT.
.EXIT EQU 0
ORG 061367A ; ORG AT CURRENT END OF PROG
SAVENV LXI D,040053A ; POINT TO RST 5
LXI H,SAVEC ; SAVE LOCATION
LXI B,6 ; 6 BYTES - RST 5 & RST 6
LOOP1 LDAX D ; A IS NEXT BYTE
MOV M,A ; SAVE IT
INX H ; BUMP UP
INX D ; BUMP UP
DCR C ; DEC COUNT
JNZ LOOP1 ; DONE?
JMP 042200 ; JUMP TO 2ND INSTRUCTION
RSTORE LXI D,SAVEC ; POINT TO STORE
LXI H,040053A ; POINT TO RST 5
LXI B,6 ; 6 BYTES TO RST 5 & RST 6
LOOP2 LDAX D ; LOAD NEXT
MOV M,A ; RESTORE IT
INX H ; BUMP UP
INX D ; BUMP UP
DCR C ; DEC COUNT
JNZ LOOP2 ; DONE?
XRA A ; YES, SO EXIT
SAVEC DB 0
I also modified several HDOS 2.0 programs (such as DEBUG) that checked the system version for 2.0 and would not run on HDOS 3.02. I wanted to use them on HDOS 3.02, so I modified the version check to accept the 3.02 version.
In my previous note I said I was working on FIND.ABS when the fix I attached was for CHECK.ABS (a file checksum generator). Both of these programs had the same defect of not restoring the vectors they changed back to entry state on exit.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/92416a23-15ab-4a7a-92a6-da1c7b1fac48n%40googlegroups.com.
Keep us posted joe. For some reason I’ve never switched to HDOS3 as mainstream. When I built “big blue” I decided to make it primarily my CP/M3 and HDOS3-based environment and I’ve been slowly making more use of it. It was an impressive achievement of the community to honcho that release! It certainly offers some nice enhancements. Perhaps we’ll see more discussion here on HDOS3. …
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBB0iKwM9W17bJRp8xFkz4P6xO3wvV0LyH%2BAC9SSqhZh2A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/010f01d80cb1%24d23bf8c0%2476b3ea40%24%40gmail.com.
Well MAPLE can do XMODEM so you should be able to transfer. Ken Owen has written up a lot on this, see e.g.
if you don’t have the MAPLE instructions I can scan and share. This would be worth writing up a step-by-step tutorial on. on the PC side I would recommend TeraTerm
an alternate way to move the file over would be the USB/VDIP interface if you’ve got that… 😊
But if you’ve got H8DUtil working you can just grab RDT from HUG disk 885-1092. Its in the HUG library on Les’ site
and Mark Garlanger has a direct link to the H8D file here:
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCJjAuD%3DEkMMDQ6ed7qS8LWUTUUd2sgE--Au%2BHro3pfBw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/01f201d80d31%245cd919c0%24168b4d40%24%40gmail.com.
p.s. finally noticed that there’s a very clean copy of the RDT manual on Les’ site..:
looks like it was OCR’ed – maybe thanks to Ken?
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBDLa%2B9NrqFoSM313_yzkGBNgUfJHh3LCzrieC_vLG8jMQ%40mail.gmail.com.