A little extra hardware to disable the NMI signal if an IRQ has recently been triggered?

Neil

I had planned to do that, but it doesn't help with the BRK handling, as it is possible for an NMI triggered e.g. one cycle before a BRK instruction was fetched to not get processed until after the BRK sequence.

What I've done, although it takes a boatload of ICs, is mask out /NMI (by ORing it with a logic one) when a /VP occurs and then unmask it again when an RTI is detected.

Well that's the gist.

I actually run the NMI source into a '74 flip-flop which I can write to to clear that interrupt (just incase /NMI is still being held low).

But there's more (although it possibly doesn't apply here). I have four sources of NMIs: a timer; another '816; a push button and an address break point. Each gets run into its own flip-flop and the state of those flip flops can be read to determine which NMIs have occurred.

As the flip-flops and /NMI mask can only be programmatically written in Kern[a]l mode that stops User mode programs from disabling the preemptive Kernal. A CLI can still be executed but then the Kernal will just undo it next time the timer NMI occurs.

I just noticed that when I replied to this thread I thought I was replying to one of these two threads:

MMU units for 6502 and 65816
Fairly complete multiprocess computer design

Which were both fairly active and related at the time.

Yes sorry for any confusion, I thought it was better to continue the theoretical discussions on these older, more focused threads, and then keep my new thread just about that specific design.

Have you published the design you referred to anywhere? I'd be interested to see it.

I haven't, unfortunately. But it's something I really want to do.

[I should mention I'm writing this during one of South Africa's rolling blackouts with an injured dog next to me. Not much else to do but I'm not great at writing stuff on my phone]

There just doesn't seem to be enough time. Like, ever. If I'm going to document this project properly then I really need to put it online somewhere. And whilst I've got simple file based HTML hosting going I haven't found a decent Wiki that doesn't require to be backed by a database. (Tiddly Wiki is almost there but doesn't seem to have a publish-for-public option)

I could do bits of documention on this forum but that could leave out context that that would be confusing or frustrating.

And I make mistakes. Which is hardly a bad thing, being just a part of learning, but it does mean I've seen some pretty major revisions. And those would take even longer if I had to redo documention to.

With all of that said [and you really are kinda being subjected to flow of consciousness in the dark] I think the design is starting to settle down to the point that I can say: this is done, now I can document. I'm hoping that early next year I should have something that holds together well enough that I can show it here.

Except that comes straight back around to the problem that there's never enough time. Because there's still so much software to write. When I started this back in 2019 or whatever I assumed the software would be the biggest part. And now, four'ish years later I don't think I was wrong. And I know myself. I would far rather be writing code than documentation.

And, you know what, let me post my schematic tomorrow after some cleanup.