Tips and Tricks for the CFFA1

As I've been using the CFFA1 Compact Flash Interface with my Replica 1, I came across a few tips and tricks that others may find useful. So here they are, in no particular order.

---

There are two menu commands that are undocumented and commented out in the source code for the help command, but they are enabled and available in the firmware. Control-S is a STATUS command which displays the status of a drive. Typical output looks like this:

DRIVE # (0-3): $3
BLOCK COUNT FOR DRIVE 3 = $D800

Control-D is a DEBUG command which toggles the display of additional debug information about data blocks being read.

---

While Linux does not directly support the ProDOS file system, you can copy the CF card under Linux using the "dd" command. This can be useful to back up a memory card or write an image, such as a po file like the Ultimate Apple 1 Archive. A Google search indicates there are some ProDOS utilities for Linux similar to Cider Press for Windows but I haven't looked at any of them yet.

---

If you want to make changes to the CFFA1 firmware and test it out, you can assemble it to RAM and run it from there, avoiding the need to program it into the EEPROM. I had to change a little more than just the definition of "Origin" in the source code. If you want a patch to do this, let me know and I'll send it to you.

---

If you want to reprogram the EEPROM on the CFFA1 with new software, it is quite easy. There is a procedure described in the manual which works. Another option is to use my JMON machine language monitor program. The basic approach is:

1. Build the firmware for EEPROM at address $A000.
2. Generate a Woz Mon file located in RAM, say, starting at address $6000.
3. Load the JMON program.
4. Load the Woz Mon file into memory.
5. Enable EEPROM write access using DIP switch 4 in the CFFA1.
6. Use JMON to copy the firmware from RAM at $6000 to EEPROM at $A000. Use a write delay (a value of 20 worked for me).
7. Use JMON to verify the data after copying.
8. Set DIP switch 4 back to disable EEPROM write access

---

If you run a buggy program when the CFFA1 is installed you may see a message "BREAK..." and then get placed in the Woz Monitor. This is a BRK handler that the CFFA1 installs. It also installs an IRQ handler. This can potentially interfere with other programs such as JMON that also set BRK handlers but is useful if a program encounters a bug and hits a BRK instruction (hex value $00).

---

This is documented in the manual but easy to overlook: From Apple BASIC you can invoke the CFFA1 menu with "CALL -24000". When invoked in this way to BASIC using the warm start address, so any BASIC program loaded from the CFFA1 will still be in memory and ready to run.

---

The CFFA1 card has data at two defined memory locations that can be used to identify when the card is present. The ID bytes listed in the manual are not correct the addresses. The CFFA1_API.s API file and documentation says to read addresses $AFFC and $AFFD but the hardware and firmware actually uses addresses $AFDC and $AFDD. Further, my CFFA1 board did not have these locations programmed even though firmware on CD-ROM did. I rewrite the EEPROM on my board using the firmware on the CD.

Here is the guts of the code I used to determine of a CFFA1 is present when I hooked up JMON and BASIC to the CFFA1 menu:

LOAD:
SAVE:
        LDA     $AFDC    ; First CFFA1 ID byte
        CMP     #$CF     ; Should contain $CF
        BNE     NoCFFA1
        LDA     $AFDD    ; First CFFA1 ID byte
        CMP     #$FA     ; Should contain $FA
        BNE     NoCFFA1
        JSR     $9006    ; Jump to CFFA1 menu, will return when done.
NoCFFA1:
        RTS

---

It is easy to load and save Applesoft Lite programs. The LOAD and SAVE commands support a CFFA1 card, if present. The commands accept a filename as a parameter (e.g. "SAVE MYPROGRAM"). The MENU command will launch the CFFA1's built-in menu.

---

I made a port of Enhanced BASIC for the Replica 1. If you want to save and load Enhanced BASIC programs, here is a procedure that will work. Save the programs as a binary file from Ram_base ($0400) to Ram_top ($5000). The length should be $4C00.

Once you have loaded and run EHBASIC, type LOAD or SAVE to invoke the CFFA1 menu. Then WRITE or LOAD as desired. QUIT after loading or saving to return to EHBASIC.

I may do a more sophisticated integration in the future (like what was done for Applesoft Lite).

---

I made a port of OSI BASIC for the Replica 1. The latest version will will invoke the CFFA1 menu when LOAD or SAVED is executed and a CFFA1 card is found. QUIT returns to BASIC.

You need to write memory from RAMSTART2 ($0300) to whatever address you specified in response to the "MEMORY SIZE?" prompt on cold start of BASIC. This address is also stored in addresses $85 and $86.

So for example, if you responded to "MEMORY SIZE?" with 24000, location $85 and $86 contain address $5DC0 which corresponds to 24000 in decimal.

To run a program after loading, either quit to get back to MS BASIC or invoke BASIC through warmstart, e.g. address $6274 if loaded into RAM at $6000.

I may do better integration in the future (like was done for Applesoft Lite).

The CFFA1 CompactFlash Interface for Apple 1

The CFFA1  is a Compact Flash Interface for Apple1 computer and compatibles like the Replica 1. It was designed and sold by Rick Dreher. It provides flash filesystem storage of up to 32MB. This is actually quite a lot -- the equivalent of over 200 floppy disks of the Apple II era.

It has 8K of on-board firmware in EEPROM which can be write enabled for updates. It has 32KB of RAM which can be used for expanding the system memory (on Apple 1 and clones that only have 4K) and for the buffer storage of saved and loaded files.

It uses the Apple ProDOS file system so it is compatible with Apple II systems. There is a menu system in firmware that lets you load, save, list directories, delete and rename files, etc. If you don't have an Apple II system there is a Windows program called Cider Press that can access the ProDOS file system on the CF card.

It uses removable CF flash memory cards which are commonly supported by some laptops and most USB card readers.

There is also a version of the card for Apple II computers.

The CFFA1 Card

There is one big problem with the CFFA1 - you can't get your hands one until and unless Rick does another run of boards or someone sells a used one to you. There may be a run this summer. I was fortunate to acquire one from someone who had one they didn't need.

Mine worked very well in my Replica 1. I had two old CF cards around and both of them worked. It worked flawlessly even on my system which is clocked at 2 MHz and has a 65C02.

I noticed one quirk. The command to format a CD card from the firmware menu is Control-F. The Replica 1 Propeller chip keyboard firmware (at least the one I am running) doesn't pass Control-F from the keyboard, so the command was not recognized. Using the serial port I was able to send Control-F. This is not a fault of the CFFA1. In fact it is trivial to map this to just "F" if you wanted to change the firmware (all the source code is included on CD).

I was also able to run the Cider Press program on Windows and access the SD cards through a USB reader.

CFFA1 Firmware Menu

A disk image for the CFFA1 called the "Ultimate Apple 1 software collection" was recently put together by nama_chari and reported on the Apple Fritter forums. It contains every piece of Apple 1 software he could find. It is a great way to get your hands on a lot of software and quickly load it up and try it. The image can currently be found here, although the location may change.

---

There are a few enhancements I would like to see to make the CFFA1 even better:

The CF format is pretty much obsolete. Newer formats are SD or micro SD. There are adaptors so that SD and micro SD can git in a CF slot, but if the hardware was refreshed it would be nice to use the smaller cards.

You can't use more than the first 32MB of the flash card. This a limitation of the ProDOS file system. It could support multiple 32MB volumes. In fact there are some hacks around to partially support this. 32 MB is a lot though. The archive of every known Apple 1 program is not even close to filling a 32MB drive.

You can't directly run programs from the menus, so you need to exit either to the Woz Mon or BASIC. It would be nice to be able to do this from the menus (maybe I will look at enhancing it to do this).

While it stores the load address and length of a program, it doesn't store the start address. For programs where the start address is not the load address, it is a pain because you need to remember the address. One option is to follow a convention of putting it in the filename.

It supports directories but currently only one level. It would be a nice enhancement to support multiple levels of directories but probably not very critical on an Apple 1 system.

I don't have an Apple II and don't have a need for ProDOS interoperability. I'd prefer to see the CD card use a standard FAT filesystem that I could read on a Mac, Windows, or Linux system.

---

There is integration with Applesoft Lite. It supports the CFFA1 card, if present, in it's SAVE and LOAD commands. I modified my port of Enhanced BASIC  to call the CFFA1 menu program when SAVE and LOAD commands are run. Better integration could be done in the future, i.e. passing a filename directly to the CFFA1 APIs.

I also added a command to my JMON machine language monitor program to call the CFFA1 menu, if a card is present.

In summary, the CFFA1 is a great accessory for the Replica 1 or Apple 1, and reduces the reliance on an external computer to load and save files.

Woz Mon

The Woz Monitor is the machine language monitor program written by Steve Wozniak for the Apple 1. It was burned into the 256 byte PROM in the original computer. It was and still is quite a functional monitor program, and he had two bytes of memory left to spare!

I noticed that the Woz Monitor in the Replica 1 does not quite match the published code for the original Apple 1. The reason is that the code is part of the Krusader assembler. It was slighly modified to support the mini monitor "!" command which can run Woz Monitor commands from the assembler. It also supports i/o for characters where bit 7 is not set. See the Krusader source code for details. I'm not sure why the IRQ/BRK vector was set to $0100 in the Replica 1 since Krusader points it to its minimonitor entry point. The original Apple 1 pointed it to address $0000.

The original Woz Mon code works fine on the Replica 1. The source code listing is widely available. It was included in the original Apple 1 Operation Manual and it is reproduced in the Replica 1 manual. Note that there is an error in the listing in the Replica 1 manual.

I have a version here which can be assembled with the CC65 assembler. The start address can be changed to run it out of RAM if desired.

Some people have extended the monitor with new functions, such as this one here.

I made a few recent updates to my JMON monitor program:

• Now prompts whether to continue when Verify detects mismatch or Search finds match.
• The Copy command will now accept source and destination addresses that overlap, copying the data up or down as needed.
• The Search and Fill commands now accept 16-bit (2 byte) patterns rather than 1. I hope to support both 1 and 2 byte patterns in the future.
• I updated the README.txt file to reflect the latest commands.
• The start address can be less than or equal to the end address in the Fill, Verify, Copy, and Search commands (previously it required that it was less).

---

I have a CFFA1 card  on it's way to me. I'm looking forward to it and will report on how it works here.

Corrections to Apple Basic User Manual

As I work with Apple BASIC I noticed a few errors and omissions on the manual. I wrote them down in the hope that they may be useful to someone else. Maybe Apple will issue a revised version :-)

The latest version can be found here but for convenience (and so it is searchable by Google) I'll paste my current version here.

---

This document lists some corrections to errors in the document "Preliminary Apple Basic Users Manual' October 1976. It also lists some notes on features that are non-obvious or of interest.

Title Page:

Note: The woodcut image of Sir Issac Newton sitting under an Apple Tree was the original Apple Computer Company Logo drawn by Ronald Wayne, the third employee of Apple.

Note: The address listed is no longer the headquarters of Apple Computer :-)

Second page:

Error: The word "likley" is misspelled (It is ironic that this is the page that says the manual may contain errors and asks users to send in corrections).

Page 1:

Note: An alternative way to get to the monitor from BASIC is to execute the command "CALL -256".

Page 2:

Note: The instructions for saving BASIC programs on tape assume LOMEM and HIMEM have their default values. If not, you need to adjust the command listed in step 3 accordingly.

Page 4:

Note: A quirk of Apple BASIC is that the number -32768, which is a valid 32 bit signed value, is not accepted. I don't think this was an oversight As Woz was an excellent programmer and had designed calculators in his career. I suspect it was to allow the the "*** >32767 ERR" message to be used for all overflow errors. We'll come across this issue later.

Page 6:

Error: Under point 3, if a string is not dimensioned it's length is taken to be one, not zero.

Page 7:

Error: The word "destingation" should be "destination" (in two places).

Page 8:

Note: Unlike expressions, string comparison using "<>" is not supported, only "#".

Page 10:

Error: The statement that changing LOMEM or HIMEM destroys the current user program is not correct. The program will still exist but may not run reliably. You should execute a SCR command before setting LOMEM or HIMEM. There is also no check that the values for LOMEM and HIMEM are valid.

Note: There is no way to suppress the question mark prompt in INPUT statements.

Page 12:

Note: The target of a GOTO or GOSUB can be an expression. This feature is not supported in most other versions of BASIC.

Note: In a remark statement like

10 REM A COMMENT : GOTO 100

Apple BASIC considers the whole line to be a comment.

Page 13:

Note: An error is reported if the last line executed in a program was not an END statement.

Note: Due to the quirk of not supporting the number -32768, you cannot use this address ($8000 in hex) with PEEK, POKE, or CALL.

Book Review: Beyond Games: Systems Software for your 6502

Title: "Beyond Games: Systems Software for your 6502"

Author: Ken Skier

Publisher: Byte Publications, 1981, 433 pages

This is a used book I purchased recently on ebay. There were many books on 6502 programming of this era but not many on tools to help writing and debugging programs, like machine language monitors and disassembler.

This book provides an introduction to 6502 machine and assembly language programming, and then quickly moves to specific programs, including:

• a "visible" machine language monitor
• two hex dump programs
• a disassembler
• a move utility
• a simple text editor

It describes the design of the programs and shows source code. In the appendices it provides complete assembler listings as well as binaries in the form of BASIC DATA statements than can be loaded into memory using a provided BASIC program.

The programs are mostly portable, and the author provides a set of interfaces or "data blocks" that adapt the code to run on the popular 6502-based systems of that era: the Ohio Scientific C-1P, Commodore PET 2001, Apple II, and Atari 800.

There is a brief chapter on each machine describing it's video memory layout.

I found it a very interesting and useful book, and intend to adapt some of the code to the Apple Replica 1.

Interestingly, the design of the table driven disassembler uses some of the same approaches that I used for the one I wrote recently.

Overall the code is clean, well documented, and clearly written. The author purposely avoided using tricks that would obscure the clarity of the code.

The book is long out of print but is available on sources for used books if you search hard enough for it.

Another BASIC Game

On Sunday I wrote a little Apple 1 BASIC program to generate horoscopes. Given your name and the date and location of your birth it generates a reading.

Is it scientific? No, in fact it hopefully demonstrates the Forer Effect .

Horoscope Program

I hope you find it amusing. You can download it from here.

Update on the 65816 to 6502 adaptor

I found a couple of forum threads (listed at the end) where the idea was discussed and plans were even made to build boards for Daryl Rictor's design but it wasn't clear that the design was ever tested. And the SMD version of the 65816 that the board used is apparently no longer available.

There was also discussion about the Ruud Baltissen design and reports that it worked for several people, although not on some systems which made use of some 6502 pins that it did not support. I don't think these limitations apply to the Replica 1.

I was thinking about assembler support and checked and confirmed that the CC65 assembler supports the 65816.

References:

1. http://forum.6502.org/viewtopic.php?f=4&t=186
2. http://www.macgui.com/usenet/?group=1&id=214542#msg

The 65816 CPU

The 65816  is a 16-bit processor that is an enhanced version of the 65C02.

It has software compatibility with the 65C02 (and hence 6502) as well as new registers, instructions, and addressing modes. Most notably it has 16-bit registers and the ability to address 24 bits (16 megabytes) of memory. It was used in some computers such as the Apple IIGS and the chip is still manufactured by Western Design Center.

The chip is not hardware compatible with the 65C02. There was a 65802 version of the processor that was pin-compatible with the 65C02. Unfortunately, these are no longer manufactured and hard to obtain.

The 65816 and 6502 have very similar pinouts. It would be cool if you could build an adaptor to put a 65816 in a 6502 socket. A web search reveals that some designs for such an adaptor are around.

This one by Daryl Rictor dates to 2004. It uses three chips plus the 65816. It even has a PCB layout. However, it comes with the caveat "I have not actually built or tested this design. Use it at your own risk." I'm doubtful that such a circuit would work the first time (no circuit of any complexity does).

A more promising design is this one  by Ruud Baltissen. He reports that he used it with a VIC-20 and it worked well. It only uses one chip in addition to the 65816.

I'm seriously thinking of building this circuit and trying it on a Replica 1. There are some limitations, like not being able to address more that 16 bits of memory, but it would be fun to try out the new instructions in the 65816. For example, there is a single instruction that can copy a range of memory. The 65816 (actually a W65C816S6PG-14) chip is under $10 from Mouser  so it's not a big investment to lose if it doesn't work.

JMON Enhanced for EEPROM

To accomodate the 16K memory card when using EEPROM, I added a write delay ("W") command to my JMON monitor program so that you can specify a delay after writes, which is needed when writing to EEPROM. It is used for the COPY, FILL, and TEST commands. Typically 28C64 EEPROM chips needs anywhere from 0.5 ms to 10 ms for a write to complete, depending on the chip manufacturer.

I used the delay routine from the Apple II ROM monitor, which is well documented in the book "Assembly Cookbook for the Apple II/IIe" by Don Lancaster.

With that change, I can copy data from RAM to the EEPROM or run the memory test on EEPROM from JMON.

JMON with New Write Delay Command

Below is a screen shot running my Replica 1 port of OSI BASIC. It is running out of an 8K EEPROM with a 8K RAM chip installed so the system has 40K of contiguous RAM.

OSI BASIC with 40K of Available Memory

16K Memory Board is Complete

The 16K memory board is assembled and works fine.  It has two sockets for 8K RAM, EPROM, or EEPROM chips, so you can add any combination of 16K RAM, 16K EPROM/EEPROM, or 8K RAM and 8K EPROM/EEPROM. The EEPROM is writeable but needs to be written with a delay after each write (approximately 1ms depending on the brand of chip used). There are jumpers for each chip to enable writing, so that the EEPROMs can be made read-only, if desired.

Memory Board Installed in Replica 1

I ran the memory test in my JMON monitor on the board stuffed with RAM to verify it.

Running Memory Test on 16K RAM 

So, for example, I could put Applesoft Lite or Enhanced BASIC in ROM (these are too big for the one 8K EEPROM on the Replica 1), or I could use RAM and bring the Replica 1 up to 48KB of contiguous RAM, twelve times what the original Apple 1 had (and then run really big programs).

I only used about half the protoboard, so I could add more circuitry to it later.

Wiring Side of Memory Board

I've put the design files here in case anyone wants to build their own or adapt the design for their own projects.

16K Memory Card Progress

I've now wired up most of the memory board for the Replica 1. I started with the address decoding and control lines and confirmed that it worked (e.g reading addresses in the correct range generated appropriate chip select signals as observed on an oscilloscope).

Testing Address Decoding

I then wired up the first of the two EEPROM/RAM sockets and confirmed that it is working, both with EEPROM and RAM chips. I now need to wire up the second memory chip socket.

Component Side

The wiring is rather tedious and time consuming. I might consider wirewrap for future projects, although the end result doesn't look as attractive with the big wirewrap pins sticking out of the back of the board.

Wiring Side

---

I'm also continuing to tweak the Apple 1 BASIC source, adding comments.

Source Code for Apple 1 BASIC

Eric Smith disassembled Apple 1 BASIC. This is the original Integer BASIC interpreter written by hand by Steve Wozniak for the Apple 1. It originally ran out of RAM and is in ROM in the Replica 1. It is 4K is size.

The disassembly was actually an assembler listing. I ripped out the listing part and made a few changes to get it to assemble with CC65. Then I compared it byte by byte to a dump of the BASIC in the Replica 1 ROM. There were a number of differences which I corrected. I now have source which can be assembled and produces the same code as the original BASIC.

I've only done a limited amount of testing so far but I am able to assemble it at a different address, (e.g. RAM) and it runs. I made a change to make the BASIC prompt a different character, and the new versions reflected that change, so that seemed to confirm that I was indeed running my version of BASIC.

The next step is to clean up the code to add and update some comments, give meaningful names to some variables and routines, and try making some changes.

The source code is here.

Odds and Ends

I noticed a bug in the disassembler function of my JMON machine language monitor program. The destination address of branch instructions was wrong. I tracked it down to a conflict of page zero locations that was introduced in the last version when I added the memory test command. I fixed it and updated the code on github.com.

---

The remaining parts for my 16K memory board arrived so I can finally start assembling it. I confirmed that the EEPROM chips work when installed in the Multi I/O board. I also confirmed that the pin-compatible RAM chips work in the Multi I/O board. Watch for updates here as I build the board.

---

I recently blogged here about my port of the 2KSA assembler. I should mention that there are some other resident assemblers for the Apple 1 that are superior. Krusader comes in ROM with the Replica 1 and is excellent. Another option is the A1-Assembler which comes in ROM if you are using the Achatz A-ONE Apple 1 clone, or you can load it into RAM. I spent some time playing with it tonight and it is quite good.

---

When writing the ZOOP program I wanted a more flexible input routine than the Apple 1 BASIC INPUT statement. It always displays a "?" prompt, for one thing. In the end I ended up using it, but it got me thinking about my earlier machine language input routine. It only supports reading characters at a time and returning them as numbers via a PEEK command. I'd like to extend it to return strings.

Unfortunately, I can't think of an easy way to do it. There is no way Ican find in Apple 1 BASIC to convert a number to a string (e.g. an equivalent to the CHR$() function in most BASICs). A possible approach is to find where the BASIC string is stored in memory and write to it. I spent a little time on this tonight but didn't get any where.

---

Speaking of Apple 1 BASIC, some people have disassembled it. An upcoming task I plan to do is to get a disassembly of it to assemble and run again, and then see if I can make a few changes.

---

While one person reported to be playing it, no one has reported successfully completing my adventure game. Come on guys, is it really that hard? I hereby offer a prize (details to be determined) to the first person to successfully complete the game.