| Merlin 32 bugs & quirks [message #370280] |
Fri, 06 July 2018 18:44  |
|
|
Originally posted by: fadden
I didn't spot a "report bugs here" on the Brutal Deluxe page, but the authors are here regularly, and this might help somebody else who's trying to use it on Linux.
Using Merlin32_v1.0.zip and building from sources ...
(1) gcc pointed out that an incorrect format is used in an error message (%d vs. %s):
*** orig/Source/a65816_Line.c Mon Feb 15 11:50:24 2016
--- new/Source/a65816_Line.c Sat Jun 23 14:16:17 2018
***************
*** 2409,2415 ****
}
if(nb_byte < 0)
{
! sprintf(param->buffer_error,"Error : Evaluation of DS data size ends up as negative value (%d) : '%d' (line %d, file '%s')",nb_byte,operand,current_line->file_line_number,current_line- >file->file_name);
my_RaiseError(ERROR_RAISE,param->buffer_error);
}
--- 2409,2415 ----
}
if(nb_byte < 0)
{
! sprintf(param->buffer_error,"Error : Evaluation of DS data size ends up as negative value (%d) : '%s' (line %d, file '%s')",nb_byte,operand,current_line->file_line_number,current_line- >file->file_name);
my_RaiseError(ERROR_RAISE,param->buffer_error);
}
(2) MVN / MVP didn't behave the way I expected:
zp equ $11
abs equ $2233
long equ $445566
mvn zp,zp+1
mvp <abs,>abs
mvn long,long+1
Yields:
MVN 11,12
MVP 00,00
MVN 44,44
So if you use an 8-bit constant, you get the constant. If you use a 16-bit or 24-bit constant, you get an implicit '^' operation.
I was expecting MVN/MVP to get a treatment like PEA, where the '#' is implicit; this seems to happen for the 8-bit constants. If I add '#' to the second line, changing it to:
mvp #<abs,#>abs
The output changes to:
MVP 00,22
which seems half right.
(3) Merlin 32 is more sensitive to end-of-line characters than I would have expected. On Linux, a source file with CRLF will often fail, because the ^M gets merged into the last thing on the line.
(This is particularly confusing because the '^M' gets printed in the error message, moving the output cursor back to the start of the line.)
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #370281 is a reply to message #370280] |
Fri, 06 July 2018 20:02  |
|
|
Originally posted by: fadden
On Friday, July 6, 2018 at 3:44:43 PM UTC-7, fadden wrote:
> So if you use an 8-bit constant, you get the constant. If you use a 16-bit or 24-bit constant, you get an implicit '^' operation.
Hmm... Eyes & Lichty's explanation of MVP says:
"The assembler strips the bank bytes from the addresses (ignoring the rest) and reverses them to object code order."
That would mean the implicit '^' is the expected behavior. I'm wondering if "#>abs" became an 8-bit immediate constant and got the 8-bit treatment, while "#<" remained a 16-bit immediate constant.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #370368 is a reply to message #370281] |
Sat, 07 July 2018 21:14 |
kelvin
Messages: 49
Registered: May 2013
Karma: 0
|
Member |
|
|
Lichty and Eyes are documenting how ORCA/M behaves. David Eyes
was the product manager at Hayden Software, the original publisher
of ORCA/M. Thus Mike Westerfield had early accesss to the 65816
and helped shape the official syntax.
WDC's assembler (formerly Zardoz) uses bank bytes, not some 24-bit
address nonsense.
https://apple2history.org/spotlight/mike-westerfield-the-byt e-works/
In <62824261-81c6-42cb-83cc-faaee658c93a@googlegroups.com>
fadden <thefadden@gmail.com> writes:
> On Friday, July 6, 2018 at 3:44:43 PM UTC-7, fadden wrote:
>> So if you use an 8-bit constant, you get the constant. If you use a 16-bit
> or 24-bit constant, you get an implicit '^' operation.
>
> Hmm... Eyes & Lichty's explanation of MVP says:
>
> "The assembler strips the bank bytes from the addresses (ignoring the rest)
> and reverses them to object code order."
>
> That would mean the implicit '^' is the expected behavior. I'm wondering
> if "#>abs" became an 8-bit immediate constant and got the 8-bit treatment,
> while "#<" remained a 16-bit immediate constant.
-------
ProLine: kelvin@pro-kegs
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #372037 is a reply to message #370281] |
Sat, 11 August 2018 17:05 |
|
|
Originally posted by: fadden
Regarding the STR op, which outputs a string prefixed with an 8-bit length....
Merlin 8/16 manual, page 109:
STR 'HI',8D [result = 02 48 49 8D]
....
Note that following HEX bytes, if any, are not counted in the length.
Merlin 32 docs for STR:
This puts a delimited ASCII string in the object code with leading length byte. Following hex values, if any, are not counted in the length.
Testing the feature, Merlin 32 actually does include the trailing hex in the length:
03 48 49 8D
which is probably a good thing. Because the set of string delimiters is limited to single- and double-quote, the only way to get the quote characters into a STR string is by escaping it, which requires a hex value.
This does represent a compatibility break with Merlin 8/16. Since Merlin 8/16's docs explicitly warned you not to do this, it's probably uncommon. I don't know if the correct action is to "fix" Merlin 32 to make it compatible (at the expense of usefulness) or just update the docs to reflect the actual behavior, though I'd learn toward the latter.
Also, the docs for the REV pseudo-op should mention that additional hex values are not allowed. (The behavior does match classic Merlin.)
|
|
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #372081 is a reply to message #370280] |
Sun, 12 August 2018 20:23 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, 7 July 2018 10:44:43 UTC+12, fadden wrote:
> (1) gcc pointed out that an incorrect format is used in an error message (%d vs. %s):
> ! sprintf(param->buffer_error,"Error : Evaluation of DS data size ends up as negative value (%d) : '%d' (line %d, file '%s')",nb_byte,operand,current_line->file_line_number,current_line- >file-
Yes, Visual Studio spotted the same thing:
....\a65816_line.c(2412): warning C4477: 'sprintf' : format string '%d' requires an argument of type 'int', but variadic argument 2 has type 'char *'
I'd already forwarded this one to Antoine and Olivier. They kindly gave permission to create a GitHub repo but couldn't (wouldn't! ; - ) suggest a license to use, so I've not done it yet. I think choosing a license is pretty important.
I also wanted to contribute this simple enhancement:
[Error] Bad Jump for instruction 'BPL next_part' (line 144, file 'Mona2gs.s') : Too long.
.... needed one more thing, so I changed it to:
[Error] Bad Jump for instruction 'BPL next_part' (line 144, file 'Mona2gs.s') : 15 bytes too long.
Cheers,
Nick.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #372119 is a reply to message #372081] |
Mon, 13 August 2018 11:30 |
|
|
Originally posted by: fadden
On Sunday, August 12, 2018 at 5:23:55 PM UTC-7, Nick Westgate wrote:
> I also wanted to contribute this simple enhancement:
>
> [Error] Bad Jump for instruction 'BPL next_part' (line 144, file 'Mona2gs.s') : Too long.
> ... needed one more thing, so I changed it to:
> [Error] Bad Jump for instruction 'BPL next_part' (line 144, file 'Mona2gs.s') : 15 bytes too long.
While you're in there you might want to fix the calculation. This:
org $1000
brl $f000
causes a "Too long" failure (as does $f000 branching to $1000). However, on a IIgs:
*!
!1000:brl f000
00/1000: 82 FD DF BRL F000 {-2003}
The assembler doesn't seem to be taking wrapping at bank boundaries into account.
|
|
|
|
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #372144 is a reply to message #372119] |
Mon, 13 August 2018 17:08 |
|
|
Originally posted by: fadden
Some errors don't result in the Merlin32 command exiting with an error.
If you type "blah blah ugh" into a file and assemble it, you get error messages and an error_output.txt, but the command exits with code 0 (success). If you change it to "blah jmp ugh", it correctly exits with code 1.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #373679 is a reply to message #372144] |
Mon, 17 September 2018 13:18 |
|
|
Originally posted by: fadden
Local labels can be non-unique within a scope. For example:
blah
:foo lda #$00
:foo sta $00
:foo bra :foo
Output is a900 8500 80fa -- it's branching to the first occurrence of :foo. This doesn't really interfere with anything, so I'd file it in the "quirks" category for now.
If you remove the "blah", assembly fails as expected (first label must be non-local), though the message is a little strange ("Can't find format for element ':foo' in Operand ':foo'").
|
|
|
|
|
|
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #373722 is a reply to message #373679] |
Tue, 18 September 2018 03:27 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Le lundi 17 septembre 2018 19:18:33 UTC+2, fadden a écrit :
> Local labels can be non-unique within a scope. For example:
>
> blah
> :foo lda #$00
> :foo sta $00
> :foo bra :foo
>
> If you remove the "blah", assembly fails as expected (first label must be non-local), though the message is a little strange ("Can't find format for element ':foo' in Operand ':foo'").
Thanks for your inputs. I guess that if you try weird things into Merlin 32, you can get weird results. If you work in a reasonable way, you should get what you asked for. I'll fix all these quirks on day. It is always a good idea to look at the output file to see what Merlin 32 has understood of the code and how it has processed it, especially for Macros and Multiple labels like here.
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #375122 is a reply to message #373722] |
Tue, 30 October 2018 13:57 |
|
|
Originally posted by: fadden
Sometimes Merlin 32 has trouble with STX zp,Y ($96). The form of the equate or label seems to matter:
-----
; #1: zero-page equate
; (succeeds)
;L00BC equ $bc
; #2: zero-page value equate
; => [Error] Impossible to decode address mode for instruction 'stx {$00bc},y' (line 21, file 'Test.S').
;L00BC equ $00bc
; #3: code label
; => [Error] Impossible to decode address mode for instruction 'stx L00BC,y' (line 21, file 'Test.S').
org $00bc
L00BC bit L00BC
org $1000
stx $bc,y
ldx L00BC,y
stx L00BC,y
-----
In all cases the LDX instruction is handled correctly. Which is interesting, because LDX has zp,Y and abs,Y ($b6/$be), while STX only has zp,Y, which should make STX unambiguous.
If you comment out the STX and look at the output using case #2, you see:
00000000: 96bc b6bc
As expected. If you put the STX back in and look at error_output.txt, it shows:
18 | 00/FFFF : 96 00 | stx $bc,y
19 | 00/FFFF |
20 | 00/FFFF : BE 00 00 | ldx {$00bc},y
21 | 00/FFFF : 00 | stx {$00bc},y
22 | 00/FFFF |
Note the LDX is using the absolute form at this early stage. Something in the code that sets the initial address modes must not have got the memo about what STX cannot do.
The same problem affects STY dp,X as well. I haven't looked for others beyond that yet.
My thanks to frank_o_rama for reporting this (it snarled SourceGen).
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #375269 is a reply to message #375122] |
Thu, 01 November 2018 13:25 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Le mardi 30 octobre 2018 18:57:22 UTC+1, fadden a écrit :
> Sometimes Merlin 32 has trouble with STX zp,Y ($96). The form of the equate or label seems to matter:
> L00BC equ $00bc
>
> stx L00BC,Y
You can force a 'cast' of a STX $00BC,Y to a STX $BC,Y by changing one line in the source code :
In a65816_code.c, you have around line #1815, the handling of the STX :
else if(!my_stricmp(current_line->opcode_txt,"STX"))
{
if(address_mode == AM_ABSOLUTE)
{
current_line->nb_byte = 3;
current_line->opcode_byte = 0x8E;
current_line->address_mode = AM_ABSOLUTE;
}
else if(address_mode == AM_DIRECT_PAGE)
{
current_line->nb_byte = 2;
current_line->opcode_byte = 0x86;
current_line->address_mode = AM_DIRECT_PAGE;
}
else if(address_mode == AM_DIRECT_PAGE_INDEXED_Y)
{
current_line->nb_byte = 2;
current_line->opcode_byte = 0x96;
current_line->address_mode = AM_DIRECT_PAGE_INDEXED_Y;
}
}
So, replace the :
else if(address_mode == AM_DIRECT_PAGE_INDEXED_Y)
with a :
else if(address_mode == AM_DIRECT_PAGE_INDEXED_Y || address_mode == AM_ABSOLUTE_INDEXED_Y)
which is a way to consider the $BC,Y and the $00BC,Y to be acceptable operand for the STX dp,Y.
You can of course extend this kind of modification to other Opcode where direct page is involved.
Regards,
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #375344 is a reply to message #375269] |
Fri, 02 November 2018 19:07 |
|
|
Originally posted by: fadden
frank_o_rama was experimenting with disassembling and re-assembling an entire 64K bank of data with SourceGen. I think Merlin 32 can do this -- it did fine with 65536 NOPs -- but it's failing because it's checking for bank overflow too early.
Things start to go wrong in CHRGET:
00/00B1 : EE 00 00 | _L00B1 inc _L00B7+1
00/00B4 : D0 00 | _L00B3 bne _L00B7
00/00B6 : EE 00 00 | inc _L00B7+2
00/00B9 : AD 00 00 | _L00B7 lda _L0202
Note the address and labels stop lining up, because the two INCs are forward references and initially defined as absolute references. I think a later pass ("Compact Code for Direct Page Lines") fixes this up.
As far as I can tell the code would be generated correctly (with the fixes I have for the problem in my previous post), but the assembler chooses to die with:
o Compute Line address...
=> [Error] Error : Object code size > 64 KB (line 29872, file 'MemDump_Merlin32.S').
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #375427 is a reply to message #375344] |
Sun, 04 November 2018 10:31 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Le samedi 3 novembre 2018 00:07:39 UTC+1, fadden a écrit :
> frank_o_rama was experimenting with disassembling and re-assembling an entire 64K bank of data with SourceGen. I think Merlin 32 can do this -- it did fine with 65536 NOPs -- but it's failing because it's checking for bank overflow too early.
What is your ORG value ?
Can you share the source file ?
Regards,
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #375431 is a reply to message #375427] |
Sun, 04 November 2018 12:10 |
|
|
Originally posted by: fadden
On Sunday, November 4, 2018 at 7:31:31 AM UTC-8, olivier...@cooperteam.com wrote:
> Le samedi 3 novembre 2018 00:07:39 UTC+1, fadden a écrit :
>> frank_o_rama was experimenting with disassembling and re-assembling an entire 64K bank of data with SourceGen. I think Merlin 32 can do this -- it did fine with 65536 NOPs -- but it's failing because it's checking for bank overflow too early.
>
> What is your ORG value ?
>
> Can you share the source file ?
It's literally an entire 64K bank, dumped from an emulator, so the ORG is $0000. It's actually kind of interesting because, if you place a code entry point hint at the start of the program you're interested in disassembling, you can see which ROM routines are potentially involved as the code scanner spiders through memory. Makes me want to do a graphical visualization.
I generated a 65536-byte data file with this:
putchar(0xe6);
putchar(0x00);
for (int i = 0; i < 65534; i++) {
putchar(0xea);
}
That's "INC $00" followed by 65534 NOPs. It fails in the expected way. If you replace the INC with a pair of NOPs, it succeeds. (FWIW, cc65 fails because it needs a linker script, but 64tass handles it without complaint.)
The SourceGen-generated source file can be downloaded from http://faddensoftware.com/bignop_Merlin32.S.gz for a little while.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #375467 is a reply to message #375431] |
Mon, 05 November 2018 07:19 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Le dimanche 4 novembre 2018 18:10:21 UTC+1, fadden a écrit :
> That's "INC $00" followed by 65534 NOPs. It fails in the expected way. If you replace the INC with a pair of NOPs, it succeeds. (FWIW, cc65 fails because it needs a linker script, but 64tass handles it without complaint.)
>
> The SourceGen-generated source file can be downloaded from http://faddensoftware.com/bignop_Merlin32.S.gz for a little while.
If you comment the my_RaiseError, can you re-assemble the 64 KB bank code ? (I have tested your NOP example).
/* Erreur : on dépasse 64 KB */
if(current_address > 0x10000) /* bug 0xFFFF */
{
sprintf(param->buffer_error,"Error : Object code size > 64 KB (line %d, file '%s')",current_line->file_line_number,current_line->file- >file_name);
//my_RaiseError(ERROR_RAISE,param->buffer_error);
}
Regards,
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #375473 is a reply to message #375467] |
Mon, 05 November 2018 10:57 |
|
|
Originally posted by: fadden
On Monday, November 5, 2018 at 4:19:05 AM UTC-8, olivier...@cooperteam.com wrote:
> If you comment the my_RaiseError, can you re-assemble the 64 KB bank code ? (I have tested your NOP example).
No, it fails in a new way:
o Check for Direct Page Lines...
=> [Bad Address Mode] Operand address '_LFA1E,x' (=0xFA1E) is located outside of the Direct Page (line 30026, file 'MemDump_Merlin32.S')
29922 | 1 MemDump_Merlin32.S 29922 | Data | 11 | | 1 | 00/FA1E : 00 | _LFA1E dfb $a4
...
30026 | 1 MemDump_Merlin32.S 30026 | Code | 11 | | 2 | 00/FAE9 : B5 1E | lda _LFA1E,x
The overflow error it would have hit was:
Error : Object code size > 64 KB (line 29872, file 'MemDump_Merlin32.S'
Note the line numbers. Since _LFA1E appears 50 lines after the line that caused the 64K overflow complaint, I'm guessing the internal PC rolled over, causing the label at that address to be treated as zero page.
I made a simple test case by replacing the last four NOPs with:
lda LastByte
LastByte nop
I posted it as http://faddensoftware.com/bignop2_Merlin32.S.gz
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376266 is a reply to message #372081] |
Sun, 18 November 2018 17:23 |
|
|
Originally posted by: billchatfield1
On Sunday, August 12, 2018 at 8:23:55 PM UTC-4, Nick Westgate wrote:
> On Saturday, 7 July 2018 10:44:43 UTC+12, fadden wrote:
>> (1) gcc pointed out that an incorrect format is used in an error message (%d vs. %s):
>> ! sprintf(param->buffer_error,"Error : Evaluation of DS data size ends up as negative value (%d) : '%d' (line %d, file '%s')",nb_byte,operand,current_line->file_line_number,current_line- >file-
>
> Yes, Visual Studio spotted the same thing:
> ...\a65816_line.c(2412): warning C4477: 'sprintf' : format string '%d' requires an argument of type 'int', but variadic argument 2 has type 'char *'
>
> I'd already forwarded this one to Antoine and Olivier. They kindly gave permission to create a GitHub repo but couldn't (wouldn't! ; - ) suggest a license to use, so I've not done it yet. I think choosing a license is pretty important.
>
> I also wanted to contribute this simple enhancement:
>
> [Error] Bad Jump for instruction 'BPL next_part' (line 144, file 'Mona2gs.s') : Too long.
> ... needed one more thing, so I changed it to:
> [Error] Bad Jump for instruction 'BPL next_part' (line 144, file 'Mona2gs.s') : 15 bytes too long.
>
> Cheers,
> Nick.
I created a github repo and invited everyone on the thread. I don't need to be the owner, but I wanted to get this done so updates can be made. License is currently 'None'.
https://github.com/apple2accumulator/merlin32
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376269 is a reply to message #376266] |
Sun, 18 November 2018 19:22 |
|
|
Originally posted by: fadden
On Sunday, November 18, 2018 at 2:23:47 PM UTC-8, billcha...@gmail.com wrote:
> I created a github repo and invited everyone on the thread. I don't need to be the owner, but I wanted to get this done so updates can be made. License is currently 'None'.
>
> https://github.com/apple2accumulator/merlin32
Thanks! I filed everything in this thread as issues there. The bignop/bignop2 test files I linked to earlier have been attached to the relevant bug.
There's one new issue, for slow performance when there are a large number of local labels. 64tass assembles the file in .019 seconds, Merlin 32 takes over 5 seconds.
I don't know who will be maintaining Merlin 32 or how it will be done, but having the issues in an actual bug tracker makes things easier to sort out.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376275 is a reply to message #376269] |
Sun, 18 November 2018 21:14 |
|
|
Originally posted by: billchatfield1
On Sunday, November 18, 2018 at 7:22:12 PM UTC-5, fadden wrote:
> On Sunday, November 18, 2018 at 2:23:47 PM UTC-8, billcha...@gmail.com wrote:
>> I created a github repo and invited everyone on the thread. I don't need to be the owner, but I wanted to get this done so updates can be made. License is currently 'None'.
>>
>> https://github.com/apple2accumulator/merlin32
>
> Thanks! I filed everything in this thread as issues there. The bignop/bignop2 test files I linked to earlier have been attached to the relevant bug.
>
> There's one new issue, for slow performance when there are a large number of local labels. 64tass assembles the file in .019 seconds, Merlin 32 takes over 5 seconds.
>
> I don't know who will be maintaining Merlin 32 or how it will be done, but having the issues in an actual bug tracker makes things easier to sort out.
I was envisioning a kind of self-service repo where people could fix whatever was important to them and merge their changes back into the master branch. But, I would be willing to do some maintaining myself.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376286 is a reply to message #376275] |
Mon, 19 November 2018 03:17 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Le lundi 19 novembre 2018 03:14:13 UTC+1, billcha...@gmail.com a écrit :
> I was envisioning a kind of self-service repo where people could fix whatever was important to them and merge their changes back into the master branch. But, I would be willing to do some maintaining myself.
I have a plan to do a major review of the code (ie re-writing some parts) somewhere in 2019. Keep updating the bugs list, I'll clean them (if not done in between) then. I'll also invite everyone to discuss about possible extension of the Merlin syntax. One of them would be a way to force Direct Page adressing mode. I guess that addind a D at the end of the opcode would be an option, as the s :
LDAD / STAD / ANDD / ORAD / EORD...
as the
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376287 is a reply to message #376275] |
Mon, 19 November 2018 03:22 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Le lundi 19 novembre 2018 03:14:13 UTC+1, billcha...@gmail.com a écrit :
>
> I was envisioning a kind of self-service repo where people could fix whatever was important to them and merge their changes back into the master branch. But, I would be willing to do some maintaining myself.
I have a plan to do a major review of the code (ie re-writing some parts) somewhere in 2019. Keep updating the bugs list, I'll clean them (if not done in between) then. I'll also invite everyone to discuss about possible extension of the Merlin syntax. One of them would be a way to force Direct Page addressing mode. I guess that adding a D at the end of the opcode would be an option, as the same way we declare LONG address mode (LDAL, STAL...) :
LDAd / STAd / ANDd / ORAd / EORd...
Because Merlin 16+ only looks at the first 3 characters of the opcode, this should keep the compatibility with previous release.
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376293 is a reply to message #376287] |
Mon, 19 November 2018 11:19 |
|
|
Originally posted by: fadden
On Monday, November 19, 2018 at 12:22:29 AM UTC-8, olivier...@cooperteam.com wrote:
> [...] I'll also invite everyone to discuss about possible extension of the Merlin syntax. One of them would be a way to force Direct Page addressing mode.
FWIW, the only time I've needed to force zero-page addressing in SourceGen output is for certain forward references in cc65. The issue there is that cc65 is a one-pass assembler, so unresolved forward references must be treated as 16-bit addresses.
> Because Merlin 16+ only looks at the first 3 characters of the opcode, this should keep the compatibility with previous release.
It would allow the code to assemble, but it wouldn't be assembling to the same thing. I'm not sure if it's better to do the wrong thing quietly or fail noisily.
|
|
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376331 is a reply to message #376287] |
Tue, 20 November 2018 17:33 |
|
|
Originally posted by: billchatfield1
On Monday, November 19, 2018 at 3:22:29 AM UTC-5, olivier...@cooperteam.com wrote:
> Le lundi 19 novembre 2018 03:14:13 UTC+1, billcha...@gmail.com a écrit :
>
>>
>> I was envisioning a kind of self-service repo where people could fix whatever was important to them and merge their changes back into the master branch. But, I would be willing to do some maintaining myself.
>
> I have a plan to do a major review of the code (ie re-writing some parts) somewhere in 2019. Keep updating the bugs list, I'll clean them (if not done in
Will do. I'm working on a branch that will fix some of the bugs.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376339 is a reply to message #376287] |
Tue, 20 November 2018 19:04 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
<olivier.zardini@cooperteam.com> wrote:
> Le lundi 19 novembre 2018 03:14:13 UTC+1, billcha...@gmail.com a écrit :
>
>>
>> I was envisioning a kind of self-service repo where people could fix
>> whatever was important to them and merge their changes back into the
>> master branch. But, I would be willing to do some maintaining myself.
>
> I have a plan to do a major review of the code (ie re-writing some
> parts) somewhere in 2019. Keep updating the bugs list, I'll clean them
> (if not done in between) then. I'll also invite everyone to discuss about
> possible extension of the Merlin syntax. One of them would be a way to
> force Direct Page addressing mode. I guess that adding a D at the end of
> the opcode would be an option, as the same way we declare LONG address
> mode (LDAL, STAL...) :
>
> LDAd / STAd / ANDd / ORAd / EORd...
>
> Because Merlin 16+ only looks at the first 3 characters of the opcode,
> this should keep the compatibility with previous release.
>
> Olivier
>
In Merlin Pro I append an “a” to opcodes to force absolute address mode.
According to the manual, appending any fourth character to an opcode will
do the same, but “a” is more mnemonic.
This is occasionally useful for timing purposes or to facilitate address
modification.
This seems to be incompatible with your suggestion.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376345 is a reply to message #376339] |
Tue, 20 November 2018 21:44 |
|
|
Originally posted by: fadden
On Tuesday, November 20, 2018 at 4:04:39 PM UTC-8, Michael J. Mahon wrote:
> In Merlin Pro I append an “a” to opcodes to force absolute address mode.
> According to the manual, appending any fourth character to an opcode will
> do the same, but “a” is more mnemonic.
[...]
> This seems to be incompatible with your suggestion.
According to Merlin 8/16 manual page 85, "the way to [force absolute addressing] is to add anything except D in Merlin 8, or L in Merlin 16, to the end of the opcode." It then uses ':' as an example.
The only reference I can find to the prohibition on appending 'D' is on page 78, where it notes that the assembler only looks at the first three characters of the opcode, except for macro calls and DEND. "However, because of the exception, the fourth letter should not be a D."
In any event, Merlin 8/16 is already using 'L' to mean something different from any other fourth letter, so "reserving" another character isn't fundamentally wrong (and, because of the prohibition, it's possible that 'D' has gone unused by existing code).
I'm generally in the "fail noisily" camp though.
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376360 is a reply to message #376345] |
Wed, 21 November 2018 03:14 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Merlin 32 has been created to be an Apple IIgs assembler, mostly for binary file using OMF format under GS/OS. So the usage of Direct Addressing is pretty limited, and always done on purpose and well written (we have X and Y index on 16 bit so the usage of indirect addressing [] using zero page is less useful). Merlin 8/16 has been design to be an Apple II 8 bit assembler, so he tries to put Zero Page addressing everywhere.
The idea is of course to re-write some parts of Merlin 32 to let it mimic the Merlin 8/16 behavior and to avoid assembly errors for 8 bit source code. But, on specific cases, I think it could be interesting to have a way to force Merlin 32 to use Direct Page addressing mode (even if the operand is an 16 or 24 bit address). I'm open to any letter (D, Z, 0...).
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376361 is a reply to message #376345] |
Wed, 21 November 2018 03:18 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
fadden <thefadden@gmail.com> wrote:
> On Tuesday, November 20, 2018 at 4:04:39 PM UTC-8, Michael J. Mahon wrote:
>> In Merlin Pro I append an “a” to opcodes to force absolute address mode.
>> According to the manual, appending any fourth character to an opcode will
>> do the same, but “a” is more mnemonic.
> [...]
>> This seems to be incompatible with your suggestion.
>
>
> According to Merlin 8/16 manual page 85, "the way to [force absolute
> addressing] is to add anything except D in Merlin 8, or L in Merlin 16,
> to the end of the opcode." It then uses ':' as an example.
>
> The only reference I can find to the prohibition on appending 'D' is on
> page 78, where it notes that the assembler only looks at the first three
> characters of the opcode, except for macro calls and DEND. "However,
> because of the exception, the fourth letter should not be a D."
>
> In any event, Merlin 8/16 is already using 'L' to mean something
> different from any other fourth letter, so "reserving" another character
> isn't fundamentally wrong (and, because of the prohibition, it's possible
> that 'D' has gone unused by existing code).
>
> I'm generally in the "fail noisily" camp though.
>
Thanks for reminding me about the exception. Although I’d forgotten the
details, I remember the screwy reason for the exception! ;-)
And count me among those who like the unexpected to make some noise...
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376363 is a reply to message #376360] |
Wed, 21 November 2018 04:08 |
|
|
Originally posted by: James Davis
On Wednesday, November 21, 2018 at 12:14:36 AM UTC-8, olivier...@cooperteam..com wrote:
> Merlin 32 has been created to be an Apple IIgs assembler, mostly for binary file using OMF format under GS/OS. So the usage of Direct Addressing is pretty limited, and always done on purpose and well written (we have X and Y index on 16 bit so the usage of indirect addressing [] using zero page is less useful). Merlin 8/16 has been design to be an Apple II 8 bit assembler, so he tries to put Zero Page addressing everywhere.
>
> The idea is of course to re-write some parts of Merlin 32 to let it mimic the Merlin 8/16 behavior and to avoid assembly errors for 8 bit source code. But, on specific cases, I think it could be interesting to have a way to force Merlin 32 to use Direct Page addressing mode (even if the operand is an 16 or 24 bit address). I'm open to any letter (D, Z, 0...).
>
> Olivier
Why not just run one (Merlin 32) or the other (Merlin 8/16) depending on whether you want to generate 32-bit or 8/16-bit assemblies? Won't Merlin 8/16 run on an Apple IIGS (in Apple IIe 8/16-bit mode)?
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #376364 is a reply to message #376363] |
Wed, 21 November 2018 04:37 |
olivier.zardini
Messages: 51
Registered: August 2013
Karma: 0
|
Member |
|
|
Le mercredi 21 novembre 2018 10:08:57 UTC+1, James Davis a écrit :
> Why not just run one (Merlin 32) or the other (Merlin 8/16) depending on whether you want to generate 32-bit or 8/16-bit assemblies? Won't Merlin 8/16 run on an Apple IIGS (in Apple IIe 8/16-bit mode)?
Because 95 % of the job is already done so I need to push myself a little bit to have a Merlin 32 100% compatible with Merlin 8/16 behavior. And once you have used a modern computer to assemble code, it is hard to go back :-)
Olivier
|
|
|
|
| Re: Merlin 32 bugs & quirks [message #388754 is a reply to message #376287] |
Wed, 13 November 2019 15:29 |
|
|
Originally posted by: marketideas1
Two points on this post:
1) If you choose to 'extend' or generate different code than the original Merlin assembler, you should add a 'compatibility' mode that gets 'extended' with a psuedo-op.
2) Choosing 'D' to force DP contends with 'DEND' if you care. I decided to go with appending a '0' (zero) to the opcode for 'force DP'. So I have LDAL (3 byte address), LDA: (2 byte address) and LDA0 (1 byte address)
On Monday, November 19, 2018 at 12:22:29 AM UTC-8, olivier...@cooperteam.com wrote:
> Le lundi 19 novembre 2018 03:14:13 UTC+1, billcha...@gmail.com a écrit :
>
>>
>> I was envisioning a kind of self-service repo where people could fix whatever was important to them and merge their changes back into the master branch. But, I would be willing to do some maintaining myself.
>
> I have a plan to do a major review of the code (ie re-writing some parts) somewhere in 2019. Keep updating the bugs list, I'll clean them (if not done in between) then. I'll also invite everyone to discuss about possible extension of the Merlin syntax. One of them would be a way to force Direct Page addressing mode. I guess that adding a D at the end of the opcode would be an option, as the same way we declare LONG address mode (LDAL, STAL....) :
>
> LDAd / STAd / ANDd / ORAd / EORd...
>
> Because Merlin 16+ only looks at the first 3 characters of the opcode, this should keep the compatibility with previous release.
>
> Olivier
|
|
|
|
Members
Search
Help
Register
Login
Home
