General Category > Programming

From MaXaM to OrGamS. A journey towards sanity.

(1/3) > >>

m_dr_m:

Here is a little summary of what is missing to migrate from MaXaM to OrgAmS.


# Missing features


• Includes. Weren't really missed since Orgams sources takes much less space and are easier to navigate. Also, independent modules are a better alternative in most cases.
   -> Nevertheless, they are incoming, in a better way! See description here (in 12 years-old English): http://orgams.wikidot.com/userguide#toc38


• Scripting from BASIC (numeric "for loops")
  -> Workaround:
Replace:



--- Code: ---10 for i=1 to 12
20 |assemble,i
30 `get necronautical
40 `ld a,necronautical
40 'ld b,necronautical*3
30 next
--- End code ---


By:



--- Code: ---12 ** [
  ld a,#+1
  ld b,[#+1]*3
]
--- End code ---




• Scripting from BASIC (passing different arguments)
   -> Workaround: Use macro.
   -> Proper solution: Support it! http://orgams.wikidot.com/v2boiteaidees#toc7

GUNHED:
Thanks for opening this thread!!! What would be of general interest is a simple "How to move my source code form Maxam to Orgams" manual, explaining in few steps how to do it. If you want "for newbies"  ;) :)
Also, it would be nice to mention potential pitfalls.


What is needed else?
- The READ"FILE instruction
- The WRITE"FILE instruction

- The WRITE"FILE.COM" instruction

What doesn't matter much (for me):
- ASM code in BASIC, because we all have ediors nowadays

m_dr_m:

Thank you for the suggestions. I will update the top post, but I would love some precisions and use cases!


Migrating your source: basically |O, CONTROL-I filename Enter, CONTROL-1 to assemble, CONTROL-4 to cycle through assembly errors :)
Note: All those shortcuts are visible via CONTROL-H (HELP).
Most of the conversion (DB to BYTE etc...) is automatic, but the import is pretty slow (incoming: progress bar).
There is a more detailled description here: http://orgams.wikidot.com/userguide#toc6
A manual is a good idea, but I wonder whether more doc would help, if the existing doc isn't consulted anyway.


Regarding the missing directives:- READ will be covered by IMPORT.


- WRITE is actually achieved by CONTROL-1 (assemble) and B (save to binary). It's not versatile at all, so we might introduce a SAVE directive. But I need to know what are the use cases! Because i'm not quite convinced by the utility of such a directive.


- WRITE .COM: does it simply write an headerless file? Or are there some other CP/M specificities? Who uses that?


https://www.manualslib.com/manual/1124962/Maxam-10-Series.html

GUNHED:

Thank you very much for your detailed answer.  :)  It will help lots of us a lot.  :)


--- Quote from: m_dr_m on 19:19, 01 June 21 ---- WRITE .COM: does it simply write an headerless file? Or are there some other CP/M specificities? Who uses that?

--- End quote ---
Yes! And it's of course very important. It does not only allow to assemble for CP/M.
It also allows to add some custom header to your file. Which is cool to add icons, additional informations and so on. I don't want to spam here too much, but on interest I can provide an example.

m_dr_m:
IIUC, that's just the absence of AMSDOS header that you need.
So basically, it would be more generic to allow: SAVE "toto.ico" ASCII
akin to [size=78%]BASIC's save"roger",a[/size]


I'm not fond of ".com" hack, but to ease migration, we could trigger an error or warning in this case:

line 42: Must specify ASCII or BIN for ".COM" files
     SAVE "DOT.COM"

Navigation

[0] Message Index

[#] Next page

Go to full version
Powered by SMFPacks Reactions Mod
Powered by SMFPacks Alerts Pro Mod
Powered by SMFPacks Mentions Pro Mod