Orgams: Best assembler in my living room.

[HAL6128]

Me. Would be great to have a complete translation.
My french is lousy. But thanks to Google-Translator I can get a glimpse of information.

[m_dr_m]

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!

[GUNHED]

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.

[TotO]

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.

[HAL6128]

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.

[eto]

"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

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.

[Otto]

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.

[TotO]

That is the problem to do jokes into a technical document. It is not the good place for that.

[m_dr_m]

"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

[HAL6128]

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.

[m_dr_m]

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:

Code Select Expand


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:

Code Select Expand


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:

Code Select Expand


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.

[Targhan]

I believe 1.2 is more natural. You don't really want to be forced to use labels with namespace when including another source.

[andycadley]

Yes, I think most developers would expect namespaces to be optional if there is no ambiguity.

[m_dr_m]

Thanks to @gurneyh and @krusty_benediction 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:

Code Select Expand


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:

Code Select Expand


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:

   
• 4 Options 2 + 3

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`

[Cwiiis]

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!

[Cwiiis]

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 )

[andycadley]

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.

[Cwiiis]

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

[andycadley]

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.

[GUNHED]

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

There are better links, I just don't find them right now.

However his great work may be helpful to you.
(Nice banjo btw).

[Cwiiis]

@Dragon : did that before. See here: 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.

[GUNHED]

There will be a way.    @dragon  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. 

[dragon]

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



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.

[GUNHED]

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.

[m_dr_m]

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.