Tuesday, April 24, 2018
Wednesday, April 18, 2018
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:
- Unscrew and remove the base plate of the computer
- Unscrew and remove keyboard
- Unscrew a bunch of tiny screws to remove the circuit board form the keyboard
- Push the broken post out the back
- Push in the new post
- Continue hating how the keyboard feels
One repair completed!
Wednesday, April 11, 2018
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.
Monday, April 2, 2018
Tuesday, March 13, 2018
Tuesday, March 6, 2018
It is that time of year again, again! RetroChallenge!
My objectives, by priority:
- Organize my office with old computers and identify stuff to eliminate.
- Give away/sell computers that don't fit with my retrocomputing goals.
- Set up an imaging machine and get all of my 800K and 1.4M disks transferred to images on Zip Disks
- Sort through 400K disks
- Repair some damaged Apple II+ parts.
- Get ElWhip source code uploaded to GitHub.
- Test out an ESP32 (new version of ESP8266) as an internet modem / PPP server for old Macintoshes.
- Test out an ESP32 as virtual serial port for Apple II.
- Add SmartPort compatibility into a2usbdsk.
Thursday, January 11, 2018
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.
Tuesday, January 9, 2018
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.
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.
Thursday, January 4, 2018
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.
Monday, January 1, 2018
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:
- Port a2usbdsk to Raspberry Pi to run the FT232H adapter;
- 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.