tokra wrote:Looking forward to trying this out @ Revison
majikeyric wrote:Will MiniMon be available to public one day?
eslapion wrote:Given a schematic, I'd be glad to make a contribution.
chysn wrote:Sweet!
I'd guess these four responses signal interest in the hardware being realised.
So, who else wants a MINIMON cartridge?
I'd like to have some more responses in that matter here in the thread, especially from my beta testers. At one point, eslapion and me will have to agree upon a price tag, and that at least partly depends on the number of interested people for the first batch.
As a refresher, here is the command set of the monitor:
Code: Select all
A <address> <mnemonic> [<operand>]
. <address> <mnemonic> [<operand>] - assemble instruction to address, give
prompt for next instruction,
C <start> <end> <start2> - compare memory block between start and end with
memory block starting at start2, list different addresses,
D [<start> [<end>]] - disassemble instructions from memory,
F <start> <end> <byte> [<byte>]*
F <start> <end> '<string> - fill memory with a single byte or a pattern,
G [<address>] - execute code at address, use the BRK instruction to return
to the monitor,
H <start> <end> <byte> [<byte>]*
H <start> <end> '<string> - search pattern in given address range,
L ["<file name>" [<dev.-#>]] - load file into memory,
M [<start> [<end>]] - dump memory as hex bytes, 5 bytes/line,
> <address> [<byte>]* - change up to 5 bytes in memory, beginning at
address,
R - show register dump,
;<pc> [<sr> [<ac> [<xr> [<yr> [<sp>]]]]] - change register dump,
S "<file name>" <dev.-#> <start> <end+1> - save memory to file. Note, end
address given is exclusive (for example, use the parameter list "... 1000
2000" to save from $1000 to $1FFF). This matches the convention used by many
other monitors,
T <start> <end> <start2> - transfer memory block between start and end to
memory block starting at start2. Overlapping transfers work in both
directions,
V ["<file name>" [<dev.-#>]] - compare file with data in memory, and,
finally,
X - exit monitor.
Some remarks:
MINIMON pretty much implements all of the VICMON/HESMON feature set with a few exceptions: the "new locator" and "instruction trace" facilities had to go. IMO, they simply don't deliver, no "new locator" would be able to detect when immediate operands form part of a address (that still takes good guesswork when re-engineering source from 6502 object code!) and the instruction trace facility wouldn't work with interrupt routines because of resource clash (interrupt vectors and VIA timers), which prohibits tracing the most interesting cases, namely cycle exact raster interrupts. The breakpoint facility is implemented in a minimal way with the BRK instruction.
I left out other "goodies" like the scrolling disassembler for good. IMO, scrolling to lower addresses can't be done 100% accurate (the disassembler could "hook" onto operand fields mistaken for opcodes), and personally, I like to use cursor down to make room on screen when working in the monitor and don't like an automatic insertion of further disassembled lines onto screen. "D" on its own disassembles roughly half a screenheight full of instructions from the last known address, that's good enough for me.
The A and D commands don't display the hex values of the instruction. With a proper line layout, that simply wouldn't fit into 22 chars/line, requiring two lines per instruction. Having more lines of code on screen is more valuable, IMO. If one wants to know the hex values, the M command still can be used for that.
The M command doesn't feature a PETSCII dump at the end of each line. I wrote a small utility program that fits into $02A1..$02FF, which displays a whole page as PETSCII (page number in A), uses the breakpoint facility, places a "G" into the keyboard buffer and auto-increments the page, so one can quickly scan a bigger memory range for text strings by repeatedly tapping RETURN.
MINIMON changes the BRK and NMI vectors, the latter one to keep itself and the BRK vector 'life' even when STOP/RESTORE is pressed.
As stated in the OP, input and output of MINIMON can be redirected for batch processing with files, printer dumps and remote debugging over RS232.
Now for the best part:
Exactly *no* relevant zeropage addresses are used by MINIMON, with the exception of a few ones that would be necessary anyhow to communicate with the KERNAL during file operations. Especially $FB..$FE are kept free.
MINIMON only uses workspace at rather unusual places, at the bottom of stack ($0100..$011E) and in the BASIC input buffer ($0200..$0258) where for other programs normally it is no good idea to keep code/data there for obvious reasons. The often used buffers at $02A1 and $033C are kept free.
I thus took quite some precautions that MINIMON interoperates well with most other programs, not only by placing it into the I/O range, but also by minimizing resource conflicts in other memory ranges.
Cheers,
Michael
