Regarding interrupt mode, monitor ROM uses mode 1. But for one of my games I use an interrupt issued every 4 BLNK signals though IM 2. I cannot place it at 0x0038 because I'm using DRAM $0000-1FFF as a virtual screen so I install mode 2 AKA Spectrum IM 2 trick such as:
; -----------------------------------------------------------------------------
; Main entry
; ----------
_main:
DI
LD SP,$CFCE ; set stack pointer far away
OUT ($E0),A ; set area $0000-$0FFF as DRAM
LD HL,$CE00
LD DE,$CE01
LD BC,257 ; length of vector table = 257 bytes
LD (HL),$CF ; point vector table at address $CFCF
LDIR
LD DE,game_isr
LD A,$C3
LD ($CFCF),A ; copy in a JP instruction
LD ($CFD0),DE
LD A,$CE
LD I,A
IM 2
EI
I'm not sure we can use a vector table with real pointers as I don't think MZ-700 is fully compatible for that as every device issuing an /INT must put in the data bus the vector index. PIT CTC2 obviously doesn't so.
Excellent point about the PIT chip! Hadn't considered that. It has no address lines to place onto the bus. I think I read from you elsewhere that the PIT chip interrupt is only for AM/PM and if you look at the monitor listing and follow from the point of interrupt entry (0038h), it definitely seems to do very little--toggles the AMPM bit, reloads 12 hours of seconds in memory, and some other very minor housekeeping that I don't yet understand.
I'm impressed that this system functions with that as the only interrupt need. When I got serious about learning a computer system and assembly programming in the '80s, MSDOS 5.0 had just arrived on the scene and with the computer architecture that went along with it, there was an interrupt for about everything. Keyboard, RTC, PIT chip, serial I/O, etc., all generate interrupts when service is needed and have dedicated address entry points in the vector. This is what I was expecting to find in these even-older systems too. If not a dedicated vector address scheme, then a common entry point with a hardware polling technique to see what triggered the need. What I think I'm learning, however, is that polling things is the ONLY way to determine most actions and that must be done at the user application level. The very low addresses of the monitor listing would suggest the same thing. There's a 'JP' table for various functions there. What's not mentioned in the comments are the preload register requirements and return register values for those routines. This brings about my next question....
Is there somewhere, a comprehensive list of system kernel operations that can be called by the user program for keyboard and whatever else? Where would I find that for the 700? Sorry to be getting off topic. That might be a question worthy of its own post.
Without knowing much about the '80, at first glance, most of these signals seem to repeat in the '700 expansion bus.
1), Would this card function attached to the 700's system bus, and if not, is it only because (according to the last page at the bottom of that document) the '80 seems to have a 44 pin bus connector?
2), How long in the '700 can I assert the EXWAIT signal before I have to be concerned about suspending DRAM refresh?
Excellent, thanks! I read online that certain similar DRAM chips allow for 4ms. Without knowing exactly what was inside my Sharp, I was going to cut that value in half. That more or less coincides with what you're saying too. 2ms is plenty generous enough. Really shouldn't require anything close to that.
Those with 4ms are the biggest DRAM. I'm not sure but they probably also ask for a 8-bit refresh register. Now the Z80 only offers a 7-bit refresh register (R).