Memory Full

Forum / Development

Orgams - The Users Speak!

Hicks * 21 Oct 2018 11:55:51 * Modified at 11:57:06

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?

Hicks * 23 Oct 2018 10:43:16 * Modified at 10:43:34

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...

m_dr_m * 25 Oct 2018 12:26:34

[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




m_dr_m * 25 Oct 2018 14:08:49

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.

m_dr_m * 26 Oct 2018 11:53:11

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

m_dr_m * 26 Oct 2018 17:01:24

Inline BREAKPOINT added as TODO #A7

Hicks * 04 Nov 2018 16:16:39

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.

m_dr_m * 07 Nov 2018 15:12:06 * Modified at 15:14:38

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.

m_dr_m * 07 Nov 2018 15:16:29

For auto-numbering labels I'm not quite sure what would be the best syntax.

m_dr_m * 13 Nov 2018 14:28:59 * Modified at 14:30:22

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
    ...
    ]


toms * 16 Nov 2018 08:56:20

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?

m_dr_m * 16 Nov 2018 11:56:38 * Modified at 11:57:12

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
    ...
]

m_dr_m * 08 Dec 2018 20:43:49 * Modified at 20:45:43

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.

ast * 09 Dec 2018 09:19:57

Could you tell more about point 3 ?

m_dr_m * 09 Dec 2018 11:44:59 * Modified at 11:45:37

« 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.

m_dr_m * 09 Dec 2018 11:51:58 * Modified at 11:52:14

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.

m_dr_m * 09 Dec 2018 16:10:54

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 ???

m_dr_m * 18 Dec 2018 10:11:49 * Modified at 10:17:18

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?

toms * 18 Dec 2018 22:34:21

« 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.

m_dr_m * 19 Dec 2018 16:29:45 * Modified at 16:30:10

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?

Hicks * 27 Dec 2018 11:39:22

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.

m_dr_m * 27 Dec 2018 18:52:46 * Modified at 18:53:39

« 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.

Hicks * 20 Feb 2019 15:56:47 * Modified at 15:58:04

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

m_dr_m * 21 Feb 2019 01:19:10 * Modified at 01:20:38

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.

m_dr_m * 24 Feb 2019 18:30:36 * Modified at 18:31:47

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.