OrgamS - Statut
Page: 1 2 3 4 5
Can’t wait to test this one...
« Can’t wait to test this one...
»
Don't ask what Orgams can do for you, ask what can you do for Orgams.
« it's sometimes useful to do CTRL+DEL, load a new source, and CTRL+P just in order to copy one line from one source to another, but the inserted line is empty... »
Fixed. It also remembers CTRL-F / CTRL-L fields.
«
Don't ask what Orgams can do for you, ask what can you do for Orgams. »
We have all projects we want to finish (cf:iMPdraw & iMPdos)
#MeToo. So here how I split my time: each action helps the previous ones.
* 1/2: Ayane.
* 1/4: Orgams.
* 1/8: Learn how to be a better coder.
* 1/16: Learn how to learn.
* 1/32: Try to get better sleep and food.
* 1/64: Learn how to to better sleep and food.
* 1/64: Learn how to learn.
Nice to see that Orgams is still growing!
And thanks for the fix, Sick Boy.
Right now, my main problem with Orgams is the impossibility to refer to labels in macros.
Just bidouille, but it's sometimes lourdingue.
Maybe you could fix that? That's the beauty of opinel source.
A good first step would be to write the unit tests data!
E.g.
BYTE "uber",0
BYTE " .loop jr loop",0
BYTE "mensch",0
BYTE " .loop jr loop",0
BYTE 0
BYTE 4,&18,-2,&18,-2
One more reason for you users to get involved in the code. If I get hit by a bus (or worse, switch to Amiga), you'll be happy to know the internals.
Nice for LOAD.
What's the better use?
The most obvious I see is: avoid Basic launcher.
Oh yes it advantageously replaces a BASIC loader:
* Can load anywhere in RAM, modulo bug #94. E.g. A700-BF00.
* Can bulk-load in BANK. E.g. 32k file to put in C4-C5:
BANK &C2:ORG 0
LOAD"BOOOBS.GFX"
* Cached in memory (no checksum yet, though).
And then we can add options to skip some part at the end or the beginning (e.g. don't load the 5 metadata bytes at the end of an OCP .win).
Oh oh oh, cool. So it's just loaded one time, and reloaded when... ? How Orgams know when he must reload it?
Brk is bugged.
When the brk is found the vsync is lost and crashed orgams debugger.
Load instruction is a good idea and works fine.
@Hicks:
* CTRL-5 (Reload + Assemble)
* CTRL-6 (Reload + Assemble + Jump)
I'm going to update the doc.
@Ast: If it happened just after you burnt the new ROM, it might be due to a messy state (previous Orgams setup in bank). I should add some extra checks. In the meantime, please use |orgams after a fresh install (erase source & start anew).
Can you reproduce? How?
« In the meantime, please use |orgams after a fresh install (erase source & start anew). »
I already do that.
Can't reproduce for now because i put the old version to work.
Thanks Madram!
Do you try the import function with this new version (CTRL+I) ?
It patine in the semoule with me....
I tried it both manually and via automated unit tests.
What do you mean? Does it complete?
It always has been extra slow (since most of assembly work is done at parsing time, and I didn't care to optimize that).
If it can be of any consolation, that's still faster than MaxaM regular assembly phase. The latter drove the most brilliant minds insane. Some of them, despite a promising future, are now cross-developing or coding on Amiga. Sad.
By the way, the main sluggishness comes from the symbol -> id lookup, since I have to scan all the symbols table.
On the other hand, it would be very fast to get a symbol's length. So, an easy and quick improvement would be to check the length before comparing the names themselves.
That is, if you're looking for "dots_append" you can skip all the symbols that aren't 11 bytes long.
Let me know if you'd like to code that (it would make the editing more reactive as well).
« Right now, my main problem with Orgams is the impossibility to refer to labels in macros.
»
Here you go. Let any question be heard :)
« Did you try the import function with this new version (CTRL+I) ?
It patines in the semoule with me....
»
Thanks to Mr X for proper report with infringing file.
For the record, it doesn't seem to be a new bug and only occurs when you try to deceive OrgamS by importing a ".o" binary rather than a text or DAMS file!
Bug #FA For reasons under my control, next revisions will mainly be bug fixes, until the final release of EroticEvaluation.
Pour des raisons dépendantes de ma volonté, les prochaines révisions seront des révisions, jusqu'à la sortie finale de EngouementExacerbé.
In the meantime, beta F is out (c).
From my point of view, this new "EE beta F" version is the event of the month on CPC: several sources at the same time, LOAD directive, and instruction documentation! Thanks again to Madram for giving him his nights to give us better days.
This leads to several questions:
1. Concerning multi-source.
1.1. The best would be to have shared labels, for example to have only one package of macros for several sources, a separate transition, etc.
1.2. In the continuity, would it be possible to be able to assemble and execute easily (ctrl+?) all the sources, and execute the one defined (directive "MASTER" to be added?)?
1.3. Would it be possible to load a "project" = several sources at once?
2. Concerning the info on z80 instructions. It was unpublished, in 2020, damn it!
2.1. Is it soon planned to use it to count the nops of a routine?
2.2. Is it possible that I put it online and that you let me know about possible changes when there will be some? It'll be very helpful.
3. LOAD directive. My only test didn't work (disk access but nothing can be found at the indicated address), I must have crashed. It looked like this:
ORG #1000
dev = 0
ENT $
...
IF dev
ELSE
ORG #3F00
LOAD "FILE.BIN"
END
Thanks! This feedback is appreciated.
1. All of this is covered by
IMPORT.
Whose another prerequisite is
local labels.
2. All of it was published (see references), but scattered and sometimes with mistakes.
2.1 Yes.
EE Beta M will give the total duration of the currently selected bloc. A rough estimate, that is, since no emulation will be done. That means that
« ld b,2:djnz $ » won't give the expected result.
In FF Beta 3, you'll be able to stopwatch a desired portion, which will be fully emulated in a sandbox.
2.2 Of course. There are already 2 fixed errors. I'll send you the latest version.
3. Is "LOAD.BIN" headerless "ASCII" by chance?
3. For an headerless file, the returned size is 0. So OrGAmS loads 0 bytes. That's consistent.
On mass storage (fat filesystem), the size is stored in the directory IIRC rather than a non existing header. But I feel uncomfortable providing a solution that would not work on regular AMSDOS floppies.
Instead:
Solution 1: Add a header to your file! Simple solution if you have less than 64 KiB of data.
Solution 2: LOAD directive would read all the physical records in that case (*). Since each record is &80 bytes, you are likely to get extra garbage bytes at the end.
NB: If you tell me how to detect when this physical length is reached, I'll update the LOAD directive.
(*) Utopia |info command (for Amsdos) is returning the physical length of headerless files. I'm not sure how they do that. Scanning the directory? Messing with Amsdos? Or maybe the information is available in AMSDOS work zone. That would ease everything.
« NB: If you tell me how to detect when this physical length is reached, I'll update the LOAD directive.
»
Wild guess: After having tried to load past end, the "
number of blocks in current extent" shall be 0.
Pour rappel: since an Amsdos catalog entry can only map 16 KiB worth of blocs, an extent is the the 16 KiB slice you are currently reading/writing. That's why after having processed 16 KiB AMSDOS has to go back to the directory to fetch the following extent (which can be heard when the floppy head is seeking back to track 0).
For the record, you don't have to peek in Amsdos internals.
DISC_IN_CHAR behavior:
• If &1A is met (soft end), NC, NZ, A=&1A. For non-text files it doesn't mean much, and in any case you can continue to read. This is purely informative.
• If all blocks on disc are read (hard end), NC, NZ, A=&0F (error code).
Reference: Amsdos code disassembly.