RC2021/10 - The Beginning

This is my first post for RC2021/10.  Throughout the month I will be documenting the development of an Apple //e expansion card that I started working on in July.  I will also be working on the development of that card.  Lastly I will be finding a few previous RetroChallenge projects from the past and posting them on github.

Around 15 years ago I found an Apple //e on craigslist and bought it.  I had grown up with Apple ][ computers in my schools, and at one time even know how to use them, but all that knowledge was gone.  I booted it, and started up the one disk that came with the computer, was confused and put it all away after a few weeks or less.  Hoping to do something with the computer, I bought a bunch of books of of alibris.com for cheap.  One of them was "Hardware Interfacing with the Apple II Plus.

I've dabbled as a hobbyist in electronics for most of my life, and made a few simple PCBs, but I always wanted to work on a real hardware project for a computer and never had.  I looked at this book often enough, thinking it was my best shot at breaking through but I didn't really know how or where to start.  Then last July I found this...

The Apple II Breadboard Adapter.  I have breadboards, and logic probes, surely this would be a great way to start.  Then, the same day, while asking around about the breadboard adapter card, I found someone who was willing to send me one for free!  I waited for it to arrive in the mail and I started reading the Uffenbeck book in earnest.  To be honest I didn't make it past chapter four.  Once I learned about the DEVICE SELECT line (~DEVSEL which I'll discuss more about in a bit) I was too excited to keep reading and spent all of my time daydreaming about the endless possibilities of fulfilling my Apple ][ expansion card dreams.  A quick aside about having an Apple ][ enthusiast, who had never talked to me before, send me this card for free... Had I bought this card, I bet it'd be sitting in a drawer unused.  The fact that someone took the time to mail it to me, at their cost, really compelled me to make use of it and not waste their effort.  It was incredibly generous.

The Apple ][, ][+ and //e have 7 or 8 card slots.  Each slot has 50 pins.  Well Uffenbeck calls them pins.  It's a card edge connector, so what are they, pads?  Doesn't matter; sometimes I'll call them lines, sometimes pins, and even sometimes bits.  There are 16 address lines and 8 data lines.  It would be completely unreasonable for a card to watch 16 address lines in order to know that data is being written to or read from the address space reserved for that card.  And that's where the DEVICE SELECT line comes into play.

Just to take a step back: the idea of "writing to" and "reading from" the "address space" "reserved for the card" are each independent concepts that I really didn't know anything about going into this project.  I didn't know how an Apple ][ and an expansion card communicated.  Turns out, for most cards, there's really not much to it.  Each card has two little spaces in the memory map just for it to use.  One is 16 bytes and the other is 256 bytes.  The Apple ][ can peek (read) and poke (write) bytes of data into those addresses, and the card, if it's listening, can respond accordingly.  The fact that cards can be "talked to" using PEEK and POKE was important to me.  That meant I could use BASIC.  I had assumed I'd need to do assembly language.  I already felt like I was having to learn everything from first principles, so I was happy to avoid that hurdle for the time being.

So lets talk about the card's address space and that DEVICE SELECT line.  A card in slot 2 has 16 bytes that are reserved for it at address spaces 49312 to 49312+15.  In hex that's 0xc0a0 to 0xc0aF.  So of the 16 address bits, only the last four address bits are changing (0 to F).  But in order for a card to be aware that the Apple ][ is reading or writing to the card's 16 bytes, the card has to watch the higher 12 bits (0xc0a).  The DEVICE SELECT line is a single line that lets a card in slot 2 know that the current address is an address that starts with 0xc0a.  Voila!  Your card can watch DEVICE SELECT, and when it goes low, it knows that the Apple ][ is reading or writing to the card.

If you just wanted to toggle an LED, you could do it by connecting to only the DEVICE SELECT line and nothing else.  Any time a basic program PEEKED or POKED any of the card's address space, the DEVICE SELECT line would go low and you could toggle a flip flop.  Or, if you wanted to turn on or off 16 devices, you can watch the DEVICE SELECT line _and_ the lowest 4 address lines to get a 4 bit value for the thing you wanted to turn on or off.

Well that's it for now.  Next time the card arrives in the mail and I have to figure out what I'm going to do with it.

 

I am intending to participate in RetroChallenge 2021/10.  In order to register I need to submit a URL to a picture.  So I am posting this picture for that purpose.  While I am here, I guess I can mention that it is a photo of my current development setup.  I write ESP32 code on the black laptop.  I write AppleSoft BASIC code on the //e and //c using Beagle Bros "Program Writer".  The //e has the apple2idiot expansion card I designed in (slot 2, this is where the ESP32 lives).  I prefer the keyboard of the //c, so, I do big bouts of code writing and file management stuff on the on the //c and then swap the code over (via floppy disk) to the //e and run the software and fix bugs.  Ta!

Grackle68k v0.0.3ß

I'm off to London in the morning, so the Retrochallenge has come to a close for me. I did manage to get System 7.6 on my 3400c, w/ wifi, although I can't get Appletalk to work via the wavelan card.

I hoped to get more done with Grackle, but I didn't. Here's a version with the authentication bug fixed...

grackle68k_v0.0.3b.sit

New Toy

Quick update today. I've been using system 7 a lot lately, and decided I wanted something that would run system 7, compile code quickly, be portable, have a _real_ ethernet jack ... and ... run OS9 to facilitate Newton development and for modern things like pdfs, mp3s, and classilla. Eschewing research for impulse, I purchased a PowerBook 3400c with 144MB of memory and a wireless card.

It arrived yesterday, and I spent much of the day cooing at it, archiving the software on it, clean installing OS 9.1 and looking into how I'd get System 7 on it.

Today was spent dealing with a broken A/C unit with above 100 degree F temps outside.

Grackle68k v0.0.2ß

Here's Grackle68k v0.0.2 for you to download if you like...

Download Grackle68k v0.0.2ß

Features:

• You can post a Tweet.
• Small amount of sanity/error checking.
• Crashes less*
  

Todo:

• Save encoded username/password.
• Refine look and feel.
• Character limits.
• More error checking.
  
• Display tweets.
• etc etc etc
• DA version.
  

If you try it out, let me know if it works. The authentication code isn't well tested. You can post bug reports here, or send me an email. Let me know what model of Macintosh, system version and amount of memory you're using.

I've tested it with on a 2MB SE running system 6.0.5 and an LC475 running System 7.5.3.

I need some time away from this project. I feel like I should have a lot more to show for my efforts. The Macintosh Toolbox *and* pascal wear me out. However, I expect to keep working on it. It's a good excuse to keep pushing my classic mac programming skills and keep what little I have sharp.

* My previous TCP app mpc68k crashed a lot (always). Starting again from Peter Lewis's OOP TCP libs, this time I took the time to create my own objects, and pulling the address object out of the main TCP objects seems to have made things more modular and more stable. I also put some time into planning how to use both the OOP TCP libs and TransSkel. Theoretically development should be more rapid because of this.

So Close...

I have succesfully posted a tweet from a Mac SE running system 6.0.5 using a dialog to input the tweet, and Base64 encoding for the authentication. Woo.

How you ask?

I've spent an ungodly amount of time over the last 4 days working on a System 6, 68000 compatible twitter client. The application, called "Grackle68k", isn't ready, but I feel the need to post an update for you all. It's been a long weekend with many ups and downs. There was some serious head-on-desk moments. Writing software for modern systems is so much easier.

First of all, I may have written the most retarded Base64 encoding function ever created. One way to authenticate with Twitter is through the http header. Base64 encoding is used so that the username and password aren't plaintext when sent. Some day I'd like to document my hacky solution (it involves bit manipulation and storing binary numbers as a giant string of ones and zeros. Go on, shake your head in disbelief). For now, it works, and I'm more than fine with that.

Ah, before I forget... for the future me that forgets... I'm not positive, but it seems like 68000 macs need code segments that are under 32k. Otherwise they freak out. Try to keep that in mind.

I've been writing every line of code on an LC475 with 36 Megabytes of memory, running system 7.5.3, using an original Apple ADB keyboard. It's been a bit of an endurance run. I don't love the feel of the keyboard; it's very slow to type on. I miss having a scroll-wheel on my mouse. I miss editing with vim. I miss a high resolution screen. I miss alt-tab.

So that's about it. I set up a twitter account to test the client. You can see it here. It is a small record of my trials and tribulations, although I did purge many of them at one point. The official twitter link for the sofware is here.

I expect to release a beta version on Tuesday. I'll need help verifying that the authentication works.

Progress

MacTCP Progress

I finally got some System 6 compatible MacTCP code written in C to compile. So far it's just an MPW tool. I can stop and start music on my Linux box from inside MPW.

Tomorrow I'll have to get it into an app. Then make it useful.

So much effort to do what I can presently do easily with Pascal. Feels a bit silly, since I might just end up going back to pascal for this project, but I have a much better understanding of MacTCP now.

As a side note, I was able to compile Porter's Browser6 with Think C. Perhaps some day I'll be able to do something useful for that project. Maybe for the Winter WarmUp?

Coding

I spent some time yesterday trying to write an After Dark module, but had no success. I might try again later in the challenge. At the very least, I'll gather the resources I found together and post them. Perhaps someone else will have better luck.

Most of today was spent working on a TCP app. I hoped to write a TCP app using C. Either Think C or MPW, but as usual, I'm having problems geting it to work. Looks like I might go back to Think Pascal tomorrow.

4th of July Weekend

A Fourth of July weekend full of working in the morning followed by barbecues in the evening has conspired to derail me from the challenge, but not completely.

I have been reading the Inside Macintosh: Devices chapter on the ADB manager. I must admit, the idea of writing inits and device handlers is a bit intimidating, and I've yet to find much example source code to pillage.

I've also played a few games of MacSki on my LC475.

So in order to make up for little in the way of content to share, please enjoy these screen shots from After Dark: Flying Toasters, and my favorite, Doodles.

ADB Window Closing Button v0.1

What this project lacks in impressiveness, it makes up for in one-big-button-ness. The classic macintosh hasn't ever been called a hacker friendly platform. That's partially where the allure of doing something beyond software comes from.

This is my first step into the world of the Apple Desktop Bus. It's not a big step. The hardware is based on a pic microcontroller. Using Microchip's appnote (AN591), most of the work was already done for me. The appnote was originally for a pic 16C56, so I converted it to run off of a 16F84 since that's what I had on hand.

For the adb cable, I sacrificed a crappy third-party adb mouse.

When you press the button, the adb device sends "command-w" and that front most window bids you adieu...


... or does it? Good question. Some windows don't respond to command-w, so in order for this to be a proper window closer I would need to write a device handler for this adb device.

Source code and hex file are available here. The schematic is in the App Note pdf.

RetroChallenge Reference Library

In order to prepare for the challenge I've spent a bit of my beer money on some books. It's remarkable the used books that can be had for classic computers, costing next to nothing (several for $0.01 + S&H).

I cleared out a bit of space for my RetroChallenge reference library, and as the books come in they'll take their place of honor.

Several of these books I already had, but the newcomers are (going left to right on the bookshelf):

• Designing Cards and Drivers for the Macintosh II and Macintosh SE


• Macintosh Family Hardware Reference


• Guide to the Macintosh Family Hardware


• Technical Introduction To the Macintosh Family (2nd Edition)


• Inside Macintosh: Devices (Apple Technical Library)
  


• Complete Mactutor Mac Programming Journal Volume 2


• The Book of Scsi: A Guide for Adventurers

I'm still waiting on a couple of Macintosh assembly language books to arrive. If they don't show up, well then I'm bailed out of having to stumble down that path.

Waiting...

Retrochallenge begins July 1st 2009.

Going to Wisco

I'm heading to Wisconsin for the rest of the month. Not sure what I'm going to take with me or what I'll be able to get done if anything while I'm there. Over the last few days I've been heading in two directions...

One is newton programming. I've got the eMate out. UNNA has a great collection of Newton development tools, documentation and source code that is compiled onto a single HFS image. The NIE (Internet Enabler) pdf from Apple looks promising -- I'd like to write an mpd client for the newton -- but I think I might have to take it to a printer to get a hard-copy. It's too hard for me to digest large PDFs on a computer. Speaking of the Newton docs, I needed to find a pdf reader for OS9 and found Pure Mac, which has lots of versions of lots of things well organized.

The other thing I've been doing is playing many of the ascii games available on SDF, and in general exploring parts of the system I've ignored or overlooked in the past.

robotfindskitten 1.0.1

It might seem odd that you could write this game without implementing the arrow keys. Well I did, and it is. 1.0.1 now supports arrow keys!

rfk-mac68k-1.0.1.hqx
rfk-mac68k-1.0.1.img

robotfindskitten 1.0

Whew...

robotfindskitten-mac68k-1.0.hqx

robotfindskitten-mac68k-1.0.img

The disk image is a bootable 6.0.8 floppy suitable for vMac or BasilliskII.

Mostly I'm happy with it. The source code is included, but you can see the meat of it here if you just want to take a quick look.

There are a few issues. If anyone cares, I can fix them. No one will.

It's pretty fun. The 68k Macs can stand tall once again.

Robotfindskitten Update

Done

1. Movement
2. NKI Placement
3. Random Characters
4. Collision Detection
5. Kitten Detection

To Do

1. Import messages.
2. Display messages.
   
3. Win screen.
   
4. Introduction screen.
5. Color detection / colorize characters.
   
6. Macintosh niceties: icon, 'about', anything else?
   
7. Whatever else I'm forgetting.

Robotfindskitten Detour

It's not done, but I'm very excited about the progress I've made on my newest classic mac development project.

I first found robotfindskitten on my ipod Rockbox install. The game is almost too good to be true. Since then I've discovered that rfk has been ported to many systems, but not the classic Mac. Look at all those retro-systems represented and no 68k Mac.

Obviously all other projects go on hold.

What's interesting about this project to me is, the Macintosh doesn't lend itself to character-based programming as easily as DOS, C64, AppleII (etc) systems do, so I'm having to do a fair amount of extra work to get an ascii game working nicely.

What I've got done... so far I have a good engine (fingers crossed) for dynamically creating a grid based on screen resolution and character widths. A full screen window; leaving the menu bar.

TO DO:

1. Random placement of non-kitten items.
2. Robot movement and collision detection.
3. Import messages.
4. Win screen.
   
5. Introduction screen.
6. Macintosh niceties: icon, 'about', anything else?
   
7. Whatever else I'm forgetting.

MacTCP Programming

I spent several days fighting with MacTCP. I'm working on a full screen app that uses google weather to display current conditions and future conditions. Ultimately I'd like to create an internet "reader" that uses different XML APIs to gather and display info on the compact mac. I don't know how into it I am, but the Google weather will happen. Anyway, I spent many hours banging my head against the wall as I was fighting a not-always-reproducible-bug that was caused by a buffer overflow, incorrect LAN setup and prickly HTTP headers.

That's all sorted out, but I was hopping to at this point to have some simple XML parsing taken care of.

Also, I can't seem to take a screen shot of the full screen app when it's running. I'd like to show what I have. It's not very macintosh application "looking", and I've decided that style is just as important as function, so I'm not sure anyone else is going to ever want to use it. I guess you could say I'm giving into all of my design impulses which doesn't help any one else.

ZX Spectrum Assembly Programming Under Linux

There's been some Z80 activity on the BBS which sent me down - what I figured would be - a simple path... Write "Hello World" in Z80 assembler, assemble it and run it on an emulator.

The first place to start is the emulator. I installed spectemu (xspect) since it was available through debian's apt-get. It worked from the start; I didn't have to hunt down roms like other emulated platorms (68k, C64). If you're following along, at this point you should go download some existing Spectrum games and test everything out, make sure it works.

Next I installed z80asm and downloaded a simple assembly language program. Assembled it, loaded it into xspect and watched nothing happen. The output of z80asm is binary z80 machine code. The output of z80asm needs a piece of code added to the beginning of your binary file to get the Spectrum to load it. It also needs to be in a .tap file format. This code can be machine code, or basic. You don't have to understand, you just have to know it's required.

What to do? I was directed towards BIN2TAP and BIN2CODE on the SevenuP website. They have an .exe version for windows/dos, but also the c source code, which compiled fine with gcc. I have the files including compiled executables for linux x86 on my website here.

Many of the simple asm files I found for spectrum wouldn't assemble, or when if they did didn't work when run. I then thought to check the 99 bottles of beer website, and downloaded the Spectrum Z80 assembly version. It assembled without errors, and ran flawlessly. The 99 Bottles website is a great place to find a simple (but not too simple) program in almost any computer language you can think of, and it's often helpful when one needs a reminder after a few years away from a language.

Here's a link to the .tap and the .asm files of my Hello World app. Let it underwhelm you...

; Hello World in Z80 assembly language.
;  Assembles for ZX Spectrum
;
; Assembled/Tested under linux with the following tools...
; z80asm $@.asm ; utils/bin2tap a.bin $@.tap ; xspect $@.tap
;
; Author: Nathanial Hendler ; retards.org
; Adapted from Damien Guard's 99 Bottles of Beer on the wall...
; Adapted from the Alan deLespinasse's Intel 8086 version

org 32768

start:
ld      a, 2                  ; channel 2 = "S" for screen
call    $1601                 ; Select print channel using ROM

ld hl,line                    ; Print line
call printline
ret                        

printline:                     ; Routine to print out a line
ld a,(hl)                     ; Get character to print
cp '$'                        ; See if it '$' terminator
jp z,printend                 ; We're done if it is
rst 16                        ; Spectrum: Print the character in 'A'
inc hl                        ; Move onto the next character
jp printline                  ; Loop round

printend:
ret

; Data
line:    defb 'Hello, world.',13,'$'

Here's the bash script I use to assemble, convert to tape, and run the program; in case anyone cares (no error checking because I never make mistakes)...

#!/bin/sh -e
# Usage: ./makez80 hello

z80asm $@.asm ; utils/bin2tap a.bin $@.tap ; xspect $@.tap

Lastly, I found zxbasic on http://www.boriel.com/. It's a set of python scripts, and it includes one that assembles and outputs .tap files. It seems like an interesting suite of tools, and the fact that they're written in python makes them appealing for their hackability.