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