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

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

Native Apple II development with Apple2Pi (even for non-Pi users)

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

Contents

  Native Apple II development with Apple2Pi (even for non-Pi users) David Schmenk <dschmenk@gmail.com> - 2013-08-24 13:33 -0700
    Native Apple II development with Apple2Pi (even for non-Pi users) Antoine Vignau <antoine.vignau@laposte.net> - 2013-08-25 03:24 -0700
    Re: Native Apple II development with Apple2Pi (even for non-Pi users) ol.sc@web.de (Oliver Schmidt) - 2013-08-26 21:09 +0000
      Re: Native Apple II development with Apple2Pi (even for non-Pi users) David Schmenk <dschmenk@gmail.com> - 2013-08-26 15:03 -0700
    Re: Native Apple II development with Apple2Pi (even for non-Pi users) Egan Ford <datajerk@gmail.com> - 2013-08-27 17:47 -0500
    Re: Native Apple II development with Apple2Pi (even for non-Pi users) Egan Ford <datajerk@gmail.com> - 2013-08-27 17:52 -0500
      Re: Native Apple II development with Apple2Pi (even for non-Pi users) Egan Ford <datajerk@gmail.com> - 2013-08-27 17:59 -0500
        Re: Native Apple II development with Apple2Pi (even for non-Pi users) David Schmenk <dschmenk@gmail.com> - 2013-08-27 16:40 -0700

#810 — Native Apple II development with Apple2Pi (even for non-Pi users)

Long title, hopefully not-too-long description.

As I was writing some Apple II code using the cc65 toolchain, I was in the same conundrum we all have when you want to test the result.  Move the binary to a disk image, fire up the emulator, load disk image, etc, etc.  I had set up my Apple2Pi workstation using my Apple IIe, 17" flat screen for Pi display, and Apple Color Monitor for the Apple II composite output.  CiderPress on another computer moved the binary images around, writing the DSK image using Apple2Pi's dskwrite command, exiting from the Apple II client, then running the code from floppy (or running Virtual ][ from my Mac).

And then I said to myself: "self, you already implemented memory read/write and call operations into Apple2Pi.  Why not use them efficiently?"  So in short order I whipped up BLOAD and BRUN like commands for Linux (cleverly named bload and brun) and could test my binaries right from the Linux command line.  Self-contained binaries can be immediately executed like: "brun test.bin 0x2000" which would download the test.bin binary at $2000 and call it.  Multi-part tests can use bload first to load memory in sections.  As the memory is written at 115K baud, it is comparable to reading from floppy, speed-wise.  Assuming the code didn't run off into the weeds, it would return back to the command line with the result value (the Accumulator value).  Now, as will happen to me, the code *will* run off into the weeds.  A simple press of RESET will re-connect the Apple II to the Pi, assuming the client code didn't get overwritten.  If it did, just reboot the Apple II and it will re-sync with the Pi.  I had to put in some effort to make the communication channel more robust between the Pi and Apple II, but it's now pretty solid.

Now, you may be saying, "I don't have a Pi so why do I care?"  Well, this will work on just about any modern Linux distro.  I've used my old x86 Ubuntu box.  If you cross develop on Linux for the Apple II, this would be equivalent to Arduino development.  Use modern development tools, test on the metal with the press of a key.

The last issue is the placement of the Apple II client code.  I currently use about 1K at $1000.  This is kind of in the middle of everything.  Anyone have a better solution?

You can find the code here, as always: https://github.com/dschmenk/apple2pi

Dave...

[toc] | [next] | [standalone]

#811

Great work, Sir!
Av

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

#812

On Sat, 24 Aug 2013 13:33:47 -0700 (PDT), David Schmenk
<dschmenk@gmail.com> wrote:

>And then I said to myself: "self, you already implemented memory read/write=
> and call operations into Apple2Pi.  Why not use them efficiently?"  So in =
>short order I whipped up BLOAD and BRUN like commands for Linux (cleverly n=
>amed bload and brun) and could test my binaries right from the Linux comman=
>d line.

Sort of similiar to the approach used in UDPSlave
(http://www.paradroid.net/udpslave/) for the C64. As that code
primarily interfaces with the CS8900A Ethernet chip and the RAM it
ports easily to an A2 with Uthernet.

Regards,
Oliver

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

#813

On Monday, 26 August 2013 14:09:04 UTC-7, Oliver Schmidt  wrote:
> On Sat, 24 Aug 2013 13:33:47 -0700 (PDT), David Schmenk
> 
> <dschmenk@gmail.com> wrote:
> 
> 
> 
> >And then I said to myself: "self, you already implemented memory read/write=
> 
> > and call operations into Apple2Pi.  Why not use them efficiently?"  So in =
> 
> >short order I whipped up BLOAD and BRUN like commands for Linux (cleverly n=
> 
> >amed bload and brun) and could test my binaries right from the Linux comman=
> 
> >d line.
> 
> 
> 
> Sort of similiar to the approach used in UDPSlave
> 
> (http://www.paradroid.net/udpslave/) for the C64. As that code
> 
> primarily interfaces with the CS8900A Ethernet chip and the RAM it
> 
> ports easily to an A2 with Uthernet.
> 
> 
> 
> Regards,
> 
> Oliver

Indeed, they both allow downloading and execution of code over the 'net.  It sure makes life easier being able to immediately run a binary after compiling/assembling it.  I won't touch another disk image again until it's time for final testing!

Dave...

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

#816

On 8/24/13 3:33 PM, David Schmenk wrote:
> Anyone have a better solution?

Not better, but different.  I use c2t with cut/paste, e.g.

c2t -pl moon_patrol,801 | pbcopy

Then from the emulator just call -151 and cmd-V.  To speed up the dump 
crank up the emulator speed.

c2t can also do multi-segment:

c2t -pl thief,801 thief.obj,3ffd thief.pic,2000 | pbcopy

For brun:

(echo "CALL -151"; c2t -pl moon_patrol,801; echo "801G") | pbcopy

c2t source/bin: http://asciiexpress.net/files

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

#817

On 8/24/13 3:33 PM, David Schmenk wrote:
> The last issue is the placement of the Apple II client code.  I currently use about 1K at $1000.  This is kind of in the middle of everything.  Anyone have a better solution?

Ah, I didn't correctly read the entire line.

Put the 1K code at $BC00, odds are your cc65 code will never go that 
high.  You can setup the linker to avoid $1000+1K or $BC00+1K.

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

#818

On 8/27/13 5:52 PM, Egan Ford wrote:
> Put the 1K code at $BC00, odds are your cc65 code will never go that
> high.  You can setup the linker to avoid $1000+1K or $BC00+1K.

Actually BC00 may not be safe.  I assumed that you were not using DOS or 
ProDOS.  I do not have my What's Where in the Apple II handy.

I do all my development and testing without DOS or ProDOS and cram my 
stuff below C000.

If you are only using cc65/ca65, then have the linker avoid $1000+1K.

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

#819

On Tuesday, 27 August 2013 15:59:09 UTC-7, datajerk  wrote:
> On 8/27/13 5:52 PM, Egan Ford wrote:
> 
> > Put the 1K code at $BC00, odds are your cc65 code will never go that
> 
> > high.  You can setup the linker to avoid $1000+1K or $BC00+1K.
> 
> 
> 
> Actually BC00 may not be safe.  I assumed that you were not using DOS or 
> 
> ProDOS.  I do not have my What's Where in the Apple II handy.
> 
> 
> 
> I do all my development and testing without DOS or ProDOS and cram my 
> 
> stuff below C000.
> 
> 
> 
> If you are only using cc65/ca65, then have the linker avoid $1000+1K.

Since I was already loading the driver in ProDOS BASIC, I decided to bite the bullet and go fully BASIC.  From the ProDOS TRM, you can hide machine language programs in the upper buffer space.  So that's what I ended up doing.  Just don't exit BASIC.  But it did clean up some other issues.

And I developed the client code in MERLIN 8.  That way I don't have to move binaries around to floppy images.  I just drop out of the Apple II Pi client, fire up MERLIN, assemble, and reconnect to the Pi.

Dave...

[toc] | [prev] | [standalone]

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

csiph-web