info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Brutal Deluxe Software releases Merlin 32
707 views
Skip to first unread message
Antoine Vignau
Jan 6, 2015, 7:20:57 AM1/6/15
to
Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
Merlin 32 is a multi-pass Cross Assembler running under Windows targeting 8-bit processors in the 6502 series (such as 6502 and 65c02) and the 16 bit 65c816 processor.
It is compatible with Glen Bredon's Merlin 16+ syntax, including support for Macros, Pre-processor, Logical Expressions, Conditional Operations, Variables, Loops, Local Labels...
It can build fixed position object code or relocatable executables (OMF v2.1) as we can find on 16-bit APPLE IIGS operating systems like ProDOS 16 or GS/OS (S16, EXE, CDA, NDA, FST, PIF, LIBRARY, TOOL...).
Merlin 32 has been successfully used to re-assemble classic Apple IIgs games and utilities such as Rastan, Sensei, Shuffle Puck Cafe, Final Assault, Lemmings, The Tinies, Cogito, Blockade, Convert 3200... without the need to modify the original source files.
Merlin 32 is part of the Brutal Deluxe's Cross Development Tools Project, a full set of utilities available on Windows (and other) platforms to enable the creation of new Apple IIgs software : 65c816 Assembler, 65c816 Disassembler, 65c816 Simulator, Graphic File Converter, Resource Catcher...
Learn more and download Merlin 32 at http://brutaldeluxe.fr/products/crossdevtools/merlin/
Antoine Vignau & Olivier Zardini
Brutal Deluxe Software
http://www.brutaldeluxe.fr/
Merlin 32 is a multi-pass Cross Assembler running under Windows targeting 8-bit processors in the 6502 series (such as 6502 and 65c02) and the 16 bit 65c816 processor.
It is compatible with Glen Bredon's Merlin 16+ syntax, including support for Macros, Pre-processor, Logical Expressions, Conditional Operations, Variables, Loops, Local Labels...
It can build fixed position object code or relocatable executables (OMF v2.1) as we can find on 16-bit APPLE IIGS operating systems like ProDOS 16 or GS/OS (S16, EXE, CDA, NDA, FST, PIF, LIBRARY, TOOL...).
Merlin 32 has been successfully used to re-assemble classic Apple IIgs games and utilities such as Rastan, Sensei, Shuffle Puck Cafe, Final Assault, Lemmings, The Tinies, Cogito, Blockade, Convert 3200... without the need to modify the original source files.
Merlin 32 is part of the Brutal Deluxe's Cross Development Tools Project, a full set of utilities available on Windows (and other) platforms to enable the creation of new Apple IIgs software : 65c816 Assembler, 65c816 Disassembler, 65c816 Simulator, Graphic File Converter, Resource Catcher...
Learn more and download Merlin 32 at http://brutaldeluxe.fr/products/crossdevtools/merlin/
Antoine Vignau & Olivier Zardini
Brutal Deluxe Software
http://www.brutaldeluxe.fr/
Steven Hirsch
Jan 6, 2015, 7:44:28 AM1/6/15
to
On 01/06/2015 07:20 AM, Antoine Vignau wrote:
> Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
You guys rock! Thanks for your hard work :-)
> Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
Riccardo
Jan 6, 2015, 8:50:23 AM1/6/15
to
Riccardo
Jan 6, 2015, 8:56:03 AM1/6/15
to
Compiling for hardware APPLE2 on 06/01/15 14.42: C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Source C:\Users\GR\workspace\A2\Rom.asm
Compiler 'MADS' output:
C:\Dev\Merlin32_v1.0\Merlin32.exe v 1.0, (c) Brutal Deluxe 2011-2015
+ Assemble project files...
o Loading Sources files...
- Rom.asm
o Loading Macro files...
o Check for duplicated Macros...
o Decoding lines types...
o Process local/variable Labels...
o Process Asterisk lines...
o Build External table...
o Build Equivalence table...
o Build Variable table...
o Process Equivalence values...
o Replace Lup with code...
o Replace Macros with Code...
o Process MX directives...
o Process Conditional directives...
o Build Label table...
o Check for duplicated Labels...
o Check for unknown Source lines...
o Check for Dum lines...
o Compute Operand Code size...
o Compute Operand Data size...
o Compute Line address...
o Build Code Line...
o Compact Code for Direct Page Lines...
o Check for Err lines...
o Build Data Line...
o Build Object Code...
+ Link project files...
o Build Binary output file...
=> Creating Object file 'C:\Users\GR\workspace\A2\Rom'
+ Create Output Text file...
=> Creating Output file 'C:\Users\GR\workspace\A2\Rom_Output.txt'
MADS is not MADS but Merlin32
Compiler 'MADS' output:
C:\Dev\Merlin32_v1.0\Merlin32.exe v 1.0, (c) Brutal Deluxe 2011-2015
+ Assemble project files...
o Loading Sources files...
- Rom.asm
o Loading Macro files...
o Check for duplicated Macros...
o Decoding lines types...
o Process local/variable Labels...
o Process Asterisk lines...
o Build External table...
o Build Equivalence table...
o Build Variable table...
o Process Equivalence values...
o Replace Lup with code...
o Replace Macros with Code...
o Process MX directives...
o Process Conditional directives...
o Build Label table...
o Check for duplicated Labels...
o Check for unknown Source lines...
o Check for Dum lines...
o Compute Operand Code size...
o Compute Operand Data size...
o Compute Line address...
o Build Code Line...
o Compact Code for Direct Page Lines...
o Check for Err lines...
o Build Data Line...
o Build Object Code...
+ Link project files...
o Build Binary output file...
=> Creating Object file 'C:\Users\GR\workspace\A2\Rom'
+ Create Output Text file...
=> Creating Output file 'C:\Users\GR\workspace\A2\Rom_Output.txt'
MADS is not MADS but Merlin32
D Finnigan
Jan 6, 2015, 10:43:12 AM1/6/15
to
Antoine Vignau wrote:
> Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
>
> Merlin 32 is a multi-pass Cross Assembler running under Windows targeting
> 8-bit processors in the 6502 series (such as 6502 and 65c02) and the 16
> bit
> 65c816 processor.
Good job! :-)
> Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
>
> Merlin 32 is a multi-pass Cross Assembler running under Windows targeting
> 8-bit processors in the 6502 series (such as 6502 and 65c02) and the 16
> bit
> 65c816 processor.
Bill Buckels
Jan 6, 2015, 2:08:20 PM1/6/15
to
"Antoine Vignau" <antoine...@laposte.net> wrote:
>Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
Bravo and Congratulations!
>Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
>Merlin 32 is a multi-pass Cross Assembler running under Windows targeting
>8-bit processors in the 6502 series (such as 6502 and 65c02) and the 16 bit
>65c816 processor.
>It is compatible with Glen Bredon's Merlin 16+ syntax, including support
>for Macros, Pre-processor, Logical Expressions, Conditional Operations,
>Variables, Loops, Local Labels...
>It can build fixed position object code or relocatable executables (OMF
>v2.1) as we can find on 16-bit APPLE IIGS operating systems like ProDOS 16
>or GS/OS (S16, EXE, CDA, NDA, FST, PIF, LIBRARY, TOOL...).
>Merlin 32 has been successfully used to re-assemble classic Apple IIgs
>games and utilities such as Rastan, Sensei, Shuffle Puck Cafe, Final
>Assault, Lemmings, The Tinies, Cogito, Blockade, Convert 3200... without
>the need to modify the original source files.
>Merlin 32 is part of the Brutal Deluxe's Cross Development Tools Project, a
>full set of utilities available on Windows (and other) platforms to enable
>the creation of new Apple IIgs software : 65c816 Assembler, 65c816
>Disassembler, 65c816 Simulator, Graphic File Converter, Resource Catcher...
My learning is slow. I make no promises. Without a C compiler, some days I
am lost. Maybe most days:)
Even with Orca C I have a steep learning curve, despite my understanding of
sgemented archictecture, API's and calling IIgs conventions, and QuickDraw
basics, and the IIgs graphics modes.
I lack the enthusiasm for the energy that is required to be effective in a
GUI environment, especially if I don't have the comfort level of the C
language.
Again, sincere congratulations. I wanted to promise to make full use of
Merlin 32, but I am unable to lie to you and Olivier.
Bill
ultramagnus_tcv
Jan 6, 2015, 4:26:25 PM1/6/15
to
m
mdj
Jan 7, 2015, 3:29:09 AM1/7/15
to
On Tuesday, 6 January 2015 22:20:57 UTC+10, Antoine Vignau wrote:
> Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
Very cool!
> Paris, January 6th, 2015 - Brutal Deluxe Sofware releases Merlin 32
I did a quick attempt at building it using GCC under Linux, just to gauge the difficulty. The only real impediment seems to be the use of Windows specific file IO in a65815_Macro.c. If that could be changed to use ANSI/ISO C calls, it'd be easy to make it build on all the major platforms.
I don't have a Windows environment to sandbox the functions and test it, so consider this a beg request.
I'm happy to share the rest of the changes I made, but I did it quickly as a hack so I'd need to do it cleanly before submitting. This is the summary:
1. Add include guards to the headers.
2. Add forward declarations for omf_segment and omf_project.
3. Replace use of stricmp() with strcasecmp()
4. Add stdint.h to Dc_Library.h.
If someone can help with the windows file IO, I'll happily submit a patch for the rest.
Thanks guys, this thing is awesome.
Matt
STYNX
Jan 7, 2015, 6:44:13 AM1/7/15
to
On Tuesday, January 6, 2015 1:20:57 PM UTC+1, Antoine Vignau wrote:
> Learn more and download Merlin 32 at http://brutaldeluxe.fr/products/crossdevtools/merlin/
>
> Antoine Vignau & Olivier Zardini
> Brutal Deluxe Software
> http://www.brutaldeluxe.fr/
Now there is another reason to learn 65xxx assembler :-P
> Learn more and download Merlin 32 at http://brutaldeluxe.fr/products/crossdevtools/merlin/
>
> Antoine Vignau & Olivier Zardini
> Brutal Deluxe Software
> http://www.brutaldeluxe.fr/
Bill Buckels
Jan 7, 2015, 6:51:35 AM1/7/15
to
Is Merlin 32 suitable for integration into:
http://llvm.org/
This is an idle thought and I wouldn't blame anyone for not replying. I have
no idea if I am capable of doing something about this either. I know of some
guys who are, but whether they would want to in this case, I have no idea.
Again congratulations on Merlin 32 Antoine and Olivier.
Bill
http://llvm.org/
This is an idle thought and I wouldn't blame anyone for not replying. I have
no idea if I am capable of doing something about this either. I know of some
guys who are, but whether they would want to in this case, I have no idea.
Again congratulations on Merlin 32 Antoine and Olivier.
Bill
mdj
Jan 7, 2015, 8:21:43 AM1/7/15
to
On Wednesday, 7 January 2015 21:51:35 UTC+10, Bill Buckels wrote:
As you point out though Bill, it's a tough project. Getting it to emit code that works is one thing, and that's probably doable in the shorter term. Generating *good* 816 code is probably an epic job.
Then you're going to need the support libraries, and you'd want most of those to be hand optimised; even on an 816 core functions need to be hand-written assembler for good results.
Matt
> "Bill Buckels" wrote:
> >I wish I was more motivated to write in Assembler.
>
> Is Merlin 32 suitable for integration into:
>
> http://llvm.org/
There's been a couple of attempts to develop an llvm backend for the Atmel AVR, so it seems that llvm is flexible enough to support smaller architectures, and it supports a text output emitter that could be used to drive Merlin32.
> >I wish I was more motivated to write in Assembler.
>
> Is Merlin 32 suitable for integration into:
>
> http://llvm.org/
As you point out though Bill, it's a tough project. Getting it to emit code that works is one thing, and that's probably doable in the shorter term. Generating *good* 816 code is probably an epic job.
Then you're going to need the support libraries, and you'd want most of those to be hand optimised; even on an 816 core functions need to be hand-written assembler for good results.
Matt
olivier...@itn-group.eu
Jan 7, 2015, 8:25:35 AM1/7/15
to
Le mardi 6 janvier 2015 14:56:03 UTC+1, Riccardo a écrit :
> Compiling for hardware APPLE2 on 06/01/15 14.42:
> C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Source C:\Users\GR\workspace\A2\Rom.asm
This should be :
> Compiling for hardware APPLE2 on 06/01/15 14.42:
> C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Source C:\Users\GR\workspace\A2\Rom.asm
C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Library C:\Users\GR\workspace\A2\Rom.asm
Because 'Source' is the folder containing Merlin 32 source code while 'Library' is the folder containing Merlin 16+ library files (*.Macs.s)
Le mercredi 7 janvier 2015 09:29:09 UTC+1, mdj a écrit :
> On Tuesday, 6 January 2015 22:20:57 UTC+10, Antoine Vignau wrote:
> I did a quick attempt at building it using GCC under Linux, just to gauge the difficulty.
> The only real impediment seems to be the use of Windows specific file IO
The modifications are limited if we stay on Intel processor architecture (sur to Little / big endian stuff) :
- change the stricmp function
- change the folders management function
- remove "b" (binary) option in fopen() functions
- remove the #include <malloc.h> for Macintosh compilation.
- check structure alignment because Windows 32 bit uses a 1 byte alignment option (where Unix uses mostly 4 or 8 bytes)
Even if the compilation step is not very complex, the test step should be done deeply, to ensure the 3 expected target systems (Windows / Linux / Macintosh) build the same files from the same sources.
Olivier
mdj
Jan 7, 2015, 8:43:05 AM1/7/15
to
On Wednesday, 7 January 2015 23:25:35 UTC+10, olivier...@itn-group.eu wrote:
> Even if the compilation step is not very complex, the test step should be done deeply, to ensure the 3 expected target systems (Windows / Linux / Macintosh) build the same files from the same sources.
You're right of course. Your code looks pretty clean to me, so I expect building a few of the large examples would do the trick.
> Even if the compilation step is not very complex, the test step should be done deeply, to ensure the 3 expected target systems (Windows / Linux / Macintosh) build the same files from the same sources.
Of course, if Merlin32 could assemble Merlin 16+ and produce a byte-for-byte result, that'd be a fairly high quality regression test :-)
Riccardo
Jan 7, 2015, 11:03:27 AM1/7/15
to
Il giorno mercoledì 7 gennaio 2015 14:25:35 UTC+1, olivier...@itn-group.eu ha scritto:
> Le mardi 6 janvier 2015 14:56:03 UTC+1, Riccardo a écrit :
> > Compiling for hardware APPLE2 on 06/01/15 14.42:
> > C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Source C:\Users\GR\workspace\A2\Rom.asm
>
> This should be :
>
> C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Library C:\Users\GR\workspace\A2\Rom.asm
>
> Because 'Source' is the folder containing Merlin 32 source code while 'Library' is the folder containing Merlin 16+ library files (*.Macs.s)
>
Right!
> Le mardi 6 janvier 2015 14:56:03 UTC+1, Riccardo a écrit :
> > Compiling for hardware APPLE2 on 06/01/15 14.42:
> > C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Source C:\Users\GR\workspace\A2\Rom.asm
>
> This should be :
>
> C:\Dev\Merlin32_v1.0\Merlin32.exe -v C:\Dev\Merlin32_v1.0\Library C:\Users\GR\workspace\A2\Rom.asm
>
> Because 'Source' is the folder containing Merlin 32 source code while 'Library' is the folder containing Merlin 16+ library files (*.Macs.s)
>
* @com.wudsn.ide.asm.hardware=APPLE2
* @com.wudsn.ide.asm.outputfileextension=.b
* @com.wudsn.ide.asm.outputfolder=C:\Users\GR\workspace\A2\
* Protocol Converter Call
XC
ZPTempL equ $0006 ;Temporary zero page storage
ZPTempH equ $0007
*** Pointers ***
LowMain equ $000A
HiMain equ $000B
*** Monitor routines ***
COut equ $FDED ;Console output ASCII
CROut equ $FD8E ;Carriage return
PRbyte equ $FDDA ;Print byte in hex
*
StatusCmd equ 0
** Status Code **
StatusDIB equ 3
StatusUNI equ 5
*
ControlCmd equ 4
......
I use XC directive to targetting 65C02;
so the Obj code is perfect equal to using Merlin 8 on my Apple IIc.
Great!
Riccardo
Michael 'AppleWin Debugger Dev'
Jan 7, 2015, 12:33:27 PM1/7/15
to
On Wednesday, January 7, 2015 5:21:43 AM UTC-8, mdj wrote:
> On Wednesday, 7 January 2015 21:51:35 UTC+10, Bill Buckels wrote:
> > "Bill Buckels" wrote:
> > >I wish I was more motivated to write in Assembler.
> > Is Merlin 32 suitable for integration into:
> > http://llvm.org/
I'll echo what Matt said.
> On Wednesday, 7 January 2015 21:51:35 UTC+10, Bill Buckels wrote:
> > "Bill Buckels" wrote:
> > >I wish I was more motivated to write in Assembler.
> > Is Merlin 32 suitable for integration into:
> > http://llvm.org/
LLVM isn't really suited for 8-bit CPUs.
It would be a real bitch to get the back-end to generate optimized code.
Writing 65(c)02 assembly really is the way to go.
Michael 'AppleWin Debugger Dev'
Jan 7, 2015, 12:38:53 PM1/7/15
to
On Tuesday, January 6, 2015 11:08:20 AM UTC-8, Bill Buckels wrote:
> I wish I was more motivated to write in Assembler.
Bill, I picked up a hard back copy of:
> I wish I was more motivated to write in Assembler.
"Assembly Lines: The Complete Book"
not because I "needed" it but because I wanted to see what all the fuss was all about.
It is a *fantastic* book and I rate most books extremely critical. Extremely well written. Go order your copy!! Worth every penny.
http://www.lulu.com/us/en/shop/roger-wagner/assembly-lines-the-complete-book/hardcover/product-21959093.html
wss...@gmail.com
Jan 7, 2015, 1:02:22 PM1/7/15
to
The fact that C compilers targeting the 6502 exist is nice for portability reasons, but I would never recommend that anyone use C as a primary development language for 6502 systems (sorry Bill). On the other hand, if that's what you know, then it's certainly better than nothing.
Message has been deleted
Christopher G. Mason
Jan 7, 2015, 1:43:09 PM1/7/15
to
by Lichty and Eyes. I never really bothered reading it though since it
used APW and Apple's macros. I wonder if the programming examples can be
adapted for use in Merlin?
Riccardo
Jan 7, 2015, 2:31:52 PM1/7/15
to
Bill Buckels
Jan 7, 2015, 7:29:45 PM1/7/15
to
<wss...@gmail.com> wrote:
>The fact that C compilers targeting the 6502 exist is nice for portability
>reasons, but I would never recommend that anyone use C as a primary
>development language for 6502 systems (sorry Bill).
Nor would I. But I would recommned that C be used with assembly.
>The fact that C compilers targeting the 6502 exist is nice for portability
>reasons, but I would never recommend that anyone use C as a primary
>development language for 6502 systems (sorry Bill).
>On the other hand, if that's what you know, then it's certainly better than
>nothing.
view. That comes from the PC perspective of extending C with assembly,
inline or otherwise.
When I was a younger person and writing tsr's and device drivers on the IBM
in 8088 assembler I may have felt differently. I seem to recall that I did:)
I also laughed at anything Apple Computer offered. Still do.
I just have a wish that something like Orca C will someday be available as a
cross-compiler.
Instead of saying that I don't code in assembly I should probably say
instead that I don't want to code in assembly if C is available. Perhaps I
am lazy.
Bill
Bill Buckels
Jan 7, 2015, 7:35:24 PM1/7/15
to
"Bill Buckels" <bbuc...@mts.net> wrote:
>Perhaps I am lazy.
There's no perhaps about this actually:)
Bill
>Perhaps I am lazy.
There's no perhaps about this actually:)
Bill
Steve Nickolas
Jan 7, 2015, 7:44:41 PM1/7/15
to
On Wed, 7 Jan 2015, Bill Buckels wrote:
> I just have a wish that something like Orca C will someday be available
> as a cross-compiler.
QFT. Or really, *any* sort of 65816 C cross-compiler that can be utilized
> I just have a wish that something like Orca C will someday be available
> as a cross-compiler.
with CiderPress and GSport to create native P16 apps.
I'm out of my league here but any needed testing I could probably do. I'm
*OK* at ASM, but I'm *good* at C.
-uso.
wss...@gmail.com
Jan 7, 2015, 7:53:57 PM1/7/15
to
Am Mittwoch, 7. Januar 2015 19:29:45 UTC-5 schrieb Bill Buckels:
> <wss...@gmail.com> wrote:
> >The fact that C compilers targeting the 6502 exist is nice for portability
> >reasons, but I would never recommend that anyone use C as a primary
> >development language for 6502 systems (sorry Bill).
>
> Nor would I. But I would recommned that C be used with assembly.
>
> >On the other hand, if that's what you know, then it's certainly better than
> >nothing.
>
> This is where we differ. Assembly language is better than nothing from my
> view. That comes from the PC perspective of extending C with assembly,
> inline or otherwise.
>
> When I was a younger person and writing tsr's and device drivers on the IBM
> in 8088 assembler I may have felt differently. I seem to recall that I did:)
>
> I also laughed at anything Apple Computer offered. Still do.
>
> I just have a wish that something like Orca C will someday be available as a
> cross-compiler.
Well Orca C targets the 65c816, which is a very different thing than a 6502. C fits the 65c816 much better than it does the 6502.
> <wss...@gmail.com> wrote:
> >The fact that C compilers targeting the 6502 exist is nice for portability
> >reasons, but I would never recommend that anyone use C as a primary
> >development language for 6502 systems (sorry Bill).
>
> Nor would I. But I would recommned that C be used with assembly.
>
> >On the other hand, if that's what you know, then it's certainly better than
> >nothing.
>
> This is where we differ. Assembly language is better than nothing from my
> view. That comes from the PC perspective of extending C with assembly,
> inline or otherwise.
>
> When I was a younger person and writing tsr's and device drivers on the IBM
> in 8088 assembler I may have felt differently. I seem to recall that I did:)
>
> I also laughed at anything Apple Computer offered. Still do.
>
> I just have a wish that something like Orca C will someday be available as a
> cross-compiler.
Bill Buckels
Jan 7, 2015, 8:35:28 PM1/7/15
to
<wss...@gmail.com> wrote:
>Well Orca C targets the 65c816, which is a very different thing than a
>6502. C fits the 65c816 much better than it does the 6502.
compiler.
I already have 2 - 6502 C cross-compilers than run in aa cmd Window on this
XP box, so I don't need anymore of those:)
Both of them offer inline assembly (I like Aztec C65 syntax for inline #asm
better than Oliver's (cc65) but both seem to work pretty well.
My first Apple II C programs contained inline assy and lots of low level
pointers too... what else can you do on the Apple II? I also hand
dis-assembled and relocated the mouse driver for a IIgs to the same set of
common vectors in mixed C and assmbler and make the calls in mixed C and
assy. It's in a C-like syntax and just easier to read.
I think it's really just that one guy likes knitting doilies and the other
guy likes painting Windows... if I could be so bold:)
Anyway, It would take me too long to write a compiler since I haven't done
one before. But of course I've done and redone library routines since
starting with C in the '80's. My assembly came after BASIC and before C...
8088 lots of it.
Assembler. It's expensive code:) Because it takes longer to write and
maintain and explain. In all fairness though, the Apple programmers I knew
were low-level too:) That quickly vanished when the major Mac market took
over and the Artists, Musicians, Writers and Teachers were the only ones
left on Apples, and nobody I would call very technical in the bunch.
Lots of techs on the PC still then though...
Bill
Christopher G. Mason
Jan 7, 2015, 8:45:23 PM1/7/15
to
On 1/7/2015 7:46 PM, Steve Nickolas wrote:
> QFT. Or really, *any* sort of 65816 C cross-compiler that can be
> utilized with CiderPress and GSport to create native P16 apps.
>
> I'm out of my league here but any needed testing I could probably do.
> I'm *OK* at ASM, but I'm *good* at C.
>
> -uso.
That would be pretty nice to have.
> QFT. Or really, *any* sort of 65816 C cross-compiler that can be
> utilized with CiderPress and GSport to create native P16 apps.
>
> I'm out of my league here but any needed testing I could probably do.
> I'm *OK* at ASM, but I'm *good* at C.
>
> -uso.
On a related note, would Merlin32 be of any use to SNES homebrew
programming?
pitz
Jan 7, 2015, 9:17:09 PM1/7/15
to
On Wednesday, January 7, 2015 5:35:28 PM UTC-8, Bill Buckels wrote:
> <wss...@gmail.com> wrote:
> >Well Orca C targets the 65c816, which is a very different thing than a
> >6502. C fits the 65c816 much better than it does the 6502.
>
> And Merlin 32 also targets the 65c816 which is my point in wishing for a C
> compiler.
>
Hmmm. Extending LLVM could be worth a shot.
> <wss...@gmail.com> wrote:
> >Well Orca C targets the 65c816, which is a very different thing than a
> >6502. C fits the 65c816 much better than it does the 6502.
>
> And Merlin 32 also targets the 65c816 which is my point in wishing for a C
> compiler.
>
Reading this thread, my initial reaction also was that targeting 6502 was gonna be real difficult. Most implementations of C use the stack to pass parameters and subroutine return addresses. The 6502 has a hardware stack of 256 bytes, so for anything but trivial programs, a stack has to be emulated somewhere else in the 6502 address space in a similar manner that a heap has to be maintained for C's dynamic memory allocation malloc(). And for an emulated stack, access to values in the stack will really bloat your compiled code.
The 65816, on the other hand, has a significantly larger stack, and you can utilize the hardware stack pointer register more efficiently.
/pitz
mdj
Jan 7, 2015, 10:27:57 PM1/7/15
to
On Thursday, 8 January 2015 04:02:22 UTC+10, wss...@gmail.com wrote:
> I agree. It is an unfortunate fact that the 6502 is not at all a good match for the C language. C was originally developed around the PDP-11 instruction set and the equivalence of integers and pointers.
>
> The fact that C compilers targeting the 6502 exist is nice for portability reasons, but I would never recommend that anyone use C as a primary development language for 6502 systems (sorry Bill). On the other hand, if that's what you know, then it's certainly better than nothing.
I was referring to the 816, but some of the objections still apply. On an 816, you can do a 'small' memory model C with a separate data segment and program segment, which will give you a quite natural sizeof(int) == sizeof(int *) == 2. Code density OTOH, will still be fairly ordinary compared to processor architectures with addressing modes that auto-inc/dec registers, condition execution, etc.
> I agree. It is an unfortunate fact that the 6502 is not at all a good match for the C language. C was originally developed around the PDP-11 instruction set and the equivalence of integers and pointers.
>
> The fact that C compilers targeting the 6502 exist is nice for portability reasons, but I would never recommend that anyone use C as a primary development language for 6502 systems (sorry Bill). On the other hand, if that's what you know, then it's certainly better than nothing.
Exploiting the full 24 bit memory model is considerably less efficient. This is perhaps the only thing the fabled 65832 CPU would've been useful for.
For the 6502, if doing C was my sort of thing, I'd look at a code generator targeting Dave Schmenk's PLASMA virtual machine. PLASMA's language is very B-like (so like a typeless C) and the performance is excellent. That, plus bytecode pipelining for critical functions, plus good-old 6502 when the going gets tough, would be quite a nice environment indeed.
Matt
wss...@gmail.com
Jan 7, 2015, 11:11:15 PM1/7/15
to
Am Mittwoch, 7. Januar 2015 21:17:09 UTC-5 schrieb pitz:
> Most implementations of C use the stack to pass parameters and subroutine return addresses. The 6502 has a hardware stack of 256 bytes, so for anything but trivial programs, a stack has to be emulated somewhere else in the 6502 address space in a similar manner that a heap has to be maintained for C's dynamic memory allocation malloc(). And for an emulated stack, access to values in the stack will really bloat your compiled code.
I have never looked at any C compilers for the 6502, but I really hope that any cross-compiler, at least, would generate a call graph and dispense with the stack frame for every provably non-recursive function.
> Most implementations of C use the stack to pass parameters and subroutine return addresses. The 6502 has a hardware stack of 256 bytes, so for anything but trivial programs, a stack has to be emulated somewhere else in the 6502 address space in a similar manner that a heap has to be maintained for C's dynamic memory allocation malloc(). And for an emulated stack, access to values in the stack will really bloat your compiled code.
mmphosis
Jan 8, 2015, 1:54:58 AM1/8/15
to
WIth a very hacked together makefile, I've successfully built for 32-bit
Linux on arm and intel and for Mac OS X on PowerPC and intel.
arm-linux-gnueabihf
i686-linux-gnu
powerpc-apple-darwin8
i686-apple-darwin10
When I run the Mac OS X versions the current address gets zeroed, and I get
this error:
=> [Error] Bad Jump for instruction 'BPL tree' (line 113, file
'forestfire.s') : Too long.
The Linux versions work with the very limited testing I've done so far.
Linux on arm and intel and for Mac OS X on PowerPC and intel.
arm-linux-gnueabihf
i686-linux-gnu
powerpc-apple-darwin8
i686-apple-darwin10
When I run the Mac OS X versions the current address gets zeroed, and I get
this error:
=> [Error] Bad Jump for instruction 'BPL tree' (line 113, file
'forestfire.s') : Too long.
The Linux versions work with the very limited testing I've done so far.
olivier...@itn-group.eu
Jan 8, 2015, 3:25:55 AM1/8/15
to
Le jeudi 8 janvier 2015 02:45:23 UTC+1, Christopher G. Mason a écrit :
> On a related note, would Merlin32 be of any use to SNES homebrew
> programming?
Yes. If you build Fixed Address binary files, you can use it for SNES programming. You probably have to define first a bunch a EQU definitions for all SNES hardware entry points to make the read of the code easier.
> On a related note, would Merlin32 be of any use to SNES homebrew
> programming?
Olivier
olivier...@itn-group.eu
Jan 8, 2015, 3:34:28 AM1/8/15
to
For the Unix port, check also the structure alignment. It is 1 byte on Win 32, you have to check on Unix but I think by default it is 4 or 8. This should not be an issue here because there is no memcpy() of whole structure content but keep it in mind.
I have received yesterday a port of Merlin 32 on Linux & MacOs X. I will check the modification today and update the original source code to merge everything together.
Olivier
olivier...@itn-group.eu
Jan 8, 2015, 3:39:30 AM1/8/15
to
Le jeudi 8 janvier 2015 02:35:28 UTC+1, Bill Buckels a écrit :
> >Well Orca C targets the 65c816, which is a very different thing than a
> >6502. C fits the 65c816 much better than it does the 6502.
>
> And Merlin 32 also targets the 65c816 which is my point in wishing for a C
> compiler.
The interest of Merlin 32 is to offer a level of abstraction for a C compiler. The C compiler has just to create the 65c816 assembly source files and do not have to care about how the source file goes as binary file (including OMF support, ExpressLoad, Multi-Files linker...). So for anyone wanting to build a Compiler (for any kind of high level language), Merlin 32 lets your work at the assembly line output, not the binary one.
> >Well Orca C targets the 65c816, which is a very different thing than a
> >6502. C fits the 65c816 much better than it does the 6502.
>
> And Merlin 32 also targets the 65c816 which is my point in wishing for a C
> compiler.
Olivier
olivier...@itn-group.eu
Jan 8, 2015, 3:43:01 AM1/8/15
to
Le mercredi 7 janvier 2015 19:43:09 UTC+1, Christopher G. Mason a écrit :
> I have a copy here of "Programming the Apple IIgs in Assembly Language"
> by Lichty and Eyes. I never really bothered reading it though since it
> used APW and Apple's macros. I wonder if the programming examples can be
> adapted for use in Merlin?
I would recommend "Apple IIgs : Machine language for Beginners" (Roger Wagner) who is very good as a first Apple IIgs programming book. It contains examples in both Merlin Orca syntax.
> I have a copy here of "Programming the Apple IIgs in Assembly Language"
> by Lichty and Eyes. I never really bothered reading it though since it
> used APW and Apple's macros. I wonder if the programming examples can be
> adapted for use in Merlin?
You can convert source code (especially if they are not very long) from Merlin to Orca or Orca to Merlin with small effort. Merlin 16+ manual (freely available for download) has a table of equivalence between the 2 environment.
Olivier
Hugh Hood
Jan 8, 2015, 10:51:48 AM1/8/15
to
Olivier:
Thanks for your work with Merlin 32
Does the OS X port you mentioned receiving yesterday have both Intel and PPC
versions? I know you mentioned that a PPC port would be more involved.
Some of us still find the older machines useful. Or is that the Apple II? :)
Hugh Hood
in article c8bb4579-8904-4861...@googlegroups.com,
olivier...@itn-group.eu at olivier...@itn-group.eu wrote on 1/8/15
2:34 AM:
Thanks for your work with Merlin 32
Does the OS X port you mentioned receiving yesterday have both Intel and PPC
versions? I know you mentioned that a PPC port would be more involved.
Some of us still find the older machines useful. Or is that the Apple II? :)
Hugh Hood
in article c8bb4579-8904-4861...@googlegroups.com,
olivier...@itn-group.eu at olivier...@itn-group.eu wrote on 1/8/15
2:34 AM:
olivier...@itn-group.eu
Jan 8, 2015, 11:27:32 AM1/8/15
to
Le jeudi 8 janvier 2015 16:51:48 UTC+1, Hugh Hood a écrit :
> Does the OS X port you mentioned receiving yesterday have both Intel and PPC
> versions? I know you mentioned that a PPC port would be more involved.
Not yet. I think it was only for Intel platform. The idea is to have one source files set that could be recompiled on any known platforms / systems (Windows / Linux / MacOS).
> Does the OS X port you mentioned receiving yesterday have both Intel and PPC
> versions? I know you mentioned that a PPC port would be more involved.
I guess the first step was to have only one version running well. No surprise, this is the Windows 32 bits because it the the more common system and the one I use everyday (but everything was done to use common C ANSI functions and not MicroSoft dedicated ones). The move to Unix (including modern Linux & MacOS) is the next step. This helps to be Windows independent. This requires extensive tests to make sure everything work the same way than the Windows release.
So the last move would be to be Intel independent. Just in case you want to compile on AIX :-)
Because the idea is to provide MODERN tools to create Apple II software, we target first MODERN configurations.
I'd like to do the Max OSX port myself but I can't find an easy way to have a Mac OSX running user a Virtual Environment on my laptop. I have a native Windows 7 64 bits system + Virtual Linux environment on the same machine. I have tried to get a Mac OSX image but I did not succeed :-(
Olivier
STYNX
Jan 8, 2015, 12:28:32 PM1/8/15
to
On Thursday, January 8, 2015 1:35:24 AM UTC+1, Bill Buckels wrote:
... REALLY lazy people let others do the work ...
> "Bill Buckels" <bb..@mts.net> wrote:
> >Perhaps I am lazy.
> There's no perhaps about this actually:)
Lazy people tend to optimize their work that there is less of it
> >Perhaps I am lazy.
> There's no perhaps about this actually:)
... REALLY lazy people let others do the work ...
Michael 'AppleWin Debugger Dev'
Jan 8, 2015, 12:59:18 PM1/8/15
to
On Thursday, January 8, 2015 9:28:32 AM UTC-8, STYNX wrote:
> Lazy people tend to optimize their work that there is less of it
> ... REALLY lazy people let others do the work ...
That's what I was trying to tell Bill in another thread, but you said it better. ;-)
> Lazy people tend to optimize their work that there is less of it
> ... REALLY lazy people let others do the work ...
mmphosis
Jan 8, 2015, 5:42:35 PM1/8/15
to
I got it working on Mac OS X, although my single test case is to assemble
forestfire-merlin32.s
mv $(SOURCE)/Dc_Library.c $(SOURCE)/Dc_Library.c.bak
sed -e 's/%I64d/%lld/g' $(SOURCE)/Dc_Library.c.bak > $(SOURCE)/Dc_Library.c
forestfire-merlin32.s
mv $(SOURCE)/Dc_Library.c $(SOURCE)/Dc_Library.c.bak
sed -e 's/%I64d/%lld/g' $(SOURCE)/Dc_Library.c.bak > $(SOURCE)/Dc_Library.c
awanderin
Jan 8, 2015, 10:27:09 PM1/8/15
to
sed -i -e 's/%I64d/%lld/g' $(SOURCE)/Dc_Library.c
--
--
Jerry awanderin at gmail dot com
Steve Nickolas
Jan 8, 2015, 10:33:09 PM1/8/15
to
extension.
-uso.
mmphosis
Jan 9, 2015, 1:39:18 AM1/9/15
to
Thanks, I saw a bunch variations for using sed. I think this will work on
Mac OS X...
sed -i '' -e 's/%I64d/%lld/g' source/dc_library.c
Mac OS X...
sed -i '' -e 's/%I64d/%lld/g' source/dc_library.c
mmphosis
Jan 9, 2015, 5:58:36 AM1/9/15
to
...but, doesn't work with gnu/Linux sed. :(
http://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux
http://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux
mdj
Jan 11, 2015, 3:56:57 AM1/11/15
to
On Friday, 9 January 2015 20:58:36 UTC+10, mmphosis wrote:
> ...but, doesn't work with gnu/Linux sed. :(
>
> http://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux
A better(?) way since sed is different across platforms is to use something that isn't, in this case, vi in 'ex' mode:
> ...but, doesn't work with gnu/Linux sed. :(
>
> http://stackoverflow.com/questions/5694228/sed-in-place-flag-that-works-both-on-mac-bsd-and-linux
ex source/dl_library.c <<EOF
s/%I64d/%lld/g
w
EOF
(I didn't verify that the substitute command behaved the same under vi, but I expect it does)
This will achieve the same result, but be POSIX compliant.
Matt
Raymond Wiker
Jan 11, 2015, 4:40:03 AM1/11/15
to
perl -pi.bak -e 's/%I64d/%lld/g' Dc_Library.c
-- since no modern platform that has sed/ed/ex is likely not to have perl.
Olivier Zardini
Jan 11, 2015, 5:46:22 AM1/11/15
to
Hi,
I'm currently working on a 'official' Linux & Mac0sX release.
The software compiles well bu I had to add extra code to handle the files properly. The issue is linked to the Linux & Mac file system which are case sensitive (Windows and Prodos are not). So, when we use a PUT directive in the source code :
PUT Cogito.Aux
Merlin 32 tries to open a file named Cogito.Aux.s
But, the file could be Cogito.Aux.S (uppercase S) or Cogito.Aux.s (lower case S) or even COGITO.AUX.S
On original Merlin 16+, we don't care because Prodos is not case sensitive, so the case doesn't have to match between the file on disk and the declaration in the source file.
On Unix, file names are case sensitive, so we have a difference. The file on disk names have to match with source file content. It is not always the case.
So I'm adding a new layer to authorize the opening of file, even if the case is not matching (read all folder content, and check files names tp get the right one).
Olivier
Bill Buckels
Jan 11, 2015, 5:54:02 PM1/11/15
to
"Raymond Wiker" <rwi...@gmail.com> wrote:
>Or just use perl
That would have been my first choice, but I am happy that seomone else made
the suggestion.
I am sure Larry Wall would agree with you too:)
Bill
>Or just use perl
That would have been my first choice, but I am happy that seomone else made
the suggestion.
I am sure Larry Wall would agree with you too:)
Bill
olivier...@itn-group.eu
Jan 13, 2015, 3:11:53 AM1/13/15
to
Hi,
Merlin 32 is now running on Linux 64 bits and Mac OS X.
You can get the program file from the Zip file located here :
http://www.brutaldeluxe.fr/products/crossdevtools/merlin/
The source files have been modified to be compatible with the 3 OS.
You can use the Exe file or simply re-compile the source code.
Regards,
Olivier ZARDINI
mmphosis
Jan 13, 2015, 3:38:16 PM1/13/15
to
Thank you.
I re-compiled the source for Linux (Intel 32 bits?) running on a 64 bit AMD,
Linux (Arm), and Mac OS X (PowerPC).
$ cat 64bitIncrement.s
CLC
LDA $00
ADC #$01
STA $00
LDA $01
ADC #$00
STA $01
LDA $02
ADC #$00
STA $02
LDA $03
ADC #$00
STA $03
LDA $04
ADC #$00
STA $04
LDA $05
ADC #$00
STA $05
LDA $06
ADC #$00
STA $06
LDA $07
ADC #$00
STA $07
LDA $08
ADC #$00
STA $08
RTS
$ Merlin32 Merlin32_v1.0/Library 64bitIncrement.s
Merlin32 v 1.0, (c) Brutal Deluxe 2011-2015
+ Assemble project files...
o Loading Sources files...
- 64bitIncrement.s
o Loading Macro files...
o Check for duplicated Macros...
o Decoding lines types...
o Process local/variable Labels...
o Process Asterisk lines...
o Build External table...
o Build Equivalence table...
o Build Variable table...
o Process Equivalence values...
o Replace Lup with code...
o Replace Macros with Code...
o Process MX directives...
o Process Conditional directives...
o Build Label table...
o Check for duplicated Labels...
o Check for unknown Source lines...
o Check for Dum lines...
o Compute Operand Code size...
o Compute Operand Data size...
o Compute Line address...
o Build Code Line...
o Compact Code for Direct Page Lines...
o Check for Err lines...
o Build Data Line...
o Build Object Code...
+ Link project files...
o Build Binary output file...
=> Creating Object file '64bitIncrement'
$ hexdump -v -e '":" 16/1 "%X " "\n"' 64bitIncrement
:18 A5 0 69 1 85 0 A5 1 69 0 85 1 A5 2 69
:0 85 2 A5 3 69 0 85 3 A5 4 69 0 85 4 A5
:5 69 0 85 5 A5 6 69 0 85 6 A5 7 69 0 85
:7 A5 8 69 0 85 8 60
I re-compiled the source for Linux (Intel 32 bits?) running on a 64 bit AMD,
Linux (Arm), and Mac OS X (PowerPC).
$ cat 64bitIncrement.s
CLC
LDA $00
ADC #$01
STA $00
LDA $01
ADC #$00
STA $01
LDA $02
ADC #$00
STA $02
LDA $03
ADC #$00
STA $03
LDA $04
ADC #$00
STA $04
LDA $05
ADC #$00
STA $05
LDA $06
ADC #$00
STA $06
LDA $07
ADC #$00
STA $07
LDA $08
ADC #$00
STA $08
RTS
$ Merlin32 Merlin32_v1.0/Library 64bitIncrement.s
Merlin32 v 1.0, (c) Brutal Deluxe 2011-2015
+ Assemble project files...
o Loading Sources files...
- 64bitIncrement.s
o Loading Macro files...
o Check for duplicated Macros...
o Decoding lines types...
o Process local/variable Labels...
o Process Asterisk lines...
o Build External table...
o Build Equivalence table...
o Build Variable table...
o Process Equivalence values...
o Replace Lup with code...
o Replace Macros with Code...
o Process MX directives...
o Process Conditional directives...
o Build Label table...
o Check for duplicated Labels...
o Check for unknown Source lines...
o Check for Dum lines...
o Compute Operand Code size...
o Compute Operand Data size...
o Compute Line address...
o Build Code Line...
o Compact Code for Direct Page Lines...
o Check for Err lines...
o Build Data Line...
o Build Object Code...
+ Link project files...
o Build Binary output file...
=> Creating Object file '64bitIncrement'
$ hexdump -v -e '":" 16/1 "%X " "\n"' 64bitIncrement
:18 A5 0 69 1 85 0 A5 1 69 0 85 1 A5 2 69
:0 85 2 A5 3 69 0 85 3 A5 4 69 0 85 4 A5
:5 69 0 85 5 A5 6 69 0 85 6 A5 7 69 0 85
:7 A5 8 69 0 85 8 60
Hugh Hood
Jan 28, 2015, 10:34:43 AM1/28/15
to
Olivier:
I realize that your Merlin 32 source code has yet to be modified for a PPC
Mac, but ...
I went ahead and built it for a Tiger (OS X 10.4.11) PPC Mac. No errors.
In _very_ limited testing, the only issue I experienced was that the Merlin
pseudo opcodes 'DA' and 'DW' did not produce code other than "$00 $00".
Would that be due to the Big Endian / Little Endian issues previously
mentioned?
Thanks. Man your program is FAST!
Hugh Hood
in article cfd2f23f-522b-4863...@googlegroups.com,
1/13/15 2:11 AM:
I realize that your Merlin 32 source code has yet to be modified for a PPC
Mac, but ...
I went ahead and built it for a Tiger (OS X 10.4.11) PPC Mac. No errors.
In _very_ limited testing, the only issue I experienced was that the Merlin
pseudo opcodes 'DA' and 'DW' did not produce code other than "$00 $00".
Would that be due to the Big Endian / Little Endian issues previously
mentioned?
Thanks. Man your program is FAST!
Hugh Hood
in article cfd2f23f-522b-4863...@googlegroups.com,
1/13/15 2:11 AM:
Riccardo
Jan 28, 2015, 12:18:27 PM1/28/15
to
Hugh Hood:
Hi, you can check the Output file in the Line Type column, you should read as DATA type in a row corresponding to DA or DW code, if not chance or tune the TAB.
Ric.
Hi, you can check the Output file in the Line Type column, you should read as DATA type in a row corresponding to DA or DW code, if not chance or tune the TAB.
Ric.
Hugh Hood
Jan 28, 2015, 10:12:40 PM1/28/15
to
Riccardo:
Thanks for the suggestion.
I checked the Merlin 32 text output file and all the 'DW' pseudo opcodes had
'Data' in their corresponding Line Type column.
Unfortunately, in each case, the data generated was always $00 $00.
Otherwise, the object code was exactly as it should have been.
For example, this line should have generated 10 10. Instead of:
00/7E70 : 00 00 | DW {$1010} ;
On the other hand, DFB and HEX both generate the correct code.
Maybe this is not an Endian issue? Has anyone run into this particular issue
with the Intel Mac build of Merlin 32?
Regardless, Merlin 32 is impressive. Very impressive. Score a big win for
Brutal Deluxe.
Hugh Hood
in article 9b4cfd28-5de4-4363...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 1/28/15 11:18 AM:
Thanks for the suggestion.
I checked the Merlin 32 text output file and all the 'DW' pseudo opcodes had
'Data' in their corresponding Line Type column.
Unfortunately, in each case, the data generated was always $00 $00.
Otherwise, the object code was exactly as it should have been.
For example, this line should have generated 10 10. Instead of:
00/7E70 : 00 00 | DW {$1010} ;
On the other hand, DFB and HEX both generate the correct code.
Maybe this is not an Endian issue? Has anyone run into this particular issue
with the Intel Mac build of Merlin 32?
Regardless, Merlin 32 is impressive. Very impressive. Score a big win for
Brutal Deluxe.
Hugh Hood
in article 9b4cfd28-5de4-4363...@googlegroups.com, Riccardo
at rigre...@gmail.com wrote on 1/28/15 11:18 AM:
olivier...@itn-group.eu
Jan 29, 2015, 3:09:13 AM1/29/15
to
Le mercredi 28 janvier 2015 16:34:43 UTC+1, Hugh Hood a écrit :
> I realize that your Merlin 32 source code has yet to be modified for a PPC
> Mac, but ...
> I went ahead and built it for a Tiger (OS X 10.4.11) PPC Mac. No errors.
The source code have been compiled and tested on the 3 'modern' environments : Win 32/64, Linux 64 bits (should work fine also on 32 bits but I had only a 64 bit Linux Virtual Machine to compile + test) and Mac OS X (compiled and tested on my old Mac OS X 10.5 laptop). All of these environments are using Intel processor.
> I realize that your Merlin 32 source code has yet to be modified for a PPC
> Mac, but ...
> I went ahead and built it for a Tiger (OS X 10.4.11) PPC Mac. No errors.
There is NO (not yet) Power PC support for the moment. This will require to modify many parts of the source code (especially the OMF part where I use memcpy to store 16 bits or 32 numbers from memory to disk).
I need first to do the modifications but I also need to test this on a Power PC environment. I have an AIX not that far so I guess I would use it. I don't have a Power PC Macintosh around.
My advice would be, every time you face a wrong results :
- Activate the Verbose Mode (-V) to check the Output file => Errors are easy to detect
- try the same source code on an Intel machine just to check if the error is still here.
If many people are requiring the Power PC support, I'll do it.
Regards,
Olivier ZARDINI
Hugh Hood
Jan 31, 2015, 2:18:07 PM1/31/15
to
Olivier,
Thanks for your comments on PPC support for Merlin 32.
As you suspected, it does appear that there is an endian issue on the PPC,
as shown from the Verbose Mode output file for this test code:
00/2178 | **START STUFF ADDED FOR MERLIN 32 PPC TEST
00/2178 : 00 00 | DW $5152 ;52 51 expected
00/217A : 00 00 | DA $5152 ;52 51 expected
00/217C : 00 | DFB $52 ;52 expected
00/217D : 00 | DB $52 ;52 expected
00/217E : 00 00 | DDB $5152 ;51 52 expected
00/2180 : 00 51 52 | ADR $515253 ;53 52 51 expected
00/2183 : 00 51 52 53 | ADRL $515253 ;53 52 51 00 expected
00/2187 | **END STUFF ADDED FOR MERLIN 32 PPC TEST
As you can see, the bytes are swapped (assuming a 4-byte string). For other
opcodes and addresses, however, the bytes are generated in their proper
order.
I'm no Bill Buckels when it comes to 'C' (or fishing), but I'd be happy to
build and test any suggested code mods, either from you, or from 'mmphosis',
who had mentioned earlier that he had re-compiled the Merlin 32 source for
Mac OS X (PowerPC).
Thanks.
Hugh Hood
in article 6fe10e83-0250-49eb...@googlegroups.com,
1/29/15 2:09 AM:
Thanks for your comments on PPC support for Merlin 32.
As you suspected, it does appear that there is an endian issue on the PPC,
as shown from the Verbose Mode output file for this test code:
00/2178 | **START STUFF ADDED FOR MERLIN 32 PPC TEST
00/2178 : 00 00 | DW $5152 ;52 51 expected
00/217A : 00 00 | DA $5152 ;52 51 expected
00/217C : 00 | DFB $52 ;52 expected
00/217D : 00 | DB $52 ;52 expected
00/217E : 00 00 | DDB $5152 ;51 52 expected
00/2180 : 00 51 52 | ADR $515253 ;53 52 51 expected
00/2183 : 00 51 52 53 | ADRL $515253 ;53 52 51 00 expected
00/2187 | **END STUFF ADDED FOR MERLIN 32 PPC TEST
As you can see, the bytes are swapped (assuming a 4-byte string). For other
opcodes and addresses, however, the bytes are generated in their proper
order.
I'm no Bill Buckels when it comes to 'C' (or fishing), but I'd be happy to
build and test any suggested code mods, either from you, or from 'mmphosis',
who had mentioned earlier that he had re-compiled the Merlin 32 source for
Mac OS X (PowerPC).
Thanks.
Hugh Hood
in article 6fe10e83-0250-49eb...@googlegroups.com,
1/29/15 2:09 AM:
Hugh Hood
Feb 1, 2015, 3:06:42 AM2/1/15
to
Olivier,
I managed to cobble together enough PPC support in your Merlin 32 to satisfy
my 8-bit assembly requirements, so please don't make PPC support a priority,
unless you have others requesting it.
For anyone else who is interested in building Merlin 32 on a PPC (and whose
needs are as simple as mine), look in Olivier's a65816_Data.c file. Starting
at line #447, he has a series of (12) statements that handle the Merlin data
pseudo ops DW, DA, DFB, DB, DDB, ADR & ADRL.
For example, here is line #447:
current_line->data[2*nb_valid_element+0] = data[0];
As one method to fix the PPC 'endian' issue, change the instances of data[x]
as follows:
data[0] to data [3]
data[1] to data [2]
data[2] to data [1]
data[3] to data [0]
This swaps the order of the (4) 8-bit bytes in the 32-bit integer containing
the data, and fixes the problem I was seeing on PPC, which is big-endian.
So far, I'm getting exact byte-for-byte copies of the code that Merlin 16
generates on a IIGS. Nice!
Regards,
Hugh Hood
in article D0F2868D.10967%hugh...@earthlink.net, Hugh Hood at
hugh...@earthlink.net wrote on 1/31/15 1:18 PM:
I managed to cobble together enough PPC support in your Merlin 32 to satisfy
my 8-bit assembly requirements, so please don't make PPC support a priority,
unless you have others requesting it.
For anyone else who is interested in building Merlin 32 on a PPC (and whose
needs are as simple as mine), look in Olivier's a65816_Data.c file. Starting
at line #447, he has a series of (12) statements that handle the Merlin data
pseudo ops DW, DA, DFB, DB, DDB, ADR & ADRL.
For example, here is line #447:
current_line->data[2*nb_valid_element+0] = data[0];
As one method to fix the PPC 'endian' issue, change the instances of data[x]
as follows:
data[0] to data [3]
data[1] to data [2]
data[2] to data [1]
data[3] to data [0]
This swaps the order of the (4) 8-bit bytes in the 32-bit integer containing
the data, and fixes the problem I was seeing on PPC, which is big-endian.
So far, I'm getting exact byte-for-byte copies of the code that Merlin 16
generates on a IIGS. Nice!
Regards,
Hugh Hood
in article D0F2868D.10967%hugh...@earthlink.net, Hugh Hood at
hugh...@earthlink.net wrote on 1/31/15 1:18 PM:
Steven Hirsch
Feb 1, 2015, 9:21:37 AM2/1/15
to
On 02/01/2015 03:06 AM, Hugh Hood wrote:
> I managed to cobble together enough PPC support in your Merlin 32 to satisfy
> my 8-bit assembly requirements, so please don't make PPC support a priority,
> unless you have others requesting it.
>
> For anyone else who is interested in building Merlin 32 on a PPC (and whose
> needs are as simple as mine), look in Olivier's a65816_Data.c file. Starting
> at line #447, he has a series of (12) statements that handle the Merlin data
> pseudo ops DW, DA, DFB, DB, DDB, ADR & ADRL.
>
> For example, here is line #447:
>
> current_line->data[2*nb_valid_element+0] = data[0];
>
> As one method to fix the PPC 'endian' issue, change the instances of data[x]
> as follows:
>
> data[0] to data [3]
> data[1] to data [2]
> data[2] to data [1]
> data[3] to data [0]
>
>
> This swaps the order of the (4) 8-bit bytes in the 32-bit integer containing
> the data, and fixes the problem I was seeing on PPC, which is big-endian.
Disclaimer: I haven't looked at the code, but based on my own development
> I managed to cobble together enough PPC support in your Merlin 32 to satisfy
> my 8-bit assembly requirements, so please don't make PPC support a priority,
> unless you have others requesting it.
>
> For anyone else who is interested in building Merlin 32 on a PPC (and whose
> needs are as simple as mine), look in Olivier's a65816_Data.c file. Starting
> at line #447, he has a series of (12) statements that handle the Merlin data
> pseudo ops DW, DA, DFB, DB, DDB, ADR & ADRL.
>
> For example, here is line #447:
>
> current_line->data[2*nb_valid_element+0] = data[0];
>
> As one method to fix the PPC 'endian' issue, change the instances of data[x]
> as follows:
>
> data[0] to data [3]
> data[1] to data [2]
> data[2] to data [1]
> data[3] to data [0]
>
>
> This swaps the order of the (4) 8-bit bytes in the 32-bit integer containing
> the data, and fixes the problem I was seeing on PPC, which is big-endian.
experience with cross-platform interoperability it sounds like some carefully
crafted macros might be helpful.
Raymond Wiker
Feb 1, 2015, 9:54:39 AM2/1/15
to
into "network byte order". Unfortunately, this is the same as
big-endian, which is the opposite of what is required for the
6502. Still, you might implement something similar, like htoll (host to
long little-endian) and htosl (host to short little-endian).
Steven Hirsch
Feb 1, 2015, 1:09:07 PM2/1/15
to
On 02/01/2015 09:54 AM, Raymond Wiker wrote:
are doing.
> Steven Hirsch <snhi...@gmail.com> writes:
>
>> Disclaimer: I haven't looked at the code, but based on my own
>> development experience with cross-platform interoperability it sounds
>> like some carefully crafted macros might be helpful.
>
> htonl and htons might be useful here: they turn native longs and short
> into "network byte order". Unfortunately, this is the same as
> big-endian, which is the opposite of what is required for the
> 6502. Still, you might implement something similar, like htoll (host to
> long little-endian) and htosl (host to short little-endian).
Exactly. htonl and htons are macros and it should be simple to flip what they
>
>> Disclaimer: I haven't looked at the code, but based on my own
>> development experience with cross-platform interoperability it sounds
>> like some carefully crafted macros might be helpful.
>
> htonl and htons might be useful here: they turn native longs and short
> into "network byte order". Unfortunately, this is the same as
> big-endian, which is the opposite of what is required for the
> 6502. Still, you might implement something similar, like htoll (host to
> long little-endian) and htosl (host to short little-endian).
are doing.
mmphosis
Feb 1, 2015, 2:30:01 PM2/1/15
to
http://hoop-la.ca/software/swapend/
I created these "swapend" functions for a few endian issues in bmp2dhr, but
they might be useful for Merlin32 and other porting projects.
bmp2dhr uses Microsoft BMP file format which has binary fields stored in
little endian format. For the big endian systems, I swap bytes after
reading and before writing. Unfortunately, I am sure there may be other
issues. To get around this, I run bmp2dhr on little endian systems, and it
would only be convenient to be able to run on the big endian systems like
Mac OS X (PowerPC.)
if (is_big_endian()) {
bmi.biSize = swap_bytes32(bmi.biSize);
bmi.biWidth = swap_bytes32(bmi.biWidth);
bmi.biHeight = swap_bytes32(bmi.biHeight);
bmi.biPlanes = swap_bytes16(bmi.biPlanes);
bmi.biBitCount = swap_bytes16(bmi.biBitCount);
bmi.biCompression = swap_bytes32(bmi.biCompression);
bmi.biSizeImage = swap_bytes32(bmi.biSizeImage);
bmi.biXPelsPerMeter = swap_bytes32(bmi.biXPelsPerMeter);
bmi.biYPelsPerMeter = swap_bytes32(bmi.biYPelsPerMeter);
bmi.biClrUsed = swap_bytes32(bmi.biClrUsed);
bmi.biClrImportant = swap_bytes32(bmi.biClrImportant);
}
I am using Merlin32 on Mac OS X (PowerPC) but I try to avoid using features
that may not work in other assemblers. So far, so good for plain vanilla
8-bit assembly code.
I created these "swapend" functions for a few endian issues in bmp2dhr, but
they might be useful for Merlin32 and other porting projects.
bmp2dhr uses Microsoft BMP file format which has binary fields stored in
little endian format. For the big endian systems, I swap bytes after
reading and before writing. Unfortunately, I am sure there may be other
issues. To get around this, I run bmp2dhr on little endian systems, and it
would only be convenient to be able to run on the big endian systems like
Mac OS X (PowerPC.)
if (is_big_endian()) {
bmi.biSize = swap_bytes32(bmi.biSize);
bmi.biWidth = swap_bytes32(bmi.biWidth);
bmi.biHeight = swap_bytes32(bmi.biHeight);
bmi.biPlanes = swap_bytes16(bmi.biPlanes);
bmi.biBitCount = swap_bytes16(bmi.biBitCount);
bmi.biCompression = swap_bytes32(bmi.biCompression);
bmi.biSizeImage = swap_bytes32(bmi.biSizeImage);
bmi.biXPelsPerMeter = swap_bytes32(bmi.biXPelsPerMeter);
bmi.biYPelsPerMeter = swap_bytes32(bmi.biYPelsPerMeter);
bmi.biClrUsed = swap_bytes32(bmi.biClrUsed);
bmi.biClrImportant = swap_bytes32(bmi.biClrImportant);
}
I am using Merlin32 on Mac OS X (PowerPC) but I try to avoid using features
that may not work in other assemblers. So far, so good for plain vanilla
8-bit assembly code.
Hugh Hood
Feb 1, 2015, 7:43:07 PM2/1/15
to
Mark,
Thanks for sharing your byte swapping functions. If I run into something
else in Merlin 32 that I can't get around by doing a shade tree byte swap
directly with Olivier's C statements, I'll get them a try.
The boys on stackoverflow show a few similar byte swap functions, and also
this interesting one that didn't use a function at all:
i = ((i & 0xFF) << 24) | ((i & 0xFF00) << 8) | ((i & 0xFF0000) >> 8) | ((i &
0xFF000000) >> 24);
As it turned out, I never needed to try it to see if it actually worked, but
it looked interesting.
FWIW, I tried some Merlin macros today with the PPC-modified Merlin 32 and
all the bytes come through just as they should. But again, I'm sticking to
8-bit stuff right now.
Thanks.
Hugh Hood
in article mmphosis-...@macgui.com, mmphosis at mmph...@macgui.com
wrote on 2/1/15 1:29 PM:
Thanks for sharing your byte swapping functions. If I run into something
else in Merlin 32 that I can't get around by doing a shade tree byte swap
directly with Olivier's C statements, I'll get them a try.
The boys on stackoverflow show a few similar byte swap functions, and also
this interesting one that didn't use a function at all:
i = ((i & 0xFF) << 24) | ((i & 0xFF00) << 8) | ((i & 0xFF0000) >> 8) | ((i &
0xFF000000) >> 24);
As it turned out, I never needed to try it to see if it actually worked, but
it looked interesting.
FWIW, I tried some Merlin macros today with the PPC-modified Merlin 32 and
all the bytes come through just as they should. But again, I'm sticking to
8-bit stuff right now.
Thanks.
Hugh Hood
in article mmphosis-...@macgui.com, mmphosis at mmph...@macgui.com
wrote on 2/1/15 1:29 PM:
Steven Hirsch
Feb 1, 2015, 8:51:15 PM2/1/15
to
On 02/01/2015 07:43 PM, Hugh Hood wrote:
> Mark,
>
> Thanks for sharing your byte swapping functions. If I run into something
> else in Merlin 32 that I can't get around by doing a shade tree byte swap
> directly with Olivier's C statements, I'll get them a try.
>
> The boys on stackoverflow show a few similar byte swap functions, and also
> this interesting one that didn't use a function at all:
> i = ((i & 0xFF) << 24) | ((i & 0xFF00) << 8) | ((i & 0xFF0000) >> 8) | ((i &
> 0xFF000000) >> 24);
Exactly. See /usr/include/netinet/in.h on your nearest neighborhood Linux box.
> Mark,
>
> Thanks for sharing your byte swapping functions. If I run into something
> else in Merlin 32 that I can't get around by doing a shade tree byte swap
> directly with Olivier's C statements, I'll get them a try.
>
> The boys on stackoverflow show a few similar byte swap functions, and also
> this interesting one that didn't use a function at all:
> i = ((i & 0xFF) << 24) | ((i & 0xFF00) << 8) | ((i & 0xFF0000) >> 8) | ((i &
> 0xFF000000) >> 24);
Hugh Hood
Feb 7, 2015, 1:54:04 PM2/7/15
to
RE: Merlin 32 and object file names containing a period / dot.
This probably won't affect most of you, but should any of your Merlin Source
files contain the 'SAV' or 'DSK' directive and the object file name you
desire contains a period / dot, Merlin 32 will truncate the name starting at
(and including) the period / dot.
For example:
SAV TO.ADD52 ; AW TimeOut App file name
generates an object file name of 'TO'.
If this is a problem for you and your object files, load Olivier's
'a65816_Code.c' source file and comment out lines #116-120 as follows:
// if(current_omfsegment->object_name[i] == '.')
// {
// current_omfsegment->object_name[i] = '\0';
// break;
// }
I suspect this was done due to Windows' file naming convention regarding
extensions, so make sure it won't cause you any other problems before making
the change. It hasn't affected my use on a Tiger (OS X 10.4.11) Power Mac,
though.
Merlin32 rocks. I'm just sorry the late Glen Bredon is not around to see
this.
Hugh Hood
This probably won't affect most of you, but should any of your Merlin Source
files contain the 'SAV' or 'DSK' directive and the object file name you
desire contains a period / dot, Merlin 32 will truncate the name starting at
(and including) the period / dot.
For example:
SAV TO.ADD52 ; AW TimeOut App file name
generates an object file name of 'TO'.
If this is a problem for you and your object files, load Olivier's
'a65816_Code.c' source file and comment out lines #116-120 as follows:
// if(current_omfsegment->object_name[i] == '.')
// {
// current_omfsegment->object_name[i] = '\0';
// break;
// }
I suspect this was done due to Windows' file naming convention regarding
extensions, so make sure it won't cause you any other problems before making
the change. It hasn't affected my use on a Tiger (OS X 10.4.11) Power Mac,
though.
Merlin32 rocks. I'm just sorry the late Glen Bredon is not around to see
this.
Hugh Hood
Olivier Zardini
Feb 7, 2015, 3:32:59 PM2/7/15
to
Le samedi 7 février 2015 19:54:04 UTC+1, Hugh Hood a écrit :
> This probably won't affect most of you, but should any of your Merlin Source
> files contain the 'SAV' or 'DSK' directive and the object file name you
> desire contains a period / dot, Merlin 32 will truncate the name starting at
> (and including) the period / dot.
> This probably won't affect most of you, but should any of your Merlin Source
> files contain the 'SAV' or 'DSK' directive and the object file name you
> desire contains a period / dot, Merlin 32 will truncate the name starting at
> (and including) the period / dot.
> I suspect this was done due to Windows' file naming convention regarding
> extensions, so make sure it won't cause you any other problems before making
> the change
This is to get rid of the .l we usually have in the dsk line :
> extensions, so make sure it won't cause you any other problems before making
> the change
lst off
rel
dsk The.Tinies.l
I need to modify this part of the source code to avoid to truncate valid file name !
I put this on the To Do List !
Regards,
Olivier
Hugh Hood
Feb 26, 2015, 11:38:09 AM2/26/15
to
Fellow Merlin 32 Users,
I am trying to troubleshoot an object code generation anomaly occurring
during my (un-official) use of Merlin 32 on a PPC Mac.
May I ask your checking something for me?
The following Merlin source:
DS 8,$A8
should generate:
A8 A8 A8 A8 A8 A8 A8 A8
I am, however, getting:
00 00 00 00 00 00 00 00
I suspect this is another endian issue, but before I go mucking around in
Olivier's C code, I need to make sure. So, could one of you Intel boys try
that for me?
Thanks.
Hugh Hood
I am trying to troubleshoot an object code generation anomaly occurring
during my (un-official) use of Merlin 32 on a PPC Mac.
May I ask your checking something for me?
The following Merlin source:
DS 8,$A8
should generate:
A8 A8 A8 A8 A8 A8 A8 A8
I am, however, getting:
00 00 00 00 00 00 00 00
I suspect this is another endian issue, but before I go mucking around in
Olivier's C code, I need to make sure. So, could one of you Intel boys try
that for me?
Thanks.
Hugh Hood
Olivier Zardini
Mar 1, 2015, 3:19:32 PM3/1/15
to
Le jeudi 26 février 2015 17:38:09 UTC+1, Hugh Hood a écrit :
> Fellow Merlin 32 Users,
> I am trying to troubleshoot an object code generation anomaly occurring
> during my (un-official) use of Merlin 32 on a PPC Mac.
> Fellow Merlin 32 Users,
> I am trying to troubleshoot an object code generation anomaly occurring
> during my (un-official) use of Merlin 32 on a PPC Mac.
> I suspect this is another endian issue, but before I go mucking around in
> Olivier's C code, I need to make sure. So, could one of you Intel boys try
> that for me?
Hi,
> Olivier's C code, I need to make sure. So, could one of you Intel boys try
> that for me?
I have added support for Big Endian processors to the source code.
You can download it from there :
http://www.brutaldeluxe.fr/products/crossdevtools/merlin/a65816_ppc.zip
I have not done any advanced tests but that should be ok. You can also build OMF files.
Let me know if you encounter any problem.
Regards,
Oliver
Hugh Hood
Mar 2, 2015, 1:49:15 AM3/2/15
to
Olivier,
Thank you for a very nice job, and for spending the time to add official
Merlin 32 support for PPC Macs.
All is working well with your PPC / Big Endian version of Merlin 32, as
every thing that I have assembled with it (8 bit programs) compares
byte-for-byte with with the files generated by Merlin 16 on the Apple IIGS.
Regards,
Hugh Hood
in article 47b9c074-5a61-46c6...@googlegroups.com, Olivier
Zardini at olivier...@cooperteam.fr wrote on 3/1/15 2:19 PM:
Thank you for a very nice job, and for spending the time to add official
Merlin 32 support for PPC Macs.
All is working well with your PPC / Big Endian version of Merlin 32, as
every thing that I have assembled with it (8 bit programs) compares
byte-for-byte with with the files generated by Merlin 16 on the Apple IIGS.
Regards,
Hugh Hood
in article 47b9c074-5a61-46c6...@googlegroups.com, Olivier
Zardini at olivier...@cooperteam.fr wrote on 3/1/15 2:19 PM:
olivier...@itn-group.eu
Mar 2, 2015, 3:43:20 AM3/2/15
to
Le lundi 2 mars 2015 07:49:15 UTC+1, Hugh Hood a écrit :
> Olivier,
Regards,
Olivier
> Olivier,
> All is working well with your PPC / Big Endian version of Merlin 32, as
> every thing that I have assembled with it (8 bit programs) compares
> byte-for-byte with with the files generated by Merlin 16 on the Apple IIGS.
Thanks for this first validation. I need to perform extra tests to make sure there is no regression before pushing it as the new official source code.
> every thing that I have assembled with it (8 bit programs) compares
> byte-for-byte with with the files generated by Merlin 16 on the Apple IIGS.
Regards,
Olivier
0 new messages