a2usbdsk mostly working on Raspberry Pi!

After much experimenting, I figured out that an unusually low usb timeout setting was causing usb transfers to stall on the Raspberry Pi. After I raised that, I was able to easily load disk images! Unfortunately, Karateka does not work. During the boot sequence, Karateka does a very quick jump from track 7 to about track 27. It is cycling the Disk ][ phase lines very quickly to make this happen. Unfortunately, I don't think the Raspberry Pi Zero is currently able to sample the USB data fast enough to keep up. As a result, it is only jumping to track 15 or so. I was having a similar problem in earlier versions of a2usbdsk. I tried some tricks to speed things up, to no avail. But, good news is:

MOONPATROL!

So, as a proof of concept this is looking good. I should be able to move on to step 2 and get this running on the Raspberry Pi's native SPI port.

a2usbdsk not working on Raspberry Pi yet

Although my Apple IIe Platinum was not working correctly, I remembered that the color pattern I was seeing was actually a self-test mode that the Enhanced Apple IIe goes into without a keyboard connected. My keyboard was connected, but was also shattered and seriously damaged. Fortunately, another Apple IIe keyboard saved the day.

Unfortunately, a2usbdsk on the Raspberry Pi is not able to send data fast enough for the Apple IIe to read... yet. I have some code optimizations I need to test out which I think may help the situation. That said, even my old MacBook air was barely able to keep up. My newer 1.8 GHz dual-core Intel Core i5 MacBook Air seems to have no problem. I'll keep trying this weekend.

Update!

The Raspberry Pi is able to keep up! The problem is that the FT232H is stalling very often. I had this problem early on in the development of a2usbdsk on Mac OS X, but I worked around it by writing most of my own read/write loops and avoiding libmpsse for the most part. There must be some difference in how libusb or libftdi is handling the packets on the two operating systems. By frequently purging the buffers, I was able to get a disk to load! Need to find a better solution though. More testing should narrow down the problem.

a2usbdsk ported to Raspberry Pi

I was able to port a2usbdsk to the Raspberry Pi quite easily due to it being based on libusb and libftdi. Really, I just had to set up a makefile. I had some issues getting it to open the FT232H though. libmpsse does not return any errors when attempting to open an FTDI device. This makes troubleshooting very difficult and frustrating. After adding some logging, I determined that the libftdi function ftdi_usb_open_desc_index() was returning error code -8, "get product description failed". Getting the product description is a pretty simple function and that error was not appearing on Mac OS X, so it left me baffled for a while. In the end, the issue was that Raspberry Pi/Linux strictly controls who can access USB devices. "sudo" got it running, but setting up a udev rule seems to be a better solution.

I have not tested this with a real Apple II yet, as my Platinum Apple //e was pretty much destroyed in a recent car accident due to air bag deployment. The case is shattered, but it may still work. I'll try this weekend.

Raspberry Pi A2-SPI-DSK

I received my first Raspberry Pi in the mail today. It is a Raspberry Pi Zero W. I am excited to really try it out. I have it running, but I need to get a USB keyboard and mouse hooked up to get everything installed.

The Raspberry Pi is pretty neat hardware that bridges the gap between a micro controller and a full desktop computer. I have done some micro controller development, but never got really engaged with it. Development on the Raspberry Pi looks a little more my speed. At $10 for the Raspberry Pi Zero W, it is significantly more powerful and cheaper than the Mega AVR Arduinos and the necessary add-on cards. Most of the cool stuff is already built in to the Pi!

So, my hope was to port a2usbdsk to Raspberry Pi, so that people never have to use 5.25" disks again. I love the nostalgia, but they are cumbersome to use and ADTpro transfers to and from the Apple II are fairly slow. Don't get me wrong, ADTpro is a wonderful piece of software that I have used and quite a bit myself. But if you don't want to actually use disks to use disk images on your Apple II, it seems like the wrong solution, and a piece that is missing in (and could easily supplement) other packages like Ivan Drucker's RASPPLE II.

To pull this off, I am going to attempt it in 2 steps:

1. Port a2usbdsk to Raspberry Pi to run the FT232H adapter;
2. Create a new program a2spidsk to run on the native SPI ports on the Raspberry Pi.

I am very concerned that the Raspberry Pi may not be able to analyze the incoming data fast enough from the USB adapter. There is quite a bit of latency between transmissions to the disk drive that I was barely able to overcome on my MacBook. This puts a long gap between sectors which the Apple II is pretty good about ignoring, but it will eventually give an I/O error.

I am also concerned that the SPI buffer for the bcm2708 in the Raspberry Pi is quite small (12-120 bytes) which could make it difficult to output the bytes fast enough and with the regularity needed by the Disk ][ interface card. Since the Disk ][ interface card doesn't really understand SPI, we need very regular SPI clock transitions and data to keep synced up with the card in order to match up the synchronous SPI bus to the asynchronous Disk ][ interface card connection.

Demo Video of a2usbdsk in a Apple II build and deployment pipeline

The build pipeline is an update of Jeremy Rand’s Apple2BuildPipline based on Quinn Dunki’s project of the same name. Using this allowed me to stop reinventing the wheel and focus on finishing coding my a2usbdsk tool. Definitely check those projects!

Retro redux: a2usbdsk Release

RetroChallenge 2017/10 is way over and I got sidetracked about half-way through. Way too much IRL stuff got in the way. However, I have had a little bit of time recently to try and finish off my project. Upon reviewing my A2-SPI-DSK tool, I noticed some problems in my code. It was causing some serious issues with getting it to compile and work correctly. I guess that’s one of the issues with trying to write that much code in a month.

Anyway I’ve had some time recently to get things working, and completed the a2usbdsk v1.5 tool (Download). It now works perfectly to get a virtual disk to a real Apple II via USB. In addition, I added support for a second drive. I was so happy to see it boot a disk again! It is still read-only, but I have some ideas for that issue.

So, if you are developing Apple II software, you can write it in Xcode with cc65, then when you build it, just add a line to your makefile like: /usr/local/bin/a2usbdsk -1 $(PGM).dsk

This will mount the disk image and make it available to your Apple II over USB via the A2-USB-DSK. The A2-USB-DSK is easy to build using the schematics below and a CJMCU-232H FT232H module available on eBay for less than $10. Total build including the other ICs and a proto-board should be in the $20 range.

I created a branch of Jeremy Rand's Apple2BuildPipeline project to showcase how it works in a real project. Hopefully I can get a video up in the next few days.

DSKalyzer doubts

Hmm,I have been playing with DSKalyzer, and as great and as powerful as it appears to be for organizing your disk images, I don't think it can create a new one. That is sort of important for making a clean build for a new program. AppleCommander can do that nicely though. I may just stick with AppleCommander in my a2bdp Apple 2 build/deployment pipeline for now. It will make my project a little easier, too.

Some AII-SPI-USB problems resolved

I was having some serious issues getting my AII-SPI-USB command line tool (for transferring disk images to the UM232H) working on my newer MacBook. I tried rebuilding it, then rebuilding libftdi, and libusb, and libmpsse. I finally got things working and Xcode asked me to update my build settings. Then, of course, nothing would work again. The primary problem was "duplicate symbol" errors that were suddenly popping up. Some edits to libmpsse, and some changes to my code, and I finally was able to re-build it. I think I should staticly link the libraries I need for the tool, since most users won't have the will power to compile libftdi, or libusb to use it.

I need a new name for the program too. AII-SPI-USB is not a very posixy name for a command line tool. Maybe a2usbdsk.

It's ironic that one of the benefits of programming for retro computers is that the hardware or operating systems almost never change. Do it once, and it works forever! Not so for modern hardware, even the modern hardware interacting with the retro computer.

More AII-SPI-DSK problems

Found my AII-SPI-DSK adapter on the breadboard. Unfortunately, the counter was harvested off of it for some other project. Now I need to track down a 74LS161 ic...

AII-SPI-DSK problems

I downloaded my AII-SPI-DSK program and tried to get it running without success. First FTDI library version errors, then a file not found error. I need to get the adapter out and try again. Unfortunately, it is packed away since I am moving this month. But I think I should be able to dig it out today.

Trying Existing Virtual Build Pipeline

To get started building an Apple II program, I used some existing resources to make sure my installation of cc65 compiler is configured correctly. Two resources:

• Mac GUI: Compiling Apple II Programs in C with cc65 and Mac OS X
• BlondieHacks: Apple ][ Development on OS X

The BLONDIEHACKS web site conveniently provides an example Apple II build Xcode project to start from. Unfortunately, I had some build errors. The solution is to edit the example's Makefile to specify cc65 assembly configuration: @PATH=$(PATH):/usr/local/bin; $(CL65) -t apple2enh -C apple2enh-asm.cfg -l$(PGM).lst --start-addr $(ADDR) $(PGM).s

Yay! Seizure inducing flashing X's in Virtual II Apple II emulator (the example code is really supposed to do that).

So, the example build process now works with an emulator. Now to incorporate DSKalyzer and a real Apple II.

A2BP .011

Minor update. It is pretty cool to watch this thing run from a clean install. Lots of scrolling text!

• adds help, clean
• sets apple2 as the default system for cc65 samples
• more variables

make is very picky about white spaces. If you copy from browser, it may convert the tabs to multiple spaces. I will set up a download link, once I am happy with everything. # # Makefile # A2BP .011 # # This downloads and installs the pieces for the A2BP # toolchain, build pipeline, and deployment pipeline # for the Apple II on OSX. # # Created by Eric Pooch on 10/05/17. # https://apple-crapple.blogspot.com # # Usage: # make all # sudo make install # PGM=a2bp help : $(info Instructions: Place makefile in a folder with no spaces in path.) $(info then type:) $(info make all) $(info [packages will be downloaded, expanded, and compiled]) $(info sudo make install) $(info [packages will be installed, overwriting existing]) $(PGM) : cc65 dskalyzer USB_AII_Disk_Emulator install-$(PGM) : cc65 dskalyzer USB_AII_Disk_Emulator make --directory=cc65 install MAKE="make PREFIX=/usr/local SYS=apple2" ditto dskalyzer /usr/local/bin/ ditto USB_AII_Disk_Emulator/AII-SPI-DSK /usr/local/bin/ USB_AII_Disk_Emulator.tgz : curl -L -O https://sites.google.com/site/maclcdproc/downloads/USB_AII_Disk_Emulator.tgz USB_AII_Disk_Emulator : USB_AII_Disk_Emulator.tgz tar zxvf USB_AII_Disk_Emulator.tgz dskalyzer-macos-amd64.zip : curl -L -O https://github.com/paleotronic/dskalyzer/releases/download/v0.1.3/dskalyzer-macos-amd64.zip dskalyzer : dskalyzer-macos-amd64.zip tar zxvf dskalyzer-macos-amd64.zip # dskalyzer is older than the archive, so update touch dskalyzer cc65 : git clone https://github.com/cc65/cc65.git make all --directory=cc65 all: $(PGM) install: install-$(PGM) clean: rm -rf cc65 rm -f dskalyzer-macos-amd64.zip rm -f dskalyzer rm -f LICENSE rm -f *md rm -f USB_AII_Disk_Emulator.tgz rm -rf USB_AII_Disk_Emulator So, now that I built my build/deployment environment. It's time to write a program!

A2BP - The OSX to Apple II build and deployment pipeline

I spent some time last night getting all of the pieces assembled for my OSX to Apple II toolchain and build / deployment pipeline ("A2BP"). The plan is to cross-compile using Xcode and cc65, send to disk image using dskalyzer, then load the disk image and transfer to the Apple II using my USB_AII_Disk_Emulator. ANSI C code to running on Apple II hardware with the press of a button! My initial thought was to create a makefile for my first "Hello World" program. But I thought it would be helpful to create a make file for A2BP first. I'm sure that I am grossly abusing make with this thing, but it is pretty helpful. So, here is my first shot at it, after the break:

RetroChallenge 2017/10 Entry

I have so many projects in my head, but I haven't had any time to work on them lately. I have a lot of IRL stuff going on, so I want to keep my RetroChallenge entry very simple. I have wanted to get the 6502 cross-assembler cc65 up and running on my MacBook so I can do some Apple II programming in ANSI C. But, I would really like to get a great build pipe-line up and running before I really start programming. BlondieHacks has a good build pipeline that I can use as a starting point. But I want to make some modifications to better suit my needs:

• Use the recently released DSKalyzer as my disk image creation tool, rather than AppleCommander.
• Use my own USB to SPI to Disk II adapter to immediately test my builds on real hardware.

This should allow me to test any software on real hardware as part of the makefile build process. So, goals are:

1. Set up automatic build and deployment pipeline from Mac OSX to real Apple II hardware.
2. "Hello World" on Apple II

Disk II Drive to USB Adapter

My CJMCU FT232H Module arrived today! Less than $10 for a FTDI FT232H break-out board / USB to SPI adapter. Really excited as it makes my AII-SPI-DSK even cheaper. In addition, I started thinking about an adapter that will allow me to rip Apple II disks right from a Disk II 5.25" drive! I haven't tested anything yet, but it should be fairly easy to implement. It is basically backwards data flow from my previous adapter.

RetroChallenge Epilogue and Apparent Success

After Review of my plan and schematics, I noticed a small error in the Eagle schematic I posted earlier.

1. Pin 11 of the socket must be connected high (or to pin 12, or to a soft switch to enable video scanning on row E of RAM).
2. Pin 11 of IC F2 must be disconnected and that line (not the IC pin) must be connected to ground instead (See my hand-drawn schematic).

I figured out problem 1 first. But when I booted I received half of a startup beep repeatedly, like it was stuck. It took a while until I realized I forgot Problem 2 since it was only on my older schematic. I used an IC socket and connected pin 11 and 12 and raised the IC leg. This is important as it decodes whether the Apple II is in RAM or I/O mode. The computer was stuck with no access to I/O or ROM (or simultaneous access to RAM and I/O or ROM).

F2 IC with pin 11 sticking out in a socket with pin 11, 12 connected

It boots!

It seems to have worked! The computer shows the APPLE ][ greeting just as expected. I need to connect a keyboard and a disk controller card to test it all out and verify that all 48K is being accessed.

So, I now have an Apple II with 48K of 4164 DRAM in just one bank of RAM. Now for 64K. Or 128K...

2 banks of RAM installed for future 128K modifications

Final Push and Failure

I ran jumpers wires on the back of the Apple II+ logic board to route the various signals I needed (PHI_0, AX, A14&A15) to the J1 socket area. Fortunately since only half of J1 is used by the Apple II+, I can use the unused pins of that socket to route my signals through to the new circuit I am adding.

Here is my circuit diagram:

and the adapter board:

Warning - I don't know if this works yet.

After I ran the wires, I started trying to solder a tiny adapter board to translate the 74LS257 signal locations to the new 74LS153 IC. That was taking too much time for something that might not work at all, so I put the circuit on a bread board. Here it is:

Unfortunately, this did not work. I suspect that the dip jumper cable may be too long and adding some capacitance or delay. Or, the RAM timing may have been thrown off by the internal logic of the new IC. My Apple II+ is not booting and is in a similar state to when the RAM was in the wrong row. I'm sure I would have figured this out, but Halloween took priority.

Better news is that my Apple IIb is in a pretty final state. I think I will start buying supplies to actually build it.

Until next time, RetroChallenge!

Apple II+ 64K RAM Refresh and Addressing

I managed to add my modifications back to the Apple II logic board to get the 4164 RAM enabled. It seems to be working! However, I want to address all 64K of the RAM, not just 16K. To do that, I need to refresh the extra RAM rows, multiplex the RAM row and column address for the new RAM address pin, and make sure that row C of RAM stays enabled instead of selecting row C, D, or E. See the detailed plan of attack by clicking below.

Troubleshooting Frustrations

I spent a number of hours last night and tonight trying to figure out why my modified Apple II+ was not beeping, and instead showing a screen full of question marks (or sometimes a white screen) on start-up, even after I added a row of 4264 DRAM. I swapped all of the ICs back and forth with my functioning Apple II+ and still had the same problem. At that point, I realized that I should have done some basic testing before I modified the logic board. I removed my modifications, and still had the same problem.

I found out that I could get very similar symptoms on my working Apple II+ if I removed the F2 74LS139 decoder, which selects which RAM bank to use. So I started checking continuity on my non-working board. I discovered that here wasn't continuity between the low bank selection line and the row that I had my RAM in. I thought I had found a major fault in the board. Then it hit me. The apple II+ rows are labeled A through K, and start with A on the bottom ROW. I had put my RAM in row E (the high address bank), instead of row C (the low address bank). I moved the RAM chips and after swapping out a bad chip, BEEP, and APPLE ][ at the top of the screen.

I felt so dumb. Hours wasted. So now I'm re-doing my modifications. Still time for some progress tonight. At least it's working. That logic board has't been fully functional in probably 30 years.

Apple II+ RAM Replacement - Power

Replacing the RAM in my Apple II+ has become a bit of a project in and of itself. Sure I could just buy some 4116 (16K bit) DRAM, but that's not very exciting, and its not an upgrade. So, Instead, I have been figuring out how I can use 4264 (64K bit) DRAM in its place. There are a lot of considerations that need to be made including power, refresh circuit, and addressing the new RAM. The descriptions below are for an RFI Revision 01 board, and may be different for other revisions. Click below to see the details of re-routing the RAM power lines and my preliminary results.