DigicoolThings Forum

djrm wrote: ↑Sat Aug 31, 2024 7:04 pm Looking at the schematic of the mecb motorola i/o board I see that the NMI signal from the 6840 PTM is inverted. I see no accommodation for this in the MAME implementation. THhs is perhaps causing the problem I have getting the Assis09 single stepping to work. No other device interrupts need inverting.

Indeed, ASISST09 uses PTM counter #1 ouptut O1 (which is positive logic), to trigger an NMI for breakpoints and single stepping.

Hence, the active high O1 PTM output needs to be inverted (and open drain / open collector), to correctly drive the NMI bus signal.

This inverted / open drain functionality would need to be implemented in any software emulation of the PTM output -> CPU NMI signal interaction.

My suspicion is moving to a signed compare will just shift the location of the issue i.e. "D 7F00 FF" will likely cause problems now. I think part of the issue is that it adjust the start to a XXX0 boundary but it doesn't do the same for the final address - otherwise it would at least stop on the "equal" component of the compare (eventually).

I agree that there appear to be several problems with the logic in this routine. The reason the "D FFE0 40" originally results in weird behaviour is because it compares the current position (after dumping a line) with the final location. In this instance the final location is 0020 and after the first line is dumped it is at FFF0 which in the unsigned compare makes it think it has past the final location and so it stops. This doesn't happen in the "D C000 40" case because the final location is at C040 and so it proceeds through C010, C020, C030 and C040 as expected.

The code probably needs some improved checking for these edge cases but it would need some careful thinking to get it right without going over the 2K limit.

Ah, I should have looked at the schematic more carefully, I'd assumed nmi was being driven by the interrupt pin. Anyway this explains why I've not seen an interrupt in mame. Now I need to see how to patch the output to the nmi input. I've seen some weirdness in some of the mame devices. I'll look again. Thanks for your help. Btw I've updated the previous pdf card post with brief instructions to make a small booklet. David

Would something like this work for the NMI (in addition to the original IRQ line - I think that is needed for normal timer operation): I'm not sure if it would compile - I can't check right at this moment and I'm not very familiar with the tracing in Assisdt09 so I wouldn't know how to check it without more reading.

djrm wrote: ↑Sat Aug 31, 2024 8:14 am I tried changing the compre from unsigned to signed and this has improved things in most cases, certainly the bug as described is fixed but there are other faults or side effects too.

A new morning here in NZL.

I'm not sure I agree with changing to a signed comparison for the X address value.
As I saw it, this is simply a 16-bit overflow problem.
Specifically, I would expect that changing to a signed 16-bit compare would just move the overflow problem from $FFFF to $7FFF ??

The HSDTA routine is written to output lines of 16 memory locations, on a 16 boundary START ADDRESS, until we are higher or same (on each 16 boundary), when compared to the passed END ADDRESS.

Analyzing this issue again this morning, it seems to me that the root issue would be best resolved if both the passed START ADDRESS and END ADDRESS were passed as on a 16 boundary (instead of just the START ADDRESS being on a 16 boundary!).

This logic correctly follows with the function of HSDTA. i.e. Output 16 byte blocks on 16 byte boundaries!

As an example, if you do: You get the same result (of course), as with:
i.e. One 16 byte block displayed.

Likewise, I notice our "display the reset vectors" issued is resolved simply by self-rounding the specified size up to the next 16 boundary. All is good!

So, in summary, I'd now probably leave HSDTA as is, and instead go back to CDISP, where I'd round up the retreived COUNT (or END ADDRESS), to the next 16 boundary. This would then align the END ADDRESS passed to HSDTA, with how it currently forces the START ADDRESS to a 16 BOUNDRY!

Doing this would resolve the "runaway wrap-around" issue we currently experience.

I note this however does leave one remaining "possible flaw", being that a specified Count which causes an Address Wrap, results in the listing ending early at the top of memory.
e.g. But, I don't actually see this remaining "possible flaw" as actually a real issue. As there is certainly some logic to not actually wrapping, when displaying to the top of memory.
Note: The wrap does occur if the "wrap-around" Count value is provided with a START ADDRESS in the last 16 bytes of memory, as the first 16 boundary END ADDRESS comparison happens when X has just overflowed back to zero (so is less than END ADDRESS on first compare).
i.e.

Okay, it's Sunday here, so I should now have my morning coffee and relax.

epaell wrote: ↑Sat Aug 31, 2024 10:36 pm My suspicion is moving to a signed compare will just shift the location of the issue i.e. "D 7F00 FF" will likely cause problems now. I think part of the issue is that it adjust the start to a XXX0 boundary but it doesn't do the same for the final address - otherwise it would at least stop on the "equal" component of the compare (eventually)....

I just read your post above, which we appear to have cross-posted on.

It certainly sounds like we are pretty much on the very same track.

djrm wrote: ↑Sat Aug 31, 2024 10:46 pm Btw I've updated the previous pdf card post with brief instructions to make a small booklet. David

Much appreciated!

which we appear to have cross-posted on.

All good ... cross-posting is fine ... it's crossing the beams that we need to worry about!

epaell wrote: ↑Sat Aug 31, 2024 10:52 pm Would something like this work for the NMI (in addition to the original IRQ line - I think that is needed for normal timer operation):

Code: Select all

	m_ptm->o1_callback().set_inputline("maincpu", INPUT_LINE_NMI);

I'm not sure if it would compile - I can't check right at this moment and I'm not very familiar with the tracing in Assisdt09 so I wouldn't know how to check it without more reading.

Good morning from UK,

Thanks for the suggestion, the single stepping is almost working now. I now see NMI interrupts occuring.
If I enable the mame debugger with a breakpoint at the NMI ISR I see an NMI when assis09 starts. I tried adding .invert() to the end of setinputline but the initial NMI still occurs, perhaps this is normal as if i continue then assis09 appears to be running properly otherwise. Still not able to single step but must be getting closer to a solution now.

And, of course, you were quite right about my suggested change to the D command moving the problem, it does. I'll leave my change in place until I need to check memory around 7fff. My initial thought was that this would happen but I made the change and I thought I had checked this case but obviously not.

Hello everyone,
Today I got nowhere trying to get NMI from the PTM o1 output working properly, however...

Instead I have reconfigured mame to give NMI interrupt from its irq pin and reconfigured Assist09 to enable interrupts on the PMT when single stepping. Much to my surprise this kind of works in that I can step through rom code at last.

I dont think that the Assis09 'S' command is working properly though, as I step through all the monitor code is visible as well as my code. Oh well a small improvement I suppose.
n.b. It would be nice to see the next instruction disassembled together with the register dump after the breakpoint. I wonder how I could do that ...
Have a nice day, David.