Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #741 > unrolled thread

Dual 65C816/65C02 programs

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Dual 65C816/65C02 programs D Finnigan <dog_cow@macgui.com> - 2013-07-14 02:35 +0000
    Re: Dual 65C816/65C02 programs Egan Ford <datajerk@gmail.com> - 2013-07-14 21:35 -0500
      Re: Dual 65C816/65C02 programs D Finnigan <dog_cow@macgui.com> - 2013-07-15 21:34 +0000
        Re: Dual 65C816/65C02 programs Charlie <charlieDOTd@verEYEzon.net> - 2013-07-15 20:47 -0400
        Re: Dual 65C816/65C02 programs gbody4@bigpond.com - 2013-07-15 18:52 -0700
          Re: Dual 65C816/65C02 programs Dagen Brock <DagenBrock@gmail.com> - 2013-07-19 07:49 -0700
            Re: Dual 65C816/65C02 programs Egan Ford <datajerk@gmail.com> - 2013-07-19 10:55 -0600
              Re: Dual 65C816/65C02 programs Dagen Brock <DagenBrock@gmail.com> - 2013-07-19 13:21 -0700
                Re: Dual 65C816/65C02 programs Egan Ford <datajerk@gmail.com> - 2013-07-20 11:52 -0600
                  Re: Dual 65C816/65C02 programs D Finnigan <dog_cow@macgui.com> - 2013-07-20 22:47 +0000
                    Re: Dual 65C816/65C02 programs Egan Ford <datajerk@gmail.com> - 2013-07-21 11:19 -0600
                      Re: Dual 65C816/65C02 programs D Finnigan <dog_cow@macgui.com> - 2013-07-21 17:35 +0000
                  Re: Dual 65C816/65C02 programs gids.rs@sasktel.net - 2013-07-25 08:25 -0700
                    Re: Dual 65C816/65C02 programs Egan Ford <datajerk@gmail.com> - 2013-07-27 15:04 -0600

#741 — Dual 65C816/65C02 programs

Thinking about Universal Mach-O binaries on OS X which could have PPC, i386,
and x86_64 code got me wondering whether anyone has ever written a program
that will run on the 6502 or 65C02, but will also get enhanced 16-bit
instructions when run on the IIgs.

I know there are some assemblers that will run on both CPUs, even the 65802,
but how many other programs have been written this way?

Is it possible to have one program binary that will run under ProDOS 8 on
the IIe and ProDOS 16 on the IIgs?

-- 
]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/

[toc] | [next] | [standalone]

#743

On 7/13/13 9:35 PM, D Finnigan wrote:
> Thinking about Universal Mach-O binaries on OS X which could have PPC, i386,
> and x86_64 code got me wondering whether anyone has ever written a program
> that will run on the 6502 or 65C02, but will also get enhanced 16-bit
> instructions when run on the IIgs.
>
> I know there are some assemblers that will run on both CPUs, even the 65802,
> but how many other programs have been written this way?
>
> Is it possible to have one program binary that will run under ProDOS 8 on
> the IIe and ProDOS 16 on the IIgs?
>

I can think of one reason why you wouldn't want to do that--code size. 
The code segment would most likely take 2x RAM.

[toc] | [prev] | [next] | [standalone]

#748

Egan Ford wrote:
> On 7/13/13 9:35 PM, D Finnigan wrote:
>> Thinking about Universal Mach-O binaries on OS X which could have PPC,
>> i386,
>> and x86_64 code got me wondering whether anyone has ever written a
>> program
>> that will run on the 6502 or 65C02, but will also get enhanced 16-bit
>> instructions when run on the IIgs.
>>
>> I know there are some assemblers that will run on both CPUs, even the
>> 65802,
>> but how many other programs have been written this way?
>>
>> Is it possible to have one program binary that will run under ProDOS 8 on
>> the IIe and ProDOS 16 on the IIgs?
>>
> 
> I can think of one reason why you wouldn't want to do that--code size. 
> The code segment would most likely take 2x RAM.

Good point; I hadn't considered that.

What about this: a stub program that detects the current operating system,
then seeks in the file to load the correct code into RAM?

Now I know why we don't do this: operating system support is a must!

-- 
]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/

[toc] | [prev] | [next] | [standalone]

#749

On 7/15/2013 5:34 PM, D Finnigan wrote:
> Egan Ford wrote:
>> On 7/13/13 9:35 PM, D Finnigan wrote:
>>> Thinking about Universal Mach-O binaries on OS X which could have PPC,
>>> i386,
>>> and x86_64 code got me wondering whether anyone has ever written a
>>> program
>>> that will run on the 6502 or 65C02, but will also get enhanced 16-bit
>>> instructions when run on the IIgs.
>>>
>>> I know there are some assemblers that will run on both CPUs, even the
>>> 65802,
>>> but how many other programs have been written this way?
>>>
>>> Is it possible to have one program binary that will run under ProDOS 8 on
>>> the IIe and ProDOS 16 on the IIgs?
>>>
>>
>> I can think of one reason why you wouldn't want to do that--code size.
>> The code segment would most likely take 2x RAM.
>
> Good point; I hadn't considered that.
>
> What about this: a stub program that detects the current operating system,
> then seeks in the file to load the correct code into RAM?
>
> Now I know why we don't do this: operating system support is a must!
>

Maybe I'm misunderstanding but I believe ProDOS 8 can load 65816 code 
and run it on a IIgs.  In fact I don't see why DOS 3.3 couldn't.  Of 
course it would have to be in a recognized file format (binary).

Anyway, I believe Sneeze V2.2 (a program launcher & file utility) by 
Karl Bunker is an example of a ProDOS 8 program that runs both 65c02 and 
65c816 code (when it is needed) depending on whether it is running on a 
//e or a IIgs.

Charlie

[toc] | [prev] | [next] | [standalone]

#751

the only examples I have seen relate to firmware on interface cards, that modify code seen in CnXX range to use different methods to copy blocks of data depending on the processor. The interface card code tested for 65802/65816 processors and modified the move routine to used MVN to move data for better performance.

Geoff B

[toc] | [prev] | [next] | [standalone]

#752

I've done this for a few programs that ran under ProDOS 8.  Generally the programs are simple, so no extra banks were needed.  The main reason I've used it is to detect if I'm on a IIgs, and if so, to set the text/border colors appropriately, or maybe use some 16-bit code to speed something up.

It's certainly doable, but not without its limits.  

Oh yes, that reminds me...  *shuffles off to the internets*  Jordan Mechner used this to change some artwork for POP. 

https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/master/01%20POP%20Source/Source/MASTER.S#L891

    lda IIGS
    bne SuperEpilog ;super hi-res ending if IIGS


Here's the machine check code he used.  
https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/c690818226e37a81d5d2dcb6568cf15aa0fb522f/01%20POP%20Source/Source/GRAFIX.S#L2004

I think there's a technote or one of the official manuals that tells you what the values are. 

[toc] | [prev] | [next] | [standalone]

#753

On 7/19/13 8:49 AM, Dagen Brock wrote:
> I've done this for a few programs that ran under ProDOS 8.  Generally the programs are simple, so no extra banks were needed.  The main reason I've used it is to detect if I'm on a IIgs, and if so, to set the text/border colors appropriately, or maybe use some 16-bit code to speed something up.
>
> It's certainly doable, but not without its limits.
>
> Oh yes, that reminds me...  *shuffles off to the internets*  Jordan Mechner used this to change some artwork for POP.
>
> https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/master/01%20POP%20Source/Source/MASTER.S#L891
>
>      lda IIGS
>      bne SuperEpilog ;super hi-res ending if IIGS
>
>
> Here's the machine check code he used.
> https://github.com/jmechner/Prince-of-Persia-Apple-II/blob/c690818226e37a81d5d2dcb6568cf15aa0fb522f/01%20POP%20Source/Source/GRAFIX.S#L2004
>
> I think there's a technote or one of the official manuals that tells you what the values are.
>

So far all the aforementioned examples assume the 65816 is in emulation 
mode (6502 mode) and therefore it is safe to write 6502 code to detect 
and launch 65816 code.  But what about the other way around?  What if 
the binary were launched from a 16-bit native mode shell or GUI? 
ProDOS-8 does not have this problem (starts in 8-bit mode); unsure about 
GS/OS or ProDOS-16.  I'd think for various reasons the designers of 
65816 systems with a desire to support 6502 code would always launch in 
emulation mode (8-bit) and expect the programmer to switch to native 
16-bit mode.

While the 65816 and 6502 share many opcode values the # of operands can 
vary (8 vs. 16 bit).  Assuming the 6502 would interpret XCE & SEP as 
NOP, then it should be possible to force 8-bit mode to start with.

[toc] | [prev] | [next] | [standalone]

#754

What?  They just read the location at $FBB3.  You can do it with 16-bit or 8-bit code.  You can't write a System 16 executable and launch it on an 8-bit Apple II.  You'd have to write your program as a ProDOS 8 system executable (or plain binary that you bload/brun.  Any time you launch a ProDOS 8 program from GSOS it will load ProDOS 8 first, putting you back in 8-bit emulation mode once control is transferred to your program. 

Your statements don't make a lot of sense.  It's a hard documented fact of these operating systems.  ProDOS 8 programs start in 8-bit (emulation mode on IIgs) and ProDOS 16/GSOS programs start in 16-bit.  

My point is, it doesn't matter what your program starts in.  Reading the status bytes and making decisions about what code to execute is trivial.  Just follow the technote:
http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Computers/Apple%20II/Apple%20II/Documentation/Misc%20%23007%20Apple%20II%20Family%20ID.pdf

[toc] | [prev] | [next] | [standalone]

#755

On 7/19/13 2:21 PM, Dagen Brock wrote:
> What?  They just read the location at $FBB3.  You can do it with 16-bit or 8-bit code.  You can't write a System 16 executable and launch it on an 8-bit Apple II.  You'd have to write your program as a ProDOS 8 system executable (or plain binary that you bload/brun.  Any time you launch a ProDOS 8 program from GSOS it will load ProDOS 8 first, putting you back in 8-bit emulation mode once control is transferred to your program.
>
> Your statements don't make a lot of sense.  It's a hard documented fact of these operating systems.  ProDOS 8 programs start in 8-bit (emulation mode on IIgs) and ProDOS 16/GSOS programs start in 16-bit.

My statements make perfect sense.  Read them again.

My first statement, "So far all the aforementioned examples assume the 
65816 is in emulation mode (6502 mode) and therefore it is safe to write 
6502 code to detect and launch 65816 code."

This aligns with your "just read location at $FBB3" statement.

My 2nd statement was a "what if" scenario, "But what about the other way 
around?  What if the binary were launched from a 16-bit native mode 
shell or GUI?"

IOW, the code would have to assume 16-bit mode to start with making it a 
challenge to run it on an 8-bit system to autodetect 8 or 16 bits.

The OP initially asked, "Is it possible to have one program binary that 
will run under ProDOS 8 on the IIe and ProDOS 16 on the IIgs?"

And I was musing about how one would write a single binary that could 
detect 8 or 16 bit on load from either an 8 or 16 bit system.

It is clearly obvious that you cannot run 16-bit code on an 8-bit 
machine, but given that some of the opcodes are the same, it may be 
possible to have code that will run on both 8-bit and 16-bit machines in 
8 or 16 bit mode for the purpose of detection and redirection.

[toc] | [prev] | [next] | [standalone]

#756

Egan Ford wrote:
> It is clearly obvious that you cannot run 16-bit code on an 8-bit 
> machine, but given that some of the opcodes are the same, it may be 
> possible to have code that will run on both 8-bit and 16-bit machines in 
> 8 or 16 bit mode for the purpose of detection and redirection.

Ever try to boot GS/OS on an Apple IIe? You'll see that code in action.

[toc] | [prev] | [next] | [standalone]

#757

On 7/20/13 4:47 PM, D Finnigan wrote:
> Ever try to boot GS/OS on an Apple IIe? You'll see that code in action.

Can't say I ever have.  Never occurred to me to try.  What was the output?

[toc] | [prev] | [next] | [standalone]

#758

Egan Ford wrote:
> On 7/20/13 4:47 PM, D Finnigan wrote:
>> Ever try to boot GS/OS on an Apple IIe? You'll see that code in action.
> 
> Can't say I ever have.  Never occurred to me to try.  What was the output?
>

Try it yourself! :-)



Ok, I'll tell. You get a message:

GS/OS Requires Apple IIGS hardware

-- 
]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/

[toc] | [prev] | [next] | [standalone]

#772

 
> IOW, the code would have to assume 16-bit mode to start with making it a 
> challenge to run it on an 8-bit system to autodetect 8 or 16 bits.
> The OP initially asked, "Is it possible to have one program binary that 
> will run under ProDOS 8 on the IIe and ProDOS 16 on the IIgs?"

> And I was musing about how one would write a single binary that could 
> detect 8 or 16 bit on load from either an 8 or 16 bit system.

> It is clearly obvious that you cannot run 16-bit code on an 8-bit 
> machine, but given that some of the opcodes are the same, it may be 
> possible to have code that will run on both 8-bit and 16-bit machines in 
> 8 or 16 bit mode for the purpose of detection and redirection.



Due to 16-bit registers used in 16 mode, detection and redirection would also not work, since there pretty much will never be any common code, unless you are using emulation mode from 16-bit mode.  But the IIGS is about speed, and you will want to use 16-bits to benefit from that speed.

You are way better off to have two separate programs so that both 8-bit code and 16-bit code are not in memory at the same time.

Step 1: Identify computer
Step 2: run 16-bit program if IIGS found
      : run 8-bit program if IIGS not found

RAM memory is way more precious than disk space.

[toc] | [prev] | [next] | [standalone]

#781

On 7/25/13 9:25 AM, gids.rs@sasktel.net wrote:

> Due to 16-bit registers used in 16 mode, detection and redirection would also not work, since there pretty much will never be any common code, unless you are using emulation mode from 16-bit mode.  But the IIGS is about speed, and you will want to use 16-bits to benefit from that speed.

Yes that is very true, however there are a few exceptions, e.g. JMPs and 
tests on flags.  E.g LDA addr, you do not care what the value is, but 
you can test for zero flag.  But then there is a challenge of what bank 
if on a 16-bit system....

> You are way better off to have two separate programs so that both 8-bit code and 16-bit code are not in memory at the same time.
>
> Step 1: Identify computer
> Step 2: run 16-bit program if IIGS found
>        : run 8-bit program if IIGS not found
>
> RAM memory is way more precious than disk space.

Completely agree.  That was my first post in this thread, "I can think 
of one reason why you wouldn't want to do that--code size. The code 
segment would most likely take 2x RAM.".

This thread has turned in to a "could I", vs. a "should I".

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web