rich_r wrote: ↑Wed Jun 05, 2024 11:28 am
Many thanks again Bob - I'm really liking the symbol shift+NMI option, as most of the time I don't want the monitor so it's nice to go straight to the file selector.
I have found myself often using fossimon to enter pokes for infinite lives etc. in games, as it means I can do a little disassembly of the commands the poke is going to update before I do it, to see what it does (OK, so most of the time it's just inserting a NOP, but not always) - which is good for me re-learning Z80. I used to be reasonably proficient when I was 16, but that was 34 years ago!
Glad you're finding the symbol shift + NMI button option useful. Thanks to @8BitSC for suggesting it. Yeah, you're usually poking a NOP for infinite lives or a RET (201) for something fancy like invulnerability.
Dear Bob, as for command TR. I tried it, but it behaves differently than you say in manual. Upon TR, one instruction on PC or set address should be carried out and then return to monitor should happen. But when I enter TR, it just returns to the program, no return to monitor takes place.
I would have an enhancement for TR command. Could there be just one key press instead of writting TR every time when I want to carry out instruction? For example in Devastace or in STS monitor it is key SS+Z. It would be much easier for the user just to press a key instead of typing command TR all over again.
Thanks anyway for this superb monitor I was missing it a long time in esxdos.
Hood wrote: ↑Tue Jun 11, 2024 9:12 pm
Dear Bob, as for command TR. I tried it, but it behaves differently than you say in manual. Upon TR, one instruction on PC or set address should be carried out and then return to monitor should happen. But when I enter TR, it just returns to the program, no return to monitor takes place.
tr command is working for me as expected - it leaves the monitor, executes the opcode and then switches back. What version of fossimon are you using and what edition - menu, no menu or symbol shift - did you install? Some steps to replicate would be helpful. What were you trying to trace - was it a specific game or demo. If so, at what point had you broken in with the monitor? If it's something else can you create a small example (happy to assemble example source) that demonstrates the issue with the trace command? Thanks.
You can now use the new 'lg' command to write a message to the log file (/tmp/mon_log.txt). 'lg' displays the contents of the log. 'lg !' deletes the log, 'lg +' copies subsequent output to the log file and 'lg -' stops this re-direction. This lets you dump memory and disassembly along with your own comments to a readable text file.
Added fast command key - executed by pressing EXTEND MODE. Currently only used when tracing, e.g. after returning to the monitor from the trace, pressing EXTEND MODE will immediately execute another trace command.
Added 'rm' command to delete a file and the 'ls' command now shows 16 bit file size (< 65536) for files. The monitor now remembers the last used address (memory dump / disassembly) between sessions.
bob_fossil wrote: ↑Wed Jun 12, 2024 5:34 pm
tr command is working for me as expected - it leaves the monitor, executes the opcode and then switches back. What version of fossimon are you using and what edition - menu, no menu or symbol shift - did you install? Some steps to replicate would be helpful. What were you trying to trace - was it a specific game or demo. If so, at what point had you broken in with the monitor? If it's something else can you create a small example (happy to assemble example source) that demonstrates the issue with the trace command? Thanks.
Hi Bob, had time to test it at last. The problem is simple. It is ZX Next real HW that is doing this glitch. When I used monitor version 01 and 03 with DivIde, TR behaved as expected. But I tried version 01 and 03 on ZX Next and TR does not return to monitor. Bad for me as I need to debug my program on ZX Next. Do you have possibility to fix it, please?
By the way the EXTEND MODE feature, is absolutely perfect. Perhaps one more thing, can TR, or EXTEND MODE carry out just the instruction+ change registers on the screen accordingly without jumping back to the game? Why? Because it would take shorter time. Otherwise the EXTEND MODE is perfect.
Hood wrote: ↑Mon Jun 17, 2024 5:08 am
Hi Bob, had time to test it at last. The problem is simple. It is ZX Next real HW that is doing this glitch. When I used monitor version 01 and 03 with DivIde, TR behaved as expected. But I tried version 01 and 03 on ZX Next and TR does not return to monitor. Bad for me as I need to debug my program on ZX Next. Do you have possibility to fix it, please?
No, I don't have access to a ZX Next. The tr command inserts the following bytes $cd, $66 and $0 - a call to the ROM NON-MASKABLE INTERRUPT routine - after the traced instruction to force a switch back. I don't know why this would fail on a ZX Next. If you try to trace an address, if you go back into the monitor via the NMI, if you disassemble the address that you tried to trace, is the call to $66 still there?
Hood wrote: ↑Mon Jun 17, 2024 5:08 am
By the way the EXTEND MODE feature, is absolutely perfect. Perhaps one more thing, can TR, or EXTEND MODE carry out just the instruction+ change registers on the screen accordingly without jumping back to the game? Why? Because it would take shorter time. Otherwise the EXTEND MODE is perfect.
The way the monitor works means the memory has to be restored before executing the trace. The opcode is executed and then the monitor is switched back in. This does take time but it was the simplest and easiest way to do a trace for me. At the time I was writing this, I wasn't even sure anyone would ever be using it so I didn't spend a lot of time on it. I can see a way to do a faster trace, which might also work with ROM routines but that would require a rewrite of the tracing code. I'll think about it some more and add it to the to-do list.
bob_fossil wrote: ↑Mon Jun 17, 2024 6:15 pm
No, I don't have access to a ZX Next. The tr command inserts the following bytes $cd, $66 and $0 - a call to the ROM NON-MASKABLE INTERRUPT routine - after the traced instruction to force a switch back. I don't know why this would fail on a ZX Next. If you try to trace an address, if you go back into the monitor via the NMI, if you disassemble the address that you tried to trace, is the call to $66 still there?
The way the monitor works means the memory has to be restored before executing the trace. The opcode is executed and then the monitor is switched back in. This does take time but it was the simplest and easiest way to do a trace for me. At the time I was writing this, I wasn't even sure anyone would ever be using it so I didn't spend a lot of time on it. I can see a way to do a faster trace, which might also work with ROM routines but that would require a rewrite of the tracing code. I'll think about it some more and add it to the to-do list.
Hi,Bob. No, the call to 66h is missing after instruction carried out by TR. So probably ZX Next does not allow write to memory? I would say, Next authors would have to help here.
But I entered manually call 102 with BR command right after instruction to which PC was showing. Dissasembly showed call 102, but Next is ignoring it. Strange,indeed.
Thanks for putting faster TR execution on a todo list.
Hood wrote: ↑Mon Jun 17, 2024 8:48 pm
Hi,Bob. No, the call to 66h is missing after instruction carried out by TR. So probably ZX Next does not allow write to memory? I would say, Next authors would have to help here.
But I entered manually call 102 with BR command right after instruction to which PC was showing. Dissasembly showed call 102, but Next is ignoring it. Strange,indeed.
Thanks for putting faster TR execution on a todo list.
Bob, maybe, if you can tell the mechanism around TR command, then I can raise the question about it in the Next community so that they can fix it. As I believe, it is rather problem on ZX Next side then on Fossimon. Thank you. Hood
Hood wrote: ↑Tue Jun 18, 2024 7:57 am
Bob, maybe, if you can tell the mechanism around TR command, then I can raise the question about it in the Next community so that they can fix it. As I believe, it is rather problem on ZX Next side then on Fossimon. Thank you. Hood
As I said, the tr command inserts the following bytes sequence $cd, $66 and $0 (basically a call to the ROM NON-MASKABLE INTERRUPT routine) after the traced instruction to force a switch back in to the monitor. If that call to $66 isn't working, that would explain why it isn't switching back to the monitor.
Hi Bob,so it is True. Next does not jump to address 66h,but does reset instead. While divide jumps to nmi browser. So I have to write to Next authors about it to correct this behaviour.
Hood wrote: ↑Thu Jun 20, 2024 3:23 pm
Hi Bob,so it is True. Next does not jump to address 66h,but does reset instead. While divide jumps to nmi browser. So I have to write to Next authors about it to correct this behaviour.
Just for completeness, there was an answer on FB-Group "ZX Spectrum Next" to @Hood ´s question:
Allen Albright:
The bits configuring the divmmc (besides the nmi button you've found already) are nextreg 184 through 187. https://gitlab.com/SpectrumNext/ZX_Spec ... extreg.txt
The soft reset values shown set the Next's divmmc to behave the same as the divmmc peripherals available for the original machine. Well, almost - divmmc interfaces trap regardless of what rom is present which is the reason they are incompatible with 128K roms. Divmmcs have traps on rst 0, 8 and $38 and in nextreg 185, the Next's divmmc is only setting rst 0 to come on when any rom is present. It shouldn't make much difference but to have completely the same behaviour, bits 1 and 7 should also be set.
Anyway you are right about the nmi at $66 (102) in memory - the Next's divmmc is qualifying that with the divmmc button. If the button is not pressed, the trap there is not being triggered. This is how the multiface works but if divmmc interfaces do not qualify with the button then I can change this in the next core version. This is documented in nextreg 187 bits 0 and 1 (... + button). The Next is a more capable machine than the standard spectrums and there is another way to handle nmi interrupts by placing nmi code in the bottom 8k at address 0x66 so this choice was in place to allow that in addition to allowing divmmc nmi button separately.
To change the nextreg from standard Sinclair basic, you have to do two OUTs. The first to port 9275 selects the register and the second on port 9531 either writes a new value or reads it:
OUT 9275,reg: OUT 9531,val
OUT 9275,reg: PRINT IN 9531
Added a new command, 'fc' to compare the current memory contents against the contents of a saved file. This outputs any differences in bytes between the file and memory. This may be useful for hunting down item counters or timers in games.
Also fixed an issue where pressing cursor up could restore a non existent line after you enter the monitor.
Luzie wrote: ↑Sun Jun 23, 2024 1:59 pm
Just for completeness, there was an answer on FB-Group "ZX Spectrum Next" to @Hood ´s question:
Dear Luzie, many thanks for your valuable answer.
Although I cannot figure out what Next ports should I change to make call #66/ RANDOMIZE USR 102 work, ie. jump to address #66 and trigger nmi menu in Divmmc in Next?
Or do I get it right, this would only work in case you change Next's core?
Hood wrote: ↑Mon Jun 24, 2024 6:26 am
Dear Luzie, many thanks for your valuable answer.
Although I cannot figure out what Next ports should I change to make call #66/ RANDOMIZE USR 102 work, ie. jump to address #66 and trigger nmi menu in Divmmc in Next?
Or do I get it right, this would only work in case you change Next's core?
Thanks
Hood
Dear @Hood . The Infos are posted on FB by @Alcoholics Anonymous , if I´m right. So I mention him here, hoping he will explain a little bit further. As I understand it for me, I think there´s are changes needed in Next core to enable what you ask for.
