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 **).
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
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:
; - 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.
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.
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.