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