cross platform coding for the Apple ][

20 Jan 2017

      Anyone have some success with getting the right tools to set a workflow
for building cross platform coding on the Apple ][ ?

I found some tools already which I hope someone can give us some advice to
build a practical workflow. While helping Evan on his robot project, the
traditional method of coding directly on the vintage platform becomes a
burden when trying to collaborate over the phone, email or online. Because
you can't see what's on their screen and you can't share the screen online
as with today's desktops. No amount of chit-chatting to summarize the code
without looking at it directly is going to help. For the moment, he wants
to work with Applesoft Basic, and perhaps later once the bugs are worked
out and the project is running, then dive into some 6502 assembly.

In the past, because it's simply not practical to do that, I once had Evan
and Jeff shine their phone's camera over the computer screen during a video
conference to help debug the code, it worked :) But I suggested they get
one of those goose-neck mounts to hold the phone or webcam so they can type
faster

Now I recommended that we change to the cross platform coding because it
helps to share the code, share the work, especially when it comes time to
debug any problems while we collaborate on this project from long
distances. And these situations happen often on a new project, with new
hardware, etc. So it becomes practical over the phone, email or online. I
do this already with my C64 assembly coding project to collaborate with
Jeff and others at long distances.

But now I'm not sure if my google-foo has lots of static for this Apple ][
topic because I never had so much trouble finding enough info, versus the
time when I had to setup one for my C64. It did take some time, but mostly
to get familiar with the software tools out there which is specific to that
machine. Then after it just took some time to iron out the steps between
each tool.

For the Apple ][
this is what I found so far

1. Editor = I think any editor would suffice here, maybe there's one
specific for the Apple][ ?
2. Disk Imager = AppleCommander[jav], CiderPress[win], Ominvore[win],
DiskBrowser[win]
3. Emulator = AppleWin[win], LinApple[nix]---> both are the same port
4. Floppy emulator = ADTPro[jav]  via serial port

Now these tools work as described, but there's still some glitches in the
workflow

problem#1,
I can open any disk image with the tools mentioned. But then when I try to
extract the Basic file on my desktop, the tools give you 2 choices, either
the original Apple format, or text format. The original format is so you
can later import the file to the disk image. But then it's not possible to
edit the file cause I can't locate an editor which can view the file in the
first place. And the viewer in the disk imagers don't let you edit file.

problem#2,
With AppleCommander, i can extract the Basic file. It's always exported as
a text file. But then it insert extra CR's on every line.
I can edit the code. then import the file back into the disk image. I can
verify the code is good when I view this in the disk imager.
And then I load this into the emulator. But when I list the file, there's
always some glitches with extra lines of garbage text, either at the
beginning or end, maybe in the middle.

So we can do the basic things[summary],
load disk images,
make disk images,
view files in the disk images,
extract files from the disk images[not 100%],

But then,
we can't successfully import the files from the desktop with the Basic code,
into the disk images for the emulator or live hardware,
even though the viewer in the disk imager verifies its there and readable,
the listing viewed in the emulator shows the glitches

This is what we're facing and we like to find somebody that can give us
advice on this
-------------------
For the C64,
I use Assembly coding. It became easier to build a practical workflow. I
just use an editor, then a script for the Assembler to build the code, the
symbol table, listing file, even a debug listing for the emulator, so I can
set breakpoints on the labels from the code when debugging, and even the
image file so I can add it to the disk image.

Then there's a 2nd tool to build the disk images for the Commodore systems.
And then a very powerful emulator called VICE, which handles every single
computer made by Commodore -- to load the disk images for testing/debugging
the code. And the same disk image is stored on a SD card to load into the
C64 hardware for live testing.

For Assembly coding, it's only 5 tools for cross platform coding on the C64
Plus there are some other tools which you use in parallel,
for creating graphics, sprites and sound effects, and SID music
1. Editor
2. Assembler = DASM
3. Disk Imager
4. Emulator = VICE
5. uIEC = SD card floppy

For those that use Basic coding, it's even simpler. Lots of people have
been very progressive in building powerful coding tools for the Commodore
scene. So there's one called CBM studio. This replaces #1, #2, and #3.
1. CBM studio
2. Emulator = VICE
3. uIEC = SD card floppy

Some use the CBM studio for Assembly coding. But as you know with
Assemblers, not all are compatible, because of their syntax style. So I try
to avoid stuff like that. Because on one project, I tried to rewrite this
network game, it was coded using DASM and I wasn't about to edit 100's of
lines of code in a dozen files just for that, I had enough work ahead of me
already, so I just kept using my editor and that assembler.

-----------------------------
And there there's always the issue that many of the tools are not built for
multiple desktop platforms. I don't fault the developers for this. Because
there are some very good and powerful software tools for all aspects of the
machine, for graphics hardware, sound hardware, etc, not just assembly
coding. So I just keep using tools like VMware to run the different tools.

You have to give lots of credit to the many people who devote so much time
to building these tools. Because it really promotes a wide avenue for other
people to use these to get very creative. I noticed there are always
multiple types of people, this is just one example. People who know how to
build the right tools for you, and people that get very creative by using
the right tools. Example, If you want to build your own house, you like to
find the right tools, rather than getting the "forge and anvil" to build
your tools -- which can already be done better by those experts who devote
their time --  so you can spend more time being creative on your house
design.
Dan

Dan Roganti

Neil Cherry

Dan Roganti

Dan Roganti

Neil Cherry

Evan Koblentz

Evan Koblentz

Systems Glitch

Dan Roganti

Evan Koblentz

Support

Dan Roganti

tags

participants (5)