Return of the geoJunky

Despite having had copies of the software forever, it wasn't until the early 1990s that I became a true convert to the cult of GEOS.

I picked up every accessory, every productivity package, every Thing I could get my hands on that was related to this Mac-like GUI for the Commodore 64 and 128.  And this included geoProgrammer, the official symbolic macro assembler, linker, and debugging package from BSW.

Code is written for geoProgrammer using the stock GEOS word processor, called geoWrite.  This has the fun side-effect of not only allowing image assets to be integrated into the source code document, but also allows you to use all the fonts and styles and margins to make your code as beautiful as possible.

So armed, I spent the 90s and early 2000s writing numerous applications for GEOS.  You can find information about most of them on my geoProjects page.  However, my geoCoding spree pretty much came to an end in 2002 ..... until very recently.

The C64Net WiFi modem, which I've blogged about to the point of exhaustion at this point, inspired not only my 8-bit programming in general, but got me back into GEOS programming in particular.

In 2017 I wrote an 80 column ansi terminal program called geoTelnet, which I've also mentioned in previous posts before, but you can find more information about it here.

In early 2018, not long after its release, I got asked to do a color PETSCII terminal program for enjoying online BBSes from GEOS.  I figured this would be a pretty easy slam dunk, since the hardest problem, rs232 communication in GEOS, was already solved.

However, as engineers are wont to do, I decided I needed to re-architect things.  You see, geoTelnet was a VLIR application, so it theoretically could grow naturally with new swapped-in code modules.  However, it was only designed for two modules:  a GEOS 64 module with all features, and a GEOS 128 module with all features.  This left things rather squeezed, with no room for, for example, more transfer protocols or a settings screen.

This created a slew of linking issues, since the code sections for the features were already pretty integrated with each other, and weren't expecting to be separated from each other.  However, that was a straight-forward problem.  What really frustrated me for several days as I started migrating to the new architecture was hard system crashes whenever text was printed on the screen.  My interest soon waned, and a year went by when I gave no thought to it.

Then, in early 2020, on a whim, I decided to pick it back up and see if I couldn't find that bug.  And find it I did, almost immediately (it was pretty stupid).  I was so excited that I spent the entire rest of the day hacking away on my PETSCII renderer. 

To test it, the next feature I tackled was getting the Buffering system working again.  This would allow me to load PETSCII files from disk for testing.  I then generated the above test pattern in Commodore BASIC, saved it, loaded it into my program, and eventually got it to what you see above.

The first time I saw true online PETSCII art rendered correctly on the screen, I was ecstatic.  I was able to borrow from the code written for ANSI and Telnet codes to implement the cursor and other special PETSCII codes.

The last unique feature to put in place is the ability to actually input PETSCII codes from the keyboard.  Things like color codes, special graphics characters, and the ability to toggle between the two font modes (lower/upper and upper/graphics).  Surprisingly, this turned out to be trickier than I thought.

You see, the GEOS kernel doesn't care about many of the keys on the keyboard, so they simply don't scan them.  And since they don't scan them, they aren't available as keystroke events for my terminal program to act upon.  This led to me having to learn how the standard Commodore KERNAL actually accomplishes the feat, so that it can be replicated in my application.  Turns out it's not too bad -- you consult an 8x8 matrix of all possible keys, tell the 6526 CIA to pull one of the rows, and then read back an 8-bit bitmap, which tells you which, if any, keys on that row are being pressed.

Once that was done, fixing the remaining features was pretty much a down-hill process.  The phonebook, terminal options, desk accessories, and x-modem worked pretty much the same as they did in geoTelnet.   X-Modem uploads did give me a little trouble, due to the fact that serial communication must be de-activated to swap modules, causing it to "miss" the handshake character from the remote side.  This was quickly figured out though.

I'm not sure what's next at this point.  I'd considered fulfilling the promise of the re-architecteing by not only adding new transfer protocols, but by actually integrating the ascii and ansi features of geoTelnet back into this program, to create one large full-featured terminal.  Though, I might also venture into other areas -- geoFTP, geoIRC, geoETC...

We'll see.

Attack of the Mouse Clones

In 1985 Commodore brought the Amiga into the world, with its amazing GUI interface, which required a mouse.  Also at this time, the GEOS GUI operating system was becoming quite popular for the Commodore 8-bit line of computers, such as the C64 and the brand new Commodore 128, and it also could benefit from a mouse.

The control ports that mice plugged into were not identical between the Amiga and C64/C128 line, so necessarily their mice would not be compatible with each other.  However, since both the Commodore 128 and the Amiga (1000) had identical case colors, it was reasonable to produce mice that matched each other in color at least.  What was NOT reasonable, however, was to produce mice that were completely IDENTICAL from the outside, while remaining incompatible with each other. 

Oh, and also, there weren't just two of them, but three functionally different mice in the exact same case:

Let me introduce you to the Commodore 1350, Commodore 1351, and the Commodore 1352, also known as the Amiga "Tank" Mouse.

Released around Sep of 1985, the 1350 is the most odd of the three mice, as it's really a directional (non-proportional) Joystick stuck in a mouse case.  It works with both the C64/C128 and the Amiga, but only as a joystick, and not as a very good one, since a mouse is a terrible way to persist directional movement.

In March/April of 1987, the 1351 mouse was released.  This is a true proportional mouse for the Commodore 64 and 128, and it works very well for that purpose.  GEOS was greatly enhanced by this product, and its design earned Commodore some sort of patent!  The 1351 is also special in the fact that it can emulate the 1350 as a joystick by holding down the right button on boot.

In November of 1985, the Amiga became available for purchase, and that's when we first saw the Amiga "Tank" mouse in its original form.  It wasn't until 1988, however, that it was marketed to Commodore PC users as the 1352.  Like the 1351, it is a good and proper proportional mouse for Amigas and Commodore brand PCs.  It is not compatible with PC "serial" mice, however.

The big question: 
If you get handed one of these things, how do you tell them apart?

Well, let's start with the easiest thing to check:  as you can tell by the picture above, they are absolutely identical from the top, so that's not the answer.

What about the cable ends?  Since all three have different pinouts, perhaps the connector is different:

Here you can see two kinds of connectors pictured: A pair of fat-but-shorter connectors on the right, and a longer-thinner connector on the left.  All three of those are from Commodore 1351 mice.  So-- not entirely helpful.  Amiga mice tended to have the long-thin connectors, and the 1350 tended to have the short-fat connector, but as you can see, the 1351 could have either.

While the above is disappointing, there is ONE connector that is a dead giveaway:

The original Amiga 1000 mouse had a large angled connector designed to fit snugly into the side connector of the Amiga case.  When you see one of these connectors, you can be sure you are looking at an Amiga mouse.

OK, so what about the bottom labels?  Surely Commodore put the model information on the bottom!  Heck, we should have looked there first, so let's take a look:

Except for the odd 1351, and the giant AMIGA letters on a few A1000 mice (not pictured), there is no model information.  Believe it or not, however, there are at least some patterns.  You see, the top row are all 1350s, the middle are 1351s, and the bottom are Amiga mice.

Amiga mice seem to usually have similar looking bottom labels, even if there isn't any model information.  They have those dark bold black letterings, the C= commodore lowercase logo, and a serial number beginning either with an A or B.   However, there are exceptions to this as well. Pictured above is an Amiga 1000 mouse, with a lighter colored labeled and serial beginning with TM.  Such labels have also been seen on non A-1000 mice.

The 1351s, when you are lucky, actually say 1351 on them.  When you aren't lucky, you get the lighter colored C= Commodore logo and lettering with a simple numeric serial number.  But mine is a small sample size, so who knows what variations are out there.

The 1350s are the only ones that say Commodore Business Machines on the bottom, again with lighter colored lettering than the Amigas, and a serial number beginning with X.  Although, again, that's just my small sample size.

But...

.
.. maybe you aren't comfortable with this method.  After all, there's no way I can survey every single Commodore mouse.  Suppose I made a mistake above, and some 1351s have labels that look like the Amiga, or some Amiga mice have labels like the 1350 or 1351s?  Surely we can just pop the top off and look inside to tell the difference:

Now we are getting somewhere.  This picture is the 1350, and it has a separate button board above the main board.  So, that's how we can tell those from the 1351 and Amiga mice below, right?  Wrong.  The raise "button board" seems to be more a sign of when the mouse was made than the model.  Since the 1350 and the Amiga mice were made earlier than the 1351, the early revisions will often have this raised button board. Meanwhile, later versions of the 1351 and the Amiga mouse will all be single-boards, as shown below.  As far as I know, the limited run 1350s do all have that raised board, but I could be surprised.

The later boards on the 1351 and Amiga mouse respectively, pictured above, have their components consolidated to a single board.  The later 1351s don't seem to have any resisters along the left-hand-side of the board, while the later Amiga mice always do -- either three or five, depending on revision.

The biggest difference, however, and the one certain SURE-FIRE way to tell the difference between these three mice is the chip inside.

So that's the answer!

Except that it's a little complicated.

The Commodore 1351 mouse is easy.  It almost always has a C= CSG 5717 chip in it.  In fact, that same chip also appears in several 1351 clones I ran across, such as the CMD SmartMouse.  So, if you see the CSG 5717 inside, you know you are looking at a 1351, period.  Although, I found a 1351 online with a chip labeled "390209-01" -- so I guess that one too?

The Commodore 1350 has a chip which is probably a little "CMOS 4 bit microprocessor with A/D converter".   This would make sense, since the analog signal from the wheel sensors are converted into simple on-off signals for the various directions.    In this case, I'm seeing the Mitsumi MP01 and the MB88201

Lastly, the Amiga mice have an analog quad comparator of one sort or another.  I think the 339 at the end is probably the giveaway here.

---

So!

That's the best I could come up with.  Clues in the labels and the connector, and then a final answer in the chip, if you are able to find the model number online to figure out what kind of chip it is.  If you have a Commodore or Amiga mouse with a serial label different from the ones discussed above, please drop me a line.

There might also be a way to check for the right-mouse-button on pin 9 of the Amiga mouse, but I was aiming for more visual inspection methods, so I didn't investigate this.  Still, if you want to pursue that, here is a pinout comparison.  The 1350 is labeled here as "1351 Joystick Mode".

Clearly Commodore should have thought about the confusion that might erupt around three products that look so similar, but which are functionally so different.  Hopefully this post can help anyone faced with the frustrating situation I found myself in today trying to distinguish between a pile of tank mice from someone else's collection.

C64Net WiFi Modem Filter State Machine

So, believe it or not, work continues on the C64Net WiFi Modem firmware.  Especially since the same firmware is being used in a traditional RS-232 version of the modem based on the ESP32 module.

Some of the newer features include:

1. New AT+CONFIG configuration menu
2. Ability to set the hostname
3. X-Modem and Z-Modem downloads
4. AT+SHELL to access an SD-card interface.
5. NTP client with configurable timezone.
6. New configurable socket filtering state machine.

That last feature is what I wanted to document here.

The use case was the ability to have the modem filter or transform bytes coming either from a socket connection, or from a web page via the AT&G command.  There were already existing commands to mask out specific bytes, but users needed something more complex.  I searched the web the best I could to find an existing language definition for doing such a thing, and couldn't come up with anything.  I therefore chose to invent a really simple filtering code/language.  

My requirements were that it had to be completely definable in ascii, using only characters available for the AT command set in quotes.  It needed to be as compact as possible for memory constraints, and needed to handle cases like filtering out everything inside html comments <!-- -->, or possibly filtering out everything NOT inside html comments.

Here is what I came up with:

State Machine entry format:

MMcCCNN

MM - byte value to match, in hex. The value 00 matches ALL.

c - Command character: e)at char, p)ush to que, d)isplay char, r)eplace char, q)ue display and empty, x)empty que

CC - if c == 'r', then hex value of replacement byte

C - if c != 'r', then same as 'c', or '-' to do nothing further.

NN - next state, in hex, starting with state 00.

The machine starts with state 00, and, for each character byte, increments the state until a match is made, at which point is executes commands and proceeds to state NN.

Example:

Suppose you wanted to filter out everything in a web page EXCEPT the contents of the comments.

Important chars and their hex values:

< 3c

! 21

- 2d

> 3e

So, to grab only the stuff from <!-- -->, your state machine would look like this:

## -CODE--  COMMENT

00 3Ce--02  <-- if a '<' go to state 02

01 00e--00  <-- anything else, ignore it, go back to state 00

02 21e--04  <-- if '<!', go to state 04

03 00x--00  <-- anything else, ignore it, go back to state 00

04 2de--06  <-- if '<!-', go to state 06

05 00x--00  <-- anything else, ignore it, go back to state 00

06 2de--08  <-- if '<!--', go to state 08

07 00x--00  <-- anything else, ignore it, go back to state 00

08 2dp--0a  <-- now inside the <!--.  If '-', then state 0A

09 00qd-08  <-- anything else, display que & char, go to state 08

0a 2dp--0c  <-- if '--', then que the char, go to state 0C

0b 00qd-08  <-- anything else, display que & char, go to state 08

0c 3ex--00  <-- if '-->', dump the que, ignore char, go to state 00

0d 2dqd-0a  <-- anything else, display que & char, go to state 08

So, to do the AT&Y command, we just combine the codes in order:

AT&Y"3Ce--0200e--0021e--0400x--002de--0600x--002de--0800x--002dp--0a00qd-082dp--0c00qd-083ex--002dqd-0a"

Then any subsequent packets received from an open socket, or from the AT&G command (which dumps a web page to the modem) will use the above filter.

A few extra utility arguments were added for convenience:

AT&Y     with no arguments clears the state machine definition entirely

AT&Yn   where n is a decimal number, will set the state machine state.

All of this will be in 3.4 of Zimodem.

Amiga Recaps, Pt. 1

Lately I've been recapping Amigas with a fellow from the CTCUG group.  That's been going pretty well.  I've been practicing on spare Amiga 600 boards, of which I had 3 non-booting boards.  All 3 began booting after the recap, which is amazing happiness.  Once I've recapped all my spare boards, I'll move on to the computers in my collection.

Some lessons I've learned:
1. You can use hot air to remove surface mount caps with tin-foil to isolate the cap and the damage, but be super-careful not to disturb nearby components for several minutes after removing the hot air.  Easier is to use a wire cutter to cut into the cap from the top, being sure not to pinch along the same line as the solder contacts, so as not to pull a trace.  When the cap is cut away, it is easy and safe to de-solder normally.

2. Remove those tiny-legged through-hold electrolytics with a soldering iron on max heat by applying heat to the bottom pin while carefully pulling that pin up through the board.  Once you've exposed the top-side of the pin, resume pulling it up from the top of the board to make sure you aren't pulling up any traces on the top.  Then repeat for the second pin.

3. Clean the area with alcohol and q-tips afterwards, and carefully clean the through-holes with solder-wick.

4. When applying the surface mounted caps, do one leg at a time after tinning the pads.

5. Check the smd caps for a short afterwards.

My new friend KIM.

I've had a pair of Commodore KIM-1 computers for at least 15 years now, but never really did anything with them.  That all changed over the last few weeks, and now I feel sorry for how much fun I've been missing out on.

The KIM-1 is a single board, 1mhz, 1 kilobyte computer (the green thing in the picture above) with a 23 key hexadecimal keypad for input, and a 6 digit LED display for output.  It also has two edge connectors on the left-hand-side.  One is called the Expansion port, and the lower one is the Application port.  The computer is powered by applying 5V to a pin on the Application port.  This port also includes a Current-Loop RS232 interface and cassette interface for saving/loading programs.

It may be a very minimal micro-computer, and it is definitely not a Home/Personal Computer, but it is certainly a computer!

The screen is divided into two segments.  The left four hex-digits are the current working Address, and the right two hex-digits are the contents of that address.  The address can represent the program counter when stepping through a program, or just the address currently being read or written to when using the KIM-1s built-in monitor.

The keyboard has the sixteen hex digits for entering addresses or data.  The AD button selects "Address" mode, where any entry on the keyboard will change the current working address.  The DA button selects "Data" mode, where any entry will change the contents of the address shown on the LED screen.  When in either Data or Address mode, the + key will advance to the next address byte.

The switch in the upper left selects between SST mode (on), which allows you to step through an executing program one instruction at a time, and normal mode (off), which allows a program to run freely to completion.  In both modes, the GO button will begin executing the program from the current address shown.  In SST mode, the GO button is then used to execute the next instruction, and then immediately return to the monitor program.

The RS button will reset the CPU and cause the KIM to re-enter the built-in monitor.  It is the first button you must press after powering-on the KIM-1.  Lastly, the PC button does nothing except replace the current address with the program counter address.

The KIM-1 is powered by three principle chips.  One, of course, is the MOS 6502 cpu/processor.  The other two are a pair of MOS 6530 RRIOT chips.  Each has 64 bytes (!) of ram, a pair of 8-bit bi-directional I/O controllers, timer registers, and 1k of ROM.  On one of the 6530s is the ROM code for the ml-monitor and cassette interface, while the other has the paper-tape interface.

I have a couple of Corsham expansion boards hooked up to my KIM, which are awfully convenient, and part of the reason why I finally dug the KIM-1 out for play.  Pictured above is their I/O board, which provides a standard 9-pin RS-232 port, which converts to the KIM's strange current-loop port.  It also has convenient interface for regulated 5V, 12V, and ground (the colored wires you see above), as well as an audio input and output jack for plugging in a standard cassette deck.  The little switch on the bottom lets me pick between TTY input, and using the KIM's keypad.

On the Expansion port is a Corsham 60k ram expansion card, gives the computer ram from $2000 all the way through $FFF7.

Once I got it working, I hooked the KIM-1 up to my VIC-20 through the VIC-1011A TTL interface and used the VIC's keyboard and monitor to program the computer.  The protocol settings are: 2400bps, 8 data bits, no parity, two stop bits, no flow control.

One of my first programs was a memory-page address tester to make sure that the Corsham 60K ram expander was working correctly.  The program simply puts the page number into every byte in every page above $2000, and I then use the monitor to spot-check the results.

The first program I wrote on it was done by writing the assembly on paper for address $0200, and then translating the mnemonics into the machine language op-code numbers, and the branch addresses into one byte 6502 offsets.

Later, I realized that I could simply write the code in assembly, assemble it on the c64, and then key in the generated bytes onto the KIM's keyboard.

I am seriously interested in translating Microsoft BASIC for the KIM, and have discovered numerous resources on the web for doing that.  Check back here in the future for progress on that project.

PETs are my Business

For a long time, I've been trying to get my hands on one of the U.S. PET 2001-B 'Business' series computers.  And boy are they rare!  I've seen at least two go through eBay, but over-confidence and under-estimations caused me to lose them. :(

But finally, I struck gold .. well, sorta.  A 2001B-16 turned up on eBay, but was advertised as non-functional.  It was still an opportunity worth taking, so I took it:

So, let's talk about this computer and what makes it unique!

At first glance, it appears to be just another PET with a 9" screen, just like it's Home series brother, the 2001N.  However, look closer and you'll see that the keyboard keycaps are not only different, but the entire arrangement of the keyboard has changed! There are no PETSCII graphic symbols on the front of the keys, the punctuation symbols and number keys are arranged together at the top row, just like a typewriter, and the numeric keypad is smaller.   This keyboard would go on to be used in the PET 8032 also.

Under the hood is another important difference.  The standard Editor ROM, which handles screen editor control and keyboard mapping, is replaced with a 'Business series' editor ROM, whose model number is 901474-01 (second rom from the left in the above picture).  This rom not only handles the new keyboard arrangement, but forces the computer to boot into Uppercase/Lowercase character set mode, instead of the Uppercase/Graphics mode the other PETs booted into.  The computer otherwise has the standard BASIC-2 Kernal and BASIC.

And lastly, of course, if the above was not convincing that this is not a 2001N series, the model number is "PET 2001-16B".

When I first got the machine, the computer did not boot, which the seller did warn me about.  Luckily, I had the Tynemouth 6502 PET diagnostics chip, v1.1!

This chip replaces the 6502 on the motherboard, and performs several tests on main ram, video ram, and provides a hash and identification of the roms.

The first run showed the video ram and ROMs in good shape (the -UNKNOWN- rom is the business editor, which is pretty rare, and the BASIC-4 was just a silly add-in I removed later).  However, it also shows ALL of the main ram as DOA.  One or two bad chips, and I might have started replacing them, but when they are all gone like that, something more fundamental was wrong.

And I quickly determined that the 12V rail was grounded.  The 4116 ram chips require +5VDC, -5VDC, and +12VDC.  So, starting at the regulator, I began removing and testing every damn component in the 12V circuit.

First up was this regulator, and the two caps and diodes you see here around C24 and C25.   The electrolytic was out of spec (it's a 47uF, but reported 68uF), so I replaced it with a high quality long-lasting modern one that was closer to spec.  Still, none of the components were shorted, so I followed the 12V rail down to the ram.

The 4116 ram chips I desoldered, socketed, and then re-inserted, after checking each one for a short at the 12V pin.  I broke one of the 4116s during this process, but had plenty of replacements.  Otherwise, I kept the original chips.

Next, on the advice of a friend, I moved to the tantalum capacitors (the larger blue caps on the LHS and RHS -- not the tiny blue ones next to the ram).  Turned out that was it!  TWO of the three tantalum capacitors I removed were shorted.  I therefore replaced all three.  The Tan colored capacitors you see intermingled with the blue ones were the ones I replaced.

And Walah! Now I have working RAM! Woohoo! You can see from the test screen that I also removed the silly BASIC-4 chip I had added for no reason other than the socket looked lonely.

You can see the char rom test is also good.

However, when I put the working 6502 processor back in, the computer still would not boot!

For giggles, I next tried the "PET tester ROM", which replaces the standard PET kernal instead of the processor, and runs a few simple memory tests.

As near as I can tell, those also came back with good results.

So, well, I thought about it.  When the computer starts, the CPU is reset, and it reads a location from the Kernal ROM at the bottom of memory and starts executing code.  So the CPU needs to work, and the Kernal needs to be readable.  Since the Pet Tester ROM test worked, I know it is doing those things.  After that, it will starting writing to main ram, and eventually screen ram.  I know all the RAM is good also, and that the CPU can read from and write to it.  What else does the PET do on startup?  I wasn't sure, but I imagined it also had to initialize the I/O chips so it can read from the keyboard.

So, I swapped out the 6522 VIA, and the two 6520 PIAs.  After swapping the PIA closest to the keyboard, BOOM:

And they lived happily ever after!

A Post! Now with even more WiFi Modem!

Well, I hope you aren't tired of news about the CTCUG "C64Net WiFi Modem", because it has remained my development focus.  Even as I type this I'm busy adding SSL support to the firmware, and wondering if the feature is really worth the 50k of program space and 5k of global ram it appears to consume.  The answer? Probably Yes.

My last posting talked about the Telnetd server for the Commodore 64.  That program turned out to be my last new application for the standard C64 kernal.  Since then, I've moved onto the Commodore VIC-20.  Some quick tinkering allowed me to discover that this little 22 column wonder can easily do 1200 baud with our new modem.  That was all I needed to know.

I proceeded to port the machine language code for the WiFi modem applications, which I call the "PML" for "Packet Mode Library", to the VIC-20 memory map, which I was surprised to find so closely resembled the C64 memory map as to need almost no changes at all!

After that, it was a simple matter to adapt most of the standard BASIC applications to run on it, provided you had at least a 16K ram expansion for the VIC.

So that means our modem comes with a nice suite of internet programs for the Commodore 64, 128, and the VIC!  I also tried the Plus/4, but we found that the DCD line on our modem was causing problems, and that a Plus/4 version of the modem would have to wait.

The next thing that happened was that our modems went on sale on eBay! You can find it by searching for "C64NET WiFi Card"

Since then, I've been working on porting my internet applications to the GEOS graphical operating system.  Back in the late 90s, I was quite infatuated with coding for this environment, and have found it quite easy to slip back into its elegant arms.

My first step, of course, was figuring out how to do modem I/O from inside an operating system that ignored the existence of the user port.  I quickly decided I would not try to replicate the C64 Kernal routines, which have some notorious speed issues.  Instead I decided to port Ilker Fiçicilar's "commLib2" library, which claims to be able to do much higher speeds.  You can download it and find other information here.

Porting commLib2 to GEOS was done in several painful steps.  The easiest part was first: I took his binary and ran it through the WFDis interactive disassembler and generated something approaching the original assembly source.  I then stripped out the terminal, which I would not use, and filled in as many labels as I could.

The next step was hardest: actually getting it working in GEOS.  Like the C64 Kernal, commLib2 relies on timer interrupts from the CIA to handle serial.  However, GEOS does not use NMI interrupts, and, by default, uses a memory map that "hides" the CIA addresses from the CPU.  After working through these problems, I uncovered a few minor bugs in the library, and discovered that the timing was optimized for a European PAL C64, which runs slightly slower than my NTSC C64.  Lastly, I replaced his more complex support for large receive buffers with a faster and simpler small-buffer design that used hardware flow control. Getting through all this took the better part of a month, but eventually I had a working driver!

Once the driver was done, I started working on an 80 column ANSI terminal program, which would be my first GEOS application for the modem.  I discovered that the driver does up to 4800 baud without any troubles.  The author says I should be able to get 7200, but I'll probably need to tweek my NTSC timing numbers at some point to actually see this.

Adding the ANSI color support was tricky, since the font is 4 pixels wide, but the C64 hi-resolution screen supports background and foreground colors in pixel blocks of a minimum 8x8.  I went ahead and allowed this fudge to go through, but I don't think it looks too bad at all.

I still have quite a ways to go before it's finished.  It will need a phonebook/dialer, and support for X-Modem file transfers, but after that, it will be ready to release.

It will eventually be followed by an IRC client, CBM graphics "BBS" client, an FTP client, and probably a combination of the WGET/D64WGET program I wrote in BASIC.  At first, all of these programs will be for the C64 version of GEOS (including Wheels, MP3, and gateWay).  For GEOS 128, I would basically need to start from scratch with the driver all the way up, so I'll leave that for the distant future.

Until next time!