I have decided to release the source code of the M4 board's HACK menu. This is a Multiface II like feature of M4 board, just more powerful :)
I never really got around to add and make all the things with this that I envisioned and as time is ticking away, I thought I'd give it to anyone who wants to give it a go or just for educational/fun purposes (is there any other NMI rom sources available?).
The source code is here:
https://github.com/M4Duke/m4hackmenu (https://github.com/M4Duke/m4hackmenu)
The HACK menu must be assembled with RASM assembler (from http://www.roudoudou.com/rasm/ (http://www.roudoudou.com/rasm/)) into nmirom.bin and copied to the root of the microSD card.
And one should use the "M4FIRM.BIN" file as development firmware on the M4 board to have it autoload from the microSD card (use CPCXFER for quick development).
You can now customize, add new features or do nothing at all to the HACK menu.
If you have an older revision M4 board without HACK menu button, you can see here how to add it: http://www.spinpoint.org/2019/04/01/m4-board-still-kicking/ (http://www.spinpoint.org/2019/04/01/m4-board-still-kicking/)
Should luck strike and someone manages to improve or fix some bugs, I will be happy to embed it with a new firmware update.
Some techinical details:
When the HACK menu button is pressed, an NMI is triggered and the HACK menu code is executed (mapped as a lowerrom replacment 0-0x3FFF).
First thing it does after saving the registers, is saving all main memory to m4/tmp1.bin so it can be reloaded later after the GUI (which then can trash memory).
The area 0-1 and 0x100 (sna header) of the HACK menu/NMI rom is (volatile) written by the M4 hardware (only) to retain all hardware register settings when resuming execution.
If any questions, let me know ! - Have fun :)
EDIT: M4 (upper) ROM source code on github was updated aswell, as there is some interaction with the HACK menu (lower rom) -> memwrite line 5650.
https://github.com/M4Duke/m4rom/blob/master/M4ROM.s (https://github.com/M4Duke/m4rom/blob/master/M4ROM.s)
This seems very interesting!
Do you think it's possible to add breakpoints, or do step-by-step debugging?
Ooooh now I'm dreaming... Would it be possible to send the registers to the PC (which could display them), and have a PC-controlled debugger (with any kind of C++/JS/whatever application)?
Quote from: Targhan on 20:36, 15 May 20
and have a PC-controlled debugger (with any kind of C++/JS/whatever application)?
hmmm, how this can be controlled external or make Z80 single-step?
The Connection to an PC is not a big Problem(?), e.g. with an Serial-Interface
Quote from: Targhan on 20:36, 15 May 20
Do you think it's possible to add breakpoints, or do step-by-step debugging?
Ooooh now I'm dreaming... Would it be possible to send the registers to the PC (which could display them), and have a PC-controlled debugger (with any kind of C++/JS/whatever application)?
Breakpoints would have to be via injection to the running code (software breakpoints).
It would be possible to open ie. a tcp/ip connection to a server (PC) and send register and memory contents via the HACK menu, unlike Multiface 2, M4 can use the entire memory for hack/debug menu as you have a quick harddrive (SD card) you can use as virtual memory (dump and restore memory).
Quote from: SOS on 21:36, 15 May 20
hmmm, how this can be controlled external or make Z80 single-step?
The NMI can be triggered via the M4 web server aswell, so you don't have to physically press the button.
Single stepping would have to be done via software analysis.
QuoteBreakpoints would have to be via injection to the running code (software breakpoints).
Do you mean, special opcodes like #ED, #FF?
Great news!
Thanks for both the code and opening it!
On a related note, I have just upgraded Orgams to make use of Multiface II for capturing proper bank connection (MMR) at breakpoint (incoming in beta J). Does the M4 also keep track of I/O?
Hardware breakpoint (e.g. when a certain address is written to) would be fantastic, but I don't know if you can monitor that.
Quote from: Targhan on 20:36, 15 May 20
Do you think it's possible to add breakpoints, or do step-by-step debugging?
What do you miss in Orgam's step-by-step debugging?
QuoteWhat do you miss in Orgam's step-by-step debugging?
You know how I work and what I'm interested in achieving. This is called remote debugging.
Quote from: Targhan on 11:17, 16 May 20
Do you mean, special opcodes like #ED, #FF?
You can trigger the NMI (Hack menu) via software like this:
ld hl,0x431D ; C_NMI
ld bc,0xFE00
out (c),c
out (c),l
out (c),h
ld b,0xFC
out (c),c
Obviously you would need some stack space to save Z80 regs that are used to trigger the menu/NMI and pop them back in the HACK rom.
Quote from: m_dr_m on 11:55, 16 May 20
Great news!
On a related note, I have just upgraded Orgams to make use of Multiface II for capturing proper bank connection (MMR) at breakpoint (incoming in beta J). Does the M4 also keep track of I/O?
Yes, M4 keeps track of the I/O registers. Once the HACK rom is triggered you will find the I/O register values at the time of triggering in the HACK menu lower-rom at rom offset 0x100-> .
Quote
Hardware breakpoint (e.g. when a certain address is written to) would be fantastic, but I don't know if you can monitor that.
M4 does not keep track of the Z80 registers (as these can be saved via software) so not keeping track of PC to do an actual HW breakpoint.
Quote from: m_dr_m on 11:58, 16 May 20
What do you miss in Orgam's step-by-step debugging?
Does ORGAMS do a real output/input (OUT/IN) when doing a step-by-step debugging?
Thanks for providing the code! :) :) :)
Does someone made a version with integrated disassembler ? ascii-memory reading is not that much helpful to debug a program ;)
I would be much interested to test/use it.
Bug report: When doing a 'break' inside an expansion ROM the hack menu will not return to the proper ROM. Since there is an option to see which ROM was banked in, this should be possible.