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

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

Targeting both Apple II and IIgs

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

Contents

  Targeting both Apple II and IIgs anthonypaulo@gmail.com - 2017-07-06 21:30 -0700
    Targeting both Apple II and IIgs Antoine Vignau <antoine.vignau@laposte.net> - 2017-07-07 02:59 -0700
    Re: Targeting both Apple II and IIgs David Schmidt <schmidtd@my-deja.com> - 2017-07-07 11:06 -0400
    Re: Targeting both Apple II and IIgs mmphosis <mmphosis@macgui.com> - 2017-07-07 16:18 +0000
      Re: Targeting both Apple II and IIgs mmphosis@yahoo.com - 2017-07-07 09:33 -0700
        Re: Targeting both Apple II and IIgs James Davis <JPD.Enterprises@outlook.com> - 2017-07-07 14:03 -0700
    Re: Targeting both Apple II and IIgs James Davis <JPD.Enterprises@outlook.com> - 2017-07-07 14:15 -0700
      Re: Targeting both Apple II and IIgs laseractiveguy@gmail.com - 2017-07-12 05:58 -0700

#3638 — Targeting both Apple II and IIgs

Does anyone have any experience targeting both the Apple II and IIgs? I'm particularly interested in how you structure a project in which most of the code is identical except for those portions that deal with capabilities that vary depending on the target platform (eg. DHR and speaker/Mockingboard on IIe vs Super HiRes graphics and Ensoniq chip on the IIgs). I would think that those parts that vary would be modular so that I can swap those parts in/out depending on the capabilities of the target machine, but I come from Windows programming world of dll's so I'd appreciate some education on how this is done in the Apple II world. 

Also, does it make sense to create a single binary that detects the machine it's running on and acts accordingly or is it better to create a separate binary for each target system? That is, a version for the II and a separate version for the IIgs?

[toc] | [next] | [standalone]

#3640

After years of disassembly, I've seen everything:
- different code for II and IIgs
- same 8-bit logic code w/sfx and gfx written for the target machine.

The IIgs is really a different machine, gfx optimizations need dedicated code.

On the other hand, some kinds of games can share the same code, eg. adventure games.
For instance, the engine we wrote for La crapule, our new game, handles the IIgs SHR screen using 16-bit code in a 8-bit engine.

Antoine

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

#3643

On 7/7/2017 12:30 AM, anthonypaulo@gmail.com wrote:
> Does anyone have any experience targeting both the Apple II and IIgs?
> I'm particularly interested in how you structure a project in which
> most of the code is identical except for those portions that deal
> with capabilities that vary depending on the target platform  [...]

I can share my experience in doing something architecturally similar in 
ADTPro.  I have two dimensions I have to manage within the code tree: 
platform (Apple II , Apple ///) and communications method (serial, 
audio, Ethernet).  There's a nucleus that is common to all; even ProDOS 
and SOS are similar enough that the business end of the logic are 
common.  Some macros take care of the binary differences in the calling 
convention.

The code 
(http://adtpro.cvs.sourceforge.net/viewvc/adtpro/adtpro/client/src/) 
that is necessarily specific to one of the two dimensions is split out 
into a different directory (serial, sos, ethernet, prodos, etc). 
There's a "main.asm" that is common to all, but the real "mains" are 
down the tree a bit that don't do a ton more than #include what they 
need to piece together the various dimensions into a whole that will run 
on a designated platform using the designated communications method:
prodos/audio/audmain.asm
prodos/ethernet/ethmain.asm
sos/serial/sermain.asm
sos/ethernet/ethmain.asm
...and so on.  It all grew organically over a 11-year period so far, so 
it's all a bit messy as you might expect.

> Also, does it make sense to create a single binary that detects the
> machine it's running on and acts accordingly or is it better to
> create a separate binary for each target system? That is, a version
> for the II and a separate version for the IIgs?

My opinion is that depends on your requirements.  My requirements were 
to maximize memory savings (ADTPro needs a yuuuge buffer for comms, and 
it must run on a non-plus II through the GS) and simply don't have room 
to have a converged client.  Well, the comms drivers usually know how to 
talk to a few different variants of their ilk like the SCC/SSC for 
serial, and LANceGS/Uthernet/UII for Ethernet in one client.  But in 
general, in my case you need to pick the first two dimensions yourself 
(platform + comms method) that you run, and other variations are taken 
care of as automatically as possible - locating a suitable comms card, 
for example.

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

#3644

This comes up from time to time elsewhere and it is debatable.  Compilers to
my knowledge don't know how to reason very well, ... yet?

http://tratt.net/laurie/blog/entries/what_challenges_and_trade_offs_do_optimising_compilers_face.html

Hand assembly can be faster than code generated by a C compiler.  On a
modern CPU, it makes little different except when it does.  It makes more
difference, more of the time, on a 6502 running at 1 MHz.  For the logic in
a program, code generated by the C compiler would be faster than logic
written in BASIC or even compiled BASIC as it often has been done on the
Apple II.  Write the logic in BASIC, and then hand optimize 6502 machine
language for the critical parts of the program -- this is where the C
compiler might be better.

Show me a C compiler that generates 6502 code optimized to the max: 
register allocation, zero page allocation, unrolled loops, and all manner of
tricks that I've seen to remove 1 cycle.  

anthonypaulo wrote:
> I can't find the thread but I read a post here recommending doing all
> development in assembly because the C compilers generate bloated assembly
> that takes up way too much space. I don't believe it had to do with
> optimizations as it's most likely the case that the compiler can optimize
> better than we can most of the time, but I think it was more along the
> lines of the C compilers not really meant to target an 8-bit system and so
> generate bloated datatypes that utilize 16-bit word lengths instead of
> 8-bit when 8 suffices. Is there some truth to this?

You ask about code optimized for space, not speed.  The trade off of a
occupying a small confined space is slow speed most of the time.  Data can
be hand optimized for space, using more compact types and compression
techniques.  Some of the Apple II role playing games did this very well by
compacting massive vocabularies, again, using all manner of tricks to save
space -- this goes way beyond simple 8-bit vs. 16-bit types.  A 6502 C
compiler might not be the best choice here.

As for the code, it might make more sense to generate or write the code in a
language that might optimize better for space like a forth, PLASMA, Short,
Sweet-16, BASIC, Pascal, or your own language / space optimized VM or
runtime.  

https://en.wikipedia.org/wiki/Shannon_coding
https://github.com/dschmenk/PLASMA/
https://bitbucket.org/martin.haye/super-mon/wiki/Short_features

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

#3646

Oops, I posted to the wrong place.

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

#3654

On Friday, July 7, 2017 at 9:33:22 AM UTC-7, mmph...@yahoo.com wrote:
> Oops, I posted to the wrong place.

You, and only you, can delete that post from this thread (or any post to any thread you wrote into)!

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

#3655

On Thursday, July 6, 2017 at 9:30:31 PM UTC-7, anthon...@gmail.com wrote:
> Does anyone have any experience targeting both the Apple II and IIgs? I'm particularly interested in how you structure a project in which most of the code is identical except for those portions that deal with capabilities that vary depending on the target platform (eg. DHR and speaker/Mockingboard on IIe vs Super HiRes graphics and Ensoniq chip on the IIgs). I would think that those parts that vary would be modular so that I can swap those parts in/out depending on the capabilities of the target machine, but I come from Windows programming world of dll's so I'd appreciate some education on how this is done in the Apple II world. 
> 
> Also, does it make sense to create a single binary that detects the machine it's running on and acts accordingly or is it better to create a separate binary for each target system? That is, a version for the II and a separate version for the IIgs?

You just need to use a case statement/procedure to branch to the proper statement/procedure/separate-program that you decide is best to use to continue your process with.  Everything could be in one program or broken up into separate programs for each case.  The decision is yours, and, like Schmidt says, depends on your needs.  Top down or bottom up programming does not matter, but in my opinion, top down is best.  Flow chart you logic, then code it.

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

#3695

The simplest way is to make your software IIE compatible, and then just have it run on the GS in 'backwards compatible mode'.  If you are targeting specific GS functions and features, and then have a 'lower grade' IIE mode, in most cases your building two entirely different sets of code.  Usually if your software does different things on different hardware, your going to eat up a lot of space on your floppy...

This code is hybrid basic/asm, but you can get an idea of what you need, if you are only loading a certain file, based on iie or iigs

10 IF PEEK(65055)=96 THEN GOTO 20
11 (ENABLE HIRES GS GRAPHIC MODE):PRINT CHR$(4);"BLOAD GSONLY.PICTURE":GOTO 30
20 HGR:PRINT CHR$(4);"BLOAD CHR$(4);"IIE.PICTURE":GOTO 30

25 REM 'LINE 10 CHECKS FOR IIE OR GS
26 REM 'IF $FE1F OR LOCATION 65055 = 96 (OR $60) ITS AN E
27 REM 'IF $FE1F IS NOT $60, ITS A GS

30 REM 'CONTINUE CODE HERE

if you need to do a lot of GS specific things, it be best to write two subroutines and also have a check subroutine, so if  MACHINE$=IIE it gosubs the IIE routine, if MACHINE$=IIGS it gosubs the IIGS routine.   This can only be generalized without knowing more of what your trying to achieve...

[toc] | [prev] | [standalone]

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

csiph-web