Monday, September 11, 2017

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!





































































Sunday, July 2, 2017

C64 Telnet Server







Of late, I have not been able to get enough of my Commodore user-port wireless Ethernet modems. Yes, the same modem I described before >here<.

Since that last blog post, we've added hardware flow control, and gone through two more revisions of the hardware.  Changes to the firmware have slowed down at this point, as I focus more of my energy on different applications of my new internet toy.

In addition to all the programs mentioned in the previous post, I've since added a version of WGET specifically for downloading .D64 (or D81, etc..) disk image and writing the sectors directly to a blank floppy.  This is perfect for users who want to enjoy games on the internet in .D64 format, but only have a single 1541 disk drive and our modem.  The program is called D64WGET on our disk.



I also ported one of my favorite old Commodore PET games, "weather", to the C64, and then made it playable over the internet using our modems.  I got my brother to help me play test it several times during testing, and I was soundly defeated. :(



I even managed to hook my Commodore SuperPET's RS232 port to the FTDI pins on an old rev 2 version of our modem (after going through a RS232/TTL converter), and playing around with it online.  This little project did require adding some more features to the firmware, since the SuperPET needed 7 bit characters and Even parity.  The fact that it uses 7-bit characters instead of the standard 8-bit was especially hard to discern, since neither the computer manual nor the uart setup menu mentioned it.  It was only after hooking up a logic analyzer to the TX/RX pins that this was figured out.



But my latest project has been a telnetd server for the C64.  From the internet you can connect to my C64 using a telnet-client of some sort, or even another ethernet modem like I'm doing here, and "take over" the C64's READY prompt.  You can write, run, load, and save programs, and so long as they limit themselves to text and keyboard input, everything works great.

In the picture above, the breadbox C64 on the left is running the server using a prototype of the rev 4 modem, while the C64C on the right is running a little four-line BASIC terminal program at 1200 baud on a rev 3.

The telnetd server resides in C64 memory at $C000 and is hard coded to initialize the modem and listen on port 6400.  The server injects itself into all the the Kernal vectors and thereby redirects modem input to the keyboard buffer, and screen output to the modem.  I've been learning quite a bit about the way the C64 Kernal RS232 routines and Kernal IEC (disk drive/printer) routines share CIA timers and thereby step all over each other.  At one point running the telnetd server all but ensured that programs LOADed would be corrupted, while also disabling remote user input.  It was a mess.  But since then I've gotten it to the point where you can remotely do disk access commands and maintain your control, which I debugged by simple disabling all modem output during LOAD, SAVE, and OPEN kernal calls.

My next mission was security.  One wrong POKE or SYS and the server is toast.  This was fixed by injecting code into the 'IGONE' BASIC vector that converted the token values for POKE and SYS into PRINT. :)



An idle timer, and an overall time limit was then put in, so that tinkerers can't hog the system forever, or just sit around doing nothing.  I chose an overall limit of 1 hour, and idle time of 5 minutes, though I'm sure that will be configurable in the future.  I tried using the ability of the TOD clock to generate interrupts to handle my time limits, but then discovered that i/o and the c64 kernal's default NMI step all over those as well.  I mean, the first thing the C64 Kernal NMI interrupt does is turn OFF all interrupts on CIA#2.  What the hell?!  In the end, I just had my normal interrupt code watch the two TOD clocks for timeouts.

Lastly, I needed a welcome message for when users connected, and, to enforce my time limits, the ability to send the delayed "+++" (pause) "ath" commands to the modem.  Since I was detecting users coming online and time limit timeouts in the standard periodic interrupt, that was where I handled this 'forced disconnect' feature as well by simply adding a state machine and letting the TOD clock used for the idle timer do double duty as a delay-pause timer as well.

When completed, this program will join its brothers over in my Zimodem/C64Net WiFi project, which you can follow at https://github.com/bozimmerman/Zimodem.

I'm sure there will be more on this forthcoming.. unless some other shiny C= bauble catches my eye of course.









Wednesday, January 11, 2017

So, What's New? A WiFi Modem, That's What!


I haven't updated the blog in awhile, but this is not because I've been idle.  In fact, I've been so constantly busy on Commodore things that I just never took a breath long enough to talk about it.  As a result, you can expect an endless barrage of posts as I try to get you, and my future self, caught up.



The Commodore WiFi Modem project has been an effort by our local Commodore users group, and has been progressing nicely, both at the hardware and software level.  A WiFi modem is a wireless ethernet device usable by Commodore computers.  Anyway, as I've been handling the software side, I'll talk a bit about the hardware side first.

Shown above is the REV1 fab.  We (CTCUG) are just days away from Carlos having REV2 in his hands.    REV1 featured a fully powered ESP8266 board with proper RS232 levels for the Commodore 64 and 128, allowing basic KERNAL I/O between the two.  REV2 will feature DCD detection for BBS support, and support for UP9600 in C64 mode.  It will also have an optimized and cheaper design, and be only half the length of REV1.

I've done almost all of my software development using the REV1 board, as well as my own hand-made version.



I have several features I desire in a Commodore 8-bit internet device, which this WiFi modem is capable of fulfilling, with the right firmware.  These desires are:

  1. Uses the User Port (No cartridge port/bus hogging)
  2. Supports KERNAL RS232 (easy simple BASIC/ML programming)
  3. Does not hog system CPU/Memory (the TCP stack is in the device, not the Commodore)
  4. Supports socket listening and multiple client connections.
  5. Supports both streaming and controllable packet-based data.
  6. Supports CRC for error detection and correction of packet data.
  7. Can look enough like a modem to the Commodore to support old BBS programs.
  8. Supports boot-options (again, for BBS support)
With those goals in mind, I wrote firmware for the ESP8266 that would run in this device, which I called Zimodem.   The project is mirrored here on GitHub. 



After some initial frustrations, development went pretty well.  If you check out the build instructions, you'll see that I had all kinds of problems with the ESP8266 Arduino libraries.  And I probably should never have bothered with trying to program for it using Arduino IDE, but, well, it seemed like the best idea at the time.

To make a long story short, all of the features listed above, and many more, are implemented, with periodic bug fixes as the capabilities are tested and stretched.

While the initial landmark was being able to use a standard Commodore terminal program, such as Novaterm in the picture above, to connect to MUDs and BBS programs, the second landmark of a suite of internet applications that run natively in the C64 and C128 is also coming along.


Here is my C128D testing an early version of the IRC chat client.  Like all the clients, the same BASIC program works in a C64, in a C128 in C64 mode, in a C128 in C128 mode, in 40 or 80 columns.  The biggest difference is which machine language support file it loads.  All the clients will be made available on my ftp site, and in a separate GitHub project when available.

In addition to the IRC client, a TELNET client has also been completed, which does full ASCII/PETSCII translation, supports color as far as it can, supports TELNET codes, at least to the extent of eating them, and supports local keystroke echo, all in super-fast machine language core wrapped by the BASIC handler.  It also has a little phonebook that gets saved to your disk.

A WGET client has ALSO been completed, which allows any text or binary file to be downloaded from a non-SSL Url off the internet.  So, if the URL starts with HTTP://, it can probably download it to your commodore.

Lastly, an FTP client is currently in the works.  It uses PASSIVE modem FTP to get around firewall issues, although early tests with non-PASSIVE socket listeners were also promising.  This will be super cool.

Beyond these, a special MUD client, similar to TELNET except for some extra features unique to MUD clients, will be done.  A special C= BBS client will also be done.  It's also similar to TELNET except that it skips ascii and telnet translation.

So, that's it.  Keep your eyes posted here for more updates!






















Monday, June 6, 2016

Amiga on Steroids, Complete with Side Effects!

.



Nestled snug in the corner of my computer room is an Amiga 600.  It was put there for one purpose: as a quick and easy game console for classic Amiga titles like Lemmings, Street Fighter II, and whatever else I could find on floppy that worked.

This was fine until the day I decided to put one of those pre-configured flash-based IDE drives off eBay inside it.  The hard drive came with a program called WHDLOAD installed on it, along with around a hundred games.  I was captivated, but very few of those games actually worked, and I was told it was the machine's fault.  So first I upgraded it to the latest Kickstart ROM, then I gave it 4mb of Fast Memory in the belly slot, and finally another 2mb through PCMCIA.  None of it was enough.

Then I heard about the Vampire V2 CPU card.  It promised to solve all my problems with an 80+mhz 68040 emulated processor, 128mb ram, and an sdcard slot for extra storage.  For the money, it was the cheapest and fastest 680x0 based cpu expansion for any Amiga.

So I placed my order, waited several months, paid the bill, waited another month.  And then one day...


The package came with the card, two little plastic mounting legs, a Q-Tip, and alcohol swab.  I used the Q-Tip and swab to clean the contacts around the existing 68000 processor, and after some moderate but careful violence, was able to push the card into place and screw it down.  I then put a cheap 8gb sdcard into the card reader and hooked it back up.



It booted right up, and a quick run of SysInfo showed that it was every bit as screaming fast as it promised to be.  I also ran AIBB, which contains numerous benchmark tests.  Generally speaking, it's screaming fast on CPU and integer intensive tasks, still Fast as Hell on Floating point tests, and (shockingly) slower than a 68040 (but still faster than a 68000) on graphics operations.

The sdcard was not recognized as a standard scsi device, so my first step was to discover, find, download, and install the latest drivers.  This took way too long to figure out.  Shipping the card with instructions on at least where to find drivers would have been nice.  Anyway, some time later, the sd card was partitioned and ready to receive data.  The process went something like this:
  1. Download Saga Driver (as of this writing, 0.9c, requiring firmware rev SILVER6)
  2. Copy sagasd.device to Devs, and SDDiag and VampireTool into C
  3. Copy SDMount into System
  4. Alter the "Information" tab on HDConfig to refer to the new sagasd.device
  5. Using HDConfig, setup and partition the drive as normal.
  6. Reboot
  7. Run SDMount in the System folder.  It will appear to have done nothing.
  8. In RAM:T/SDMount, you'll find some number of device config files equal to the number of partitions you created.  Copy these into your DEVS:DosDrivers folder.
  9. Edit each of the new device files with a text editor.  They will have an empty "Filesystem =" entry that you must fill in.  For example, if you set up the partitions to use FastFileSystem, you would put: FileSystem      = L:FastFileSystem
  10. Reboot Again
  11. After a few seconds, the new devices will appear in Workbench.  Quick Format them.
It only took a few megabytes of copying data onto the new partitions to discover my error: The cheap (slow) 8gb flash card I used wasn't cutting it.  The OS would constantly error out as if the device was no longer there. It would ask me to reinsert the volume as if I had removed it. Hitting retry would usually work, but that's not behavior you want out of fixed storage.  Using a  higher quality (faster) $20 8gb sdcard did the trick.

Another problem I discovered is that running a computer with a 68040 but no FPU (Floating Point Unit/Math CoProcessor) creates confusion.  The Vampire team promises a core update with an FPU in the future, but until then, certain programs are going to be a problem.  Thankfully, they are always non-Game programs.















































































Tuesday, March 22, 2016

Commodore Collector Trudgery


I don't really have much exciting to say for this entry, but wanted to let blogspot know that I have been quite busy.


This beautiful Amiga 500 was purchased off eBay only because I wanted an earlier motherboard and the "Chicken Head" logo case.  The original box was bonus and might have been the best part.  It's gorgeous!

When it arrived, however, it had two flaws: a missing disk drive ejection button and a mostly malfunctioning keyboard.


The problem with the disk drive button was easy enough to fix, as I had a spare floppy to draw it from.  The keyboard, however, was tricky.  Upon very close inspection of the keyboard membrane, it turns out that several of the metal traces near the connector had gotten bent to the point of breaking.  I tried using some liquid carbon with the absolute finest tipped brush I had, but was only able to bring back two or three of the dead traces that way.  Luckily, someone on facebook routed me to sellmyretro.com, where someone was selling brand new (and compatible!) membranes.  I dropped my repair attempts (who knows how long that liquid carbon would have held anyway) and just got a new one.


While all this was going on, I was also contacted by a Houston resident who was moving out of the country and wanted to unload all his Commodore stuff.   Apparently, he was a big Commodore 128-mode and C128 CP/M-mode fan, as well as a Commodore 8-bit power user who kept up with all the latest storage, memory expansion, and accelerators.



I'm a big fan of CMD (Creative Micro Designs), who designed much of those later expansions, so I knew the deal would be a good and useful one.



Once I got as much of it home as my wagon would carry, it took weeks just to take stock. And then came very minor repairs.  A CMD Hard Drive got a new SCSI drive mechanism.  A pair of FD2000s swapped drive mechs so that the one with the functioning motherboard would be a fully functioning drive.  A 1581 had a shorted capacitor replaced.   And meanwhile, there were stacks of floppy disks to archive.  All of this has kept me extremely busy to this day.




Then, on top of all this, the power supply in my CBM-256 has gone out, again, I *think*.  This is the third of fourth time it has failed to power up.  Most times, tinkering with it for a few weeks would make it mysteriously start working again.  Once, all it needed was a new monitor fuse, but that won't work this time.  The symptom is, once again, an utter lack of voltage on all lines.

So, it's hardware that has kept me busy.  I've actually been looking forward to doing some software projects, but those will wait.




Monday, February 22, 2016

Project Batteries: Finished

The longest and most exhausting hardware "project" I've ever embarked on is completed.  I'm referring, of course, to the mission of inspecting every Commodore Amiga, PC-compatible, and PC-laptop for leaking or dead batteries, and replacing them.


The final computer to receive attention, out of the dozens and dozens, was this plain Jane Amiga 500 with an A501 memory expansion in its "belly".  The A501 provides this computer with an addition 512k of memory, as well as a real-time battery-backed clock.  However, that aforementioned battery was a leaky Ni-Cd barrel that needed cutting out and replacing, which I did.

All of the computers which required a battery replacement received ordinary lithium-ion "coin" batteries.  This represented a trade-off.  These batteries are not rechargeable, but they are easy to swap, since I always mounted a battery-holder for them, and they do not leak acids or bases over time, but simply fade into oblivion.

Safer computers was not the only thing I had to show for having done this project, however.  Since these computers were coming down from high shelves in some cases, being tested, and often disassembled to get to the motherboards, I took pictures.  Lots and lots of pictures.



A few also required repair, such as the Amiga 600 in the above picture.



Others got their hard drives reformatted for a fresh install of Windows 3.1, for no reason at all.  Such was the case for this Commodore Select Edition 286, with 80287 co-processor!


This Amiga 4000 /040 got a fresh install of AmigaOS 3.9.  It deserved it.



But most of them I was just happy to see still kicking after all these years, such as this Commodore PC10-III, which was one of my first Commodore PCs.  I remember using it for many years as a 64NET server for the 8-bits.  Later it got PC-GEOS installed on it for productivity use.



It's good to know these computers will be safe and secure for years of new joys to come.

Wednesday, January 27, 2016

The Strangest Collectables

Of all the things in my collection, printers and monitors are the strangest.  They serve very narrow purposes and tend to all do their tasks in about the same way.  Of the two, printers are the strangest. Monitors can often be justified due to the non-standard video output of some computers, especially the RGBI of the C128, the Chroma/Lumina of the C64, and the 15khz signal from the Amigas.

Printers, however, just print.  They take paper with tiny holes along the side, onto which they deposit letters by pressing a shape against a piece of cloth coated with ink.  And they are all either IEEE-488, IEC, or GPIB (Parallel).


This is a Commodore 4022P IEEE-488 printer.  It has enough processing power and memory to handle the IEEE-488 communication with the computer, and it prints.  It does not scan. It does not fax.  It has no lasers or jets of ink.


Instead it takes, as I mentioned earlier, a piece of cloth dipped in ink and rolled up in a continuous loop inside this plastic casing.  Much like the printers of today, every printer takes a slightly differently shaped ribbon cartridge, allowing the manufacturers to sell the printers at a loss and make it up on all the ribbon sales.


This particular model was made for the European market, having an AC 220V power input.  Inside is a step-down transformer and some sort of rectifier circuit to provide the DC current needed by the chips and paper motor inside.  The data port is, as mentioned earlier, IEEE-488, meaning it was meant for either the Commodore PET, CBM or CBM-II line of computers.