I have too much on my plate! Ok, we are all in that case ; yet you might be interested in contributing, especially if you're using the tool or plan to.
The time investing in improving the tools will be recouped!
CRTC Emulation
The Z80 is pretty complete, it would be very useful to have CRTC emulation as well. CRTC 1 for a start!
CRTC internal registers detection
I'm using the MF2 to get CRTC registers (R0, R1, ...) at breakpoint.
Now, I'd like to get the internal register (C0, C4)
This can be done by e.g. measuring time to next halt, next vsync, etc.
On CRTC 1 the status register gives the "Display Enable" flag (off for Border), which can be useful.
Persistent monitor screen
When exiting monogams (the monitor), its content is lost. I am not content.
It should be stored (would also allow to scroll up to see past output).
Just storing the variable-size text lines, not the full screen!
Just two routines:
append_line
; Append line to the history
; IN: HL = Null-terminated string
get_line
; IN : A = line number in reverse order (0 being the most recent)
; Out : If line still exist:
Carry is set
HL = pointer to Null-terminated string (in rotating history buffer)
; Otherwise, NC
Wait! I could reuse my command-history manager. Just switching the &100 buffer for a &800 buffer.
Other wishes thrown in the well!
Hexadecimal memory/file editor
The feature I'd would really like is "custom width", either smaller or larger than what the screen area can display. Very useful to examines array of structures with an arbitrary alignment. E.g.
&4000 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00
&4100 00 00 00 00 CC FF 00 00 00 00 00 00 00 00 00 00 00
&4200 00 00 00 00 CC 00 00 00 00 00 00 00 00 00 00 00 00
The memory/file read and update are already abstracted out, so you would just need to call some simple routines to fill your buffer/update the memory (for files it would be pushed to disc at explicit save command).
Sorting chunks
Context: assembled code is cached into chunks (slices) of &100 bytes (with a header containing some meta-data, but you don't need to be concerned with the internal details, see point below about iteration routine).
The only annoyance is that are stored in assemblage order, not memory order.
Respecting memory order would unlock:
* Bug #A9 [Assembler] Overlapping output should raise error.
* WRITE directive
Actually sorting can be done on the fly, I just need a tiny routine that doesn't require to be fast:
get_lowest_chunk_higher_than
; In: BCDE = 32 bits address (in the form bank:address, like &7EC0:&BABE)
; Out: If such chunk exist (lowest address >= BCDE), Carry, DE = ID chunk (D=MSB, E=bank)
; Otherwise NC
There already is a routine iterating through all the chunks, calling back a hook for each chunk, passing the start address in BCDE and ID in IXH (bank), H (MSB).
Hum actually it was longer to describe than it would have been to code!
Suffix tree or any equivalent datastructure for fast label lookup.
Assemblage of a single source is quite fast as all labels are pre-encoded with their IDs.
This is not true anymore with IMPORTs, since the same label will have a different IDs in a difference source. Hence the need to resolve the label cross-sources.
For now it is done by brute search, as Orgams wasn't designed for this use case.
Any fast label -> id lookup would drastically improve this state of affair.
Wait, maybe I could use a fast 13 bits hash. I must study Prodatron's article!
Any contribution for todos #116 to #11d
Please see here: http://orgams.wikidot.com/todos (http://orgams.wikidot.com/todos)
[Bonus] Fast Parser
In a similar fashion, the parser was designed to be easily amendable (just updating the grammar, no code needed), not fast, as each edited source line is encoded on the fly by the editor.
It will become a assemblage-speed bottleneck for the incoming "macro textual substitution" feature (sacré Offset!), and an hindrance to port the assembler on other platforms which might not use the integrated editor (well there maybe the right solution here is to port the editor as well. I've heard Symbos is quite capable).
So the idea would be to be able to take the grammar (for a recursive descent parser) and generate the equivalent bottom-up parser.
I meant "Call Para Contribution"!