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
...
]
Salut, c'est Madram.
Here is an informal list of what to expect next for OrgAmS, in chronological order.
1. Release "Demomakers' Delight".
2. Fix source visualization in trace (bug #c0).
3. Multi-file edition (backbone needed for next point).
4. Include includes.
The first point is a prerequisite, but the number and order of items can change depending on users' votes.
Could you tell more about point 3 ?
« 3. Multi-source handling »
TODO #81: Being able to open several sources in memory.
TODO #A9: Being able to close one particular source (to recover memory).
These would allow both:
* Editing several sources.
* Including one source from another.
NB: Multi-edition raises multiple questions. For instance, should we keep one bloc range per source? If so, how to copy-paste from one source to another?
Tell me what you think.
Also, which UI?
* CONTROL-O: Replace current source (as now).
* CONTROL-SHIFT-O: Open source in new "tab".
or:
* CONTROL-O: Open source in new "tab". (We have to explicitly close the previous one)
(I really prefer this option, for several reasons)
or ???
Since day 1, Orgams reinstall firmware (before assembling) as it was at ùO invocation. The rational being:
* We want each "Assemble(+Jump)" to behave like the first one (modulo the RAM changed in "user" part of the memory).
* Covers most use cases (namely, firmware used at the beginning but potentially overwritten afterward).
* "Just works" (tm).
This behavior gets in the way when trying for instance to analyze memory used.
There is a workaround. Place in the source:
ORG &A500
FILL &1B00,0 ; Warning &BFC8+ overwritten anyway (bug #c2)
ORG ... ; Your program
But maybe we can come with better solutions:
* Special shortcut to override this behavior (meh, conflicts with muscle memory)
* NOFIRMWARE directive in the source.
* Tackle the real issue at hand: diff tool or marking to see which bytes are touched.
WDYT?
« how to copy-paste from one source to another? »
Do you ask for the way to do it in the editor or to implement it?
« CONTROL-O: Open source in new "tab". (We have to explicitly close the previous one) »
This solution is fine for me as it will prevent some mistakes.
Yep I'm asking from an UI point of view. Right now it is not a copy/paste operation, but a select/copy, which made sense for a unique file to edit.
Several options:
• Only one bloc allowed across all opened files. Meh.
• One bloc per file. Then, which one COPY-C would pick?
• One bloc per file, but one shared clipboard. We need shortcuts to copy to/from the clipboard (like CONTROL-C CONTROL-V on pc). Reuse COPY-C?
Preferences:
- Shared bloc range: essential for source communication (copy-paste), I agree, and one bloc across all opened files is enough for me ATM,
- Ok for CTRL-O to open source in a new tab.
Suggestion:
- New directive allowing to open a list of files, for example:
OPEN "player.o"
OPEN "transit.o"
OPEN "cheat.o"
Useful if you want to start a new code session, and open all these file just from the main source.
« one bloc across all opened files is enough »
I'm afraid at some point it will be very frustrating to lose bloc markers because another bloc was selected in another file! Let see if we can come up with a better solution. Mimicking CTRL-C / CTRL-V might be nice after all.
Introducing ad-hoc directives isn't very appealing in my book. Alternatives:
0. Use ùORGOPEN instead (from a BASIC file). It's like ùO,"toto.o" but would return instead of jumping to the editor.
Rational: this RSX is needed anyway for
scripted assemblage.
1. Idem, but allow
RSX to be invoked from source.
Also, bear in mind that if your main .o includes "transit" and "intest", there will have navigation facilities to open those files. Namely, CONTROL-ENTER at include line or for any symbol defined in the external file.
Welcome feature for macros.
It's useful to do:
MACRO setCRTC reg,val
ld bc,&bc00+reg
out (c),c
ld bc,&bd00+val
out (c),c
ENDM
BUT it would be nice to be allowed to pass a register instead of a value (here: easier for evolutive splitting management). Something like (where 'r8' is a 8 bits register like a,h,l,d,e):
MACRO setCRTC reg,r8
ld bc,&bc00+reg
out (c),c
inc b
out (c),r8
ENDM
Indeed! Still pondering whether or not we should use an explicit syntax for non-value parameters. E.g. :
MACRO setCRTC reg,%r8
ld bc,&bc00+reg:out (c),c
inc b:out (c),%r8
ENDM
In the meantime, possible workaround:
rA = 0
rD = 1
rE = 2
...
MACRO setCRTC reg,r8
ld bc,&bc00+reg:out (c),c
inc b
if r8-rA:else:out (c),rA:end
if r8-rD:else:out (c),rD:end
if r8-rE:else:out (c),rE:end
...
ENDM
Meh... One advantage: prevent using C by mistake.
Explicit syntax pro:
* Explicit!
--> ld a,%reg ; clearly shows %reg might be special
--> ld a,reg ; usually seen as ld a,n (&3e)
No syntax pro:
* No special syntax to be aware of or to search in documentation.
* Compatible with maxam and rasm.
