Orgams: Best assembler in my living room.

[m_dr_m]

For those of you new to Orgams (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
Warning: Import is very slow, for some reasons under my control.


Which version to use?

• Demomaker's Delight Release: http://orgams.wikidot.com/releases
• Or EcstaticEndeavour Beta: http://orgams.wikidot.com/working

Well it's up to you!

• The known issues of DD are described here: http://orgams.wikidot.com/userguide#KnownIssues
• The known issues of EE bete are in the "Regression" section from the WIP notes: http://orgams.wikidot.com/working

I can say that thanks to hundreds of NRTs, the latest Beta 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 beta comes with accurate Z80 timing and flags behaviour.
Yes, but you can change the font and the colors in the release disc.

[GUNHED]

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?

[m_dr_m]

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 (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), ...

[GUNHED]

Sounds great!!!    Can't wait FutureFlight version. 

[m_dr_m]

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.

[GUNHED]

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. 

[m_dr_m]

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!

[GUNHED]

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.

[m_dr_m]

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

[GUNHED]

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. 

[m_dr_m]

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 (:

[m_dr_m]

Beta I is out!  (c),0

[GUNHED]

Enhances #BURN a bit, press ESC-ESC to see what I mean...

[m_dr_m]

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?

[GUNHED]

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!