HRTmon & other monitors

[chaos]

Hi everybody.

I got stuck on a software monitor setup problem and would really appreciate your help.

I'm working on minimig, trying to debug why a few games don't work on TG68K-based minimigs, that do work on the original minimig with a real 68000 CPU (they also work in WinUAE and on the real hardware). I've already pinpointed the problem to the TG68K CPU core (the latest version, as the previous TG68 core works OK). Now, the minimig includes the ActionReplay cart, but unfortunately, that also doesn't work on the latest CPU core, but that is a separate problem - something to do with the fastRAM implementation probably. For now, I'd like to focus on the problematic games.

I setup a bootable floppy with HRTmon for debugging the games, and here are my problems:

1. I want to setup HRTmon so I'll be able to enter it with the NMI button. If I try to update the NMI vector ($7c, VBR=0) with the m command, after exiting and re-entering the monitor, the vector gets somehow reset to some $00f8xxxx value. What am I doing wrong here? Is this the proper way to setup what I want?
2. Will this approach work at all, or is it possible that the (cracked) game will simply overwrite the NMI vector, thereby disabling the monitor?
3. And another WinUAE-related question - is the NMI button enabled, if you don't select any of the embedded monitors, but start your own from the floppy?

Oh, I have the same problems with ThrillKill.

Please excuse me if these are pretty basic questions, I'm not very familiar with these monitors, I only have a little experience with ActionReplay. I mostly spend my 'hacking hours' on the hardware - Verilog side of minimig.

Thanks!

[Wepl]

Originally Posted by chaos

1. I want to setup HRTmon so I'll be able to enter it with the NMI button. If I try to update the NMI vector ($7c, VBR=0) with the m command, after exiting and re-entering the monitor, the vector gets somehow reset to some $00f8xxxx value. What am I doing wrong here? Is this the proper way to setup what I want?

Why do you want to set nmi vector using the mon??? it will be set already while installing the mon. inside the mon you will be maybe see the vector saved by the mon. also updating this vector will be probably useless because the mon will itself save and restore it.

Originally Posted by chaos

2. Will this approach work at all, or is it possible that the (cracked) game will simply overwrite the NMI vector, thereby disabling the monitor?

most of the games which bang the hardware will overwrite the vector, os friendly ones will usually leave it untouched.
you could use whdload installed games if available and 68010+ which will always allow you to enter the monitor (any interrupts must be enabled)

Originally Posted by chaos

3. And another WinUAE-related question - is the NMI button enabled, if you don't select any of the embedded monitors, but start your own from the floppy?

I think not, because AFAIK WinUAE calls the builtin monitors directly and not via an NMI trigger.

[Toni Wilen]

Originally Posted by chaos

I'm working on minimig, trying to debug why a few games don't work on TG68K-based minimigs, that do work on the original minimig with a real 68000 CPU (they also work in WinUAE and on the real hardware).

Just wondering.. Do they still work in WinUAE if it is configured for non-cycle exact and "more compatible" is not ticked?

3. And another WinUAE-related question - is the NMI button enabled, if you don't select any of the embedded monitors, but start your own from the floppy?

NMI is always available. NMI and activation of built-in monitors is not same thing.

NMI = normal NMI button.
Activate monitor = More than NMI, for example monitor still starts even if NMI vector has been modified.

[chaos]

Hi, thanks for trying to help me guys. I forgot to subscribe to this thread and I didn't see your answers till now, when I'm revisiting this problem.

Originally Posted by Wepl

Why do you want to set nmi vector using the mon??? it will be set already while installing the mon. inside the mon you will be maybe see the vector saved by the mon. also updating this vector will be probably useless because the mon will itself save and restore it.

Yes, I didn't realize that. I managed to make it work by simply letting the mon do its thing.

most of the games which bang the hardware will overwrite the vector, os friendly ones will usually leave it untouched.
you could use whdload installed games if available and 68010+ which will always allow you to enter the monitor (any interrupts must be enabled)

Personally I do use (and love!) WHDload, but in this case I was trying to debug why a specific (cracked) game wasn't working on minimig.

I think not, because AFAIK WinUAE calls the builtin monitors directly and not via an NMI trigger.

I see that now, I also found the required assignment for the Level 7 interrupt in WinUAE, so that is clear to me now.

Originally Posted by Toni Wilen

Just wondering.. Do they still work in WinUAE if it is configured for non-cycle exact and "more compatible" is not ticked?

Yes, they did work on WinUAE with those settings, the problem was specific to minimig, if I remember correctly the games needed fastRAM completely disabled to work, so it turned out to be an easy fix.

NMI is always available. NMI and activation of built-in monitors is not same thing.

NMI = normal NMI button.
Activate monitor = More than NMI, for example monitor still starts even if NMI vector has been modified.

OK, I get that now, thanks. Just a question - does the built-in monitor work even if the supervisor stack is pointed to an odd address?

On to the real problem - I would like to implement HRTmon for the minimig in the same way as it works in WinUAE - so no need to first load / enable / configure it, and it should work regardless of where the NMI vector is pointing.

The latter part is already done - I can intercept the CPU reading the NMI vector address and return whatever address I choose. The only problem I am having is obtaining a binary of HRTmon that will work like that - so after being loaded into memory (which can be fixed address), it should be ready to run, like in WinUAE.

I see that in WinUAE, HRTmon is loaded to $A10000, is that a good address space to use? Why not $A00000? There seems to be some config data (memory sizes etc) at the beginning of that space, if I'm reading the WinUAE sources correctly. Is that used by HRTmon somehow?

So basically, I would like to get / make a binary of HRTmon that will get loaded to a fixed address, lets say $A00000, and will be callable with NMI button emulation without first having to load it. Could I use the binary image that is used in WinUAE? Or the ROMmable image? Will any of these work in the way I described, or will they require some changes? I'm really not knowledgeable enough to disassemble / change the sources myself

Thanks!