Attn: HDOS 3 ISR experts, help needed...

33 views
Skip to first unread message

Joe Travis N6YPC

unread,
Sep 23, 2022, 5:00:01 PM9/23/22
to SEBHC
I've been debugging an ISR issue in HDOS 3 for several hours, trying to find out why the ISR I (thought was) installed isn't being called.  I finally added some debugging statements that verify my ISR is being pointed to in the interrupt vector table however, a moment later when checked again, I discover that the old ISR vector is back in the table.

Is there a procedure / mechanism that I'm unaware of that is necessary to properly install an ISR?  Thanks again for your help!

Regards,
Joe Travis n6ypc

Douglas Miller

unread,
Sep 23, 2022, 5:06:25 PM9/23/22
to se...@googlegroups.com

Hopefully an HDOS 3 expert will chime in soon, but the ROM (and HDOS 2) uses interrupt jump vectors in RAM. If you are poking into 0x0018, 0x0020, ... then you are likely hitting ROM (at least in the case of HDOS 2). The ROM sets up interrupt vectors for redirection starting at 0x201f for INT1. These are simple JMP vectors, 3 bytes each.

If HDOS 3 is using the same memory layout and interrupt vector scheme, you'll need to change how you poke the ISR into memory.

--
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/6080b7af-8c0b-47c5-bf97-dafaad290b2cn%40googlegroups.com.

Glenn Roberts

unread,
Sep 23, 2022, 5:40:05 PM9/23/22
to se...@googlegroups.com

I’ll second Douglas’ point joe.

 

I looked at your code and it looks like you’re putting the vector into low memory space

 

        h84ivec = ivec << 3; /* x8 */   /* save the interrupt vector */

 

which, on the H8, is in ROM.  The user interrupt locations are re-vectored to .UIVEC (defined in MTR.ACM).

 

.UIVEC     EQU  40037A          USER INTERRUPT VECTORS

 

That’s in RAM and is where you should insert your vector (with the appropriate offset of course – see the ROM documentation)

 

I was a little confused when looking at your code.  it looks like you’re writing code for stand-alone application (no OS?)  because HDOS already implements a full interrupt-driven console I/O capability…

 

  • Glenn

Mark Garlanger

unread,
Sep 23, 2022, 5:43:59 PM9/23/22
to se...@googlegroups.com
HDOS 3.0 has the ROM swapped out with RAM, just like CP/M. I haven't done any ISR work in HDOS though, so can't provide much help without digging through everything.

Mark


Joseph Travis

unread,
Sep 23, 2022, 6:46:32 PM9/23/22
to se...@googlegroups.com
Thank for your replies. As Mark pointed out, HDOS 3 swaps out the ROM after copying it into RAM which is why I went the route I did to replace the vector in low memory.

I suspect there is something that occurs in the 2mS interrupt that ensures those vectors are "protected".  As stated previously, I was able to verify my ISR vector was installed only to be overwritten a moment later.

Note, I'm not attempting to replace the console driver.  I desire to communicate with multiple devices, each on different ports (ham radio, antenna rotor controller, TNC, BSR X10 controller, Hayes chronograph, etc).  Yes, I need two H8-4's or could possibly use the serial port on the H8-5 (library yet to be written).

My H8-4 library currently supports one port using interrupts to communicate reliably at 9600 baud. All other ports can run at 4800 baud or less without using interrupts. I may add additional interrupt support later. For now, it's baby steps.

Joe


Douglas Miller

unread,
Sep 23, 2022, 7:18:15 PM9/23/22
to se...@googlegroups.com

I booted up HDOS 3 on my simulator and poked around memory. It appears that HDOS 3 is using the same 0x201f area for interrupt vectors, in the same way as the ROM sets them up. This makes sense, since I suspect HDOS 3 strives to be compatible with HDOS 2. I also confirmed that the interrupt/RST locations in page 0 point (jump) to the corresponding ones in 0x201f (with the exception of the special-case of INT1 - the 2mS interrupt - and of course RST0).

Note that your program should be saving the previous contents of the JMP vector, and restoring that when it exits. Otherwise, you're likely to crash after exit.

Douglas Miller

unread,
Sep 23, 2022, 7:52:37 PM9/23/22
to se...@googlegroups.com

You may also need to "daisy-chain" your ISR - i.e. use the previous value in the JMP vector to finish up your ISR. This would be the case if you are adding a new interrupt handler to an interrupt that is already in use (e.g. if HDOS is using INT3 for the console, and you are using INT3, then you may need to call/jmp to the previous contents of vector 3 or else you lose console input). Maybe others have more knowledge of how HDOS 3 uses interrupts and these vectors.

Mark Garlanger

unread,
Sep 23, 2022, 8:06:54 PM9/23/22
to se...@googlegroups.com
There is a manual for HDOS 3.0 on my site: https://heathkit.garlanger.com/software/OSes/HDOS/3.0/  Not sure if it covers programming and ISRs, searching for ISR as a whole word didn't find anything but searching for interrupt found 175 matches.

Mark

Douglas Miller

unread,
Sep 23, 2022, 8:27:46 PM9/23/22
to se...@googlegroups.com

Probably the best thing to do is read the manual Mark mentions. But, from inspecting the memory image of a running HDOs 3 instance, it appears that JMP vector 3 at 0x2025 contains a jump to the HDOS console input ISR. If you simply replace that vector with something that doesn't differentiate the source of the interrupt and selectively call the HDOS ISR, you'll lose console input. Also, if you don't restore the original value on exit you'll crash and/or lose console input until you reboot.

glenn.f...@gmail.com

unread,
Sep 23, 2022, 8:58:29 PM9/23/22
to se...@googlegroups.com

The “HDOS way” to do this is with device drivers.  This would typically be done by tailoring the generic ones provided with the OS (e.g. AT:  ).   I’m guessing you’re worried about the RAM overhead of a large number of devices?  Understandable, but still by rolling your own you’re “fighting” the OS norms a bit.  I’m a bit rusty on device drivers but wonder if you could provide numbered units within a serial I/O DD?  E.g. AT0: would be the BSR X10, AT1: the chronograph, etc.  not sure if the DD design allows for this on non-disk devices…  but it would be a way to handle multiple devices with a single driver.  I think the Lindley printer driver did this?

 

To my knowledge HDOS 3 does little or nothing to change the system programming interface.  In fact  for what you’re doing you’re really working a layer below the OS.  I would definitely advise using the user interrupt vectors (.UIVEC) vs. poking into low RAM.  As others have pointed out be very careful with the chaining of interrupts and restoring state on closure.

 

Hopefully you’re getting some of that mental exercise you sought!??

 

😊

Joseph Travis

unread,
Sep 24, 2022, 11:05:48 AM9/24/22
to se...@googlegroups.com
Thank you for your help and encouraging words.  This is really my first foray into HDOS programming.  Some 35+ years ago I was more in tune with Z80 ASM on CP/M or PL/M under ISIS on a MDS-80.  I much prefer Z80 ASM over 8080 ASM as the instruction set is easier to understand (and a 16 bit subtraction is only one instruction on Z80 vice 6 on an 8080).

After sleeping on it, I figured out the real issue... I miscalculated the vector location by not including the JMP instruction, a stupid mistake.  I knew it had to be something simple / stupid.  I'm able to replace the vector in low memory and restore it when I exit the program... works great!.  The same code should work for both HDOS 3 and CP/M (which is something I strive for).

Thanks again all for your kind assistance.

Joe


Reply all
Reply to author
Forward
0 new messages