CPCWiki forum
General Category => Programming => Topic started by: m_dr_m on 06:57, 28 April 20
-
For those of you new to Orgams (http://orgams.wikidot.com/ (http://orgams.wikidot.com/)): it is the best full-blown Z80 IDE on CPC 128k. By 2022 it will become so powerful that Zilog will start using it to crossdev *from* CPC.
Used to make Germany-winning French demos and Orgams itself, we can gladly say it is both fresh and mature.
Quick start: http://orgams.wikidot.com/userguide#toc0 (http://orgams.wikidot.com/userguide#toc0)
Warning: Import is very slow, for some reasons under my control.
Which version to use?
- EcstaticEndeavour Release: http://orgams.wikidot.com/releases (http://orgams.wikidot.com/releases)
- Or FluffyFlags alpha: http://orgams.wikidot.com/working (http://orgams.wikidot.com/working)
Well it's up to you!
- The known issues of EE are described here: http://orgams.wikidot.com/userguide#KnownIssues (http://orgams.wikidot.com/userguide#KnownIssues)
- The known issues of FF alpha are in the "Regression" section from the WIP notes: http://orgams.wikidot.com/working (http://orgams.wikidot.com/working)
I can say that thanks to hundreds of NRTs, the latest version is very stable and that's the one I use every day. Now that really sounds like a salesman pitch.
The release comes with example sources, though.
Yes, but the alpha comes with accurate Z80 timing and flags behaviour.
Yes, but you can change the font and the colors in the release disc.
-
Thanks for the great post! It's a well way to enter the world of Orgams.
Now let me please ask some noob questions. I'm sure they're of common interest for beginners.
1. What are the differences between the two versions:
- Demomaker's Delight
- Or EcstaticEndeavour
Is one just the actual release, while the other is the actual newest version. Or is there more to that?
2. What are NRTs?
3. What is an .o file?
-
Hey! Thanks for your interest.
1. What are the differences between the two versions:
- Demomaker's Delight
- Or EcstaticEndeavour
Is one just the actual release, while the other is the actual newest version. Or is there more to that?
The different versions alphabetically sorted:
* AsterixAhead (obsolete release)
* BugsBunnyHill (obsolete release)
* CodigoConCPC (obsolete release)
* Demomaker's Delight (last official release)
* EroticEndeavour (current working Beta)
All differences are listed in the notes. You can find all updates between DD and EE (and also updates between each beta) here: http://orgams.wikidot.com/working (http://orgams.wikidot.com/working) (just after the screenshot)
2. What are NRTs?
How do you check bugs aren't introduced in such a big program? Answer:
Non Regression Tests. Automatized tests that check everything is working as expected. For example for each opcode (>1000), i verify that disassembling + assembling gives back the opcode. If a test passes, it simply returns. Otherwise, there is a breakpoint at the expectation mismatch.
3. What is an .o file?
A source file (encoded).
For orgams to be that fast, both in assembling time (around 1000 lines / sec) and in navigation (check CONTROL-ENTER for exemple to access an arbitrary routine), the source is pre-assembled. That's why import (from text files) takes so much time: most of the work is done there.
A side effect is that it is quite compact. A maxam source will see its size divided by 5 or more (unless the comments predominate).
Also, this special format also to store some meta-informations, like the current cursor position (so you go back to your work exactly where you left it), last modified lines (CONTROL-M to cycle through those), ...
-
Sounds great!!! :) :) :) Can't wait FutureFlight version. ;D
-
Nice new graphics dump feature and step by step emulated execution.
You will like the next version of graphic dump: faster for the default one. New mode where you can highlight just a specific byte value.
In a near future, you'll be able to take snapshot of the memory and do a diff between past & present.
-
In a near future, you'll be able to take snapshot of the memory and do a diff between past & present.
That's great. Now, I do have a feature request which would really boost Orgams beyond everything else. Because it doesn't exist in that way (sadly, AFAIK).
Aside of a memory snapshot, please also do an I/O snapshot. I mean save the data which has been sent to ports. These things are very _very_ important when writing code for new hardware. Hope you like the idea, maybe one day it will be reality. :)
-
Great idea! I plan to do a similar thing for CRTC to help with rupture debugging (including on CRTC other than yours), plus one surprise feature.
Do you have a specific need right now? Anyway, to brainstorm the best possible interface, can you describe how you would use such a feature?
Execution would require to happen in emulation (trace) mode, which is 5x to 50x slower.
The timing could become a problem with some devices. One way to mitigate that (which is a cool feature on and par itself): mock the device. That is, also emulate the device! The downside is you have to setup how the device is meant to react, i.e. the responses to IN r,(c) with respect to the contexte.
Or, (b), we could instrumentate to have both the real execution and then the emulated one.
Or, (c), a more intrusive instrumentation would replace each OUT / IN by a call to the recording routine. The overhead would be much less.
There would be at last too ways to trigger the recording:
- In source (e.g. IO RECORD START directive). That would add such instrumentation code switching to record mode. The benefit is that you can execute at full speed until you reach this point. Also allows (b) and (c) above.
- From monogams (the monitor). It's less intrusive and allow to trace something already burned in ROM (though with Orgams + |BURN it takes me less than 3 seconds to change code in ROM).
Things to consider:
- Filtering port. E.g mask + expected bits of the port to be recorded. Actually AND mask and OR mask allow to describe exactly what you want for each bit (must be set, must be reset, don't care).
- How much to record.
- Breakpoint for a specific port + value combination.
- I thought of something else, but then forgot.
- I thought of yet another thing, but completely unrelated.
It could be reality soon if you're willing to help!
-
Plenty of great ideas!
For the beginning one could reserve one 64 KB expansion RAM bank and put the last OUT value in the corresponding address. Of course that's a waste of RAM, so it would be good to be able to switch the feature on an off.
Example:
LD BC,&FA7E
OUT (C),D
Now the content of register D would be stored in RAM address &FA7E. Later on you could look which bytes was sent to the port just by reading the value.
A more sophisticated approach would be to store the last xxx OUTs in a table, like IO port and value. That is 3 bytes for each OUT command.
The same could be done for IN commands too. But it may make a bit less sense.
-
Yeah I'd rather store the sequence of IO with device-wise LRU window if needed!
By the way, beta H is out. As always, the change are described here: [size=78%]http://orgams.wikidot.com/working (http://orgams.wikidot.com/working)[/size]
Among other things if fixes some QWERTY shortcuts:
- CONTROL * Go to next occurrence of label under/near cursor (akin to Vim's *). Life saver in my book.
- CONTROL ; Cycle through scope delimiter (IF/ELSE/END, MACRO/ENDM, or repetition bloc start/end).
- CONTROL M Cycle through last modified lines. The cycle algorithm should be revised. Still pretty useful.
-
Download completed!
In that window on your screen (link) it's written IN 0,(C) - guess that's what some call IN F,(C). Somehow they are both wrong. One could name it TST (C), but this would just lead to confusion. :)
EDIT: I had a look at #BURN.BAS. So it doesn't modify the ROMs, and therefore any program can be used to burn the Orgams ROMs. Also it's cool that the three supporting ROMs can have ROM numbers from 1 to 127.
But let me ask you for one favour: Maybe in future the default number for Orgams (main ROM) can be 9 instead of 10? That would be great, because it wouldn't collide with FutureOS installations. 9 is the perfect number anyway. :)
-
IN 0,(C) --good-- vs IN F,(C) --bad-- vs TST (C) --ugly-- is explained in the file itself!
The main ROM can be installed from 1 to 15 already. If you are using another program to burn, the default is the the one you choose (:
-
Beta I is out! (c),0
-
Enhances #BURN a bit, press ESC-ESC to see what I mean...
-
Thank you for the enhancement!
On the other hand, it breaks the nice gray square (&0a, &1a, &1b, &0b).
I know, FutureOs uses &0a as well. But do you use |burn?
-
Aehm, no. Actually I do everything ROM with the ROManager (yes, also FutureOS crap, but I'm used to it). ;) :) Guess the appearance of the ROM slots is different. :)
Actually, it's fascinating how quick the Orgams does still evolve, even after years. The developing team is quite on the task. Hats off! :) :) :)
-
Orgams "Ecstatic Endeavour" Release Candidate (http://orgams.wikidot.com/working) Happy New Year!
#### New features ####
--- General ---
* Multi-sources.
- In the editor, use CONTROL-f1 to CONTROL-f9 to open isolated "tabs".
- In each tab, you can load a distinct source.
- Warning, if you load a same source in different tabs, make sure you know what you are doing. There isn't automatic synchronisation.
* Comes with Z80 instruction set timing & advanced flag behavior (Z80.o).
* Comes with |BURN (for X-MEM WinBond)
* Versioned ROMs (mainly for me, to be able to have 2 distincts Orgams version in ROM).
Also, prevent messy state if you burn a new version in different slots.
* Power user mode (quite unnecessary now with multi source):
Custom base bank: |org,bk (eg &ef, &e7, &df, &e7 ...)
-> Each would be a separate instance.
That's a temporary poor-man solution to handle several files
or do some side tests.
Warning, no overlap verification is made. Using 128k per
instance (that is, &cf, &df, &ef and the default &ff) would be safe.
You should always save sensitive work, but at last you can
save loadings.
Now, if one of this non-default page is corrupted, |ORGAMS won't help you.
Instead, clear the page via Monogams (default instance via |M):
>b&da (or &df)
>clearpage (or clp)
--- Editor ---
* Deluxe status board.
- Soon to welcome new information.
* CONTROL-% Cycle through IF/THEN/ELSE, MACRO/ENDM and repetition blocks.
• CONTROL-ENTER works in comments (most of the time! bug #F4).
* COPY-G twice to go to *end* of bloc.
* SHIFT-CLR and SHIFT-DEL work when editing fields (filename etc).
• Comments are shaded.
* "repeat n" and "rend" from rasm are supported (but *not* "repeat n,cnt")
--- Assembler ---
* New directive: LOAD"file.bin"
* load"her" ; insert raw bytes at current pos ($$)
--- Monogams ---
* Dedicated status bar
* RSXs without parameters are accepted. [[[todos#ca]]]
* Can select non-X-MEM banks. E.g. b&7cc4 for CPC's internal RAM, b&7eff for RAM outside first 512k.
* SHIFT-CLR and SHIFT-DEL work.
* CTRL-LEFT / RIGHT for graphical dump (gr).
--- Trace ---
* CTRL-ESC working even from DUMP mode.
* Don't display blank lines, for improved source coverage.
* Show call stack (navigate with U/D). E.g., for the code:
call aa
ret
aa call bb
ret
bb BRK
It will display:
? <- Nevermind
aa
bb
#### Change ####
--- General ---
* No more display message for BRICBRAC.ROM (|BURN).
--- Monogams ---
* Use default screen dimensions.
#### Bug Fix ####
--- General ---
* |burn,"file" : handle headerless files.
--- Editor ---
• Markers correction corrected (#E3, #E4)
* Label search (CTRL L, *, ENTER) much faster.
* Stored line (CONTROL-DEL) still present for new source (todo #D0)
* Line per line scrolling speed fixed (x1.4 from Demomaker's Delight).
* COPY now really acts a dead key.
* Shortcuts ok for EN / ES keyboard (CONTROL-; rather than CONTROL-%)
--- Trace ----
* BRK: Exact capture of RMR (+ ROM #) when firmware is used. (#105a)
* BRK + Multiface 2: Exact capture of MMR (at least all 7Fxx connections. 7Cxx to 7Exx not handled). (#106)
• Trace visu lost less often (#C0)
• Fix clipping (#E0)
#### Regression ####
--- General ---
• Requires 4 ROMs instead of 3.
--- Editor ---
* Slower to compute number of lines (post loading).
* Page navigation (Control up/down) is 30% slower.
--- Monogams ---
• Slightly slower (access, display, clear, skip zeros in memory dump).
--- Trace ---
* Slower display / navigation.
-
do you have a feature comparison of different cpc assemblers?
-
It's easy: Orgams is the best (really).
-
Thanks Mr Ghan!
Well, Pyradev and Maxam have "includes" (coming soon in Orgams). If you don't have a ROM Board (X-Mem or else), DAMS remains the most convenient and powerful. Or maybe TurboAss!
-
From Maxam there is a disc version too. The best assembler IMHO (for non exp. ROM systems).
-
Thanks Mr Ghan!
Well, Pyradev and Maxam have "includes" (coming soon in Orgams). If you don't have a ROM Board (X-Mem or else), DAMS remains the most convenient and powerful. Or maybe TurboAss!
You forgot to mention GENA! One of the best assemblers if you like to torture yourself :D
-
Are there Orgams users that doesn't speak French?
Trying to assess how important/necessary it is to update English documentation.
-
Trying to assess how important/necessary it is to update English documentation.
Another idea would be to ditch the French documentation, and only keep the English one.
-
Another idea would be to ditch the French documentation, and only keep the English one.
Je suggère l'inverse.
-
Well, believe it or not, but the Arkos Tracker doc is in English only, and I never had any complaint from French people (and yes, some are using it).
-
Me. Would be great to have a complete translation. ;D
My french is lousy. But thanks to Google-Translator I can get a glimpse of information.
-
Well, believe it or not, but the Arkos Tracker doc is in English only, and I never had any complaint from French people (and yes, some are using it).
That's because all AT users have already capitulated to the empire.
Another idea would be to ditch the French documentation, and only keep the English one.
Ich mag die Erlangen Geometrieschule.
Me. Would be great to have a complete translation.
Oh yes, nice!
This version: http://orgams.wikidot.com/userguide also comes from googletranslate, pimped with the help of some members of this forum!
I'll try to improve it incrementally. Don't hesitate to do the same, that's a wiki!
-
Are there Orgams users that doesn't speak French?
Trying to assess how important/necessary it is to update English documentation.
Of Course! French is nice (as much as I like German), but English is what we all understand.
-
English is nice to communicate between peoples, but not to write technical documentations if it is not the native language. Best to write with your own language and next use a translator and each users from other countries interested by the project can improve the quality to deserve the same technical quality as expected.
-
Yes, I agree. Because it's much easier to write and bring down what you have mind. But it is also sometimes hard to understand, even with the help of a translator. E.g. in the "Guide Utilisatuer" of Orgams there are some sentences where I think "hmm, what does the author means with ...?" >> ou encore en appuyant sur l'interrupteur du disjoncteur." >> translated with Google "by pressing the circuit breaker switch" (funny)
or
"La première chose que vous voudrez faire, c'est écouter 6:33." ?? It seems to be for insider or I don't have the right clue?
But most time it's understandable and easy to follow. Therefore I will try my best to translate the guide because Orgams is the best tool to program directly on the CPC.
-
"by pressing the circuit breaker switch"
So my French is too rusty to really understand that, but with the help of Google translate AND Google I think it's doable. I'm actually really surprised how good the Google translation already works. Probably much better than if the documentation was done in English directly by someone, who's English is not perfect. Except for a few aspects of course, which you pointed out.
1) Google is not good at translating things that have rarely been translated before and where it's missing the context. In this case, with the context we have, I could imagine, that it's the Reset button.
2) Cultural references, which others don't understand, are generally problematic. The language is irrelevant here. "6:33 "would not be better, if it was written in English, you would still miss the insider joke. ;-) But then, a search for 6:33 in Google helps a lot. Turns out this is a French band (*). (btw: pretty cool music). With that information, the sentence makes sense. (Btw: How about making "6:33" a link to one of their videos on Youtube?)
If it would have been the other way around and someone would have put a "listen to 50 cent" into the documentation, then French readers would be surprised why they should "écouter 50 centimes". Or even worse: "hör Dir Silbermond an" which turns out as "Lune argentée".
* fun fact: 6:33 has a German Wikipedia entry but no French one: https://de.wikipedia.org/wiki/6:33 (https://de.wikipedia.org/wiki/6:33)
As long as the documentation is available on a website, I am happy. Google translate is doing a really good job. It gets more problematic if images have text in it that can't be translated or if the whole document is in a PDF or Word only. The Spanish 8BP documentation is an example that is doing both of it, so the 8BP library is more or less limited to Spanish readers just because the documentation is so hard to translate. It's a lot of effort to make sense of it and translated it with some tools that often corrupt the layout and then, a few weeks later, the next version is published and you start from scratch.
-
Don't miss the online translator: https://deepl.com/
It's much better than Google.
Haven't it tested with French, but for English <-> German translations it's excellent, and it covers most European languages.
-
That is the problem to do jokes into a technical document. It is not the good place for that.
-
"La première chose que vous voudrez faire, c'est écouter 6:33."
If it makes you fell better, even French people might miss my jokes. Even I, don't understand them after some times.
Who said it was a joke anyway? You really need to listen to 6:33 https://www.youtube.com/watch?v=mK8FxrdzeBA
-
Ok, now I understand. :)
[/size]Nice music by the way. Thanks for sharing. The name of the group "6:33" sounds somehow mysteryful.
[/size]
[/size] Don't miss the online translator: https://deepl.com/ It's much better than Google. Haven't it tested with French, but for English <-> German translations it's excellent, and it covers most European languages.
[/size]Thanks for this one. I didn't know it. Works very good.
[/size]
[/size]2) Cultural references, which others don't understand, are generally problematic.
[/size]But that's what it also makes intersting I would say. :)
-
Upcoming import behaviour: my heart still balances between two options.
- 1. Explicit namespace (a.k.a. full qualification).
That is basically what is explained here: http://orgams.wikidot.com/userguide#toc38
In summary:
init ; global init
call ui.init
call player.init
(see doc for more examples).
Pro:
- Explicit and legible, no ambiguity.
Cons:
- Doesn't work like Maxam or Rasm, makes porting a bit more tedious.
- Makes it more difficult to swap code. E.g:
if use_mock
import "fakemus"
else
import "shapmus"
end
[...]
; Also have to adapt prefix: fakemus.iter vs shapmus.iter
For the record, this latter point could be fixed by aliasing:
if use_mock
import "fakemus" as mus
else
import "shapmus" as mus
end
[...]
call mus.iter
- 2. Best of both worlds: implicit and explicit are supported.
As long as a label is unique, qualification isn't needed.
There would still be some degree of encapsulation, since I don't plan to transitively expose labels (e.g. if A imports B and B imports C, A doesn't see C's labels).
I'm leaning forward this solution. Feel free to weigh in.
Thank you for your attention.
-
I believe 1.2 is more natural. You don't really want to be forced to use labels with namespace when including another source.
-
Yes, I think most developers would expect namespaces to be optional if there is no ambiguity.
-
Thanks to @gurneyh (https://www.cpcwiki.eu/forum/index.php?action=profile;u=2960) and @krusty_benediction (https://www.cpcwiki.eu/forum/index.php?action=profile;u=1579) here are two more options!
- 3 Decouple IMPORT and namespaces.
Namespaces (even in a single source) are interesting in their own right.
Exemple curtesy of Gurneyh:
module Player
init
[...]
update
.loop
[...]
djnz .loop
ret
display
[...]
endmodule
module Monsters
init
[...]
update
.loop
[...]
djnz .loop
ret
display
[...]
endmodule
[...]
call Player.update
The code-swap exemple would become:
module mus
if use_mock
import "fakemus"
else
import "shapmus"
end
endmodule
This French variant wouldn't use automagic namespace (labels from imported sources accessible both via namespace and without):
* Pro: more explicit
* Pro: less surprising
* Pro: doesn't depend on filename
* Con: less handy in certain cases.
This leads to the following alternative:
Automagic namespace like in 1.2, with possibility for explicite namespace via `module` like in 1.3.
This would be handy in the following scenario: main.o imports both "lib" and "lab".
None have common labels, so no namespace qualification is used nor needed.
Then, a routine (e.g. `parse`) is introduced in "lab", with the same name than one existing in "lib".
Now, with option 3: one of the import must be wrapped in a namespace, hence all its references must be updated.
With option 4: we only have to qualify the `parse` reference: `call lib.parse`
-
I'm keen to try out Orgams - I can get it working fine in WinAPE, but that's a bit redundant and I'd really ideally like to use it on my 6128 Plus when that arrives (soon). I have a C4CPC cart and a Gotek drive, I suppose I could craft a cpr file that includes Orgams, but looking at the .ROM files, I see that there's a header and I'm not really sure where the header ends... I could just take the last 16k, but it also looks like there might be a footer, so I guess I have a few questions:
- What's the format of the .ROM files?
- Are there any handy tools for making .cpr files? (I can easily write a Python script to do this, but maybe someone already has?)
- Does C4CPC already have support for something that makes all of what I'm asking pointless?
- How is everyone else going about using this? I see all this talk about burning, I assume this is referring to some kind of ROM replacement or add-in? Is this the X-MEM device I've seen referred to?
Messing around with it in WinAPE, this seems very cool - nice work! :)
-
Answering some of my own questions...
- What's the format of the .ROM files?
- Are there any handy tools for making .cpr files? (I can easily write a Python script to do this, but maybe someone already has?)
- Does C4CPC already have support for something that makes all of what I'm asking pointless?
- How is everyone else going about using this? I see all this talk about burning, I assume this is referring to some kind of ROM replacement or add-in? Is this the X-MEM device I've seen referred to?
- Format of .ROM files; it's a 0x80 byte header with this structure: https://github.com/M4Duke/cpcxfer/blob/master/cpc.h#L11
- Tools for making .cpr files; There's buildcpr available here: https://www.genesis8bit.fr/frontend/emu-uti.php though this only takes in a single binary file as input
- C4CPC; I couldn't find any documentation about a C4CPC mode that makes it easier to use it as a multi-file ROM extension board, so I assume it doesn't have that capability
- How is everyone else going about this; By internal/external ROM extension boards it would appear, either M4, X-MEM or other things. It seems the Plus isn't a common development machine.
Any more information appreciated; for now I'm just going to write a Python tool to combine ROM files into a single cpr for use with emulators/C4CPC (which I assume is a thing that's possible and that I haven't gravely misunderstood something :))
-
You might need a hacked BASIC/Firmware ROM inside the CPR in order to initialize ROMs that are located in the cartridge ROM space as opposed to the "usual" ones. I don't know if there is one floating around, but I suspect there probably is as I'm sure I've seen carts that include some ROMs already.
-
You might need a hacked BASIC/Firmware ROM inside the CPR in order to initialize ROMs that are located in the cartridge ROM space as opposed to the "usual" ones. I don't know if there is one floating around, but I suspect there probably is as I'm sure I've seen carts that include some ROMs already.
Yes, I plan on building a ROM like the ones provided on the C4CPC page, but including Orgams, Starkos and some kind of paint program to make it easy to do development on a stock 6128+ (and probably excluding Burning Rubber :)).
Something I'm absolutely not used to right now is just how amazing the documentation for this machine is... There I was struggling with header formats and such, but it's all in the manual! In case it helps anyone, here's the wiki page about the AMSDOS header format, which includes a link to the relevant scanned manual pages: http://www.cpcwiki.eu/index.php/AMSDOS_Header
I've got a Python script that decodes the headers of a list of files (verifying with checksumming whether they're headerless or not), now I just need to get it to write out a cpr file and test that with an emulator...
-
Yeah, the Amstrad manual is fantastic. I think only overshadowed by the original Spectrum one (and it's revised +3 incarnation) which even goes into exact details of how BASIC lines are encoded in memory.
-
Yes, I plan on building a ROM like the ones provided on the C4CPC page, but including Orgams, Starkos and some kind of paint program to make it easy to do development on a stock 6128+ (and probably excluding Burning Rubber :) ).
@Dragon : did that before. See here: https://www.cpcwiki.eu/forum/programming/futureos-corner/msg134987/#msg134987 (https://www.cpcwiki.eu/forum/programming/futureos-corner/msg134987/#msg134987)
There are better links, I just don't find them right now.
However his great work may be helpful to you.
(Nice banjo btw).
-
@Dragon : did that before. See here: https://www.cpcwiki.eu/forum/programming/futureos-corner/msg134987/#msg134987 (https://www.cpcwiki.eu/forum/programming/futureos-corner/msg134987/#msg134987)
There are better links, I just don't find them right now.
However his great work may be helpful to you.
(Nice banjo btw).
Cheers :) I guess things work in that case as FutureOS is Plus-aware(?) I need to take a look at FutureOS for sure. For now, I've contacted TotO to get an X-MEM board, but it'd be nice to come back and figure this out properly - I got as far as finding arnoldemu's work of patching the OS to load from cartridge banks instead of the lower ROM banks, but it didn't behave quite right and debugging it is probably slightly beyond me (or rather, that's more time than I want to spend on something like that, rather than just using the machine!) I did at least finish a tool to build cpr files, hopefully someone finds that useful at some point.
-
There will be a way. :) @dragon (https://www.cpcwiki.eu/forum/index.php?action=profile;u=251) made these awesome 512 KB cartridges for 6128plus including expansion ROMs, CP/M, SymbOS and FutureOS. But basically you can throw in everything you want. I'm sure he can help you to compile your own super cartridge.
For FutureOS (informations/help/anything else) you can always contact me. :)
-
The trick is simple if I remember o.k it work like that:
You have four repeat parameters that plus recognize |game and variants.
Every |game have a dedicated jump in the amsdos/parados rom.
Four addresses that jump to the same site (all are burning rubber).
You change the far call where it jump to a site where you write your code.
Then you can detect where is called by the stack.
Then is a matter of check the parameters write in the |.xx that firmware give you.
When you have check the string then you jump to the adress where original rom jump.
So you need insert every | the rom have manually and jump there.
Also maybe you need patch the rom a little because with multiple roms it can't detect the others. Because they search in 0-15.
These thing of how firmware give parameter are in 10.6 of this document
http://www.cpcwiki.eu/imgs/f/f6/S968se10.pdf (http://www.cpcwiki.eu/imgs/f/f6/S968se10.pdf)
I'n her day I use:
1.|c4cpc
2.|hxc
3.|os.xx - >all subtypes.
Why not add entry jumps to the amsdos/parados table instead of recycle |jeux, |juego, etc..?
Becase you are moving all rom code from their original adress.
Then you are made the same amstrad when update plus. That cause software incompatibility.
-
Hello Orgams team. Well, I don't know who to ask in particular, so I ask here...
As I did hear Orgams does use the Nova card for storage of some data. Can you please tell me in which way? Is some kind of directory structure used? How much bytes?
The reason I ask, is to eventually have something (data structure, code, etc.) which is compatible with every application we use/create.
-
The Nova card isn't used.
Sources and some other stuff (e.g. command history in the monitor) are persistent across reset, backed by some checksum verification.
-
it would be friendly to use
/*
ld hl,#4000
ld de,#4001
ld bc,#3fff
ld (hl),l
ldir
*/
ld hl,#c000 ; this instruction will be assembled.
in this case, all the instructions between /* and */ are comments...
-
Thank you for the suggestion.
Yet, in my book it's far more convenient to do:
if 0
ld hl,#4000
ld de,#4001
ld bc,#3fff
ld (hl),l
ldir
end
or even better:
clear_screen = 0
display_tm = 1
dev_checks = 1
[...]
if clear_screen
ld hl,#4000
ld de,#4001
ld bc,#3fff
ld (hl),l
ldir
end
So you can control all conditional assembly from one place, and go from the flag definition to its use(s) with CONTROL-*.
There are other advantages not to bury code in comments.
Alternatively, you can put the clear routine in a macro, and just comment the macro invocation.
Be creative!
-
Or get out of the 50ies. Let the Editor care about what's comment and what's not.
On screen show code and comments in different colors or in regular and italics. Something like that.
This would save as from strange comment characters like ";" or "/*".
Yes, you won't like the idea, but I needed to tell . :) :) :)
-
After getting used to Orgams a bit more, I think my number 1 feature request would be to show all 8 bits, including leading zeros for binary numbers, and all 2 or 4 characters for 8 or 16-bit hex values. Thought I'd post because that seems like quite an easy thing to do and would have a huge impact, at least for me :)
I suppose with the 80-character per line limit, perhaps it'd make more sense for it to just remember the number of leading zeros the user inputs, but if that's less feasible, I'd definitely pick showing all 2/4/8 digits over stripping the leading zeros.
-
Or get out of the 50ies. Let the Editor care about what's comment and what's not.
On screen show code and comments in different colors or in regular and italics. Something like that.
This would save as from strange comment characters like ";" or "/*".
* Orgams already shows comments in shaded colour. You should try it, really.
* Ast suggestion was about block-comment. Relying on editor command and invisible markers isn't practical in my book. For instance, that means you have to reselect the whole block to uncomment.
Yes, keeping the leading 0s for binary or hex values is good idea!
-
Yeah, I guessed that. The world is not ready for my idea. I'll come back to it in 2028. ;D
-
Another feature request; I'm very used to using vim and split panels - if you could introduce a horizontal split at the cursor so you could look at a different range of lines in the same file, that would be great. I realise you could open the same file in a different tab, but sometimes you just want to have a reference handy. Still really liking Orgams btw :)
-
A question and possible request, for macros, can you use parameters in commands? I wanted to do this for a line-interrupt macro;
MACRO LINE_INT n
MAP_PLUS(1)
ld a,n
ld (&6800),a
MAP_PLUS(0)
ENDM
MAP_PLUS is a predicate macro to page in CRTC registers. Building this, I get a syntax error on ld a,n - is there a way to do this currently? If not, that'd definitely be nice :)
-
I'm also a long time user of Vim (hence the CONTROL-* to go to next occurrence of label!).
Split panes would require a lot of work, though. Maybe less through Gedeihen (Declarative GUI engine), which is still WIP.
Parameters in MACRO is meant to work, and you are the first one to report a bug about that.
I wasn't able to reproduce your problem, would you be able to post a complete exemple with invocation that triggers the syntax error?
Hypothesis: there is a syntax error in MAP_PLUS(1), and a bug about the reported line.
What happen if you put a NOP before ld a,n?
-
Hypothesis: there is a syntax error in MAP_PLUS(1), and a bug about the reported line.
What happen if you put a NOP before ld a,n?
No idea what happened, but I uncommented it and it just works now. Previously it was complaining that the parameter label didn't exist... Who knows!
Another question, are there greater than/less than predicates? Following your example for a nops macro, I wanted it to preserve all registers and in the case that you give it a value less than the minimum, just use nops... But it seems </> aren't valid syntax. They aren't mentioned in the user guide, so I suppose not... In which case, that's definitely another feature request :)
And aside, I've switched to real hardware instead of WinAPE now (6128 Plus, X-MEM and Gotek) and a weird bug I get, on first launch of Orgams, after scrolling a few pages, it resets back to basic. Relaunching orgams, everything seems fine and I can just carry on as normal (the cursor starts in the margin, but once I move it away, it behaves normally). Bit of an odd one!
-
Previously it was complaining that the parameter label didn't exist...
That can happen when the passed expression cannot be resolved at invocation time (e.g. forward reference).
LINE_INT(defined_after)
[...]
defined_after = 4
Another question, are there greater than/less than predicates?
Not yet! I can explain how to add them :)
it resets back to basic
Orgams is pretty much crash-safe (at worse, some assert/breakpoint might be triggered, which would switch to debugger page).
Make sure your connector is perfectly clean.
Anyway, glad to hear you use the real stuff!
-
I've got to the point where I could really use a way of transferring text from PC to Amstrad. If I put a text file on a disc using WinAPE without generating an AMSDOS header, Protext views it fine, but if I try to import it in Orgams, it hangs.
On reset, I can see it imported the text, but then it also imports thousands of lines of nothing... So I guess somehow Orgams is missing the end of the file, or I'm not doing this correctly? I don't have an M4 cart, so Gotek + WinAPE to edit disc files is my current means of transfer. Any tips?
-
Can you please make a DSK with that file and post it here. I will have a look at it.
-
then it also imports thousands of lines of nothing...
Which DOS are you using?
If CubeMDOS, this is due to https://www.cpcwiki.eu/forum/applications/cubeios-fat16fat32-rom-for-the-cpc's-with-xmass/msg203159/#msg203159
Either way, I'll try to publish a corrected version this week-end.
-
I don't recall if I was using AMSDOS or ParaDOS, but one of those. I've attached the disc image, 'GHOST.TXT' is the text file in question (I think - can't conveniently check right now). Please ignore the rest of it :)
-
I think my number 1 feature request would be to show all 8 bits
Done!
So I guess somehow Orgams is missing the end of the file
Fixed!
Available in alpha7. http://orgams.wikidot.com/working (http://orgams.wikidot.com/working)
The world is not ready for my idea
The world was ready decades ago. It's called WYSIWYG, and that's usually in a pain in the ass.
I guess the best of both worlds is markdown-like markup with immediate render.
-
Poll: Separator for module (aka namespace)
Context:
Since FroggyFlags Alpha2, Orgams allows local labels (which can be reused in different scope / macro invocations):
gen_mesh
ld b,width
.loopx
[...]
djnz loopx
[...]
display_mesh
ld b,width
.loopx
[...]
djnz loopx
[...]
For now, you cannot access those labels outside of their scopes. Once possible, the syntax would be:
ld b,width2
jr gen_mesh.loopx
Now, I will also introduce module/namespace:
- Similar to: [/size]https://z00m128.github.io/sjasmplus/documentation.html#po_module (https://z00m128.github.io/sjasmplus/documentation.html#po_module)
- [/size]See motivation here: [/size]https://www.cpcwiki.eu/forum/programming/orgams-best-assembler-in-my-living-room/msg204960/#msg204960 (https://www.cpcwiki.eu/forum/programming/orgams-best-assembler-in-my-living-room/msg204960/#msg204960)
[/size]In that case you can write:
module Player
init
[...]
update
.loop
[...]
djnz .loop
ret
display
[...]
endmodule
[/size]The poll question amounts to how to access `init` outside `Player` scope?
- [/size]Also with dot notation.
call Player.init
jr Player.update.loop
- [/size]Used dy other assemblers (e.g. sjasmplus)
- [/size]Nice symmetry with global+local labels (it’s a pro from some, a con for others).
call Player::init
jr Player::update.loop
- [/size]Similar to namespace qualification in some languages (rust)
- [/size]Would allow having both a module and a global label with the same name (I’m not convinced it’s a good thing).
- [/size]Would allow having two imports with same name but different extension (idem):
import “math.i”
import “math.o”
ld hl,math.i::PI
call math.o::cos
[/size]FWIW, rams uses `_`, but since it’s also a valid label character, I find it too ambiguous.
-
I vote for the dot and will implement like this for my own assembler.
There is no reason to differentiate modules from global labels. And to use : everywhere would be unusual.Nested modules should be possible.To name a module with the imported file name is maybe not a good idea: you illustrate the issue with the extension, and what happens with compatible cross-assembler that can use complex paths ? I would rather use the filename without extension/path or provide it explicitly
import “math.i” as math_i
import “math.o” as math_o
In case of ambiguity, module name could be prefixed by :: to ensure lookup starts at module level and not inside module level
::Player is module Player
Player is label player if any otherwise module Player
-
The 'as' syntax is sweet, but I'd rather re-use existing mechanism (well, not existing yet, but soon enough):
module math_i
import "math.i"
endmodule
module math_o
import "math.o"
endmodule
-
Also, please share your enlightened opinions about http://memoryfull.net/post.php?id=30&page=3#863