Here is a thread to express the users POV on Orgams, especially what will be useful to integrate in priority. On the
Orgams offical Wiki, there is already a list of
Todos and
Bugs.
First, you can find the
last official Orgams release here and the
last working Orgams version here. The last working version is usually the most recent and advanced.
Today, two suggestions:
- [Monitor] Display the number/date of the version in the Monitor homepage (because we forget this information),
- [Assembler] Allow JR and JP in bloc duplication:
4 ** [
...
bit 7,h
jr z,bit7off
bit7on
...
jr endBit7
bit7off
...
endBit7
...
]
Hard to implement?
About the bloc duplication, I'm aware it's possible to use actual PC value with $, to do for example JR $-4, but it's not very flexible in big loops or when the code is changing...
[Date/revision in monitor] Yep, it will become useful since all incoming beta versions are likely to be useful as they come.
[Duplicated labels] Two solutions:
* local labels (each repetition would introduce fresh invisible global label as the anchor)
* numbered labels
Cf, in french: http://orgams.wikidot.com/v2boiteaidees#toc13
A third solution: pseudo-label '_' = next line.
Eg.
add e:jr nc,_:inc d
Neither solution is really hard to code, but there are two blockers:
* I wish to release "Demomaker's Delight" before introducing substantial changes (which might require switching to 4 ROMs).
* I'm mostly working on my demo.
That being said, I would happily explain the architecture and guide anyone willing to write this features.
Everyone can help, if only to write the unit tests.
Request for comments!
[BRK = nn]
Currently we lose BReaKpoint ability when &BE00-&BE1F is used.
The directive 'BRK = nn' would allow to put the breakpoint routine in a custom place, but I'm not really satisfied with the syntax:
1. Same syntax than 'chair = &cafe', different meaning.
2. Let say that instead of picking a particular address we'd rather embed the routine in the code. I.e. 'BRK = $'. That would clash with code assembled at that address (detected when
bug #A9 is solved, but still not very intuitive).
3. What if we need several access point (e.g. in central RAM, and from &C2 connection)?
Related question:
* Should we replace BRK by a direct call (call &be00 or the custom address) rather than RST &30?
* Pro: doesn't rely on &30 to be setup.
* Con: take more space, might force to swith JR to JP...
A solution that would address most of these concerns:
a. Introduce a BREAKPOINT directive that inlines breakpoint code (similar to RESTORE)
b. Call this routine as needed.
; Somewhere in code,
break
BREAKPOINT
[...]
; Conditional break!
or a:call z,break
REF: todo #05
THX Mdr for your replies.
The third solution ("jr nc,_") is a smart one. The only limit is that you can go further but no forward (jr nc,$-4).
Using the iteration counter ("step(#)") seems to be the better choice.
Revision of Breakpoint: I'm ok with the directive usage, as RESTORE. Don't imply much dev code, and few drawbacks.
For going backward, I've though of '<<' which would 'rewind' to line's start.
4 ** [
ld (hl),a:inc l:jr nz,<<
inc h
]
* Cons of those pseudo labels: you have to refer to the doc to know what they mean. Problem alleviated by inline doc and by the navigation hints (CONTROL-ENTER would lead you to the correct destination).
* Cons of explicit labels: introduces a label just for a local use. It doesn't convey the fact that the label isn't meant to be accessed otherwise (that's the central point of 'Goto considered Harmful' BTW). Alleviated by use of local labels.
For auto-numbering labels I'm not quite sure what would be the best syntax.
X's example would work like this:
4 ** [
...
bit 7,h
jr z,bit7off ; No need for dot prefix here.
.bit7on
...
jr endBit7
.bit7off
...
.endBit7
...
]
Internally, Orgams would unroll somethink like:
rep(0)(0) ; Fresh label
...
bit 7,h
jr z,bit7off
.bit7on ; rep(0)(0).bit7on
...
rep(0)(1) ; Fresh label
...
bit 7,h
jr z,bit7off
.bit7on ; rep(0)(1).bit7on : no conflict
...
]
This solution is fine for me as everything is internally managed by Orgams. However I can see one drawback as we could not directly access to one of the repeated routines because of the invisible labels. Except if we can use 'rep(0)(1).bit7on' in other pieces of code?
The internal syntax such as
« rep(0)(1) » is indeed invisible and invalid as a regular label.
If you want to access one particular repetition, you will have to introduce an explicit numbered label:
4 ** [
...
bit7on(#) ; Will expand to bit7on0, bit7on1, ...
...
]
Or you might write:
4 ** [
blitter(#)
...
.bit7on
...
]
...
ld (blitter3.bit7on),a
...
If you wish to access only one of the iteration, the current OrgamS version makes it possible:
4 ** [
...
IF #-3:ELSE
bit7on ; Only defined at the 4th iteration
END
...
]
