Alternatives for rolling software in C for 65816?

[Steve Nickolas]

While pirating from Apple and/or Addison-Wesley has never been something
that concerned me, pirating Orca is something that feels a bit more
morally questionable even to someone like myself.

The 65816 world seems to lack any sort of usable C compiler, including
cross-compilers, which could be used to make ProDOS-16 or GS/OS apps. A
shame; I'd really like to venture into the 16-bit Apple world. (Being on
a fixed income, paying hundreds of dollars for documentation and compilers
isn't exactly feasible for me - especially given the nature of the
platform.)

I speak 65C02 asm, but don't understand anything about the 65816 yet.
However, my cross-assembler of choice is capable of emitting 65816 code.
Something as simple as a program launcher (file open dialog, shell out to
another app, lather rinse repeat) would probably be a simple enough place
for me to start.

-uso.

[Stavros Karatsoridis]

$80 for the whole OPUS collection is not "hundreds of dollars."

[Charlie]

Merlin-16+ v4.nn is a good alternative. It's a macro assembler with the
toolbox macros included and it comes with help files that document most
of the toolbox calls. The help files aren't a substitute for the
Toolbox reference volumes but they are good enough for a lot of
programming.

If you can code in 65c02 assembly then learning 65816 assembly isn't
that big of a step.

Charlie

[Steve Nickolas]

That doesn't, so far as I know, include Apple's documentation, which last
I checked, *was* running in the hundreds of dollars.

-uso.

[fx]

Seriously? Where can I buy that?

[Bill Buckels]

"Steve Nickolas" <usot...@buric.co> wrote:

>The 65816 world seems to lack any sort of usable C compiler, including
>cross-compilers, which could be used to make ProDOS-16 or GS/OS apps.

ORCA C is quite usable and "affordable", however here are my regrets (they
are similar to yours):

I have always used command line C compilers, even while writing 16 bit
Windows and 32 bit Windows applications. Whether developing for Linux and
Unix or MS-DOS and Windows, or for the Apple //e or Commodore 64 or CP/M 80
or CP/M 86 ir has been command line tools.

To a "real" C programmer which I doubt if anyone would dispute my opinion on
that subject, a command line C compiler is a C compiler, and an IDE is not.
I don't like IDE's. They cramp my style.

I also prefer cross-compilers and cross-development because I am at heart an
MS-DOS guy. Even while developing in TrollTech's Qt C++ for Mandrake, I used
the Windows version extensively and Linux only to compile and test the
production release after completion. The Microsoft command line C compiler
is used in Windows and GCC in Linux.

Back to the GS...

My regret is that no MS-DOS cross-compiler for GS/OS and ProDOS 16 was ever
done, and no toolset bundled with such a beast to create resource forks and
data forks in a cross-development environment apparently exists.

Aztec C65 which produces both 6502 and 65C02 is the closest thing I have.

> I'd really like to venture into the 16-bit Apple world.

Me too! With a C cross-compiler that runs from the Windows command line!

> However, my cross-assembler of choice is capable of emitting 65816 code.

Aztec C does an assembler pass first, however it is geared at either ProDOS
8 or DOS 3.3 and Zero page usage and hardware is intrinsically bundled so
translating from 65C02 to 65...16 is not an option either...

I haven't time in my lifetime to build a parser that works. I certainly
don't have time to rewrite ORCA C as a cross-compiler for the Windows
command line. But that is what I want.

My compromise will be ORCA C after I educate myself further about writing 8
bit Apps that run on the GS. My foray into SHR with Charlie was a good
start.

My routines for walking through the ProDOS 8 filing system in Aztec C were a
good start.

I wish Payton had decided to write some SHR text plotting routines in Aztec
C. Perhaps I will do that next.

Good luck on your own quest! I already have ORCA C and it is is without
doubt excellent, but I don't want to work in an emulator to write code in
Windows, but a guy can't have what doesn't exist...

Bill

[Steven Hirsch]

On 09/02/2013 07:54 AM, Bill Buckels wrote:

> I haven't time in my lifetime to build a parser that works. I certainly
> don't have time to rewrite ORCA C as a cross-compiler for the Windows
> command line. But that is what I want.

I wasn't aware that the sources for ORCA C were available. But if they are
and are written in anything resembling ANSI C, a port to Linux, Windows or
MS-DOS should be possible.

I rather suspect that ORCA was written in assembler, though.

Steve

[D Finnigan]

Steven Hirsch wrote:
> On 09/02/2013 07:54 AM, Bill Buckels wrote:
>
>> I haven't time in my lifetime to build a parser that works. I certainly
>> don't have time to rewrite ORCA C as a cross-compiler for the Windows
>> command line. But that is what I want.
>
> I wasn't aware that the sources for ORCA C were available.

As part of Opus II: The source. There is even the unreleased beta version
there.

>
> I rather suspect that ORCA was written in assembler, though.

IIRC, Pascal was used to write the C compiler, since Mr. Westerfield had
completed his 65816 assembler first, then Pascal.

--
]DF$
Apple II Book: http://macgui.com/newa2guide/
Usenet: http://macgui.com/usenet/ <-- get posts by email!
Apple II Web & Blog hosting: http://a2hq.com/

[mdj]

On Monday, 2 September 2013 21:54:17 UTC+10, Bill Buckels wrote:

> Good luck on your own quest! I already have ORCA C and it is is without
>
> doubt excellent, but I don't want to work in an emulator to write code in
>
> Windows, but a guy can't have what doesn't exist...

I wonder if mpw-tools can be cajoled into compiling on a windows box ....

[Steve Nickolas]

On Mon, 2 Sep 2013, Bill Buckels wrote:

> I have always used command line C compilers, even while writing 16 bit
> Windows and 32 bit Windows applications. Whether developing for Linux and
> Unix or MS-DOS and Windows, or for the Apple //e or Commodore 64 or CP/M 80
> or CP/M 86 ir has been command line tools.

Sometimes in the beginning I used an IDE because I had the online help.
But for many years I've done most of my development from the command line,
using my text editor of choice.

> To a "real" C programmer which I doubt if anyone would dispute my opinion on
> that subject, a command line C compiler is a C compiler, and an IDE is not.
> I don't like IDE's. They cramp my style.

Yeah, pretty much.

> I also prefer cross-compilers and cross-development because I am at heart an
> MS-DOS guy. Even while developing in TrollTech's Qt C++ for Mandrake, I used
> the Windows version extensively and Linux only to compile and test the
> production release after completion. The Microsoft command line C compiler
> is used in Windows and GCC in Linux.

I use Watcom mostly on Windows, GCC the rest of the time. And on Linux
and FreeBSD, of course GCC.

> Back to the GS...
>
> My regret is that no MS-DOS cross-compiler for GS/OS and ProDOS 16 was ever
> done, and no toolset bundled with such a beast to create resource forks and
> data forks in a cross-development environment apparently exists.

EXACTLY MY COMPLAINT. But if I knew how, I'd try to make one, using
cc65's "binutils" as a backend.

> Aztec C65 which produces both 6502 and 65C02 is the closest thing I have.

And CC65 is the closest thing I have.

>
>> I'd really like to venture into the 16-bit Apple world.
>
> Me too! With a C cross-compiler that runs from the Windows command line!

^ THIS

> Good luck on your own quest! I already have ORCA C and it is is without
> doubt excellent, but I don't want to work in an emulator to write code in
> Windows, but a guy can't have what doesn't exist...

Yeah. :<

-uso.

[Steve Nickolas]

On Mon, 2 Sep 2013, D Finnigan wrote:

> Steven Hirsch wrote:
>> On 09/02/2013 07:54 AM, Bill Buckels wrote:
>>
>>> I haven't time in my lifetime to build a parser that works. I certainly
>>> don't have time to rewrite ORCA C as a cross-compiler for the Windows
>>> command line. But that is what I want.
>>
>> I wasn't aware that the sources for ORCA C were available.
>
> As part of Opus II: The source. There is even the unreleased beta version
> there.
>
>>
>> I rather suspect that ORCA was written in assembler, though.
>
> IIRC, Pascal was used to write the C compiler, since Mr. Westerfield had
> completed his 65816 assembler first, then Pascal.
>
>

Well, Pascal isn't that different from C.

-uso.

[mdj]

On Tuesday, 3 September 2013 01:14:29 UTC+10, Steve Nickolas wrote:

> Well, Pascal isn't that different from C.

Easy there. Great wars were once fought over comparisons like that

;-)

[retrogear]

On Monday, September 2, 2013 9:56:49 AM UTC-5, mdj wrote:

snip

> I wonder if mpw-tools can be cajoled into compiling on a windows box ....

Sure, via Sheepshaver but I know that's not what you meant... :)

Larry

[Charlie]

There is also Cortland Programming Workshop 4.1 which was the original
IIgs programming environment. I never used it so I don't know much
about it but it is free and it was based on the old 8 bit Orca system.
It looks like it has an editor, assembler, C compiler and linker, etc.

http://www.byteworks.us/Byte_Works/Morgue.html

Charlie

[Bill Buckels]

"mdj" <mdj...@gmail.com> wrote:
> On Tuesday, 3 September 2013 01:14:29 UTC+10, Steve Nickolas wrote:
>> Well, Pascal isn't that different from C.

> Easy there. Great wars were once fought over comparisons like that.
I am not Wirthy:)

[mmphosis]

http://www.6502.org/tools/lang/

Toshi Morita has successfully ported LCC to compile for the 65C816
microprocessor, and this archive contains complete source code for the
compiler along with simple instructions and examples.

http://www.6502.org/tools/lang/lcc-1.9-retargetable.tar.gz

-----

I first started building this using Mac OS X, but very quickly got this
error:
ld: warning: option -s is obsolete and being ignored

I moved onto Linux where the compiler tools haven't been gutted as badly as
Mac OS X especially for cross-compiling work.
With some futzing around, I was able to build the tools: lcc, rcc, dag2gs2

In the past, I've sucessfully used LCC using the MS-DOS command line (from
Windows, wine / Mac OS X, VMs / emulators), at least I think it's the same
lcc C Compiler, perhaps just older but retargetable!

I was able to compile a hello world C program...

int main(int argc, char * argv[])
{
printf("hello world\n");

return 0;
}

Using the following commands, dag2gs2 expects the opt0.dag and opt1.dag
files to be in the same directory...
rcc hello.c hello.dag
dag2gs2 hello.dag hello.s

It produces hello.s which I have not yet been able to assemble using a
number of 65816 assemblers...

; STARTFUNC(%0),(_main)
_main start
dag_temp_start equ 1
gen_temp_start equ dag_temp_start+0
local equ gen_temp_start+-1
_argc equ gen_temp_start+5
_argv equ gen_temp_start+9
; LINK(),()
lda r15
add.l #-local
sta r15
; ARGP(ADDRGP(%0)),(L2)
pea +(L2)|-16
pea L2
; CALLI(ADDRGP(%0)),(_printf)
jsl _printf
tsc
clc
adc #4
tcs
; RETI(CNSTI(%0)),(0)
tsc
clc
adc #local
tcs
pld
lda #<0
ldx #^0
rtl
; LABELV(%0),(L1)
L1 anop
; ENDFUNC(%0),(_main)
_main end
; FLUSH(),()
end
hello0 data
L2 entry
dc i1'104,101,108,108,111,32,119,111,114,108,100,13,0'
end
; FLUSH(),()

[Bill Buckels]

"Steve Nickolas" <usot...@buric.co> wrote:
>On Mon, 2 Sep 2013, D Finnigan wrote:
>> As part of Opus II: The source.

>> IIRC, Pascal was used to write the C compiler...

>Well, Pascal isn't that different from C.

Close enough.

I once translated my share of Turbo Pascal then Delphi to C/C++ and as long
as it's procedural Pascal I think I could handle it. But not in my
lifetime.Object Pascal would take me two lifetimes.

But this is a community project worth considering. If a command line
compiler were written that followed Orca C exactly and did not involve an
IDE it is doable as a portable community project I think.

I guess I made the wrong choice when I bought the compiler only... I should
have bought Opus II. Its not too late to correct that mistake.

If this happens, it will ironically be as a result of what has been a rather
negatively charged thread, so I suggest we start another thread... it could
be a long one from the sounds of things.

What's this compiler going to be called?

CC65816 seems like alot of typing... ccg sounds like the Canadian Coast
Guard:)

I must have time to think now:) And listen to the thoughts of others... the
guy leading the charge on this doesn't have Opus II... so now what?

Bill

[Michael J. Mahon]

At a SIGPLAN conference, Wirth once introduced himself, and said he "could
be called by name (Virt) or by value (Worth)", and got a good laugh. ;-)

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[Steve Nickolas]

On Mon, 2 Sep 2013, Bill Buckels wrote:

> If this happens, it will ironically be as a result of what has been a rather
> negatively charged thread, so I suggest we start another thread... it could
> be a long one from the sounds of things.

I'll take my (100%) share of the blame. I can be a bit of an ass
sometimes, admittedly, but I think it's something the community needs.
And I think it often takes outsiders and misfits to shake things up (CC65
came from the Atari 800 community, for example).

> What's this compiler going to be called?
>
> CC65816 seems like alot of typing... ccg sounds like the Canadian Coast
> Guard:)

What about just cc816?

> I must have time to think now:) And listen to the thoughts of others... the
> guy leading the charge on this doesn't have Opus II... so now what?
>
> Bill
>
>
>

-uso.

[Kamelito]

I suppose that something like vamos could be done for the IIGS.
http://lallafa.de/blog/category/amiga/vamos/

Kamelito

[Steve Nickolas]

You mean like emulating GNO on top of *x?

-uso.

[Steven Hirsch]

On 09/02/2013 11:13 AM, Steve Nickolas wrote:
> On Mon, 2 Sep 2013, Bill Buckels wrote:
>
>> I have always used command line C compilers, even while writing 16 bit
>> Windows and 32 bit Windows applications. Whether developing for Linux and
>> Unix or MS-DOS and Windows, or for the Apple //e or Commodore 64 or CP/M 80
>> or CP/M 86 ir has been command line tools.
>
> Sometimes in the beginning I used an IDE because I had the online help. But
> for many years I've done most of my development from the command line, using
> my text editor of choice.
>
>> To a "real" C programmer which I doubt if anyone would dispute my opinion on
>> that subject, a command line C compiler is a C compiler, and an IDE is not.
>> I don't like IDE's. They cramp my style.
>
> Yeah, pretty much.

I have also avoided IDEs, but my new job assignment requires extensive Java
coding. Trying to manage a large multi-package project without Eclipse seems
cruel and unusual. So, I made an exception and it's actually been quite helpful.

[Steven Hirsch]

On 09/02/2013 10:53 AM, D Finnigan wrote:
> Steven Hirsch wrote:
>> On 09/02/2013 07:54 AM, Bill Buckels wrote:
>>
>>> I haven't time in my lifetime to build a parser that works. I certainly
>>> don't have time to rewrite ORCA C as a cross-compiler for the Windows
>>> command line. But that is what I want.
>>
>> I wasn't aware that the sources for ORCA C were available.
>
> As part of Opus II: The source. There is even the unreleased beta version
> there.
>
>>
>> I rather suspect that ORCA was written in assembler, though.
>
> IIRC, Pascal was used to write the C compiler, since Mr. Westerfield had
> completed his 65816 assembler first, then Pascal.

Hmmm. There is at least one solid Pascal compiler available for Linux.
Wonder how practical this port would be? Beyond that, the issues of licensing
and legality seem a bit complex. I wonder if the copyright owner would
consider ownership of the non-source Opus II CD to be a license to use such a
port?

Steve

[Bill Buckels]

"Steve Nickolas" <usot...@buric.co> wrote:
> I can be a bit of an ass

Err, next topic:) I was just playing with an old Aztec C compiler one day
and got carried away... next thing I knew I woke-up in here.

> What about just cc816?

Question is... If this is an orca port, maybe "Open Orca"... ?

I'll have to take a look at that source...

I wonder if the Assembler could be ported as well...

If it was done as a true port as a command line toolchain, much of the
original documentation could be levered. It is very good documentation.
Also, I don't give a fig for the pascal, but others might. Just think... a
command line pascal cross-compiler...

Thinking about this a little more, "ocm, occ, and ocp" with a linker called
"ocl".

I wonder if it fits?

Byteworks is still very much alive. I am assuming one of the first steps
would to ask if this would be appropriate use of the source.

You will need to say something now... it's your vapour ware thread:)

Bill

[Steve Nickolas]

On Mon, 2 Sep 2013, Bill Buckels wrote:

>

> "Steve Nickolas" <usot...@buric.co> wrote:
>> I can be a bit of an ass
>
> Err, next topic:) I was just playing with an old Aztec C compiler one day
> and got carried away... next thing I knew I woke-up in here.

I lol'd.

>
>> What about just cc816?
>
> Question is... If this is an orca port, maybe "Open Orca"... ?

Only if pretty much the whole code was gutted, so that it COULD be open...

>
> I'll have to take a look at that source...
>
> I wonder if the Assembler could be ported as well...

I would personally just use CA65 which already can do 65816 code, although
its macro syntax is no doubt different.

>
> If it was done as a true port as a command line toolchain, much of the
> original documentation could be levered. It is very good documentation.
> Also, I don't give a fig for the pascal, but others might. Just think... a
> command line pascal cross-compiler...
>
> Thinking about this a little more, "ocm, occ, and ocp" with a linker called
> "ocl".
>
> I wonder if it fits?

Perhaps.

>
> Byteworks is still very much alive. I am assuming one of the first steps
> would to ask if this would be appropriate use of the source.
>
> You will need to say something now... it's your vapour ware thread:)
>
> Bill
>
>
>

>:P

-uso.

[Bill Buckels]

"Steven Hirsch" <snhi...@gmail.com> wrote:
> Wonder how practical this port would be?

Some of this should be straight forward. The programming part I mean...

Try this link:

http://schneider.ncifcrf.gov/p2c/

> Beyond that, the issues of licensing and legality seem a bit complex.

Exactly. Well said...

>I wonder if the copyright owner would consider ownership of the non-source
>Opus II CD to be a license to use such a port?

That's an idea but does that match this Open Orca idea?

I guess a guy could do part of a port to see if it's even feasible and then
run it past ByteWorks...

Packaging for the GS concerns me. Perhaps the output could be to a .2mg
format disk image. I don't know much about how an installer works for the GS
so I'd best shut-up and see what gets said.

Bill

[Bill Buckels]

"Steve Nickolas" <usot...@buric.co> wrote:
> I would personally just use CA65 which already can do 65816 code, although
its macro syntax is no doubt different.

I have some idea that Orca C does not just do assembly code. When we work in
Windows C we make Pascal calls on the stack. The DLL's interface that way,
so does everything. Back in the 80's I did a modest amount of what we called
"Mixed Language Programming" linking MASM 5.1 and MSC 5.1 to QuickBASIC 4.5
(or PDS 7 BASIC). The Pascal Calling Convention was used for these as well,
or whatever passed for Pascal's Calling Convention in MS-DOS.

It sounds to me that you want a ProDOS 16 C Compiler. I guess I woke up in
here again.

Guys like Sheppy would know if this is possible anyway. I hope Eric
weighs-in on this thread.

Bill

[Steve Nickolas]

On Mon, 2 Sep 2013, Bill Buckels wrote:

> Packaging for the GS concerns me. Perhaps the output could be to a .2mg
> format disk image. I don't know much about how an installer works for the GS
> so I'd best shut-up and see what gets said.

What about a format Ciderpress can handle natively?

-uso.

[Steve Nickolas]

On Mon, 2 Sep 2013, Bill Buckels wrote:

> It sounds to me that you want a ProDOS 16 C Compiler. I guess I woke up in
> here again.

Output to ProDOS 16, yeah.

-uso.

[Steven Hirsch]

On 09/02/2013 06:28 PM, Bill Buckels wrote:
> "Steven Hirsch" <snhi...@gmail.com> wrote:
>> Wonder how practical this port would be?
>
> Some of this should be straight forward. The programming part I mean...
>
> Try this link:
>
> http://schneider.ncifcrf.gov/p2c/
>
>> Beyond that, the issues of licensing and legality seem a bit complex.
>
> Exactly. Well said...
>
>> I wonder if the copyright owner would consider ownership of the non-source
>> Opus II CD to be a license to use such a port?
>
> That's an idea but does that match this Open Orca idea?
>
> I guess a guy could do part of a port to see if it's even feasible and then
> run it past ByteWorks...

If I had a spare $150 and some indication that the current owner (Tony?
Cannot keep track anymore) would agree to reasonable license terms I'd
consider taking a shot.

I'm not prepared to shell out the bucks on pure speculation about either the
licensing or the practicality of the port.

[Bill Buckels]

"Steve Nickolas" <usot...@buric.co> wrote:
> What about a format Ciderpress can handle natively?

CiderPress works with 2mg format. I am suggesting that you wouldn't need
CiderPress if you compiled to .2mg.

Problem with CiderPress is that it's compiled in Visual Studio 6, and not
easily portable to other platforms or to newer versions of Visual Studio
because of it's dependence on Microsoft Specific MFC for that version.

That's if you worried about anyone other than Windows users (or if you
stayed only with P16 programs). I don't usually worry about that either, but
I was thinking that being inclusive might be a better idea politically
speaking... there seems to be a large number of Mac users and Linux users in
here too.

The Linux guys would likely be really into this if it was portable across
distros and OSX etc. as well as Windows.

A large army of Ants is needed to carry a loaf of bread as big as a Whale...
in this case a Killer Whale.

It bears looking into whether a person could remove just the parser and the
ProDOS 16 stuff from Orca C and call it a day. This other stuff seems to be
scope creep and might be best parked for now...

I am assuming that something resembling an Object format has already been
established by Orca. A C Compiler is more than a mere assembler which you
are no doubt aware. The use of the stack and zero page and link libraries
and so forth are a big part of compiler design.

Bill

[Bill Buckels]

"Steven Hirsch" <snhi...@gmail.com> wrote:
> I'm not prepared to shell out the bucks on pure speculation about either
> the licensing or the practicality of the port.

I am, but not right now. Like you, I have no time at the moment. I wouldn't
start with Tony. I would contact byteworks directly if I got anywhere at
all. I would include Tony and Eric both in my research notes if I got
anywhere of course.

The product is well-done and has survived the passage of time. The source
has been provided for a reason. Is it "show code" or is it meant for
customization to suit some nefarious need to customize my own version? Or
both? I can't imagine someone didling with it in a basement without sharing
the results... despite my self-indulgence I post my stuff... FWIW... so it
seems unlikely that a customization that goes nowhere is the intent here.

The idea of separating the ProDOS 16 stuff from the rest of it is the best
one for me I think. Maybe I could handle that. I'll call you for help when I
get stuck. Make sure you're still alive when I get around to it, OK?

Bill

[Steve Nickolas]

On Mon, 2 Sep 2013, Bill Buckels wrote:

> "Steve Nickolas" <usot...@buric.co> wrote:
>> What about a format Ciderpress can handle natively?
>
> CiderPress works with 2mg format. I am suggesting that you wouldn't need
> CiderPress if you compiled to .2mg.

No, I meant filename#tpxxxx, which CiderPress can import as a ProDOS file
with type and address information. 2MG would be a real waste, I think.

> Problem with CiderPress is that it's compiled in Visual Studio 6, and not
> easily portable to other platforms or to newer versions of Visual Studio
> because of it's dependence on Microsoft Specific MFC for that version.
>
> That's if you worried about anyone other than Windows users (or if you
> stayed only with P16 programs). I don't usually worry about that either, but
> I was thinking that being inclusive might be a better idea politically
> speaking... there seems to be a large number of Mac users and Linux users in
> here too.

Well, if you use WINE, CiderPress runs without issue on Linux. I was
going to write tools to do the same job from the command line, but burned
out after a hard drive crash leaving the job not half done and mostly
destroyed (I think only dir33 and format33 survived).

> The Linux guys would likely be really into this if it was portable across
> distros and OSX etc. as well as Windows.

=p

-uso.

[roughana]

On Monday, September 2, 2013 5:07:24 AM UTC+10, Steve Nickolas wrote:
> The 65816 world seems to lack any sort of usable C compiler, including
> cross-compilers, which could be used to make ProDOS-16 or GS/OS apps. A
> shame; I'd really like to venture into the 16-bit Apple world.

Discussion of a similar topic took place recently during the Downunder Chat.

Instead of starting from scratch, perhaps you would like to contribute to prior art.

Kelvin Sherlock has developed an OMF linker in Java, and a 65816 assembler in Java that uses OMF linker. See the announcement here:
http://a2central.com/1658/kelvin-sherlocks-java-based-apple-ii-development-tools/

I spoke to Kelvin about this recently and he indicated that not much movement had happened on it recently.

The assembler could potentially be modified to use the assembly format that gcc uses. Apparently gcc already has the ability to output 65816.

This would do much of what you seem to be looking for.

Regards,
Andrew

[Steve Nickolas]

...Java? seriously?

Though I thought GCC handling 65816 was an impossibility because of 65816
being a segmented architecture (the documented reason it was never
targetted to 8086 or 286).

-uso.

[Steven Hirsch]

On 09/02/2013 07:08 PM, Bill Buckels wrote:

> It bears looking into whether a person could remove just the parser and the
> ProDOS 16 stuff from Orca C and call it a day. This other stuff seems to be
> scope creep and might be best parked for now...
>
> I am assuming that something resembling an Object format has already been
> established by Orca. A C Compiler is more than a mere assembler which you
> are no doubt aware. The use of the stack and zero page and link libraries
> and so forth are a big part of compiler design.

Yes. Writing a token scanner and parser that accepts valid C syntax is not
rocket science. The real heavy lifting is generating code from the grammar.

[Steven Hirsch]

On 09/02/2013 07:22 PM, Bill Buckels wrote:
> "Steven Hirsch" <snhi...@gmail.com> wrote:
>> I'm not prepared to shell out the bucks on pure speculation about either
>> the licensing or the practicality of the port.

> The product is well-done and has survived the passage of time. The source
> has been provided for a reason. Is it "show code" or is it meant for
> customization to suit some nefarious need to customize my own version? Or
> both? I can't imagine someone didling with it in a basement without sharing
> the results... despite my self-indulgence I post my stuff... FWIW... so it
> seems unlikely that a customization that goes nowhere is the intent here.

But that's my main concern: If you purchase the sources, I presume that gives
you a license to enjoy them yourself in the privacy of your own computer room.
Anything produced from those sources is a derived work that is almost
certainly covered under the author's copyright. The question is what the terms
would be for a third party to obtain a license to use the new binary. One
would hope that ownership of the original GS-hosted C compiler would be deemed
sufficient, but that's a decision that can only be made by the copyright holder.

> The idea of separating the ProDOS 16 stuff from the rest of it is the best
> one for me I think. Maybe I could handle that. I'll call you for help when I
> get stuck. Make sure you're still alive when I get around to it, OK?

I'm not sure exactly what you are suggesting. Do you want only an 8-bit C
compiler? If that's the case, what's wrong with Aztec C?

Steve

[mmphosis]

I've got lcc-1.9-retargetable building on Mac OS X now. Rather than using
the -s compiler/linker option, instead I am using a separate command: strip
-u $(HOST).o

Unfortunately, the 65816 assembler output is for a 65816 assembler named
after a whale.
For instance, I am not sure what the expression in this line of output is
supposed to do:

pea +(L2)|-16

I've been playing around with the generator, and changing some of the
entries in opt0.dag and opt1.dag to create output for the other plethora of
65816 assemblers.

I don't think much of my development thus far is ready to move out of the
basement.

[Bill Buckels]

"Steven Hirsch" <snhi...@gmail.com> wrote:

> Bill Buckels wrote:
>> The idea of separating the ProDOS 16 stuff from the rest of it is the
>> best
>> one for me I think. Maybe I could handle that. I'll call you for help
>> when I
>> get stuck. Make sure you're still alive when I get around to it, OK?

> I'm not sure exactly what you are suggesting. Do you want only an 8-bit C
> compiler? If that's the case, what's wrong with Aztec C?

NOT!!! ProDOS 8 Steve, ProDOS 16 for the GS...

Essentially I want Ansi Aztec C for the GS, but that ship long since sailed.

So separating the ProDOS 16 core from the GUI core would be a good first
step for an eventual port... but hey, we're just wishing...

As far as what's wrong with Aztec C, I could make a list that would fill a
book... but the list of what's right would fill a library:)

Bill

[Stavros Karatsoridis]

Tony is not the copyright holder for the ByteWorks stuff. Mike Westerfield is. Tony is just the distributor/reseller, as it were.

The ByteWorks website is www.byteworks.us

You could start with Mike to see if he would be willing to allow the use of his source code that way.

[David Empson]

mmphosis <mmph...@macgui.com> wrote:

> I've got lcc-1.9-retargetable building on Mac OS X now. Rather than using
> the -s compiler/linker option, instead I am using a separate command: strip
> -u $(HOST).o
>
> Unfortunately, the 65816 assembler output is for a 65816 assembler named
> after a whale.
> For instance, I am not sure what the expression in this line of output is
> supposed to do:
>
> pea +(L2)|-16

I'm rather rusty on Apple II assembler syntax and don't have the manual
nearby (assuming it survived), but dredging my memory...

The vertical bar in ORCA/M is a binary operator meaning "shift left by
N", with a negative value in its second operand doing a right shift. In
this case, that's "shift right 16".

That means it does a Push Effective Absolute of the high order 16 bits
of the 32-bit address of L2. The plus sign is not significant.

--
David Empson
dem...@actrix.gen.nz

[mmphosis]

tcc-65816

http://code.google.com/p/snes-sdk/wiki/C_for_the_65816

Tiny C Compiler

http://bellard.org/tcc/

[retrogear]

On Tuesday, September 3, 2013 6:42:40 PM UTC-5, David Empson wrote:

Correct - here's the output from the whale's spout:

ORCA/M Asm65816 2.1.0

0001 0000
0002 0000 * syntax example
0003 0000 Test start
0004 0000
0005 0000 L2 equ $12345678 ;32 bits
0006 0000
0007 0000 F4 34 12 pea +(L2)|-16 ;pushes high 16 bits
0008 0003
0009 0003 end

9 source lines
0 macros expanded
0 lines generated

Larry

[Steve Nickolas]

On Wed, 4 Sep 2013, retrogear wrote:

> 0001 0000
> 0002 0000 * syntax example
> 0003 0000 Test start
> 0004 0000
> 0005 0000 L2 equ $12345678 ;32 bits
> 0006 0000
> 0007 0000 F4 34 12 pea +(L2)|-16 ;pushes high 16 bits
> 0008 0003
> 0009 0003 end

Well, looks like in CA65 you use >>16...

ca65 V2.13.3 - (C) Copyright 1998-2012 Ullrich von Bassewitz
Main file : xper.a65
Current file: xper.a65

000000r 1 L2 = $12345678
000000r 1 .p816
000000r 1 F4 34 12 pea L2>>16
000000r 1

[retrogear]

your assembler syntax actually uses common sense :)

Larry

[Steve Nickolas]

On Wed, 4 Sep 2013, retrogear wrote:

> On Wednesday, September 4, 2013 6:12:49 AM UTC-5, Steve Nickolas wrote:
>> On Wed, 4 Sep 2013, retrogear wrote:
>>
>>> 0001 0000
>>> 0002 0000 * syntax example
>>> 0003 0000 Test start
>>> 0004 0000
>>> 0005 0000 L2 equ $12345678 ;32 bits
>>> 0006 0000
>>> 0007 0000 F4 34 12 pea +(L2)|-16 ;pushes high 16 bits
>>> 0008 0003
>>> 0009 0003 end
>>
>>
>> Well, looks like in CA65 you use >>16...
>>
>> ca65 V2.13.3 - (C) Copyright 1998-2012 Ullrich von Bassewitz
>>
>> Main file : xper.a65
>>
>> Current file: xper.a65
>>
>> 000000r 1 L2 = $12345678
>> 000000r 1 .p816
>> 000000r 1 F4 34 12 pea L2>>16
>> 000000r 1
>
> your assembler syntax actually uses common sense :)
>
> Larry
>

It's not my assembler, it's just what I use as an assembler... xD

But yeah. If I were going to push for any assembler to be used as the
backend for a 65816 C compiler it would be CA65.

-uso.