Hi!
(I post this message here and not in "Application" because I'm not sure to be a "serious" CPC user :) )
We were working, Madram, Drill & me, on a new ROM based Z80 assembler (exploiting the X-MEM) since some months, and the first version has been released yesterday! You can download it here (http://www.pushnpop.net/Download/Tools/Orgams%20(Overlanders+Vanity).zip). Madram, Drill & me can answer to your questions on this Push'n'Pop thread (http://www.pushnpop.net/topic-476-1.html#lastpost). If you speak french, you can also read our dedicated Wiki (http://orgams.wikidot.com/guideutilisateur). Check the full credit list on this page (http://www.pushnpop.net/prod-395.html)... and the next versions!
Feeback is welcome! Basically, we are DAMS/Turbo Assembler users, so if you are using MAXAM or something else, you can maybe suggest us some features (Hi TFM :) ).
>run"#
>coucou!
:D :D
Hello,
You can find OrgAms test here! (http://amstradplus.forumforever.com/t72-OrgAms.htm)
Have a good fun with this great tool.
Quote from: Hicks on 12:30, 21 February 15
... so if you are using MAXAM or something else, you can maybe suggest us some features (Hi TFM :) ).
I'll check it out :-) Great news!!! :)
Quote from: Gryzor on 13:03, 22 February 15
>run"#
>coucou! :D :D
So... it only runs in the ROM - got it! :P
I tried to import IMPdraw source code (coming from winape assembler) with OrgAms (control+i) and unfortunately, some last lines are missing... I've got a message error. :-\
Is winape assembler syntax different than Maxam asm syntax? Is it possible to import winape source code to OrgAms?
I noticed that defb, db, defw, dw... are not converted into byte, word... Is it normal ?
Edit :
Excuse me, i've forgotten to tell you what the error is.
So, Orgams has written "dos error"
Attention: Using OrgAms may need to adapt the burn program, since it uses fixed ROM numbers. It uses 10, and therefore may overwrite important other software ;) . So adapt the basic listing to alter target ROM numbers.
This isn't an answer to my question TFM. :-\
Was not referring to you. Was targeted to developers. I "just" start to take a look at OrgAMS since it's new.
But to your problem... try another disc, maybe it is like the message told, just a "dos error"
I've already test another file in another disc... Verdict? Same error :-\
@AST: send me a test file, ok with WinAPE and corrupted with Orgams, and then we will check the problem...
Sorry but i can't send you iMPdraw code source, but i'll try with others sources written with winape and then, i'll tell you and will send it to you, for sure.
Return to basic with OrgAms is a little bit chaotic, because sometimes, it's bugged. I don't know why.
@Hicks (http://www.cpcwiki.eu/forum/index.php?action=profile;u=581) : i sent you a winape asm example, good luck!
One suggestion... dunno if wanted / doable... IMHO it would be nice if OrgAms can handle hex number with # and &. So it would be great if there would be an option to switch between "#" and "&". :)
I can't use this, but damn I love the font!!!:
[attachimg=1]
Any way to port this for use on Windows? Is the full charset available somewhere?
I'm *JUST* _REALLY_ glad to see that on the
CPC! :) :) :)
:) don't shoot me!
Quote from: Ast on 16:44, 26 February 15
@Hicks (http://www.cpcwiki.eu/forum/index.php?action=profile;u=581) : i sent you a winape asm example, good luck!
Hello,
finally got some time to try Orgams on my untouched xmem ;)
You seem to be working also on winape,
so I thought I would try in an emulator first ( because my sitting time in front of the actual machine is limited ;D ).
My problem is that the basic burn program fails at |BURN ,
which means I'm missing an rsx in winape ?
I am a newbie when it comes to rom, please don't shoot me!!!
I went through the options in winape, everything related to rom seems to be enabled .
As I know, the |BURN RSX allow to program the X-MEM ROM. No emulator actually support that.
Orgasm programmers are not related to the WinAPE programmer.
Quote from: trabitboy on 15:34, 09 April 15
My problem is that the basic burn program fails at |BURN ,
which means I'm missing an rsx in winape ?
I went through the options in winape, everything related to rom seems to be enabled .
Since emulators in general do not emulate the new famous ACME hardware you have to do it an an real CPC. And from the CPC you can save the ROMs to disc and bring them to the PC for emulation.
Or take the ROMs from the DSK and put them into the emulator. But beware: The ROM numbers are hard coded (like in every super fast professional software). You can take a look at the BASIC program to see where to put the ROMs in an emulator. :)
Try this DSK, numbers are indicated!
Quote from: TotO on 16:18, 09 April 15
As I know, the |BURN RSX allow to program the X-MEM ROM.
So if an xmem is present in the system, |burn is available ? is that right ?
Thanks also tfm for the detailed explanation, I just didn't think of feeding the roms from the emulator side [emoji1]
Oh, btw, iirc, the original DSK contains the BURN RSX (called XBURN or so) just in case you don't use FW 3.15 on your CPC X-MEM.
Thanks a million, this is helpful :)
Try on real hw tonight !!!
( trying the roms on emu right now )
Could get it to run on emu successfully; after going through the wiki and trying a few things I have a question: does it import winape sources that have includes? How does this "ide" deal with multiple source?
I can easily concatenate all my sources into one but I don't like it too much, surely somebody else already had a need to work on multi source projects?
Otherwise super sexy, although I am still searching for my xmem in my boxes #shame# #full disclosure# to try it on real hardware.
Orgams only handle one file at a time. My work-flow is to assemble separately each source, each with its jump table, and to burn the binaries in ROMs.
So, the main source remains very fast to assemble, without any drive access occurring.
This method has its limitations, thus 'includes' are meant to be included at some point, with a cache mechanism (i.e. included file is only loaded once).
But it's unlikely to happen before Christmas, except:
- by popular demand.
- someone's is willing to help in this area.
Oh! In case you've missed it, user guide here: UserGuide - ORGAMS (http://orgams.wikidot.com/userguide)
Feel free to fix remaining anglefish mistakes.
Request for comments
The ability to load binaries from source would be handy.
Even in Monogams, it would be better than LOAD from BASIC or HACKIT :
* no buffer/memory issue.
* can load anywhere, up to 64k. Would also work in special configuration (e.g. Bank &c2).
Then, the default would be to use file's loading address.
A contrario, within the source, we likely want to load from current position ($, or $$).
So, what would you prefer :
load "donut.raw",$
or
include "donut.raw"
or
better solution yet.
In both cases, we will be able to load only a part of the file (mimicking the size parameter of save command):
load "donut.raw",$,&200 ; first 512 bytes
load "donut.win",$,-5 ; all but last 5 bytes
Here is my comment !
Within the source, I think we need both, since behavior would be different:
- LOAD to load at an arbitrary address, leaving $ and $$ untouched
- INCLUDE to load at current $$, adding 'size' to both $ and $$
Put in other way, since LOAD can use an arbitrary address, it doesn't feel right to update $ or $$.
The behavior of LOAD would be exactly the same than the corresponding monitor command.
And of course, INCLUDE would make no sense in monitor.
@madram (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1459): just a short question: I tried the assembler for the first time. The "ret" command wont be recognized by the editor as a command but as a label? What do I do wrong? (It's too difficult to understand the French user guide correctly.)
You must put a Space before the ret command as the other z80 opcodes or they Will be taken as label.
...ah, that's easy! :)
Thank you very much for your short hint & help.
You're welcome.
Note: Orgams is very permissive for labels. 'ret' could be a label, not an advisable one for sure. Even 'd' is accepted, handy for quick debugging shortcut (i.e. 'dd' in monitor).
But you don't need any spaces when entered text can't be a label :
; Miaou
lda,-1 ; expand to LD A,-1
exaf, ; expand to EX AF,AF
Note2: there is an English user guide, thanks to Shakespearean CPCWiki members: UserGuide - ORGAMS (http://orgams.wikidot.com/userguide). Will be on disk in the incoming release.
Thanks to the wonderful job of Drill and Hicks, I'm glad to announce the new official Orgams release: 'Codigo Con CPC'
HFE: http://orgams.wikidot.com/local--files/releases/Orgams-Codigo-Con-CPC.hfe (http://orgams.wikidot.com/local--files/releases/Orgams-Codigo-Con-CPC.hfe)
HFE+DSK+ROMs: http://orgams.wikidot.com/local--files/releases/Orgams-Codigo-Con-CPC.rar (http://orgams.wikidot.com/local--files/releases/Orgams-Codigo-Con-CPC.rar)
User Guide: UserGuide - ORGAMS (http://orgams.wikidot.com/userguide)
Camembert: GuideUtilisateur - ORGAMS (http://orgams.wikidot.com/guideutilisateur)
Release notes 'Codigo Con CPC'
Bug fix:
* Bloc repetition was corrupted when corresponding source was overlapping 2 banks
* Division with MSB set in divisor (e.g. &240/&C0) was corrupted
* Sign was lost with sub-expression (e.g. -1/[1/1] or -1 mod [4 mod 5])
* Negative values for FILL, ORG and repetitions raise error.
* Bad expression for repetitions (e.g. undefined label) raise error.
* Proper binary save from 9800-HIMEM zone
* Returning to basic won't reset 9800-HIMEM zone anymore
* 'ORG &100' now correctly parsed (not as 'OR G AND 100')
* Assembling in RSX workzone (e.g. A6FC+) won't corrupt firmware (Orgams-wise) anymore
* Reset CRTC in RESTORE
* Mute AY in BRK/RESTORE
* At first invocation of BRK/Monogams, select RAM by default (lower & upper)
* Robuster memory detection
* Fix stack going down at each assemble / editor access.
* Numeric pad is active when invoking |m
* Block markers properly corrected when importing file
* LD B,(IX) doesn't crash anymore
* LD H,IXH doesn't crash anymore
* Miscellaneous search bugs (CONTROL F) corrected.
New features:
* Trace: Source visualization while debugging (imperfect, Orgams can be lost with conditional or repeated blocs)
* Trace: Memory visualization while debugging
* Trace: CONTROL UP/DOWN for faster navigation
* Monitor: Binary display with '?' command
* Monitor: Display restored zone when returning to BASIC
* Assembler: Can assemble up to #BF80, and in #C000-#FFFF page
* Editor: Free cursor
* Editor: TAB to repeat previous search (text or label)
* Editor: ESC to stop current search (only works with CONTROL F)
* Editor: CONTROL-ESPACE put/remove BRK
* Editor: CONTROL-C to display CATalogue
* Editor: Can join lines (DEL at first column). Corollary : 'DEL' after 'RETURN' cancels an unexpected split
* Editor: Use '&' for hexa, like in BASIC and MAXAM.
* Editor: Allow (IX) as shortcut for (IX+0)
* General: Use RAM from very last bank (&FF) to alleviate conflict with 256k RAM-DISC.
* General: Extension and Monogams ROMs can be burned everywhere (i.e. ROM 1 to 127)
* General: Allow |o,"source" (no need to write ".o")
Comming Next:
* Surprise
* Another surprise
SuperCool! Will give it a try very soon!!! :) :) :)
I am getting stupid I guess. I did some tests with Orgams yesterday. Everything worked fine.
I tried again today, now everything is well assembled, but Jumping into the program does NOT execute it. It shows a little flickering of the screen (as if the RESTORE mnemonic was called) and returns to the assembler. I tried very simple program like:
ORG #1000
ld a,7
call #bb5a
ret
or even:
ORG #1000
jr $
The same behavior happens! It returns to the Assembler without doing anything.
I tried to save as binary, loaded in Basic and my code works. What am I doing wrong? The parameter at the top seem fine to me (#7fc0, LRAM, URAM).
The only thing I did today was plugging the PlayCity and typed some code to detect it (it works).
Thanks.
Mmmh, Ctrl+1 + Jump works, but Ctrl+2 returns to the Assembler.
But making some tests with the PlayCity really makes Orgams behave strangely.
(I have the latest version)
Did you think about the "ent adress' command ?
If not, Orgams will do a jp #9000
My playcity is plugged and i use Orgams all the days. No problem with OrgAms.
Of course, i've ever do some test with my playcity...
"ENT" exists on Orgams? I never used it, but you must be right. Yet the "Jump" indicates #1000 (which is where my code is assembled). I'll try this evening, thanks!
Well, you were right all along! Missing ENT, but I don't understand how I missed the "jump" pointing at the wrong address, I'm pretty sure I triple checked. Anyway, problem solved. Thanks !
Great !
Using OrgAms, a playcity on réal hardware !
I've an idea of what you're doing... ;D
I'm sure you have :).
Preparing new release 'Fluffy Flags' for 2023/12/12. All known bugs won't be fixed though. Any one that particularly annoys you?
No bugs for me annoying me so far.
Looking forward to it.
What are the changes of this release?
Good question!
If you go to Orgams Last Beta (http://orgams.wikidot.com/working) page, you'll find
Change since lastest release (EE).Now, the incoming changes are:
- Fix bug#167 [Monogams UI] Garbage in status bar when label not found
- Fix bug#162 [Assembler] Supernumerous 'END' not detected
- New logo
Thank you.
Just a general question because I hadn't worked so much with the step tracer / debugger: it is an emulation not a real step tracer (or have I read / understood something wrong)?
I'm not sure what is a step tracer then!
Yep it's emulated. Only Z80 and ROM/RAM connection for now.
As a benefit, it allows for instance fast trace until the instruction under the cursor.
Handy to fast-track a loop.
Incoming (Per
@Cwiiis request, thanks!)
- Auto-completion also for CONTROL-L (go to label)
- Fix bug#169 and #16A
Quote from: m_dr_m on 10:19, 05 December 23I'm not sure what is a step tracer then!
Yep it's emulated. Only Z80 and ROM/RAM connection for now.
As a benefit, it allows for instance fast trace until the instruction under the cursor.
Handy to fast-track a loop.
Yeah, that's what I thought. Step by step debugging. It would be be very, very handy to have also external devices and registers available with with OUTs and INs.
Some "logging" (eg. which value has been sent to which port) could be added quite easily.
Also, in some case we should actually write or read to the actual port. E.g.:
ld a,&f5:in a,(&ff)Not to be blocked in flyback wait.
Do you have a specific use-case in mind?
Just a simple routine where I put for detection purpose a value in an external vram via OUT command and read it back with an IN.
Ok, so no emulation for the port, just doing the exact I/O (with slower timing though).
Should be pretty easy.
Just by curiosity, instead of step by step trace, why not use normal execution + (conditional) breakpoint?
Ok, what do you mean by "just doing the exact I/O with slower timing?
The conditional break points are a good idea (IF ... THEN call RST06). Thanks for the hint. Let me try.
If RAM/ROM IO (7fxx) -> emulated
If CRTC IO -> nothing (for now)
Otherwise -> Do the OUT / IN
Note: the breakpoint is at &be00, so you can do CALL cond,&be00