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.
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…
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/dd34e597-6501-31e9-6b18-fb7ad9007f1b%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/0c2c01d8cf95%2409c9b380%241d5d1a80%24%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAAjkm78ybWWP9_cwtWzOwAA-dPq5aTgBehb3YW3jNta5vs_wmQ%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCoDW5B3d18omk3FGjAsbPi6hzPcPEDpJrKgxkyUuUzKA%40mail.gmail.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/23cded98-4820-e237-8648-71073ec3ba43%40gmail.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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAAjkm79Xo6CAtephY9hycsbTMN8Bqqa6dJYpYiRsPrb9tCyCBA%40mail.gmail.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!??
😊
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CAGQDgBCoDW5B3d18omk3FGjAsbPi6hzPcPEDpJrKgxkyUuUzKA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/020901d8cfb0%24c08401a0%24418c04e0%24%40gmail.com.