|
|
Post by gtoal on Feb 10, 2021 15:44:49 GMT -5
ORG $CBEA
;
STACK DS 1
HEIGH DS 7 ;TITLE PAGE HIGH SCORE
INMI ; UNUSED LABEL inmi aliases to swi2
ISWI3 ; swi3 aliases to swi2
ISWI2 DS 3
IFIRQ DS 3
IIRQ DS 3
ISWI DS 3
JRES DS 2
;
;
; - - - - - - RESET VECTORS - - - - - - -
;
ORG $FFF2
DW ISWI3 ;RAM INDIRECT VECTORS ; FFF2 swi3 (swi2)
DW ISWI2 ;NMI AND SWI HANDLED BY -MAID- ; FFF4 swi2
DW IFIRQ ; FFF6 firq
DW IIRQ ; FFF8 irq
DW ISWI ;NOT IN MAID ; FFFA swi
DW ISWI ;NOT IN MAID ; FFFC nmi (swi)
DW POWER ; FFFE reset -> rom code
Looking at the RUM, it looks like swi2, and swi3 are handled by the same vector, and swi and nmi and both handled by a different vector. (despite there being a INMI label that is equated to swi2! It's unused.)
I'm trying to decide whether swi2 or swi would be preferable to use in a user program - does either have an advantage? SWI would be shorter but problematic if there are any nmi's floating around. Does the normal vectrex operation ever generate NMI's at all? I don't see anywhere in the RUM where those 3-byte jump vectors in RAM are initialised. That would suggest any stray NMI's that might happen would probably cause a jump to 0000 and reboot the program?
The way I'll use this will likely be a swi/swi2/swi3 followed by some inline data bytes to determine the sub-action.
Graham
|
|
|
|
Post by kokovec on Feb 11, 2021 10:23:08 GMT -5
From Malban's blog...
"Interlude: Vector drawing
Drawing vectors with the vectrex hardware needs to be very exact!
Depending on the circumstances the user can discern when vectors are drawn with a difference in the timing frame of only one processor cycle – 1/ 1500000 of a second!
Amongst other things – this means the programmer MUST ensure, that vector drawing is never “interrupted” otherwise a clean display can not be guaranteed.
Per default the BIOS and nearly all Vectrex programs have interrupts disabled – otherwise the clean display would suffer!
(Exceptions to the rule: Lightpen programs, 3d-imager programs)"
|
|
|
|
Post by gtoal on Feb 11, 2021 21:07:41 GMT -5
From Malban's blog... "Interlude: Vector drawing Drawing vectors with the vectrex hardware needs to be very exact! Depending on the circumstances the user can discern when vectors are drawn with a difference in the timing frame of only one processor cycle – 1/ 1500000 of a second! Amongst other things – this means the programmer MUST ensure, that vector drawing is never “interrupted” otherwise a clean display can not be guaranteed. Per default the BIOS and nearly all Vectrex programs have interrupts disabled – otherwise the clean display would suffer! (Exceptions to the rule: Lightpen programs, 3d-imager programs)" I think we may be at cross purposes. A SWI is not an asynchronous interrupt. There's an IRQ mask and a FIRQ mask, but you can't mask out SWIs. G |
|
|
|
Post by kokovec on Feb 12, 2021 22:42:45 GMT -5
Ah OK, missed that you are writing a user program, like ASSIST09.
I believe SWI saves you a couple of cycles over the other two.
The IRQ and NMI lines are only brought out to the cart port, so not used.
The FIRQ line is brought out to a button on the right controller, but not used (CC F-bit must be cleared first).
|
|
|
|
Post by D-Type on Feb 13, 2021 2:55:23 GMT -5
Not sure if this is of any value to you regarding SWI, but I ported Lennart Benschop's 6809 BUGGY monitor program to the Vectrex, it's similar to ASSIST09 or MIKBUG.
It all works, except I haven't tested the code debug single stepper yet (or Xmodem file transfer, but Motorola SREC transfer works fine).
For code debug, you give it a breakpoint(s) and it replaces the code temporarily at those locations with SWI instructions to give you command line control.
Obviously your code needs to be in RAM and you need a serial port for a terminal. The code is on GitHub as repository VecBUGGY.
It also includes a working interactive command line assembler and disassembler, among other features!
|
|
|
|
Post by gtoal on Mar 8, 2021 17:20:24 GMT -5
I have a follow-up SWI question. If I'm executing code invoked by a SWI, am I right in thinking that any IRQs or FIRQs that would have been triggered are suspended until the SWI returns with RTI. Would the IRQ still be triggered at that point if it had been unasserted before the point of the return?
|
|
|
|
Post by kokovec on Mar 8, 2021 19:16:35 GMT -5
When an IRQ is triggered, further IRQ interrupts are disabled by setting I condition flag.
When an FIRQ is triggered, further fast and normal interrupts are disabled by setting I and F condition flags
I believe an FIRQ has priority over an IRQ, and will trigger if the F condition flag is set while servicing an IRQ.
|
|
|
|
Post by gtoal on Mar 13, 2021 11:10:48 GMT -5
When an IRQ is triggered, further IRQ interrupts are disabled by setting I condition flag. When an FIRQ is triggered, further fast and normal interrupts are disabled by setting I and F condition flags I believe an FIRQ has priority over an IRQ, and will trigger if the F condition flag is set while servicing an IRQ. My question is what happens if IRQ is asserted while a SWI is executing (and therefore IRQ is locked out as SWI has priority), and then the IRQ input signal is deasserted - does the flag remain set, and when you return from the SWI, does that IRQ then trigger? I can't trust an emulator to get this right, I was hoping someone with hands-on 6809 hardware experience might know? G |
|
|
|
Post by kokovec on Mar 13, 2021 16:43:26 GMT -5
I've played with the IRQ line in the past and remember IRQ and FIRQ being disabled during an SWI.
From the datasheet:
IRQ Mask (I)
Bit 4 is the IRQ mask bit. The processor will not recognize interrupts from the IRQ line if this bit is set to a one.
NMI, FIRQ, IRQ, RESET and SWI all set I to a one.
SWI2 and SWI3 do not affect I.
However...
FIRQ MASK (F)
Bit 6 is the FIRQ mask bit. The processor will not recognize interrupts from the FIRQ line if this bit is one.
NMI, FIRQ, SWI, and RESET all set F to a one.
IRQ, SWI2, SWI3 do not affect F.
|
|
