Of course, it took forever to route all of the wires by trial and error. Anyway, it's done (other than the step buttons), and it seems like it will work... but I need to get some decals so I know what key I am typing!
...and the SuperProto card finally arrived this weekend, just in time!
Check out all of my RetroChallenge 2019/03 posts and updates.
 |
| Growing collection of Apple II and KIM-1 prototyping parts. |
I have been working on a internet modem for the ESP32 that can be used with a wide variety of computers, some more retro than others. Here are some expected use cases:
Basically, since the ESP32 is so cheap, it is much more affordable than a dedicated Raspberry Pi + interface card. One of the big issues is connecting to the modern web with SSL and complicated web pages. Although connecting to a computer running Lynx is certainly feasible, I was looking for something more lightweight. So, here is a sample of some of the applications:
Above is a screen shot of Virtual ][ (an Apple II emulator) running DCOM 3.3 (a VT100 terminal emulator) connected the esp32 contiki webbrowser. This setup can be used to connect an Apple II to the internet.
And this is the same browser running in the Mac terminal. In the lower right, you can see the Mac has a terminal window that is connected to the ESP32 and showing a https secure web page. The HTML is parsed by the Contiki webbrowser, which I modified to use the ESP32 web client that includes SSL encryption. The ANSI/VT100 colors are added by my Contiki console i/o module that detects the VT terminal type.
For computers with TCP/IP stacks, but no ethernet card, use the PPPD command, making a serial TCP/IP connection, so all your existing internet programs will work:
Of course, since it uses the standard ESP32 AT commands, you can do all the normal connections to telnet-based BBSs.
Some of the code is on my GitHub page, with more to come!
sudo curl -L https://github.com/datajerk/c2t/raw/master/bin/c2t >/usr/local/bin/c2t sudo chmod 755 /usr/local/bin/c2t
Apple ROM files are fairly easy to find. Once the archive is downloaded to your Downloads folder, extract the files and convert to audio using the Terminal commands:
open ~/Downloads/APPLE+II+ROMS.zip
cd ~/Downloads/APPLE\ II\ ROMS/APPLE\ II+/
c2t -2 APPLE\ II+\ -\ LOWERCASE\ CHARACTER\ GENERATOR\ -\ 2716.bin,8000 ~/Downloads/LOWERCASE_ROM.aif
This creates an audio file in your Downloads folder named "LOWERCASE_ROM.aif", which can be used to transfer the ROM data to your Apple II. This audio file is available for download, if you want to skip installing c2t.
The Apple SSC manual documents how to modify the card to accept an SRAM chip, which is compatible with the pinout of a 28C16 EEPROM. I have a clone of the SSC which is slightly different and will allow me to easily enable and disable this function.
First, I removed the ROM (the lower big chip) so I didn't accidentally damage it. Then, I cut the traces that link the some of the vias in the center of the card, and removed the solder in the vias.
These vias correspond to the bow-ties and solder pads on the SSC card. I soldered in gold and silver double row header pins so I can easily see which pins should be jumped at the same time.
If you have an SSC, card just cut the bowties and solder across the jumper pads, according to the instructions in the manual. Note that you will have to undo this modification to use the original SSC ROM
With the pins soldered in, I can use jumpers to configure the card for the original ROM, for EEPROM, and to set the write enable separately for the EEPROM (black jumper cap).
Now, install the 28C16 EEPROM into the ROM location (double check the orientation of the EEPROM chip!) and insert the card into slot 2 of the Apple II.
It would be really simple if we could just transfer the audio data directly into the memory locations of the EEPROM. Unfortunately, I was unable to do this. I believe that the EEPROM needs more time to write than is given to it by the Apple II Monitor, so maybe the faster AT28C16E would work better for direct writing. I could only successfully write about 16 bytes at a time reading audio or copying directly to the AT28C16.
Instead, we will copy to the Apple II memory, then slowly POKE it into the EEPROM using AppleSoft BASIC. On the Apple II, assuming 64K of RAM:
] CALL -151 * 8000.87FFR
Play the LOWERCASE_ROM.aif file on your Mac. When it is loaded, you should hear a beep on the Apple II, and get another * prompt.
At this point, you could try directly copying to the EEPROM by:
* CFFF * C200 * C800<8000.86FFM * C200<8700.87FFMBut, I received errors when verifying:
* C200<8700.87FFV
So, if that doesn't work, let's load an AppleSoft BASIC program to get the data into the EEPROM. To load it, return to BASIC by hitting:
<CTRL><RESET>Enter the BASIC command:
] LOADThen use the Mac to download and play the audio file for the ROM transfer BASIC program or, skip the LOAD command and enter it by hand:
5 REM ?"TRANSFER BIN FROM $8000 TO SSC CARD" 10 S = 2 : REM ?"SLOT 2, DO NOT USE 0, 1, 3" 20 LM = 49152 + (S*256) : REM ?"SLOT IOSEL" 30 HM = 51200 : REM ?"$C800" 40 ST = 32768 : REM ?"$8000" 50 X=PEEK(53247) : REM ?"$CFFF" 60 X=PEEK(LM) : REM ?"ENABLE HM" 70 BL = 1792 : REM ?"IOSEL SIZE" 80 LM=LM-BL 100 FOR X= 0 TO 2047 110 V= PEEK(ST+X) 120 IF X < BL THEN EA = (HM+X) : GOTO 140 130 EA = (LM+X) 140 POKE EA,V 150 ? EA; ": ";V 160 NEXT X 170 ? "TRANSFERRED ";X;" BYTES" 200 ENDAfter the beeps, run the loaded BASIC program:
] RUNThis will slowly write the data you previously stored in the $8000 memory range to the I/O shared $C800.$CEFF range, and the slot 2 $C200.$C2FF range. The process should take less than 2 minutes (1 min 45 secs). You can edit the BASIC program to change slots if you need to, but don't use slot 1 on any Apple, or slot 3 on an Apple //e, as the IOSEL area we are using is not normally addressable in those slots.
Once the program runs, turn off the Apple II, remove the EEPROM and insert it into the "ROM_SPCL" location at the bottom of the logic board (double check the orientation of the EEPROM chip!). You will normally have to disassemble the computer case to reach down there.
I integrated the 4164 DRAM decoder wiring into the logic board this weekend. It was very difficult to troubleshoot, and on retrospect, I think an adapter board would have been easier and less problematic. The main hangup was that the A14 signal to pin 10 of the J1 socket is connected on both sides of the logic board. One side in from expansion slot 7, and the other side goes out to H1 socket which creates the (A14&A15) signal. I had routed the (A14&A15) back to the J1 socket to decode the upper 16K of RAM. After disconnecting the A14 line from pin 10 and re-connecting pin 10 to a new video decoder signal (HIRES&PAGE2), the video decoder signal was getting sent through to H1 to give (HIRES&PAGE2&A15), which is wrong and caused computer to not be able to access the ROM.
Anyway, I fixed the problems and 74ls153 now sits in the J1 socket like it was always supposed to be there. The signals to decode the upper 16K of memory in the 4164 DRAMs are now available. I need to build circuit with registers to set to enable the upper bank and bank switch the 4K that overlaps the I/O area of the Apple II+. It will basically be 1/2 of an Apple 16K RAM/Language card.
I spent some time working on my Wimos Lolin ESP32 this weekend. I recently wrote up a simple how-to about the ESP32 device on my other blog. Since I am pretty familiar with lwIP and PPP based on my work on the Macintosh 128k webserver, I also previously contributed a small amount of code to enable the PPP server in the lwip network stack that the ESP32 uses. But, without an interface to access the PPP server code, it was useless. So, I decided to integrate access to the PPP server into the ESP32's standard AT command interpreter. With a small amount of code, I think I have it working! My MacBook can connect to itself using PPP now. I need to get one of my classic macs set up to further test the connection. I should get code posted in the next few days.
Update!
During my recent move, one of my Apple II+ computers didn't fare so well and broke 2 key posts. I really don't like the keyboard in this particular computer: it sticks, it often misses key strokes, and the feel is not very good. I didn't know how different the keyboard was until I took it apart and found... no Alps key switches! But, since Apple II+ keyboards are not cheap, I paid a few bucks for replacement key posts instead of replacing the keyboard. Process:
One repair completed!
 |
| Weird spring / contact matrix |
 |
| I tried to repair the posts, and the one on the left worked OK, but I ended up replacing both of them. |
 |
| 6 and T are fixed! |
I spent last week working on a sketch of what it would look like and this past weekend doing some construction:
 |
| RetroLoft - Desk Area SketchUp |
 |
| RetroLoft - SketchUp |
 |
| RetroLoft - Before |
 |
| RetroLoft - During |
 |
| RetroLoft - Desk Area |
I installed a hand rail, moved the storage shelves over, installed a desk support, and more storage shelves. I used some old shelf standards I had on-hand and discovered that shelf standards are not 'standard'. The two sets had slots that were not quite aligned the same way. I still need to install the desk surface (an old interior slab door), then run a new power line, and set up some old computers. Its a little warm up there, but a large fan in the garage keeps the air moving now.
It is that time of year again, again! RetroChallenge!
My objectives, by priority:
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:
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.
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.
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.
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:
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.
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.
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.
@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.
#
# 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!
I haven't tested anything yet, but it should be fairly easy to implement. It is basically backwards data flow from my previous adapter.
 |
 |
| 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 |
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!
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.
Here are the two Apple II+ logic boards that I have for repair. They were mostly stripped of integrated circuit chips, and even have some ports and connectors that were de-soldered to repair other boards (back in the 1980's).
I chose to repair the board on the left due to the missing D6 RAM socket on the other board and a possible damaged trace under the F8 ROM.
I swapped the power connector and added a missing audio jack. These are still available on eBay as "panel mount mono jack":
A word of caution. I have found that the solder on these old boards has the potential to make you feel sick and hung-over. Drink some milk before you solder and work in a very well-ventilated area.
I was able to replace most of the missing IC on the board from the box of spares I had, and from the other board. I have no idea if they work, so that will probably require a lot of troubleshooting.
The only IC I could not replace from old pulls was the one labeled "9334" in the J14 position. Fortunately, this IC can be replaced by a 74LS259, which I had on hand from my early experiments with my SPI based Disk II emulator.
Finally, I did not want to have to troubleshoot with old, possibly bad RAM, so I have some 64K 4264 DRAM chips on hand to see if I can replace the original 16K 4116 chips. This will require some modifications to the logic board (due to the different power requirements and slightly different pinouts), which I hope I can complete before the end of RetroChallenge.
 |
The parts donor Apple II+ I am trying to repair is really a mess. Even the rubber feet were harvested for another computer. Fortunately, I found some decent rubber feet on eBay. I bought two packs of 12 20mmx20mmx8mm and it is a great replacement part for Disk II and Apple II feet. |
 |
|
| Composite video works | and RGB works! |
 |
| Trace repairs and new SMT resistors in R193 and R14 locations. |
 |
| Trace repairs and new battery holder. |
 |
| Copper Tape, UV cure Solder Mask, and a weird spatula thing. |
I have an old, un-enhanced Apple IIe that that would give me errors while trying to load disks, like: UNABLE TO LOAD PRODOS or NO BUFFERS AVAILABLE . Now that I know a lot more about the Apple IIe (and electronics in general) than when I put it in mothballs, I tried my hand at fixing the problem again.
I recently learned that by holding down the closed (filled) apple, while turning on the un-enhanced Apple IIe, it will do a self diagnosis. Here were the results:
RAM: F13 F12 F11 F10 F9 F8 F7 F6
This indicates that every built-in RAM chip was bad (or that the unenhanced Apple IIe can not distinguish which chip is bad). I didn't quite believe this could be true, so I tried replacing some of the ICs around the RAM... to no effect. So, I splurged on an ebay auction for a set of "MICRON MT4264-10 64K 100NS DRAM". I replaced all of the RAM chips, and my un-enhanced Apple IIe sprang to life for the first time in 25 years! As it turned out, only 2 of the RAM chips were bad, but they both failed in a way that would cause the self-diagnosis to report that all of the RAM was bad. Anyway, based on my machine having 2 chips that failed in the same way, I think it must be a relatively common problem.
Now all this thing needs is a "V" key and a replacement key switch. I think the V key is around here somewhere...