Jump to content

Modern coding tools for Apple II?


Recommended Posts

I've been tinkering with 8-bit workshop and it's pretty nice to quickly try small changes to a program:



But it doesn't seem very easy to export a file to .dsk, which is something I'd want to do eventually.

On the other hand there's cc65 (which I think the website uses internally) but then it's 100% command-line based.


Does anybody have a good example of VS Code integration for Apple II dev?

So far I've only found a VS Extension for BBC Micro development and a thread on Atari Lynx (below)


I've also found this 8-bit Unity tool, that claims to be able to compile across several 8-bit systems.

Has anybody tried using it for Apple II development?  https://8bit-unity.com/



Link to comment
Share on other sites

One way to get your code onto a .dsk image is to simply load a blank .dsk into Applewin or another emulator, then take your compiled code or Applesoft listing and copy and paste it into the emulator. Save the file(s) onto the .dsk and you're done. It may not be elegant, but it works. I've done this when typing in programs from magazines.

Link to comment
Share on other sites

59 minutes ago, TheDevil'sCompass said:

One way to get your code onto a .dsk image is to simply load a blank .dsk into Applewin or another emulator, then take your compiled code or Applesoft listing and copy and paste it into the emulator. Save the file(s) onto the .dsk and you're done. It may not be elegant, but it works. I've done this when typing in programs from magazines.

Does this only work for BASIC, or are you able to paste machine code as well?

I've been able to import (and export) BASIC programs from a text file into a .dsk using CiderPress.


Tinkering a bit more with 8bitworkshop, I suspect it doesn't implement DHRG...

the below gives me a blank screen when the same commands on emulator shows vertical lines:

  __asm__ ("sta $C050" ); // TURN ON GRAPHICS
  __asm__ ("sta $C057" ); // TURN ON HIRES
  __asm__ ("sta $C052" ); // TURN ON FULLSCREEN
  __asm__ ("sta $C05E" ); // TURN ON DHR
  __asm__ ("sta $C00D" ); // TURN ON 80 COLUMNS


Edited by Newsdee
Link to comment
Share on other sites

36 minutes ago, Newsdee said:

Does this only work for BASIC, or are you able to paste machine code as well?


It works with machine code too. You just have to type in CALL -151 before pasting or include it as the first command that you paste.


For example:

CALL -151
2000:01 02 03 04 05 06 07 08

If you paste these four lines in an emulator it will enter the code then save it, providing you have a .dsk loaded with space available. If you then issue an HGR command and BLOAD WHATEVER, you'll see the 8 bytes in the upper left corner of the screen.


Link to comment
Share on other sites

8 minutes ago, TheDevil'sCompass said:

It works with machine code too. You just have to type in CALL -151 before pasting or include it as the first command that you paste.

Thanks! I had to use SHIFT + INSERT for it to work.

Now I just need to get cc65 to output machine language in a compatible format so I can paste it...

Link to comment
Share on other sites

I guess the issue is that you need to create a file that's in the BSAVE format?  And I guess CiderPress doesn't directly support that?


If you can at least have it write a binary file, you just need to format your file with 4 extra lead bytes.  2 bytes are load address and the other 2 are load size.  Note that this is for DOS 3.3.  ProDOS apparently has a larger catalog structure with an aux_type field.  If it's a binary file, the aux_type field has the load address.


If CiderPress determines that the file is binary, it will move the data 4 bytes forward to make room for the load params.  So now the question is, how do you set where it starts?  The answer is that you have to give your file a special name with what they call a "preservation string" at the end.  This is a 6-hex-char value where the first 2 are the file type byte and the other 4 are the load address.  So if you want to load MYBIN at address $1000, you'd name the file (in Windows):



This will make Apple BASIC BLOAD (or BRUN) it to the correct location in memory.

Edited by ChildOfCv
Link to comment
Share on other sites

Thanks, yes that makes sense. Other than getting the files into a .dsk, it's also about having a simple workflow (a la 8bitworkshop) but offline.


I've just installed that 8-bit Unity package, it turns out to be a series of C libraries for cc65 + a collection of free software utilities

(sprite editors, music editors, emulators to test.... not all necessary but at least it's all together).

Probably the way to go unless somebody shows me a good VS Code extension :)


Edited by Newsdee
Link to comment
Share on other sites

  • 1 month later...

a VS code extension for writing assembler, C, Pascal, or something else that compiles to 6502 would be nice, but I haven't found one for THOSE, yet. However,  for BASIC, there some other options for developing for the Apple II.

Funny you should mention Visual Studio Code, I just found this yesterday:



It even has mouseover info for pokes and peeks that tell about the address you are working with.

It doesn't seem to be complete yet, but it was updated May 2022, so I think the author may still be actively developing it.


In my earlier searches for modern ways to develop for the apple II, I came across this:



I was thinking about contacting the author of the vs code extension and asking him about implementing some of the features of virtual basic into it.


Virtual BASIC lets you code Applesoft BASIC (and Integer BASIC maybe?) with modern indenting style, and it has the ability to separately label and define gosub routines. The labels for gosub routines require using the british pound symbol though, but I looked at the code and it's easy to substitute that to something else.

After you've finished coding, it can convert the code you've written into properly numbered BASIC statements, which you can then save to a text file then do something like SHIFT+INSERT into Applewin or whatever.

Please note Virtual BASIC requires Python 2, but as a result, it is cross platform. It hasn't been updated since October of 2019.


I'm currently "disassembling" some of my old favorite Apple II games that were written using BASIC (+ some ASM,) to get the logic written out so I can re-implement for modern platforms (with my own ideas for additions / corrections.)


I haven't looked at CC65 yet, but that seems like something that might be useful as well.


There doesn't seem to be any all-in-one tool that lets you write for, compile, and debug for the Apple II in both high-level languages AND assembly at the same time, and/or disassemble those types of things (unless you count the Applewin debugger, which as GREAT as it is, isn't documented very well.)


As near as I can see the closest thing to a somewhat complete package for Apple II development on modern platforms seems to be the 8-bit Unity, but I haven't looked at it yet.


Just a note, as I was about to hit the submit reply button I also found THIS:



Edited by xorxif
Link to comment
Share on other sites

@Newsdee I too have been using 8bitworkshop.com. It has some serious issues for professional development, but I have nonetheless found it to be the fastest path for me for Getting Shit Done®. The main reason for this is that the very instant I make a change, the code is quickly rebuilt and the emulator is updated with it - this makes for much faster code/debug cycles, particularly if I don't have to fuss with reloading a .dsk image.


The major obstacle to using it, for me, was that I really needed a pretty genuine Apple ][ ROM, including AppleSoft, to do what I wanted. Fortunately, the current dev version of 8bws allows one to upload their own Apple ROM (or include it in their repo); if it's named "apple2.rom" then it will be used in place of the default copyright-unencumbered one. You can see how that works out in my project Taki, by clicking the 8bws link found there (it will automatically use the "dev" version rather than the latest release, which still doesn't yet include custom ROM support). My project bootstraps some BASIC code to drive the whole thing (the BASIC is stored as strings in a ca65 .s file though, heh). (My project is still a WIP, so doesn't do all that much - but most of the framework for doing things is now built, and it does do one or two types of text animation from within a BASIC program and with configurable animation parameters)


True, you can't generate a .dsk, but for my part I'm happy running a separate Makefile in my local development directory to do that. I've also had some small discussions with Steven Hugg about approaches to doing .dsk generation within the IDE.


While the addition of custom ROM support, along with some keyboard tweaks, allowed me to proceed just fine on my Taki project, I do foresee the following issues being a hindrance/burden to future development, unless someone (possibly me?) works to address them:

  • The emulated machine is basically a stock Apple ][/][+. So, no DHRG, no DLRG (and no "any key pressed", either). Having the features of a ][e available would be very nice, and necessary for some types of projects. The IDE in general isn't really designed in a way to make it easy to customize the particulars of the machine under emulation.
  • Currently the start position of your program is hard-coded (to $803). I work around this by putting a jump there to my "real" code start...
  • The integrated editor sucks.
  • Being able to generate a .dsk directly in the IDE would be a boon, as would be a more complete build environment, with minimal POSIX and "make" support. The latter's kind of a stretch-goal type of thing though...
  • The GitHub support is rather basic. It'd be great to be able to keep source files in a subdir, for instance, instead of at the top level. And I'd really love to have recursive repository support; at the moment I have several sub-projects to Taki already (one for bootstrapping into AppleSoft for 8bws, one for 16-bit maths, and another for Forth-style stack manipulation operations in assembly); at the moment I maintain those in separate repos but then copy the files into Taki, which is pretty damn ugly, and could lead to unintended codebase divergence.

But again, despite these major flaws, 8bws has proven far and away a much faster development cycle than anything else I've tried so far. Once I got used to doing things in 8bws, and got the minimum changes pulled into it that met my needs, I was able to really roll up my sleeves and get work done at a surprisingly fast pace.


@Newsdee, you mentioned needing something you can use offline. 8bws can actually work just fine for offline, because it doesn't host anything on a server - it's all done using JavaScript and your in-browser storage. You can just use a Docker container or what have you to run your own instance of the webserver, and then you have access even while you're offline. Just be sure and sync your changes to your github repo before switching between the online instance and your private server (or, probably better, avoid using anything but your private server instance).


The only thing that uses servers is that a cloud file storage account is used to temporarily host the files for a repo before uploading to Github. The 8bws sources currently include a configuration file that will use the same account that the production server does, so that too is taken care of for you.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...