Hicks: It shouldn't be.
This buffer is only cleared with CTRL-N.
Can you reproduce the problem?
I will try.
Another strange thing:
8 ** [
2 ** BYTE #
2 ** BYTE #+64
]
Generate #00,#01,#40,#41,... instead of #00,#00,#40,#40,...
Maybe confusing, not strange at all! The `#` is the innermost counter (associated with 2 **).
You want:
8 ** [
2 ** BYTE ##
2 ** BYTE ##+64
]
About the "CTRL-DEL / CTRL+P problem", I tried again and the buffer is still here... So I guess I pressed CTRL+N by reflex last time.
Ok for the "repeted byte problem", it's a little bit confusing but we just have to know how to avoid the issue.
Sorry for those two fake bug report news!
It's not
that confusing. Consider:
3 ** BYTE # ; Gives 1, 2, 3
1 ** [
3 ** BYTE # ; Also gives 1, 2, 3
]
The assembler cannot read your mind and associate # with the counter you are thinking of.
So it's best:
* To be consistent (# is always the innermost counter)
* Make sure 1 ** [ CODE ] is equivalent to CODE.
Considering using CONTROL-f1 to CONTROL-f9 to switch between opened files.
* Pro: More handy than cycling through files. You quickly memorize which number is which file (also it will be
* Con: Limited to 9 files.
What do you think?
A tip from Orgams' coder himself.
Since CTRL-ENTER now works in comments, you can put a table of content as the top or bottom of your source:
; Shortcuts:
; - params
; - start
; - gen_texture
; - frame1
; - frame2
; - variables
What about unrolling the macro's content under its name inside the source when pressing a special key with the cursor pointing on it?
That would be very useful to see on the same screen the macro's content with what's happening before and after, for optimization sessions (jumping from the macro's usage to its definition many times is quite distracting).
I don't know if this feature is already planned?
I add: auto-completion would really be very useful to be able to use longer (and therefore more explicit) names more easily.
When using IMPORT directive, I plan to make the source available in one of the tabs.
IMPORT "math"
Since math.o is loaded for assembling, we might as well want to see it. CONTROL-ENTER on the directive would switch to math.o "tab".
Conversely, if math.o was already loaded in a tab, the IMPORT would use the in-RAM version rather than the disc one. So any change in math.o would automatically be picked up, even if we forgot to save.
Now, to avoid much confusion, Orgams would prevent to load the same file in different tabs. That is, CONTROL-O "math" would switch to math.o tab rather than loading the file.
But what if we really want to reload from disc in a new tab? For instance we have made several changes, but want to get the old version of one of the routine.
I'm proposing to allow that by pressing CONTROL when validating the filename (CONTROL-ENTER or CONTROL-RETURN then). A message would hint this possibility (only when the file exists in another tab in a modified state).
Open: math. Press RETURN to switch to tab, CONTROL-RETURN to load it here.
WDYT?
Incoming soon: local labels.
You can already
read the doc.
Comments and traduction bienvenus.
I've posted some musings on
cpcwiki.
(since there are a lot of serious users there, and I'm far too serious).
Small suggestion: when you accidentally type 'EX HL,DE', it would be smart if the editor replaces it with 'EX DE,HL' (like when 'ADD A,C' becomes 'ADD C'). Since these operations are identical (question of convention).
Are there Orgams users that doesn't speak French?
Trying to assess how important/necessary it is to update English documentation.
Reminder: Orgams only install RST &30 and &Be00 when it's invoked. It was on purpose (Resolution bug #8a: don't install &30 and &be00 at rom init).
That means that after a reset, BRK will go to the original RST &30 (which is an alias for ... RST 0) -> RESET instead of Breakpoint.
I'm considering reverting to the previous behaviour: installing the routine + JP at ROM INIT inconditionnaly with the following rationale:
* Simplify life of ROM coders, and others' as well.
* I'm not aware of any possible conflict. That is, another tools using those areas. Well, there is Maxam, but that's also for breakpoint purpose, and its debugguer is crappy.
I asked Madram how to make a more complex use of conditionnal assembly.
The common way allow only two possibilities (condition=0 or condition<>0):
IF condition
...
ELSE
...
END
But, Madram's tip:
IF condition-1:ELSE
... ; assembled if condition=1
END
IF condition-2:ELSE
... ; assembled if condition=2
END
...
It's now possible to manage multiple conditions... nice!
It's often useful to Trace (T) a code and take a look at Memory dump at the same time (M). To do that, we have to type (for example) M&700 then T&2000 (then we can look at memory dump on the top of the trace). Why not T&2000,&700? Optionnal parameter.
Good idea! But it conflicts with this request:
Todo #f6
Possible alternatives:
1/ I plan to add an optional size to m command:
mstart,size
I plan to allow chaining commands with ":" (like in BASIC and Assembly sources).
Then, you could do:
m&700,0:t&2000
Even better:
m&700,8:m&800,0:t&2000
Would show while tracing:
* 1 line from &700
* 6 lines from &800
2/ M from trace to change current address.
Labels could be used, so you can add in your source some shortcuts:
m = &700
n = &800
As a bonus, registers would be recognised, so
mhl + ENTER
would dump from HL value.
WDYT?
Trying to centralise feature poll
here.
Requête du samedi après-midi : quand on dump (M), on aimerait pouvoir naviguer vers le haut et vers le bas dans la RAM (actuellement : seulement vers le bas = limite de ma propre routine).
Saturday's request.
It will be useful to be able to have a BRK who jump in trace mode with memory dump = $.
Usage:
error_too_long
BRK
BYTE "Too many iterations, 16384 is the max!"
Then, when the error occurs, BRK = RST #30 is executed, Orgams jump into trace, and I can read my error message on the memory dump.
!?! Why not just switching to source visu, so you can see the BRK line and the message (which could be just a comment, hence not wasting precious bytes in memory).
Nice trick. I need to put a NOP after the BRK to have > on the good line of the source, but that's fine, thanks!
Yes, `>` points to the **opcode** after the BRK, so if there are a lot of comments, first ones might be skipped.
Another trick:
BRK
ld a,err_too_long
`CONTROL-ESC` to go to the editor at the current `>` line.
`CONTROL-ENTER` to see the long comment attached to `err_too_long`.
Page: 1 2 3 4 
