Modern Apple II development options

[John Brooks]

I'm just getting back into Apple IIGS programming again after being distracted by other things for the past 25 years.

I'm curious what modern development tools and workflow options are available when the code must be run on a physical Apple II/GS due to hardware dependencies (IE, the code doesn't run the same on an emulator).

Right now I'm continuing to use Merlin16 on the GS as I did in the 1980's, but I wonder what other options are available. A primary goal is fast iteration speed.

I'm open to using OS X, Linux, or Windows if it improves dev iteration.

Apologies in advance is this has recently been discussed somewhere and I missed it.

Thanks!
-JB
@JBrooksBSI

[Andy McFadden]

On Monday, October 12, 2015 at 1:48:03 PM UTC-7, John Brooks wrote:
> I'm curious what modern development tools and workflow options are available when the code must be run on a physical Apple II/GS due to hardware dependencies (IE, the code doesn't run the same on an emulator).
>
> Right now I'm continuing to use Merlin16 on the GS as I did in the 1980's, but I wonder what other options are available. A primary goal is fast iteration speed.

If you haven't seen them yet, start here:

http://www.brutaldeluxe.fr/products/crossdevtools/merlin/
http://www.brutaldeluxe.fr/products/crossdevtools/cadius/
http://adtpro.sourceforge.net/

Back in the early 1990s I remember Andy Nicholas building GS/ShrinkIt on a Mac under MPW, cross-compiling it, and sending the output to a IIgs over AppleTalk/AppleShare for testing. This was a whole lot faster than compiling it under APW.

I had AppleShare set up from a Linux box using netatalk and a Farallon EtherWave device through the IIgs serial port once upon a time, but these days you have other options (http://a2retrosystems.com/). I haven't tried to set up file sharing for a while though.

[John Brooks]

Thanks Andy. The networking option is the most attractive, but I'm not sure how difficult it will be to set up. I have pre-ordered a Uthernet II which may be the key to getting executable files built on OS X over to the GS quickly & easily. Though I'm not sure if the Uthernet II will come with transfer software or if that will need to be written.

Other transfer options I've heard about are standard serial connection (slow xfer), Appletalk (complex setup), and using a USB floppy drive to share a floppy disk between OS X & GS (slow xfer & manual process).

Does anybody have recent experience doing cross-development using any of these transfer methods?

Another possibility I'm curious about is a wifi-enabled compact-flash or USB flash drive on the GS being written to via wifi. Anybody tried that?

Thanks!
-JB

[D Finnigan]

John Brooks wrote:
>
> Thanks Andy. The networking option is the most attractive, but I'm not
> sure
> how difficult it will be to set up. I have pre-ordered a Uthernet II which
> may be the key to getting executable files built on OS X over to the GS
> quickly & easily. Though I'm not sure if the Uthernet II will come with
> transfer software or if that will need to be written.

Using the Uthernet II to transfer files with the software that's available
now won't be as convenient as using AppleShare over LocalTalk.

There is FTP that will work with the Uthernet II, but it hardly needs be
stated that it's less convenient than mounting an AppleShare volume.

>
> Does anybody have recent experience doing cross-development using any of
> these transfer methods?

My solution to it is that I don't do cross-development! :-P

(Sorry, I know that's not really helpful for you)

>
> Another possibility I'm curious about is a wifi-enabled compact-flash or
> USB flash drive on the GS being written to via wifi. Anybody tried that?

That sounds like a good way to go if such a thing is available.

--
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[D Finnigan]

John Brooks wrote:
> I'm just getting back into Apple IIGS programming again after being
> distracted by other things for the past 25 years.
>
> I'm curious what modern development tools and workflow options are
> available when the code must be run on a physical Apple II/GS due to
> hardware dependencies (IE, the code doesn't run the same on an emulator).

There is Merlin 32 from Brutal Deluxe, which will compile under Mac OS X, as
I've recently learned.

MPW is the good old standby.

>
> Right now I'm continuing to use Merlin16 on the GS as I did in the 1980's,
> but I wonder what other options are available. A primary goal is fast
> iteration speed.

If that's your primary goal then you're probably going to be a little
disappointed with current cross-development options, unless…. and this is
a big "unless"...

… you can use AppleShare to mount volumes on your IIgs desktop.

That's where cross-development hits the snag that limits fast iterations:
getting the stuff back to the physical machine.

>
> Apologies in advance is this has recently been discussed somewhere and I
> missed it.

It's an ongoing discussion. Cross-development is slowly getting better and
better.

Transferring files back to real hardware hasn't been (IMO) satisfactorily
solved yet.

[Michael J. Mahon]

Is this a job for A2CLOUD?
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[D Finnigan]

Michael J. Mahon wrote:
>
> Is this a job for A2CLOUD?
>

Is A2CLOUD 16-bit native? I looked at the site just now and it doesn't look
like it is. :-(

http://appleii.ivanx.com/prnumber6/category/a2cloud/

[David Schmidt]

On 10/13/2015 2:08 PM, John Brooks wrote:
> Other transfer options I've heard about are standard serial connection (slow xfer), Appletalk (complex setup), and using a USB floppy drive to share a floppy disk between OS X & GS (slow xfer & manual process).
>
> Does anybody have recent experience doing cross-development using any of these transfer methods?

I do cross development in 8 bits for ADTPro, and it is maybe a little
different than what you're after - since I use emulation almost
exclusively until it comes time to test a particular communications
mechanism that is only relevant/testable on real hardware (i.e. serial
or audio).

I have an Ant-based build that uses the c665 toolchain to assemble and
AppleCommander to copy resulting binaries to disk images. I can then
double-click the disk images and immediately boot up an emulator to try
the changes out. Couldn't be faster, but it's not on real hardware.

When I do go to work on real hardware, I find it easy to swap a USB key
between the host computer and my CFFA3000 card and boot the Apple from
the disk image I copy to that. The CFFA3000 config will remember the
active image name to boot from, so it's as easy as plugging in the USB
key and rebooting and it's running with the new image.

Andy already gave you the main ADTPro page, and the place where I go
into detail about the build process is here:
http://adtpro.sourceforge.net/developing.html
and the ant script itself is here:
http://adtpro.cvs.sourceforge.net/viewvc/adtpro/adtpro/build/build.xml?revision=1.269&view=markup

[John Brooks]

From what I've learned so far, I think the most effective transfer options for my Prodos8-targeted development workflow will be:

1) ADT Pro virtual drive w/Uthernet II

or

2) Wifi compact-flash or USB flash drive

In the next week or so when my Uthernet II arrives I will experiment with Merlin32 + Cadius/AppleCommander + ADT Pro + UthernetII.

I hope to get a CFFA later this year and can then try the wifi flash option to see which workflow works better.

Thanks!
-JB

[roug...@gmail.com]

On Wednesday, October 14, 2015 at 5:08:09 AM UTC+11, John Brooks wrote:
> Does anybody have recent experience doing cross-development?

Merlin32 does not have the ability to execute the Merlin command files that I use in my build processes. So I would need to convert all these command files into the Windows environment to be able to replicate the output that I have now from Merlin16+. I don't have the ability or desire to do so.
(Examples: Set rVersion, Copy Resource Fork)

I am currently using Merlin16+ to build within the Sweet16 emulator. I then export output of the build process using SAFE2 (FTP) to the Mac.
On my Uthernet equipped IIgs I use SAFE2 (FTP) to copy the archive across the room for on-the-metal testing.

One of my ideas for the future is to build a Merlin command that transfers a file via FTP. This would automate the step of lifting the output of the build out of the emulated environment.

> Another possibility I'm curious about is a wifi-enabled compact-flash or USB flash drive on the GS being written to via wifi. Anybody tried that?

I understand that the CF and SD WiFi media are geared towards getting data (.JPG) off the media rather than facilitating putting data (.PO/.2MG) on. However, Nishida Radio have an SD based drive emulator solution that allows writing of Apple II disk images to the SD card via WiFi.
http://tulip-house.ddo.jp/DIGITAL/UNISDISKAIR/index.html

I recently bought a FlashAir with the intent to try this in a CF-SD adapter with my CFFA3000. I am hoping that I can leverage Nishida Radio's configuration of the FlashAir card.

However, what is the output of your Merlin build process? Usually it is an executable file or set of files.
To work with one of these disk image mounting solutions, the output must be wrapped in a disk image so it can be mounted as a volume.

Another of my ideas for the future is to build a Merlin command that creates a disk image wrapper (e.g. 2mg) around a set input files.

By calling the image wrapper command and the ftp command from the Merlin linker command file I expect that the output of the build process can be ready for mounting on a real IIgs in a format that can be mounted and used.

Another alternative would be to be able to upload the output of the build process directly into the IIgs file system. E.g. By using an FTP server running on the IIgs. Perhaps Kim Howe's FTP NDA will allow this.

This is where an Appleshare solution is handy because the output of the build process appears in a drive that the IIgs already has mounted. However, running an intermediary machine to host Netatalk is not what everyone wants to do.

If we ever get an SMB filesystem solution for the IIgs then this would make cross development transfers fly.
http://a2central.com/5062/eric-shepherd-announces-s-prize/

Regards,
Andrew

[David Schmidt]

On 10/13/2015 8:03 PM, John Brooks wrote:
> 1) ADT Pro virtual drive w/Uthernet II

Well, the problem with that combination specifically is the amount of
memory the VEDrive driver takes up. There isn't a lot of space left for
your program. (And, it's not available in 16 bit environments.) Device
drivers outside of ROM on an expansion slot is simply not the Apple II's
strong suit. It works fantastically in SOS - because device drivers are
part of the OS's architecture. Not so in ProDOS. If I were smarter, or
had some help, maybe we could get this working under ProDOS 16.

If you can live in the restricted memory footprint the Ethernet driver
affords you, it's pretty handy.

> I hope to get a CFFA later this year and can then try the wifi flash option to see which workflow works better.

A word of caution - just because it plugs into the CF slot it doesn't
guarantee it'll work in the CFFA3000. Some of these devices weren't
available when we were testing the first couple of versions of the
CFFA3000, so there are some devices that may be little speculative yet.
There are certainly some USB devices that for sure don't work - such
as hubs.

[John Brooks]

Is that because it's using memory in the low 64k? Is there any reason a GS version couldn't be placed in a higher memory bank?

> It works fantastically in SOS - because device drivers are part of the OS's architecture. Not so in ProDOS.

I've had no probelm with P8 device drivers on the GS as long as they are allocated in higher memory banks. Is the memory space on a 6502 system what you are referring to as the Prodos driver problem?

> If you can live in the restricted memory footprint the Ethernet driver affords you, it's pretty handy.

I was primarily thinking of using it to copy data from OS X to my HD after each build, so I don't need much memory.


I did a quick test using a USB serial connection between OS X & the GS via ADT Pro VSDrive.2.0.1.

Copy II+ was able to access the virtual drives in s2 like a normal Prodos volume and copy files between my HD & the virtual volume.

One odd thing though is that Prodos had already assigned s2d1 & s2d2 to my other devices at boot. When I ran VSDrive, it grabbed slot 2 and overrode the existing mappings, but also added 2 more volumes.

Here is my Copy II+ device list prior to installing VSDrive:

S3D2: /RAM DISCONNECTED
S5D1: 3.5" d1
S5D2: /RAM5
S2D1: 3.5" d2
S4D1: /HD1
S4D2: /HD2
S1D1: /HD3
S1D2: /HD4
S2D2: /HD5
S7D1: /HD6
S7D2: /HD7
S6D1: 5.25" d1
S6D2: 5.25" d2

And after running VSDrive:

S2D2: /VIRTUAL2
S2D1: /VIRTUAL
S3D2: /RAM DISCONNECTED
S5D1: 3.5" d1
S5D2: /RAM5
S2D1: /VIRTUAL
S4D1: /HD1
S4D2: /HD2
S1D1: /HD3
S1D2: /HD4
S2D2: /VIRTUAL2
S7D1: /HD6
S7D2: /HD7
S6D1: 5.25" d1
S6D2: 5.25" d2

So now the 2 virtual drives are mapped to 4 slot/drive devices, displacing the 2nd 3.5" & the 5th HD partition. It's also showing 15 mounted Prodos volumes when the max is 14. I haven't seen that before.

Bredon's Cat Doctor (Prosel8 utility) crashes with vsdrive installed.

Apple's ProDOS filer utilities seems to work fine with vsdrive and will catalog, copy files, etc.

Looks promising, particularly with ethernet instead of serial and a GS driver.

-JB

[Hugh Hood]

in article 17f44174-1463-4bb0...@googlegroups.com, John
Brooks at jbr...@blueshiftinc.com wrote on 10/13/15 1:08 PM:

>>
>> I had AppleShare set up from a Linux box using netatalk and a Farallon
>> EtherWave device through the IIgs serial port once upon a time, but these
>> days you have other options (http://a2retrosystems.com/). I haven't tried to
>> set up file sharing for a while though.
>
> Thanks Andy. The networking option is the most attractive, but I'm not sure
> how difficult it will be to set up. I have pre-ordered a Uthernet II which may
> be the key to getting executable files built on OS X over to the GS quickly &
> easily. Though I'm not sure if the Uthernet II will come with transfer
> software or if that will need to be written.
>

John:

I'll agree with what the other guys here have said. -- Since your goal is
fast iteration speed in order to test on real hardware, it will be hard to
beat the convenience of AppleShare/AppleTalk file sharing.

It _might_ limit the complexity of setting this up between your development
machine (Mac or Windows) and your Apple IIGS if you were to use the
'virtual' version of Ivan Drucker's A2Server.

<http://ivanx.com/a2server/a2server_virtualbox.html>

You can then 'run' Netatalk on the virtual machine and not have to use an
intermediate machine, whether that be a Raspberri Pi or a Unix box. Ivan did
such a marvelous job doing all the heavy lifting on that project.

Hardware wise, you'll still need to get a LocalTalk to Ethernet adapter like
the Farallon iPrint LT (#559), but it seems those are less than $20.00 on
eBay these days.

Merlin32 is great, BTW. Edit your code in a modern text editor (use 'normal'
ASCII and LF line enders even with Merlin files), compile it to your shared
folder, and then run it on your IIGS.

Unlike you, I really haven't needed fast iteration speed on real hardware,
so I've been content either to sneakernet the compiled file(s) via HFS
media, or to Zmodem the file(s) serially using ProTERM on the Apple II side
and the unix programs 'rz' and 'sz' on the Mac OS X side. Stock ProTERM 3.1
allows 57,600 baud transfers. You can also get 115,200 baud transfers with a
modified ProTERM. To keep Apple II ProDOS file types intact, however, you
need to add a Binary II header on the Mac side, though. Otherwise, you have
to set that manually on the Apple II side.






Hugh Hood

[John Brooks]

Taking a quick look at the VDrive src, it looks like the mount problem is here:

ldx DEVCNT
checkdev:
lda DEVLST,X ; Grab an active device number
cmp #$a0 ; Slot 2, drive 1?
beq present ; Yes, check if it's our driver
dex
bpl checkdev ; Swing around until no more in list
instdev:
; All ready to go - install away!

As of Prodos v2.0, SmartPort devices with more than 2 volumes per slot will get their extra volumes mapped to open slots and routed to the smartport driver which will remap the driver call to the correct slot/volume . Here is my DEVCNT/DEVLST prior to installing VSDrive:

BF31: 0C
BF32: E0 60 FB 7B AB 9B 1B CB 4B 2B DB 5B BF 00 00

-JB

[John Brooks]

On Tuesday, October 13, 2015 at 9:42:21 PM UTC-7, Hugh Hood wrote:
> John Brooks wrote on 10/13/15 1:08 PM:

Thanks for the tips Hugh. I'm not sure I'm following all your comments, and I have some questions:

> Hardware wise, you'll still need to get a LocalTalk to Ethernet adapter

Okay, so is the idea to use the 212kbaud localtalk on the GS, bridged to ethernet via a 3rd party hardware device? And then from there to an ethernet file server?

Why would that be faster or more convenient than using a Uthernet II board directly in the GS?

> Merlin32 is great, BTW. Edit your code in a modern text editor (use 'normal'
> ASCII and LF line enders even with Merlin files), compile it to your shared
> folder, and then run it on your IIGS.

I'm looking forward to trying it. I'm a bit concerned about the lack of cyc on/off as I have to do a lot of cycle counting when racing the timing windows on the IWM/SHR/DOC, but I figure it won't be too hard to add cyc to the assembler.

I've compiled the Brutal Deluxe tool Cadius for OS X and plan to compare it against Apple's DuplicateIIGS MPW transfer program for moving files in & out of disk images. I'm not sure yet how much this will slow iteration or if having the GS files reside on a disk image will be a problem compared to using a network file server.

> Stock ProTERM 3.1 allows 57,600 baud transfers. You can also get 115,200 baud transfers with a
modified ProTERM.

I think I want to avoid manual xfers and slow serial for my workflow. So far the ADTPro VDrive w/Uthernet (or 115k baud RS232) looks like a fairly simple connection with my dev machine where I can use an exec file or basic program to automatically copy files between the OS X virtual drive and the GS HD (or ram disk, etc).

> To keep Apple II ProDOS file types intact, however, you
need to add a Binary II header on the Mac side, though. Otherwise, you have
to set that manually on the Apple II side.

I think this step will be handled by Cadius when it copies files into the virtual disk image on OS X, but I'm not sure if that will cover all the use-cases. I'll have to do some experimentation.

Great discussion. Thank you for the options and ideas!

-JB

[olivier...@itn-group.eu]

Hi,

The Cross Development Toolbox is at an early stage.

Cadius was the first brick because of the need to interact with disk Image file format using command line process (CiderPress is wonderful but you spend a lot of time to do the actions one after the other using the GUI).

Merlin 32 was the central assembler tool capable to go further than Merlin 16+ (which can't process a large number of EXT labels). OMF Analyzer was build to expose the internal of OMF structures.

The next tools on the list are a 65c816/OMF disassembler, a resource Compiler (for GS/OS application) and a 65c816 simulator (to run 65c816 code with facilities like step by step, memory look, cycle counting & co). These are already working but are not ready yet for a distribution. I'm currently busy on something else, but they see the light of the day probably next year.

All tools have to be open source (up to you to modify for your own needs) and must be easy to port on different architecture (even if modern 32 bits / 64 platforms are preferred) so C language was chosen.

There is nothing planned to facilitate the transfer of the Merlin 32 output to a real Apple II. I guess a basic FTP layer would be useful.

Olivier

[D Finnigan]

John Brooks <jbr...@blueshiftinc.com> wrote:
> On Tuesday, October 13, 2015 at 9:42:21 PM UTC-7, Hugh Hood wrote:
>> Hardware wise, you'll still need to get a LocalTalk to Ethernet adapter
>
> Okay, so is the idea to use the 212kbaud localtalk on the GS, bridged to
> ethernet via a 3rd party hardware device? And then from there to an ethernet file server?
>
> Why would that be faster or more convenient >than using a Uthernet II
> board directly in the GS?

AppleShare.

[David Schmidt]

On 10/14/2015 12:09 AM, John Brooks wrote:
> On Tuesday, October 13, 2015 at 7:04:05 PM UTC-7, schmidtd wrote:
>> Well, the problem with that combination specifically is the amount of
>> memory the VEDrive driver takes up.
>
> Is that because it's using memory in the low 64k? Is there any reason a GS version couldn't be placed in a higher memory bank?

Yes, that's why. Everything is tuned for 64k machines, and doesn't take
advantage of any other memory map. Further, the older IP stack is
fairly large in and of itself; re-engineered to use the on-board IP
stack on the Uthernet II instead will relieve that quite a bit.

[David Schmidt]

Ok, so basically I need to check for phantom devices taking the expected
slots and bail if they're full?

[John Brooks]

On Wednesday, October 14, 2015 at 6:44:22 AM UTC-7, D Finnigan wrote:

Some questions about Appleshare:

1) Will Appleshare work over Ethernet on the GS or is Appleshare limited to Appletalk speed?

2) Can Appleshare be used to automate the mounting of a remote volume at ProDOS boot (or from Prosel8)?

3) Approximately how long does it take to mount a remote volume?

4) Are there any problems with the fileserver representing Apple II file properties such as filetype/aux type, resource fork, Prodos backup bit, etc?

Thanks!
-JB

[John Brooks]

Ok. Good to know. Has the effort of re-engineering for the Uthernet II started? If so, any estimate on when that might be ready to test?

-JB

[John Brooks]

Right. Although it might also be good to mount a single volume if there is only one empty ($00) slot in the DEVLST instead of failing. Another way to test if you're already installed is have your driver start at a different address from the Disk II driver ($d001?) and chk the device driver vectors (DEVADR01) for a match. If you don't find any devices pointing to your handler, then you are free to grab the first unused ($00) DEVLST entry. Of course the most robust check would be to use a driver code checksum.

BTW, I noticed that the Disk II devices are not unmounted, so trying to access a Disk II results in the drive turning on and some subset of the disk access to be performed resulting in a disk error. Prodos indicates that the disk is bad/unreadable which may confuse users. Ideally the disk II devices would be unmapped. This could be another alternative for mapping in the VDrive volumes: replace the Disk II devices.

For P8 drivers on the GS, I usually put thunks at the end of the GS clock routine. Prodos reserves 125 bytes for the old Apple II Thunderclock driver, and on a GS, P8 only uses ~85 bytes of that space for the GS clock driver since it just makes a toolbox call to get the time. That leaves ~40 bytes of space for extra device driver thunks at the end of the GS clock driver which can vector out to large 816 drivers above the 128k of Apple // memory.

If 40 bytes of main LC is not enough, the entire clock routine can be moved to high memory giving 125 bytes. Another option is to relocate or remove the /ram auxmem ramdisk driver which saves another 130 bytes of main LC, and ~400 bytes of aux driver @ $200.

-JB

[John Brooks]

Great job so far Oliver. Both Cadius and Merlin32 look like they will be key to my cross-development workflow. I appreciate the straightforward C++ source code architecture and cross-platform portability.

> There is nothing planned to facilitate the transfer of the Merlin 32 output to a real Apple II. I guess a basic FTP layer would be useful.

I suspect this will happen naturally as part of ADT Pro and/or Uthernet II refinement.

At work, my console development workflow since about 2000 on Dreamcast/Playstation/Xbox has been to keep the executable and data binary files on my host machine and have the target machine pull the data over ethernet on-demand. I'm kind of hoping to set something like that up for the GS.

I'm leaning towards using up a 32MB virtual ProDOS HD on my OS X laptop which will be mounted on Prodos8 via ADT Pro's VEDrive over the Uthernet II with the ethernet driver & buffers tucked away in the upper 4MB of RAM. Then I can use the OS X laptop to do my code build & data processing and the GS can run the binary directly from the virtual drive over ethernet and also use the virtual volume as a source for copying graphics/sound/etc to floppies.

Keep up the great work!

-JB

[David Schmidt]

Well, no, not really. I tuned the IP65 stack to the new chip, but I
didn't do the full refactoring to use the onboard stack. It would
essentially be another transport type, not sharing much code at the
"driver" level with anything that came before. So it'll get there...
but I'm not making commitments as to when.

[D Finnigan]

John Brooks wrote:
>
> Some questions about Appleshare:
>
> 1) Will Appleshare work over Ethernet on the GS or is Appleshare limited
> to
> Appletalk speed?

There is no AppleShare over Ethernet. It's LocalTalk only now. It could be
done, but no one has done it yet.

>
> 2) Can Appleshare be used to automate the mounting of a remote volume at
> ProDOS boot (or from Prosel8)?

Yes, you can auto mount at boot in GS/OS.

>
> 3) Approximately how long does it take to mount a remote volume?

As long as it takes you to select it in the dialog box and type your
password (if any). If you have auto mount, it's even quicker.

>
> 4) Are there any problems with the fileserver representing Apple II file
> properties such as filetype/aux type, resource fork, Prodos backup bit,
> etc?

None. This is why we use Apple equipment. "It just works." :-)

[Ewen]

<roug...@gmail.com> wrote:

Andrew,

> I am currently using Merlin16+ to build within the Sweet16 emulator. I then
> export output of the build process using SAFE2 (FTP) to the Mac.
> On my Uthernet equipped IIgs I use SAFE2 (FTP) to copy the archive across
> the room for on-the-metal testing.

Those steps could of course be condensed down to one, that is FTP direct
from Sweet16 to a real IIgs, using SAFE2 on each. SAFE2 on Sweet16 must
run in PASV mode, but can run in Active or PASV mode on a real IIgs.

Cheers - Ewen

[Oliver Schmidt]

Hi David,

>I have an Ant-based build that uses the c665 toolchain to assemble and

>AppleCommander to copy resulting binaries to disk images. [...]

>
>When I do go to work on real hardware, I find it easy to swap a USB key
>between the host computer and my CFFA3000 card and boot the Apple from
>the disk image I copy to that.

It's sort of ironic that you who are developing a tool for transfering
disk images to real hardware don't use to yourself ;-)

Regards,
Oliver

[Oliver Schmidt]

On Wed, 14 Oct 2015 18:04:27 -0400, David Schmidt
<schm...@my-deja.com> wrote:

>Well, no, not really. I tuned the IP65 stack to the new chip, but I
>didn't do the full refactoring to use the onboard stack. It would
>essentially be another transport type, not sharing much code at the
>"driver" level with anything that came before. So it'll get there...
>but I'm not making commitments as to when.

I personally don't see the benefit of replacing the IP65 software IP
stack with the W5100 hardware IP stack for the "classic" ADTPro disk
transfer tool. Especially as support for the Uthernet I and LANceGS
still requires the IP65 variant to be kept alive.

On https://github.com/oliverschmidt/adtpro is an ADTPro 2.0.1 modified
to use my latest IP65 code. That IP65 code comes with support for the
Uthernet II (beside the Uthernet I and LANceGS) and as such the ADTPro
mentioned supports the Uthernet II implicitly.

I'd be very happy if you would consider to integrate my ADTPro
modifications into your code base for further ADTPro development.

In contrast to the "classic" ADTPro disk transfer tool the ADTPro
Virtual Ethernet Drive would benefit greatly from the W5100 hardware
IP stack as it would allow to create a Virtual Ethernet Drive that -
like the Virtual Serial Drive - lives "inside" ProDOS (replacing the
Disk II driver).

On
https://github.com/oliverschmidt/ip65/blob/master/supplement/w5100_udp.s
is a low level W5100 code specifically targeted for that very usecase.

It would be great if you would create an ADTPro Virtual Ethernet Drive
replacing the Disk II driver (based on that code)!

An implementation note: The W5100 doesn't contain a DHCP client (as
mentioned in another post). Just staying with IP65 for the "classic"
ADTPro disk transfer tool - but using the W5100 IP stack for the
Virtual Drive - means that you don't need to implement your own DHCP
client. From my perspective overall a pretty appealing cost-benefit
ratio.

Regards,
Oliver

[John Brooks]

On Thursday, October 15, 2015 at 1:07:36 PM UTC-7, Oliver Schmidt wrote:
> On Wed, 14 Oct 2015 18:04:27 -0400, David Schmidt

I think one of the potential user benefits of the W5100 stack will be faster transfer speeds. The bottleneck for data transfer with the Uthernet II looks like it will be the Apple II CPU, so offloading processing to the W5100 should make those 3.5" and hdv transfers much nicer.

-JB

[D Finnigan]

John Brooks wrote:
> I think one of the potential user benefits of the W5100 stack will be
> faster transfer speeds. The bottleneck for data transfer with the Uthernet
> II looks like it will be the Apple II CPU, so offloading processing to the
> W5100 should make those 3.5" and hdv transfers much nicer.

Yes, not having to compute the checksum will be good.

[David Schmidt]

Oh, believe me - there are lots of scenarios where I do. It's
especially handy for a single disk. I leave a serial connection up all
the time between my workhorse GS and a Mac Mini. But there are times
when I want to move a 32MB-size partition around, and then the speed
tradeoff tips in the favor of hardware swap.

[David Schmidt]

On 10/15/2015 4:07 PM, Oliver Schmidt wrote:
> On Wed, 14 Oct 2015 18:04:27 -0400, David Schmidt
> <schm...@my-deja.com> wrote:
>
>> Well, no, not really. I tuned the IP65 stack to the new chip, but I
>> didn't do the full refactoring to use the onboard stack. It would
>> essentially be another transport type, not sharing much code at the
>> "driver" level with anything that came before. So it'll get there...
>> but I'm not making commitments as to when.
>
> I personally don't see the benefit of replacing the IP65 software IP
> stack with the W5100 hardware IP stack for the "classic" ADTPro disk
> transfer tool. Especially as support for the Uthernet I and LANceGS
> still requires the IP65 variant to be kept alive.
>
> On https://github.com/oliverschmidt/adtpro is an ADTPro 2.0.1 modified
> to use my latest IP65 code. That IP65 code comes with support for the
> Uthernet II (beside the Uthernet I and LANceGS) and as such the ADTPro
> mentioned supports the Uthernet II implicitly.
>
> I'd be very happy if you would consider to integrate my ADTPro
> modifications into your code base for further ADTPro development.

I did a similar thing with my IP65 stack - but the problem I ran into is
lack of space for all three "drivers" to be available in one program. I
could fit two, but not three. I'll be interested to see how that works
with your pre-built stack. What version of ca65 are you using?

> In contrast to the "classic" ADTPro disk transfer tool the ADTPro
> Virtual Ethernet Drive would benefit greatly from the W5100 hardware
> IP stack as it would allow to create a Virtual Ethernet Drive that -
> like the Virtual Serial Drive - lives "inside" ProDOS (replacing the
> Disk II driver).
>
> On
> https://github.com/oliverschmidt/ip65/blob/master/supplement/w5100_udp.s
> is a low level W5100 code specifically targeted for that very usecase.
>
> It would be great if you would create an ADTPro Virtual Ethernet Drive
> replacing the Disk II driver (based on that code)!

Right, we'll get back to that when my cards arrive. ;-)

[Hugh Hood]

in article 82829625-f3f0-4760...@googlegroups.com, John
Brooks at jbr...@blueshiftinc.com wrote on 10/14/15 12:18 AM:

>
> Okay, so is the idea to use the 212kbaud localtalk on the GS, bridged to
> ethernet via a 3rd party hardware device? And then from there to an ethernet
> file server?
>
> Why would that be faster or more convenient than using a Uthernet II board
> directly in the GS?
>

John:

Good questions.


(A) Convenience - edge to AppleShare
-------------------------------------
AFAIK, (currently) to receive a file via FTP on the Apple IIGS requires
first opening an FTP client application (e.g. Ewen Wannop's excellent SAFE2)
to instigate the transfer and then to save the transferred file on the IIGS,
whereas folders (and the files therein) shared under AppleShare are ready to
use as soon as they are saved to the shared folder by your development
machine.


(B) Speed - edge to Uthernet II
-------------------------------------
I haven't yet used an Uthernet II card, but I suspect that its speed smokes
that of Localtalk. SAFE2 FTP transfers should be very quick.



Ideally we would have a speedy ethernet solution that supports AppleTalk for
both GS/OS and ProDOS 8. Apple's never-introduced Ethernet card for the
Apple II series <http://www.apple2.org/AIIEthernet.html> (and its ProDOS 8
and GS/OS support) apparently offered that, but IIRC, the guys who did get
to play with the prototypes say it wasn't really very speedy. To build
something like that now would seem to be a Herculean task, unfortunately.

As Andrew Roughan mentioned, Eric Shepherd has requested (backed with his
own money) the development of an SMB2 compatible FST for GS/OS, but I assume
ProDOS 8 users would not benefit from such an FST.

David Schmidt's ADTPro VEDrive has even greater potential (than it currently
does) provided that he can figure out a way to use the new features of the
Uthernet II to allow moving the driver to the space occupied by the Disk ][
driver, as he has done with his VSDrive driver. You'd still need to get your
file into the disk image that ADTPro is serving, but that probably is not a
big deal and you could automate it.





Hugh Hood

[John Brooks]

On Friday, October 16, 2015 at 10:01:36 PM UTC-7, Hugh Hood wrote:
> in article 82829625-f3f0-4760...@googlegroups.com, John

> Brooks wrote on 10/14/15 12:18 AM:

Right. I agree it would be awesome to just mount a server drive and use files on it as if the drive was local to the GS, but the networking complexity and file system translation complexity appear overwhelming. Unless there is a significant amount of GS Appleshare capability in ROM or somewhere which can be leveraged.

But then there's the problem of hooking up legacy GS Appleshare to a modern Uthernet II driver...

> David Schmidt's ADTPro VEDrive has even greater potential (than it currently
does) provided that he can figure out a way to use the new features of the
Uthernet II to allow moving the driver to the space occupied by the Disk ][
driver, as he has done with his VSDrive driver. You'd still need to get your
file into the disk image that ADTPro is serving, but that probably is not a
big deal and you could automate it.

Yes, this approach seems the fastest to implement at the moment. I've been experimenting with using VSDrive until my Uthernet II arrives.

A GS version of VEDrive can be loaded high into GS memory, so it does not need to replace the 5.25" driver and can also have more code & buffers than are possible with a 6502 version. One potential wrinkle is that the ADTPro toolchain appears to be 6502-only at the moment, but that's a minor hurdle.

As to performance, the fastest I/O I've been able to get on the GS is 1.5uSec-per-byte memory moves using 16-bit instructions. This is much faster than the 6502 can move bytes and was one of the key reasons Rastan GS was able to get a fast frame rate while scrolling the SHR screen. Hopefully we can find a way to utilize these fast 65816 memory copy techniques with the Uthernet II to get fast ethernet speeds.

> You'd still need to get your file into the disk image that ADTPro is serving, but that probably is not a
big deal and you could automate it.

Right. I've tested building 65816 code on OS X, using Cadius to copy files into a ProDOS disk image on the OS X HD, then having the GS mount the disk image and access the files via VSDrive. So far so good.

-JB

[Ewen]

I had a slight brain fade here. Although SAFE2 can allow Active
connections to hosts that support those, SAFE2 was not designed to be an
FTP server, so does not have a "Listen" mode. This means it can't sit
there behaving as an FTP server, waiting for random connections to be
made.

SAFE2 running under Sweet16, can though make connections to servers that
are external to the emulator. Sweet16 allocates a working local IP
Address to Marinetti, which is not the same as the IP Address of the
host Macintosh that Sweet16 is running on. This is how you you are able
not only to connect to servers outside your LAN, but to the FTP server
on the host Mac as well.

Until the recent addition of "drag 'n drop" of files between the Sweet16
desktop and the Mac desktop, that was the easiest way to transfer files
to a real IIgs. All you needed to do was to first trannsfer it to the
Mac, then using the Mac's FTP server, log into that from a real IIgs,
and use SAFE2 to transfer the files across from the Mac.

To get a "flat" file from Sweet16 to a real IIgs, should now only
involve two steps. Drag the file from Sweet16 to the Mac, and FTP the
file from the Mac to the IIgs.

That is probably as quick as any other method would be, as you only need
to run SAFE2 once.

I open a challenge for someone to write an application that would allow
the dropping of a file onto an "active" folder on one IIgs, that then
magically appeared in a folder on a second target IIgs. It would need to
involve TCP/IP so the target computers could be anywhere on the net,
including sending from Sweet16, but needn't involve FTP protocols, so
forked files could be sent back and forth...

Cheers - Ewen

[Oliver Schmidt]

Hi David,

>I did a similar thing with my IP65 stack - but the problem I ran into is
>lack of space for all three "drivers" to be available in one program. I
>could fit two, but not three. I'll be interested to see how that works
>with your pre-built stack.

That's sort of surprising to me! I was afraid of running into that
very issue and was happy to find that the memory segment in question
still had more than one (or even several ?) pages left.

And an additional note: I analyzed what you had changed in your IP65
from Jonno's IP65 and made sure that everything is present in my
current IP65. So there's from the content perspective no need at all
to have your own IP65 anymore. It's of course up to you if you
* Copy my source from my GitHub IP65 into your project.
* Refer to a local clone of my GiHub IP65 from your Ant file.
* Use the Makefile from my GitHub IP65 to build an IP65 library and
link that from your Ant file.

I did the latter with in my ADTPro. But it's a matter of (your) taste.
I removed all the strange special segments form IP65. Now it's just a
straight cc65 library using the cc65 default segments and cc65 default
zeropage variables - much easier to integrate and confire from my
perspective. As a result the linker config(s) in my ADTPro look my
simpler and cleaner. I'd hope you like them :-)

> What version of ca65 are you using?

I'm using the GitHub HEAD. That's slightly inccompatible with what You
seemed to use. But it was only a question of command line aguments in
the Ant file. As far as I can see both the assembler source and the
linker configs should work with both the GibHub HEAD and something
older if you prefer that.

>Right, we'll get back to that when my cards arrive. ;-)

That would be really cool as I still seee this as the Uthernet II
killer app.

Regards,
Oliver

[Oliver Schmidt]

Hi,

>> I think one of the potential user benefits of the W5100 stack will be
>> faster transfer speeds. The bottleneck for data transfer with the Uthernet
>> II looks like it will be the Apple II CPU, so offloading processing to the
>> W5100 should make those 3.5" and hdv transfers much nicer.

I wouldn't bet on that...

>Yes, not having to compute the checksum will be good.

For UDP (which is used in ADTPro) the "full" checksums are optional!
Only the header checksum is obligatory. I.e. Contiki doesn't do UDP
checksums at all.

Regards,
Oliver

[Oliver Schmidt]

Hi David,

>Oh, believe me - there are lots of scenarios where I do. [...]

I was just kidding :-)

Regards,
Oliver

[Oliver Schmidt]

Hi,

>One potential wrinkle is that the ADTPro =

>toolchain appears to be 6502-only at the moment, but that's a minor hurdle.

What does "ADTPro toolchain" mean?

>As to performance, the fastest I/O I've been able to get on the GS is 1.5uS=
>ec-per-byte memory moves using 16-bit instructions. This is much faster tha=
>n the 6502 can move bytes and was one of the key reasons Rastan GS was able=
> to get a fast frame rate while scrolling the SHR screen. Hopefully we can =
>find a way to utilize these fast 65816 memory copy techniques with the Uthe=

>rnet II to get fast ethernet speeds.

With any Ethernet controller it's not about copying bytes in memory
but copying byte from/to the controller. The controller in the
Uthernet II uses 8-bit transfers with an auto-increment register.

Regards,
Oliver

[Oliver Schmidt]

On Sat, 17 Oct 2015 11:34:10 GMT, ol...@web.de (Oliver Schmidt) wrote:

[lots of syntax errors - even more than usual]

Sorry, I wrote that in a hurry - I should take more time to write
postings!

Oliver

[Steven Hirsch]

On 10/17/2015 01:01 AM, Hugh Hood wrote:

> (A) Convenience - edge to AppleShare
> -------------------------------------
> AFAIK, (currently) to receive a file via FTP on the Apple IIGS requires
> first opening an FTP client application (e.g. Ewen Wannop's excellent SAFE2)
> to instigate the transfer and then to save the transferred file on the IIGS,
> whereas folders (and the files therein) shared under AppleShare are ready to
> use as soon as they are saved to the shared folder by your development
> machine.

I use AppleShare exclusively for I/O with the world-at-large and never found
the speed to be any impediment and it's incredibly convenient.

But, I'm curious. What would be involved in getting AppleTalk working over the
Uthernet II?

[David Schmidt]

On 10/17/2015 7:34 AM, Oliver Schmidt wrote:
> Hi David,
>
>> I did a similar thing with my IP65 stack - but the problem I ran into is
>> lack of space for all three "drivers" to be available in one program. I
>> could fit two, but not three. I'll be interested to see how that works
>> with your pre-built stack.
>
> That's sort of surprising to me! I was afraid of running into that
> very issue and was happy to find that the memory segment in question
> still had more than one (or even several ?) pages left.

I agree. I have ingested your library, and was happy to see that 1) it
fit, and 2) it worked. ;-) So I will now switch to your standard IP65
library.

> I did the latter with in my ADTPro. But it's a matter of (your) taste.
> I removed all the strange special segments form IP65. Now it's just a
> straight cc65 library using the cc65 default segments and cc65 default
> zeropage variables - much easier to integrate and confire from my
> perspective. As a result the linker config(s) in my ADTPro look my
> simpler and cleaner. I'd hope you like them :-)

The disadvantage is not being able to debug IP65 at the source level
with an assembler listing with all current memory offsets in hand. On
the other hand - as long as the library is flawless, no need to worry
about debugging! ;-)

>> What version of ca65 are you using?
>
> I'm using the GitHub HEAD. That's slightly inccompatible with what You
> seemed to use. But it was only a question of command line aguments in
> the Ant file. As far as I can see both the assembler source and the
> linker configs should work with both the GibHub HEAD and something
> older if you prefer that.

Yes, the command line arguments have floated around over the years. I
can build the github HEAD with Mac, and it works fine. I'm not so lucky
on Win32, but that's a task for another day.

>> Right, we'll get back to that when my cards arrive. ;-)
>
> That would be really cool as I still seee this as the Uthernet II
> killer app.

For sure...

[John Brooks]

I believe the ADT drivers use the cc65 assembler invoked by ANT.

> With any Ethernet controller it's not about copying bytes in memory
> but copying byte from/to the controller.

Right, I meant I/O<->Mem which is the 1.5uSec/byte time using 16-bit instructions. The GS fastpath mem-to-mem copy time is 1.2uSec/byte using 16-bit instructions.

8-bit I/O transfers are 1/2 speed: 3.0uSec/byte.

> The controller in the Uthernet II uses 8-bit transfers with an auto-increment register.

Yes, in order to get fast GS transfer speed, we'd need to be able to access the W5100's auto-inc data register at contiguous memory addresses (ie 16-bit accesses). The simplest way of doing this is to connect W5100 A0/A1 lines to the slots A1/A2 lines.

-JB

[John Brooks]

Update on my progress attempting to do modern cross-dev of Apple IIGS code using OS X:

The TL;DR summary is that I can now edit 65816 assembly source in Xcode and in 4 to 5 seconds see it running on the Apple IIGS using ADTPro & a USB serial cable.

One thing to note is that my test program is pretty small: ~3000 lines of assembly & 6.5KB binary. For big code+data, I'm hoping the answer is "Uthernet II". :)



Times in seconds on 2012 i7 rMacbook Pro:

0.08 Merlin32 assembly of 2 source files into one ProDOS8 BIN executable
0.02 Cadius time to delete the old BIN file from the virtual disk image and add the new BIN file to it
1.40 Quit ADTPro, then launch ADTPro via command line & select communication method 'serial'

1.00 Manually type "-r<return>" on the GS keyboard
1.50 Run the 6.5KB BIN file from the OS X virtual disk over RS-232 using ADTPro's VSDrive

The above times are for normal code iteration. If my program crashes ProDOS8 and forces a reboot, the GS time is slightly longer:

3.50 Reboot the GS to /RAM5 which automatically mounts VSDrive and does -r to run the exec file

The total time is 4-5 seconds which is much better than what I was doing before.


The pieces:

HW: USB to RS-232 & GS mini-DIN8 to RS-232.

ADTPro - The data xfer workhorse.

Merlin32 - Brutal Deluxe cross-assembler.

Cadius - Brutal Deluxe utility to transfer files in & out of ProDOS disk images.

Xcode - IDE used to edits asm src, though any editor would work.

Terminal - Used to automate the build & xfer on OS X .

b.sh - My shell script which assembles using Merlin32, copies the BIN to the disk image with Cadius, and launches ADTPro.

GS: VSDrive - ADTPro serial-port virtual drive client.

GS: r - My exec file to run the assembled BIN file directly off the mounted VSDrive.

GS: startup - My basic program to handle reboots by installing VSDrive and running the exec file.



The file contents:

b.sh

pkill -f java
~/bin/merlin32 . font.s
~/bin/cadius deletefile /Applications/ADTPro*/disks/Virtual.po /VDRIVE.2.0.1/FONT
~/bin/cadius addfile /Applications/ADTPro*/disks/Virtual.po /VDRIVE.2.0.1 FONT
/Applications/ADTPro*/ADTPro.command serial&


"r" GS exec file

prefix,s2,d1
bload font,a$800,t$00
mtr
800g


startup

10 ?chr$(4)"-vsdrive"
20 onerr goto 30
30 ?chr$(4)"-r"


/RAM5
PRODOS
BASIC.SYSTEM
VSDRIVE
STARTUP
R


The bumps in the road:

I wanted to leave ADT running during my edit/asm/test cycle, but found I was unable to because ADT does not recognize changes made to the VDrive disk images by other OS X applications. I suspect it might be the java runtime caching file reads, but I'm not sure. Cadius can see changes to the disk image as soon as the GS+ADT perform the block write, but ADT is blind to Cadius changes.

The only way I could get ADT to 'see' changes to the virtual disk was to shut it down and relaunch it.

Which brings me to the next bump which is that when ADT is launched, it waits for the user to select the communication method. I needed to automate ADTPro's startup & connection method and found the handy ADT shell script "ADTPro.command" which does exactly that.

However, there's a few odd things about launching via ADTPro.command:

1) Since the app is run via java, the dock icon becomes java and the app name becomes org.adtpro.ADTPro.

2) The about ADT menu reports the version as 1.0 instead of 2.0.1

3) ADT does not respond to quit appleevents so I resorted to a rather harsh process kill of java


Another occasional problem is that sometimes after the ADTPro server starts up, the VDrive client will get an error on the initial connection attempt. That's why I added the onerr check, though it's really needed in the exec file, so I'll need to rework that a bit.


Congratulations if you made it this far!


Next steps are to get the build workflow integrated into the IDE, perhaps do a more proper set of makefile & shell/exec scripts, and explore getting the BIN filetype/auxtype/A$/L$ ProDOS attributes set correctly.

Now that I think about it, perhaps ADT will 'see' changes to virtual disks made by AppleCommander since they're both using the java runtime. I'll try testing that tomorrow.


-JB
@JBrooksBSI

[Hugh Hood]

in article 053cbd74-86a3-40dc...@googlegroups.com, John
Brooks at jbr...@blueshiftinc.com wrote on 10/17/15 12:48 AM:

>
> Right. I've tested building 65816 code on OS X, using Cadius to copy files
> into a ProDOS disk image on the OS X HD, then having the GS mount the disk
> image and access the files via VSDrive. So far so good.
>
> -JB

John,

If you have a minute, may I ask that you share your mods to the Cadius SRC
so that it compiles under Mac OS X?

I've already built a makefile, and pointed it to malloc.h on the Mac, but
it's still throwing up several errors.

I had avoided Cadius since it's billed 'for Windows', but after you reported
success with it under OS X, I thought 'why not'?

Thanks.






Hugh Hood

[John Brooks]

On Sunday, October 18, 2015 at 11:46:09 AM UTC-7, Hugh Hood wrote:
> in article 053cbd74-86a3-40dc...@googlegroups.com, John

> Brooks wrote on 10/17/15 12:48 AM:

>
>
> >
> > Right. I've tested building 65816 code on OS X, using Cadius to copy files
> > into a ProDOS disk image on the OS X HD, then having the GS mount the disk
> > image and access the files via VSDrive. So far so good.
> >
> > -JB
>
> John,
>
> If you have a minute, may I ask that you share your mods to the Cadius SRC
> so that it compiles under Mac OS X?
>
> I've already built a makefile, and pointed it to malloc.h on the Mac, but
> it's still throwing up several errors.
>
> I had avoided Cadius since it's billed 'for Windows', but after you reported
> success with it under OS X, I thought 'why not'?
>
> Thanks.
>
>
>
>
>
>
> Hugh Hood

Sure. Here it is:

https://drive.google.com/file/d/0B9I8jo6bktRATmJVNTlveWUzVWc/view?usp=sharing

Perhaps you can help with some of the Cadius improvements. I'm hoping to store the ProDOS/GSOS attributes directly in the native OS X file on HFS+ instead of having to specify them when files are copied onto a disk image. I know HFS supported ProDOS types and I'm hoping HFS+ will too, but I'm not sure.

I also find that I like the Cadius helper functions which convert MSB-set text to MSB-clear, and can indent or outdent source files being transferred from/to the Apple II editors/assemblers.

-JB

[Antoine Vignau]

Olivier Z..., please put Cadius for MacOS on the site :-)
av

[Hugh Hood]

in article a222eee0-b13d-4fb3...@googlegroups.com, John
Brooks at jbr...@blueshiftinc.com wrote on 10/18/15 1:59 PM:

>>
>> John,
>>
>> If you have a minute, may I ask that you share your mods to the Cadius SRC
>> so that it compiles under Mac OS X?
>>
>>

>> Hugh Hood
>
> Sure. Here it is:
>
> https://drive.google.com/file/d/0B9I8jo6bktRATmJVNTlveWUzVWc/view?usp=sharing
>

John,

Wow! Thanks for serving that up on a silver platter as an Xcode project. It
built without error even as a universal (Intel/PPC) binary. Initial testing
seems good, too.

>
> Perhaps you can help with some of the Cadius improvements. I'm hoping to store
> the ProDOS/GSOS attributes directly in the native OS X file on HFS+ instead of
> having to specify them when files are copied onto a disk image. I know HFS
> supported ProDOS types and I'm hoping HFS+ will too, but I'm not sure.
>
>

> -JB

Please correct me if I've misunderstood you. I _think_ what we'd both like
to see is two-fold:

1. Have Merlin32 respect (rather than ignore) the Merlin 'TYP' directive
when running under Mac OS X (on HFS/HFS+ formatted volumes) and (when
creating the object file) set the ProDOS filetype and auxtype attributes
using the traditional 'p' + 'filetype' + 'auxtype' in the 4-character Mac
file type field of FinderInfo. This is still respected on HFS+ volumes, BTW.

I know this is possible from a command line utility because Andy McFadden's
'nulib2' <https://github.com/fadden/nulib2> writes those attributes for
unshrunken Apple II archives when running under Mac OS X.

AND,

2. Have Cadius (when running under Mac OS X) interpret the FinderInfo
(filetype) associated with the object file in order to set the proper ProDOS
attributes in the disk image to which it copies the object file.


{To keep this interesting for Windows users, I think that rather than using
the 'Mac' method of storing the attributes, the Xattr extended attributes
could be called upon to 'store' the ProDOS info}.


Or, perhaps I have misunderstood?


Again, thanks for the Xcode Cadius. I appreciate it.






Hugh Hood

[John Brooks]

On Sunday, October 18, 2015 at 5:05:31 PM UTC-7, Hugh Hood wrote:
> in article a222eee0-b13d-4fb3...@googlegroups.com, John

> Brooks wrote on 10/18/15 1:59 PM:

Cool. Glad to hear it compiled on PPC too. The code is cleanly organized and written efficiently. It should be easy to enhance/extend and it certainly runs fast given that it's native C code.

> Please correct me if I've misunderstood you. I _think_ what we'd both like
> to see is two-fold:

Yes, you've got it exactly. On OS X, we have the filesystem support to handle all ProDOS types, so Merlin32 could use the TYP directive directly when it writes the output file(s). Also Cadius could move 'intact' ProDOS/GSOS files with type/auxtype/rez between ProDOS disk images & HFS+.

Disk images are very fast to manipulate on modern machines, and of course they are fast and easy for the Apple ][ to access remotely.

-JB

[Steven Hirsch]

On 10/18/2015 02:59 PM, John Brooks wrote:

> Perhaps you can help with some of the Cadius improvements. I'm hoping to
> store the ProDOS/GSOS attributes directly in the native OS X file on HFS+
> instead of having to specify them when files are copied onto a disk image.
> I know HFS supported ProDOS types and I'm hoping HFS+ will too, but I'm not
> sure.

That's fine for Mac users, but please keep in mind that this is a special
case. In the interests of an eventual Linux port it would be a good idea to
keep it well encapsulated. Consider an abstract interface to propagate file
types that can be specialized for a side-file based or intrinsic (Mac HFS)
approach as appropriate.

[John Brooks]

Right. Luckily, Cadius originated on Windows and already has cross-platform support for maintaining file attributes and resource forks via side-files.

I suspect that supporting ProDOS file type info & resource forks on HFS+ can be done with simplified implementations at key points in the existing API as the side-file machinery can be skipped/null on OS X.

-JB

[Steven Hirsch]

One other thought: Why not built-in support for AppleDouble? This is the
mechanism used by Netatalk when storing typed and/or forked files on Unix
filesystems. That would make things quite simple if one targets an
Apple-doubled directory on the Netatalk server for the file destination. It's
immediately ready to go.

The library support for this is in the Netatalk code base and could perhaps be
borrowed (depending on license specifics).

[Kelvin Sherlock]

For IIgs development, I use the MPW IIgs Assembler/Linker/Rez/etc on OS X.

https://github.com/ksherlock/mpw

Then drag-and-drop into Sweet 16. Before drag-and-drop support, I wrote a
gopher client so I could edit files on the Mac and then pull them into sweet 16
(or a real IIgs) for compiling

https://github.com/ksherlock/gopher

I haven't used it lately, but the silver platter NDA (that's a web server)
supports HTTP PUTs, so you can use curl to send files that way. It was
developed on a IIgs but I used curl to copy the source code to a windows
machine to backup in a perforce repository. Occasionally, I made edits in
windows and pushed them back.

(Sweet 16's TCP doesn't support inbound connections which is why I had
to resort to gopher).

Kelvin


On 2015-10-12 20:48:02 +0000, John Brooks said:

> I'm just getting back into Apple IIGS programming again after being
> distracted by other things for the past 25 years.
>
> I'm curious what modern development tools and workflow options are
> available when the code must be run on a physical Apple II/GS due to
> hardware dependencies (IE, the code doesn't run the same on an
> emulator).
>
> Right now I'm continuing to use Merlin16 on the GS as I did in the
> 1980's, but I wonder what other options are available. A primary goal
> is fast iteration speed.
>
> I'm open to using OS X, Linux, or Windows if it improves dev iteration.
>
> Apologies in advance is this has recently been discussed somewhere and
> I missed it.
>
> Thanks!
> -JB
> @JBrooksBSI

[Oliver Schmidt]

Hi David,

>I agree. I have ingested your library, and was happy to see that 1) it
>fit, and 2) it worked. ;-) So I will now switch to your standard IP65
>library.

:-) And given that I consider ADTPro the primary reason to work with IP65 in the first place there's no reason to fear that I'll change things make that work less well in the future.

>The disadvantage is not being able to debug IP65 at the source level
>with an assembler listing with all current memory offsets in hand.

I see.

>On
>the other hand - as long as the library is flawless, no need to worry
>about debugging! ;-)

Anyway there's really nothing special (anymore) about building IP65.
You can easily switch to another approach if necessary.

>I
>can build the github HEAD with Mac, and it works fine.

:-)

>I'm not so lucky
>on Win32, but that's a task for another day.

I work nearly only on Win32 - and Travis builds a Win32 snapshot
automatically on every change - so it for sure generally works. If you
are at that task we can get in touch trying to find out what your
specific issue might be - or you just go for the prebuilt Win32
snapshots.

Regards,
Oliver

[Oliver Schmidt]

Hi John,

>> What does "ADTPro toolchain" mean?

>I believe the ADT drivers use the cc65 assembler invoked by ANT.

All ADTPro code is 8-bit 6502 code using the cc65 assembler. This
includes the IP stack named IP65.

But I don't see why the toolchain is relevant. I'd say the source code
is relevant. The cc65 assembler has btw. support for the 65816.

>> The controller in the Uthernet II uses 8-bit transfers with an auto-increment register.
>
>Yes, in order to get fast GS transfer speed, we'd need to be able to access the W5100's auto-inc data register at contiguous memory addresses (ie 16-bit accesses). The simplest way of doing this is to connect W5100 A0/A1 lines to the slots A1/A2 lines.

Have you read the W5100 data sheet, especially the indirect bus mode?
It seems to me you have no clear understanding about this.

Regards,
Oliver

[olivier...@cooperteam.fr]

We have chosen to include all file information into a separate text file instead of trying to use native OS facilities or surcharging the file path.

We use a side (text) file named _FileInformation.txt containing, for each file of the current folder, the Prodos file informations :
- Type
- AuxType
- Version Create
- Minimum Version
- Access Flags
- Macintosh Finder Info

We use native system facilities to store :
- File Name
- Creation Date
- Modification Date
- Visible / Invisible attribute

You can simply create your _FileInformation.txt file with the Type, AuxType and other information and Assemble with Merlin32 your source file to get a binary file as output.

During the transfer to a Prodos disk Image, CADIUS will read the _FileInformation.txt file content to populate the disk Image with File Data + File Resource Fork + Prodos File information.

The idea of having a separate _FileInformation.txt file is to guarantee that exporting Prodos files (from a Prodos disk image) into a modern file system (like Windows, Linux or Mac OSX) won't loose any of the original Data or Information. You can Export / Import without loosing anything.

Olivier

[John Brooks]

Thanks Kelvin!

I've used the MPW emulation a fair amount. It's very cool!

I found I needed to go to Mac MPW and extract the actual compile commands from old MPW builds as the MPW make syntax was a no-go in the OS X environment.

I also found that a handful of the files I tried to reassemble with MPW on OSX had errors (memory related IIRC) and I had to go build them on Mac MPW instead. I tried both the 68k & 68020 versions of the MPW tools under MPW emulation, but neither version worked.

BTW: Do you know if there's a way to get help info on the emulated MPW commands? I miss MPW's Commando but have been getting by with .pdf docs.

I've recently been using the OS X MPW tool to convert an APW app to AsmIIGS. The Apple conversion tool (CvtAsmIIGS sp?) seems to work fine on OS X. It's too early to tell if I will be able to assemble this project on OS X or will run into those memory errors.

BTW, I've also been putting together an Xcode project & build scripts for cross-development. I have an initial version which uses Merlin32 & ADT VDrive, and plan to do a version for AsmIIGS and later one for Orca/C as I recover and attempt to build long-dormant GS projects.

-JB

[Kelvin Sherlock]

On 2015-10-19 23:13:00 +0000, John Brooks said:

>
> I found I needed to go to Mac MPW and extract the actual compile
> commands from old MPW builds as the MPW make syntax was a no-go in the
> OS X environment.

There is an mpw-make command (not yet pre-built, you have to compile it
yourself) which run's MPW's make and executes the output. Simple
makefiles work but may need some minor editing.

>
> I also found that a handful of the files I tried to reassemble with MPW
> on OSX had errors (memory related IIRC) and I had to go build them on
> Mac MPW instead. I tried both the 68k & 68020 versions of the MPW tools
> under MPW emulation, but neither version worked.

I haven't seen any memory errors, lately. the Tools are not 32-bit
clean so don't give your emulator too much memory.

>
> BTW: Do you know if there's a way to get help info on the emulated MPW
> commands? I miss MPW's Commando but have been getting by with .pdf docs.

A new version of Commando is on the todo list. mpw help (from
https://github.com/ksherlock/mpw-tools) will print out the help file,
if available.

[anthon...@gmail.com]

Hey guys,

This thread had me thinking last week so I went and purchased a WiFi SD card to see if this could be done as painlessly as possible, and I believe it works! Please see the thread : Cross-compiling toolchain delivered straight to your Apple II

Hope this adds another viable option to your modern-day cross-dev options!

Cheers!

Anthony