Manually making a bootable NitrOS9 hard drive image – part 2

See also: part 1, part 2 and part 3.

Updates:

  • 2016/05/02 – Added link to David Ladd’s experiment.

In the first installment, I discussed a bit about how the Radio Shack Color Computer boots OS-9 using the Disk BASIC “DOS” command. I ended the article by mentioning David Ladd’s exciting experiment to place the OS-9 boot track in ROM on a CoCoSDC interface. The advantages of this would be:

  1. No need to write out the kernel boot track to a boot floppy (or virtual floppy).
  2. A whole extra track of disk space on any boot disk.
  3. Faster booting, since copying from ROM would be faster than loading the 18 boot sectors from a floppy drive.

Number 2 is not a huge deal on a hard drive since 4.5K isn’t much space. Neither is number 3 since reading 18 sectors from a virtual floppy on the CoCoSDC is blazing fast. I can already do a complete OS-9 boot to a shell prompt in about 3 seconds. But, faster is faster. It’s number 1 I want to focus on.

The Problem With Cobbler

The OS-9 utilities cobbler and os9gen were written to work on floppy disks. historically, that’s all anyone has ever used them on — even if the floppy was a virtual one contained on an RGB-DOS/HDB-DOS hard drive partition, or .DSK image file across Drivewire.

CoCoSDC allows you to create .DSK image files and mount them as if they are a floppy disk. The CoCoSDC decides what to do with them based on the size of the .DSK file. See the “Disk Geometry Table for DSK Images (without header)” table on the CoCoSDC blog. Basically, any .DSK file with more than 2880 sectors (as many as an 80 track quad density floppy could have) will be treated as a hard drive image.

I’m not quite sure what this implies, since if you mount such an image, Disk BASIC will still see and use the first part of it as a 35-track single sided floppy disk*. To Disk BASIC, all it knows it Tracks 0-34 each contain Sectors 1-8 and each sector is 256-bytes. If you mount such a large .DSK image and then type “DOS”, Disk BASIC will go out to Track 34, Sector 1 and start loading things in to memory at $2600, same as if it was a real floppy disk.

* Is this true? It seems to be. If it’s not, what I am about to describe shouldn’t be working.

Track 34, Sector 1 is sector number 612 (34 tracks * 18 sectors per track = 612). As long as a kernel boot track is found there, you should be able to attach a 128MB .DSK image, type “DOS” and boot in to OS-9 (assuming the boot track has the proper OS-9 booter on it for the CoCoSDC hardware, and there is a OS9Boot file properly set up, too).

This is exactly how the NitrOS9 CoCoSDC sample .dsk image works. Mount it, type “DOS”, and in seconds you are at a NitrOS9 shell prompt. The NitrOS9 makefiles create the .dsk image using the Toolshed tool “os9”. Toolshed supports formatting a .DSK image for OS-9, os9gen-ing a bootfile on to it, and dsave-ing files and directories over to it. You end up with a large bootable .DSK file that is formatted for OS-9, has a “track 34” boot track, and the OS9Boot file linked in at sector 0. Magic.

You would think you could do the same thing via OS-9, but you would be wrong. os9gen and cobbler will not work because they were never written for anything but a physical floppy drive. In a moment, I will explain why this may be an incorrect statement.

If you mounted an OS-9 boot .dsk image in DRIVE 0, and a formatted 128MB OS-9 hard drive .dsk image in DRIVE 1:

DRIVE 0,"OS9BOOT.DSK"
DRIVE 1,"128MBHD.DSK"

…and then you boot in to OS-9 and try to “cobbler /sd1”, bad things happen. cobbler and os9gen will try to place the kernel boot track at track 34, sector 1. If this was a physical floppy interface, seeking to Track 34 and Sector 1 would work, but to OS-9, there is no such thing as physical tracks or sides. Every disk device is just a bunch of logical sectors, and it’s the device drivers job to translate whatever the hardware has to a series of logical sectors. The cobbler and os9gen utilities use something called “math” to figure out what logical sector corresponds to Track 34, Sector 1. It does this with a simple forumla:

logical_sector = 34 * 1 * sectors_per_track * sides (see side note)

Side Note: Sides is used because on a double sided floppy, tracks are interleaved between the two sides of the disk. On a single sided 40-track floppy, there are 720 sectors which make up the top side of the disk. On a double sided 40-track floppy, there are 1440 sectors. The first track’s worth of sectors (sectors 0-17) is written to the first track of the top side, then the next track’s worth (sectors 18-35) is written to the first track of the bottom side of the disk. The job of an OS-9 disk driver is to translate the logical sectors OS-9 uses to whatever format the hardware uses. In the case of floppy disks, it turns 1440 logical sectors of a double sided 40-track disk in to two sides of a physical floppy. On modern hard drives, the drive controller speaks sectors, so the only thing the OS-9 driver has to do is deal with the 512-sector size issue on modern drives, but that’s a topic for another series of articles.

If the hard drive is configured with a different number of sectors per track than the 18 used by a floppy disk, the math will be wrong. cobbler/os9gen will multiply the drive’s sct (sectors per track) setting by 18 (hard coded assumption) and either 1 or 2 sides (see note below) and try to write the kernel track at that location. The end result is a file being written in the wrong place on the .DSK image than where the “DOS” command expects it to be.

Side Note 2: For sides, cobbler and os9gen aren’t using the actual sides field — they are using a bit in the DD.TYP field that indicates if the device is single or double sided. For a proper OS-9 hard drive descriptor, the hard drive bit is set and the sides bit is clear, so cobbler and os9gen should see a hard drive as a huge single sided floppy disk.)

But wait! It gets worse…

While OS-9/6809 can theoretically support a 4GB hard drive, it could only do so by using a large cluster size (having multiple sectors representing one cluster). For me, I am using the largest size possible when each cluster represents one sector. Below, when I mention “cluster” or “sector”, they effectively mean the same thing for me since I am using a cluster size of one sector. Get it? Good.

On my system, in order to get the largest 1 sector cluster hard drive possible (128MB, see note below), I configure my hard drive descriptor to be 65,535 tracks (cyl=$ffff), 8 sides (sid=$8) and 1 sector per track (sct=$1). This (65535 * 8 * 1) gives me 524,280 sectors, which is as large as we can get.

As part of the file system, a series of bits is used to represent which clusters are used or are free. This is called the DAM (disk allocation map) and it serves the same purpose as the FAT table does on a PC. The largest the DAM can be is 65,535 ($FFFF) bytes and since each byte represents 8 clusters. The more clusters, the larger the DAM must be.

DAM Note: Since there are only $FFFF (65535) bytes in the DAM table, with each byte representing eight clusters, the largest amount of  clusters OS-9/6809 can handle is 524280 (65535 * 8). 524280 * 256 bytes per sector is 134,215,680 which is just shy of 128MB (using 1024 bytes of a K). If only we had one more byte in the FAT, then we could fully use the 128MB. By using a larger cluster size, where each DAM bit represented 2, 4, 8, or 16 sectors, the total size of the hard drive can as much as 4GB. The 4GB limit is because OS-9 can only access up to 16,777,215 ($FFFFFF) logical sectors.

Sector Note: If you are clever, you might be thinking “oh, that’s with a 256-byte sector drive, so on an IDE drive where every sector is 512-bytes, we should be able to access 8GB!”. Very clever, but that would only be the case if OS-9 was not using deblocking drivers that split each physical 512-byte sector in to two logical 256-byte sectors. The max sector value that OS-9 can read is $FFFFFF 256-byte logical sectors. If those just happen to be half of each 512-byte sector on an IDE drive, then sure, it’s accessing an 8GB drive, but wasting half of each sector since OS-9 still only sees it as $FFFFFF 256-byte sectors. Now stop being clever so I can finish this article.

Where was I? Oh, right. Trying to use the largest hard drive I can…

If I ran cobbler or os9gen on this 128MB drive, it would multiple the number of tracks (cyl=$ffff) by 34 and then try to write the kernel boot track starting at sector 2,228,190. DOS will be looking for it at sector 612, so this clearly won’t work.

Theoretically, if I had made my hard drive use 29,126 tracks (cyl=$0x71C6), 18 sectors per track (sct=$12), and one side (sid=$1) like a simple floppy disk, I might be able to get this to work. cobbler and os9gen would do the math (track 34 * 18 sectors per track) and end up at sector 612 like it is supposed to and all would be well in the world. Except it isn’t.

First, that only gives a hard drive size of 524,268 sectors, which is 12 sectors shy of our max. I wouldn’t sleep well at night knowing I could be using 12 more sectors just by using more optimum settings. But that’s not the real issue. The real issue is that cobbler and os9gen were never written to work on hard drives. Taking a peek inside the cobbler source code, I find this:

 * Request memory for the FAT buffer + 256 bytes for stack space R.G.
 ldd <DD.MAP
 addd #size+256
 os9 F$Mem

First, the D register is loaded with the DD.MAP field from logical sector 0. That field holds the size of the DAM bitmap which, on a 128MB hard drive image, is $FFFF.

Next, it adds 256 to this value which, on a 16-bit register, rolls over and D ends up being 255.

Finally, it allocates memory which is will use for stuff. Instead of getting $FFFF+256 bytes, it’s really only getting 256 bytes and “bad things can happen.” This is a bug. Cobbler was not written to be used on a disk with that many clusters.

ERROR #244

Maybe that is why cobbler exits with an ERROR #244 when you try it on a hard drive configured that way. At least it does on mine.

As-written, cobbler and os9gen will fail here. They need to be updated to handle things differently, or at the very least, exit with an error if the drive is too large. And honestly, the easiest fix might be to do it like the Toolshed os9 utility does and just seek to sector 612 in the file (or 1224 in the case of a double sided disk). That’s really the only math we need for the boot track.

Up next: Finally, the original promise of this article… How to manually make a NitrOS9 hard drive bootable using only a disk editor, the copy command, and some duct tape.

Manually making a bootable NitrOS9 hard drive image – part 1

See also: part 1, part 2 and part 3.

Updates:

  • 2016/05/03 – Added link to David Ladd’s article on putting the OS-9 boot track in ROM on the CoCoSDC.

This article discusses how to manually make a hard drive bootable under the NitrOS9 operating system running on a Radio Shack Color Computer.

Creating an OS-9 Boot Disk

Creating a bootable OS-9 Level 2 disk in the past was always pretty simple. If you booted from a disk in drive /d0 and wanted to make a freshly formatted disk in drive /d1 bootable, all you had to do was run “cobbler /d1” (which wrote out the boot track and OS9Boot file based on what you currently were using) and then “dsave /d1 ! shell” (which copied all the files from your /d0 boot disk over to the newly bootable disk in drive /d1). Done! Beyond the infamous “BLOB” (bootlist order bug) that plagued users for years until someone figured out what caused it, you were pretty much guaranteed to have a new bootable OS-9 disk without any hassle.

Another method was to use the os9gen utility, which would read a text file list of individual modules and merge them together in to the OS9Boot file and write out the boot track. This was the method used when you wanted to customize what was in the boot disk, and the only option if you didn’t have any of the great 3rd party utilities that were written to make the job so much quicker and easier.

I almost never made a boot disk those ways. Once I had one that worked, I tended to just use utilities like Burke & Burke’s ezgen to edit the bootfile and insert, rename, remove or replace modules. Once I understood that OS9Boot was just a (contiguous) file on the disk and the only thing that made it special was two entries in logical sector 0 (LSN0) telling the booter where to find it, it became a simple thing to manipulate them without using any special tools. Between ezgen and the ded disk editor, and maybe a few other ones, I pretty much forgot how to use cobbler or os9gen.

NitrOS9 works the same way, however, today most folks are just using floppy disks for booting. The free Drivewire project lets OS-9 pretend it has a hard drive by communicating over the CoCo’s serial port to a Mac (or PC or Linux) machine running the Drivewire server. Still, you had to have something to load OS-9 from Disk Extended Color BASIC. Traditionally, that was the “DOS” command.

“DOS” Command Booting

The “DOS” command would go out to Track 34 of the floppy disk and, if the first two characters there were “OS”, it would load the entire track in to memory starting at address $2600. It would then execute the code starting at $2602 (just after the “OS” characters). That code could be anything, including a small standalone program that loaded up something else from the disk. Almost all of my RS-DOS disks had some form of “DOS” booter on it that would do things like set the drive seek speed to 6ms or turn on double speed mode. Sub-Etha Software sold Super Boot by Carl England which did things like this and allowed you to specify any command for “DOS” to execute.

For OS-9, the code on track 34 contained a booter, which knew how to find the “OS9Boot” file, and the OS-9 kernel module. DOS would load that in to memory and the boot process would begin, hopefully ending with an OS9: prompt.

Since booting begins with the “DOS” command, we can only boot from whatever device it supports. If the CoCo only had Disk Extended Color BASIC, that device has to be a floppy disk. The boot track on that floppy disk could then contain a hard drive boot module that goes on and finds OS9Boot on a hard drive (MFM/RLL, SCSI, IDE, Drivewire, CoCoSDC, whatever the booter knows how to work with).  Thus, we had a two stage boot: Boot is loaded from floppy, then boot loads OS-9 from the hard drive.

The only way to boot fully from the hard drive was to use a Disk BASIC replacement like RGB-DOS (today known as HDB-DOS and freely available). RGB-DOS altered Disk BASIC so commands that normally read from a WD1773 floppy drive controller would read from a SCSI hard drive. (HDB-DOS was later updated with versions for IDE hard drive controllers, Drivewire, etc.). Using RGB-DOS, it was possible to put that initial OS-9 boot floppy on a virtual hard drive floppy and boot entirely from the hard drive. The “DOS” command was still acting like it was reading sectors from a floppy disk, they were coming from a hard drive.

When using RGB-DOS, typing “DOS” would go to a virtual floppy disk, load in the boot track, and then proceed. Once the booter track was loaded from the virtual floppy drive, it took over and then … would look for OS9Boot on the physical floppy drive. Why? Because the boot code on track 34 was still floppy drive code. As mentioned earlier, replacement boot modules were needed to finish loading OS9Boot off of whatever hardware was being used.

The boot process, therefore, includes:

  1. Typing “DOS” to load the boot track. If using Disk BASIC, this was a physical floppy disk. If using RGB-DOS/HDB-DOS, this was a virtual track from a hard drive parition.
  2. Low level “booter” takes over and loads “OS9Boot” and starts OS-9. If using stock OS-9, the booter looked for OS9Boot on a physical floppy disk. If using an alternate booter, it could look for it using SCSI, IDE, Drivewire, or whatever.
  3. OS9Boot takes over, and OS-9 is running using whatever OS-9 hardware drivers it has to access floppy drives, hard drives, serial ports, etc.

That may seem like a lot of pieces, but it’s really only three steps.

CoCoSDC Changes Everything

Historically, the only way to boot CoCo OS-9 was through the “DOS” command, whether that be the standard version that loaded from a physical floppy drive, or a modified version that loaded from a hard drive. There was nothing that required this to be so — it was just how it was done.

When Jeff Vavasour wrote the first CoCo 3 emulator, he created a replacement for the BASIC ROM that did nothing but simulate the DOS command by loading a virtual track from a virtual hard drive image. This let OS-9 users who had no use for BASIC boot directly in to OS-9 without even needing the CoCo ROM files. This could have easily been done on a real CoCo, perhaps by replacing the ROM on a KenTon SCSI hard drive interface with code that did nothing but boot OS-9. It seems likely this was done, but I never heard about it.

Recently, David Ladd began working to do this using the CoCoSDC. The CoCoSDC is an incredible floppy drive replacement that. Unlike RGB-DOS, it let you copy a standard floppy boot disk to a virtual .dsk image file and “DOS” boot from it. Both Disk BASIC’s floppy code and OS-9’s floppy booter code still think they are talking to a real floppy so “it just works.” But, another feature of CoCoSDC is virtual ROMs. There is 128K of flash onboard that can be configured to look like up to eight different 16K ROMs to the CoCo. It ships with SDC-DOS in bank 0, and pure Disk Extended Color BASIC 1.1 in bank 1

David wondered if he could just take the track 34 boot code and put it in ROM somehow, and thus never need a boot track again. By theory, this should be very simple, but If you simply clone all of track 34 and write that out to a flash bank (starting at $C000),  that won’t do anything but crash the system when the CoCo starts up and tries to execute $C000. Instead, $C000 needs to contain a small bit of code that will copy the boot track code (from just after it in the ROM) down to $2600, and then JMP $2602 to start it — just like DOS does. Easy!

With six available ROM banks in the CoCoSDC, one bank could have the KenTon SCSI boot track, another the Cloud-9 SuperIDE boot track, and another the Driverwire boot track. What a great idea!

But … there is a problem.

In the next installment, I will discuss that problem and how to solve it.

Penn & Teller’s BBS – MOFO EX MACHINA

Updates:

  • 2019-09-27: Here is an interesting read about Penn Jilette’s time writing for PC Magazine, which mentions his BBS and links to this post.

Before the public Internet and the World Wide Web, there were computer Bulletin Board Systems (BBSes). A device called a modem (modulator/demodulator) would turn computer data in to audio tones (modulate) so it could be sent across a phone line, and the modem at the other end would turn these tones back in to data (demodulate).

My first exposure to BBSes and modems was thanks to a local Radio Shack in Houston, Texas. They let me use their TRS-80 Model III to dial in to BBSes around the city. The salesmen there turned me in to part of a sales pitch. “This young man is currently connected to a computer across town…”

I never had a modem for my first computer, a Commodore VIC-20 that I received in 1982. I did, however, get to borrow a modem (from that same Radio Shack salesman) to use with my Radio Shack Color Computer I bought in 1983. That modem was a 300 baud (very slow, about the speed of a really fast typist) acoustic coupled version, which was the type with round holes on it that you would set a phone handset in so it could play sound to the mouthpiece, and hear sound from the earpiece. That’s right — you had to dial the phone yourself then set the handset down on the modem when the computer at the other end answered! (There were “smart modems” by then that could dial and answer the phone — that’s what the BBSes used — but they were vastly more expensive. I wouldn’t have one of those until years later when the price came down.)

But I digress.

Over the years, modem technology evolved, and they got faster and cheaper. BBSes were operating everywhere, and I remember calling them as late as 1995-1996 or so after I moved to Iowa. By that time,dialup internet was starting to spread, and soon calling a local BBS would be a thing of the past.

I miss my BBS days. I wrote one in 1983 that a cousin of a friend operated in Houston for awhile, and I ran my own several years later elsewhere in the state. I even started it up again (briefly) in Iowa. It was a fun time, and there was a greater sense of local community on them since most users would be from the local area (avoiding long distance charges).

Magicians Penn & Teller had a BBS of their own, too. It was called MOFO EX MACHINA. The following is a transcript of a dialup session I had with the system on November 24, 1990. Set your wayback machine to 300 baud (but hopefully 1200 by then) and read on:

CONNECT 1200
 
Remote V.1.3  
 
Connected.... 
Please enter your password 
............. 
Incorrect password 
Please enter your password 
............. 
Hello, FAN. 
11-24-1990 03:26:34 
Checking your terminal type ... 
Your terminal type is Universal. Please wait... 



pc-runner


.
.
.
.
.
(c) 1986,87 eXTended Software Services
(c) 1988 New York Municipal Computer Service Group
    Password series: Beta Trey


NYCDT                      Node 3                             XTPCSS v. 2.3

                 New York City Department of Traffic

         Employees are to take not that we are still testing
         this system and we are not yet ready to network this
         machine with the IBO-DEC 80 files.  Do not rely on this
         system as a sole source of information and do *not*
         count something filed here as "Recorded Diem" until you
         are notified to do so by your supervisor.

         We would like to thank those brave enough to help us
         work out the in-operatives in this system.  Remember,
         "We are rebuilding New York."

         Thank you for staying within the fifteen minute time
         limit, we are back-logged on reimbursments for phone
         expendentures.  These calls should be short enough to
         fall under the 'petty cash' heading on Form 36J3/201/6
         (available from Supervisor Bradley's Brooklyn office).

15 minutes Press any key -->

NYCDT                      Node 3                             XTPCSS v. 2.3

                 New York City Department of Traffic

         WARNING:  Any attempt to enter names for exception of
         parking tickets is ILLEGAL!  More importantly, before
         we bring this machine on-line it will be audited, save
         the favors until after we are up to speed.

         Notice: Meter maids applying for gun permits that were
         approved before January 21, 1988 please contact the
         assistant-supervisor's secretary: because of the
         Maynes-Fieldstein difficulty some permits were approved
         without official approval.


Press any key... except that one.


NYCDT                      Node 3                             XTPCSS v. 2.3

                 New York City Department of Traffic

  Verifying use-approval code.  Please stand-by.
  Checking...

  Usr apprvd.
  Accs denied.  Accnt clsd.

  Usr apprvd.
  Accs denied.  Accnt clsd.

  Usr apprvd.
  Accs denied.  Accnt clsd.

    Manual override/%THY!  MO:HCK@NYC


NYCDT                      Node X                             XTPCSS v.666

                New York City Department of Tra
                                            Tra
                                            Tra
                                            Tra
                                          --trapdoor activated--

          Thanks to bribes, kickbacks and the department in
          charge of tracking municipally-owned equipment
          (or lack there of any such department), we are proud
          to present a bulletin board with a real purpose...

14 minutes Press any key -->

W E L C O M E   T O


                    M O F O   E X   M A C H I N A




A public service bulletin board from the good folks
at the Buggs & Rudy Discount Corporation.

Mofo controls this bulletin board, telling you about Penn &
Teller and the ever-changing world in which they live in.  Why
not give it a try?

Press any key... except that one.

14 minutes Press any key -->

                        T E L L E R   T A L K
      Hello, and thanks for logging on.  This is Teller.  I'm writing
this installment in a hotel room in Baltimore on November 10th, 1990.
We're touring this fall, and this is my fifth hotel room, if you don't
count the one in Chicago by the ice machine that I moved out of so that
I could sleep.
      I am reading SUNDAY NIGHTS AT SEVEN the Jack Benny
biography/autobiography.  In dark type is interesting stuff from a
manuscript by Benny.  It's nice, good-natured stuff about the life of a
vaudevillian, radio star, and tv personality.  In light type (the bulk
of the book) is petty crap, poorly written (dictated into a tape
recorder?) by his smug, talent-free adopted daughter.  Oh, boy, at last
she has the chance to brag about being a spoiled brat and get back at
her demanding mother.  Unfortunately, every once in a great while, she
quotes George Burns or somebody else good; so you can't get away with
just skipping the light type.
      The tour is going gangbusters.  It's a bit eerie.  We land in a
new city.  We drive into town.  We walk into the theatre, which is
always distinctly different from the last one.  And there on stage is a
little microcosm that is absolutely the same:  our set.  It's almost as
if somebody picked up everything in my bedroom, even the waste basket


13 min [?,C,G,M,Q] --> ?
[C]ontinous, [G]oodbye, ,[M]ore, [Q]uit this file

13 min [?,C,G,M,Q] --> C


full of trash, and placed it, exactly as it was, in the middle of the
forest.
      My happiest extracurricular activity:  I heard a great band in
Milwaukee, The Rhythm Club.  Four women and a bass player who are all
amazing musicians and who, like NRBQ seem to be able to do ANYTHING they
want at the drop of a hat.
      Upcoming events -- Letterman on November 20th.  Our big special:
"Don't Try This At Home" on the 23rd.  Minneapolis, San Francisco, Los
Angeles, then a short vacation.  Ta for now.

13 minutes Press any key -->



What's up with Penn - 11/20/90

Well Mofo computer friends,  

I'm on an airplane flying to Minneapolis where we'll do our show
for a few nights.  I'm writing this on my Grid 1450SX, a major cool
computer that I get to borrow because I'm writing the back page for
"PC Computing" magazine.  The issue on the stands right now has an
article of mine on the back page with a little drawing of me.  The
picture is okay - my fat smiling face sitting at a computer but the
computer has a sticker that says, "Kiss Me, I'm User Friendly". 
I'm sorry, it was not my idea.  They didn't show it to me before it
was printed.  As a matter of fact this whole article was edited
heavily but they promised that won't happen in the future.  I've
asked Pie to get my original one on this machine so you can check
it out.  I've written my next four back pages already and you can
tell because the vast majority mention Uma Thurman.  That means I
had to have written them before I saw "Henry and June" where Uma
doesn't feature her Thurmans.  Since then, I don't talk about her


12 min [?,C,G,M,Q] --> C


much.  I hold a grudge.  I'll try to get all the "PC Computing"
articles on-line here so you can read them without having to buy
"PC Computing" but you have to promise that if you read them here
you'll write a letter to "PC Computing" and tell them how much you
liked my articles and how because of them you'll buy the magazine
from now on every month.  They've had someone cancel their
subscription and write a nasty letter because I'm too violent.  I
need your help.

We've been on TV a lot pimping the "Penn & Teller: Don't Try This
at Home" - If you have a Nielsen box, please watch it and nothing
else that whole week and if you don't have a Nielsen box, use your
own judgement.  I think it's a good special and if it does well,
they'll let us do it again.

This is the first thing I've written in a long time for the Mofo
machine.  Since the Wall Street Journal talked about it we're
trying to get it up and keep it good so, if you got any ideas - let
us know.  I'll be writing stuff for this area pretty often from now
on and maybe I'll even write something good but right now I'm on an
airplane and you know how that is.

I'll have a diet cola, no glass, no ice,

Penn

12 minutes Press any key -->

           P E N N   &   T E L L E R ' S   S C H E D U L E

Television appearances:

November 16 - Late Night with David Letterman
November 20 - "Live at Five" in New York
November 23 - Penn & Teller "DON'T TRY THIS AT HOME" on NBC at 8:00 PM

Live appearances:

THE REFRIGERATOR TOUR
November 21 - November 25    Minneapolis
November 28 - December 16    San Francisco
November 18 - December 31    Los Angeles


11 minutes Press any key -->

                      N E W   P A S S W O R D S

   There are a couple new passwords.  To keep things clear I'll
   just list them all.

   MOFO -- basic password, basic TTY terminal
   MOFOV -- for fans who can emulate a Dec VT-100 terminal
   MOFOC -- fans that want to skip the Cold Open screens
   MOFOCV -- combo of C & V, natch

   Let me know if there are more options you want.

                            Mofo

-- Some people have said that the vt-100 emulation isn't working.
I'll look into it and let you know why.

11 minutes Press any key -->

                     Join Penn & Teller's F.B.I.

They're three thousand nine hundred and fifty three point twenty
five miles below Manhattan, to be exact.  Coming at you louder
and louder from the Center of the Earth.

Want to know more? (Y or N): Yup


                     Join Penn & Teller's F.B.I.
              F A N S   B E L O W   T H E   I S L A N D

Penn & Teller, with the help of MOFO the Psychic Gorilla have
gone under, way under, to develop a fan club for all of you out
there who know these boys are onto something big.  Yeah, you'll
get bimonthly newletters, discounts on wild t-shirts, records,
tapes and videos, and someday (after they're out of style), there
may even be a button.  Gives you chills, huh?  You'll learn how
to swindle and humiliate like a pro, talk a blue streak about
funky new strains of music, pull crack-up jokes out of thin air.
Hey, you'll learn how to be cool.  This club's not for wimps or
Doug Henning/David Copperfield fans (redundant), your stomach is
probably not strong enough to join.  Think it over carefully.
Then GET DOWN, and send six dollars to:

Penn & Teller's F.B.I.
Earth's Center
c/o Box 1196, NY, NY  10185-0010


10 minutes Press any key -->

                            S E R V I C E
                      without the smile, for now

No, there is no electronic mail for now.  Talk to the Evil
Overload SweetiePie about this if you wish.  Don't bother
me, I just do as I'm told, when I feel like doing it.

There should be some fresh stuff on the board soon.  The
email probably won't return until I figure out a stable way
for it to operate, and perhaps not even then.

We're thinking about it.

November 1990:

Someone called in and trashed all the files on the hard drive.
We're not sure why, but we've taken some measures to make it a
little more difficult.  There are two announcements here, each
written by Penn and Teller.  Soon there will be a way for you to
write to them.



10 min [?,C,G,M,Q] --> C


-cs

10 minutes Press any key -->

                    A N O T H E R   W E L C O M E

    Glad you could squeeze in among the twenty calls a day that
    we've been getting.  Any comments you would like to leave for
    Penn & Teller should be sent with the electronic mail system.
    You have to log in with a name and password to use it.

Is this your first time on? Nope

 -- you said  to stop --
    by pressing a key



                   M O F O ' S   M A I N   M E N U

                This is Mofo's root menu, all submenus
               are accessed from here.  You can return
               to the previous menu from each submenu,
                       eventually ending here.


          Mofo ex Machina, version 3.0
          G: say goodbye (disconnect)

That was almost 25 years ago. Hopefully one day we can hear Penn tell us more about this BBS, and how it started and ended. Drop by Penn’s Sunday School (audio podcast) and drop him a note and maybe, if there is enough interest, he will make it a topic for an episode.

Preserving the past 8-bits at a time

There have traditionally been two types of computer owners: Users and Creators (programmers). In the early days of home computers, long before the existence of software stores, if you had a computer, you had to be a programmer to do anything with it — even if doing something with it just meant blinking some lights.

Soon, these Creators had become so prolific that they created their biggest creation: Users. By the time the home computer market exploded during the 1980s, there were people buying computers who would never create anything. Their technical skills may have only required them to know how to plug everything up and type some commands to load a program.

The days of the Creator as the primary computer owner have passed. Slowly over the 90s and 2000s, Creators became just a small percentage of the computer owning population. Many early Creators themselves went on to become Users as they no longer has the desire (or perhaps skills) to create the things they needed to make a computer useful. Why reinvent the wheel by writing your own word processor if you could just buy Word Star?

Certainly, if you were a Creator, you may have the only copies in existence of anything you created, whether that be a BASIC program, a love letter to an old girlfriend, or version of the Ghostbusters theme song you hand entered from sheet music.

If you were just a User, there is a much greater chance that someone else also has a copy of that Color Baseball you used to play so much on the family TV when you were twelve. However, relying on “someone else” to preserve it doesn’t always work. Today there is much software that has been lost, seemingly, forever. Even if you were just a User, it might be worth looking through all your old stuff you have in storage. You might have the only copy of something left in existence. (At least, until someone else does the same. But if you find it first, that saves them the work, right?)

As to myself, I was a Creator. I had cassette tapes and floppy disks and hard drives full of programs, documents, letters, music files, home movie scripts, song lyrics, ideas, and more. These are mostly items I have not seen since the 1980s as I moved from one piece of technology to another (cassette to floppy drive to hard drive), never looking back. I expect only the current “needed” stuff ever got transferred to the next new format. Sadly, some of the things I Created are now gone forever as the only floppy disk the contained them are unreadable.

If you still have some old tapes, diskettes or hard drives from an early computer, consider doing an archiving project. You never know what you might find.

In future articles, I plan to start sharing some of the really cool things I have found from my past, and sharing some tips on migrating your old data — at least if you are migrating it from an old Radio Shack Color Computer.

CoCo/OS-9 escavation update…

Floppies. Lots of floppies!

A few weeks ago I dug out my old Tandy Color Computer 3 and began the project of archiving all my old floppy disks to disk image files. I am using Darren Atkinson’s CoCoSDC interface for this project, and it has been an amazing pleasure to work with so far.

I have backed up probably well over 300 Disk BASIC floppy disks, and have hundreds more OS-9 disks to get to next. I am also dealing with files that are on Compact Flash cards plugged in to the Cloud-9 SuperIDE interface (I never bothered with a physical IDE drive by the time I got that interface in 2004), and even some on my old SyQuest EZ135 SCSI drive using a KenTon SCSI interface.

IDE, SD, SCSI and Floppy interfaces.
IDE, SD, SCSI and Floppy interfaces.

This mixture of controllers, device drivers and “hard drives” has given me much time to revisit how things worked back then. Right now, I have a fresh 128MB .dsk image on an SD card in my CoCoSDC and I am backing up an EZ135 SCSI disk to it. It is taking hours (and just finished as I type this), but the end result is an exact clone sector-by-sector, including any deleted files I may want to peek at again. (It would probably have been much faster just to use a file copy tool, like “arc”, and go “arc -am /h0 /sd1”).

Along the way, I have discovered programs I had forgotten writing. For instance, in my pre-OS-9 days, I knew I had written a MIDI librarian program for the Kawai K1 synthesizer. It was sold by Rulaford Research:

I wrote a MIDI librarian for the Kawai K1.
I wrote a MIDI librarian for the Kawai K1.

…but I had forgotten I wrote a Layaway program for an East Texas furniture store:

Apparently, I wrote a layaway program, too.
Apparently, I wrote a layaway program, too. This was before spell checkers, and as a teenager, my spelling were not good.

During my disk-cavations, I unearthed many more projects I had forgotten about. Some were completed and deployed (freeware tools, music demos, utilities), and others were work-in-progress items.

An unfinished CoCo 3 OS-9 3-D maze game inspired by the old "Phantom Slayer" by MED SYSTEMS.
An unfinished CoCo 3 OS-9 3-D maze game inspired by the old “Phantom Slayer” by MED SYSTEMS.

And so much more! I have also found old documentation to the Sub-Etha products, and discovered I wrote an MM/1 program I had completely forgotten about – MegaBanners (an updated MiniBanners, but using Joel Hegberg’s high-resolution font engine). Wild.

I guess since most of this was twenty years ago, and has been packed away since then, I can be forgiven for my faulty memories. It sure has been fun rediscovering things.

After a few more weeks, I expect to have all of my old floppies and hard drives archived to the CoCoSDC. After that, a huge project begins: sorting and organizing everything.

Once I get to this point, I plan to put together some .dsk images of the old Sub-Etha Software items for folks to check out. They will be made available as shareware with the hope of making a few dollars. We’ll see if that works in 2015.

More to come…

PCLEAR 0 to get more CoCo BASIC memory

Updates:

  • 2021-12-15: Added screen shot of BASIC ROM assembly.

On the Radio Shack Color Computer, Extended Color BASIC added new commands to access high resolution graphics modes. The following modes of the CoCo’s Motoroal 6847 VDG chip (video display generator) were implemented:

  • PMODE 0 – 128×96 2-color (1536 bytes)
  • PMODE 1 – 128×96 4-color (3072 bytes)
  • PMODE 2 – 128×192 2-color (3072 bytes)
  • PMODE 3 – 128×192 4-color (6144 bytes)
  • PMODE 4 – 256×192 2-color (6144 bytes)

Extended Color BASIC allows a program to allocate up to eight 1536 byte pages of memory for graphics. If you wanted to use a single 128×96 PMODE 0 screen, you would want to reserve on page of memory for it (PCLEAR 1). If you wanted to use a 256×192 PMODE 4 screen, you would want to reserve four pages of memory (PCLEAR 4).

In BASIC, you could reserve eight pages (PCLEAR 8), and then draw on eight different PMODE 0 screens and flip between them, creating simple page-flipping animation. It was amazingly fun back then.

But this isn’t an article about graphics (though now that I think about it, I really want to write one).

By default, BASIC reserves four pages of graphics memory (6144 bytes) which, I guess, saves a BASIC program from having to do “PCLEAR 4” in it before using PMODE 4. Proper BASIC programs always did the PCLEAR anyway just to make sure the memory was available (for instance, if you typed PCLEAR 1 before you ran, the program would error out if it was assuming PCLEAR 4 was available). There have always been bad programmers.

The point of this article is to point out that, by default, BASIC has 6K less memory available to it. On startup, a 32K or 64K disk-based CoCo shows 22823 bytes free to BASIC:

On startup, the CoCo has 22823 bytes available for BASIC.
On startup, the CoCo has 22823 bytes available for BASIC.

64K NOTE: The reason BASIC memory is the same for 32K and 64K is due to legacy designs. The 6809 processor can only address 16-bits of memory space (64K). The BASIC ROMs started in memory at $8000 (32768, the 32K halfway mark). This allowed the first 32K to be RAM for programs, and the upper 32K was for BASIC ROM, Extended BASIC ROM, Disk BASIC ROM and Program Pak ROMs. Early CoCo hackers figured out how to piggy-pack 32K RAM chips to get 64K RAM in a CoCo, but by default that RAM was “hidden” under the ROM address space. In assembly language, you could map out the ROMs and access the full 64K of RAM. But, since a BASIC program needed the BASIC ROMs, only the first 32K was available.

To get the most memory possible for BASIC we would want to not reserve any graphics pages. However, the PCLEAR command does not allow typing PCLEAR 0. The best we can do is PCLEAR 1, which still reserves 1536 bytes. Doing” PCLEAR 1″ and then “PRINT MEM” will show 27431 bytes free. I am not really sure why PCLEAR 0 was not implemented, but without it, there is always 1.5 K of memory wasted for BASIC programs that do not use high-resolution graphics.

However, it is very simple to achieve a PCLEAR 0 by using a few bytes of assembly language. The short program I use to do it is this:

10 CLS:FORA=0TO8:READA$:POKE1024+A,VAL("&H"+A$):NEXTA:EXEC1024:DATAC6,1,96,BC,1F,2,7E,96,A3

This program reads the 9-byte assembly code and POKEs it in to memory, then EXECutes the routine. I chose to store it at memory location 1024, which is the start of the 32 column text screen. As a result, when it runs, it will put garbage on the first 9 characters of the screen. I just chose that memory since I knew no other program would use it (unless it was a temporary thing like this). If you understand the CoCo memory map, you can change that 1024 to any other safe location in memory and avoid having the text screen temporarily corrupted.

After running this, now a “PRINT MEM” will show 28967. Now we have 6144 bytes extra for our program! Big win.

However … 28K still isn’t quite the 32K we may have hoped for. This is because there is also memory reserved for the text screen (512 bytes, 1/2 K), cassette load buffers, BASIC input buffers, etc. There is additional memory reserved for Disk BASIC, so you actually have a bit more BASIC memory on a cassette-only system.

On startup, a cassette-based CoCo has 24871  bytes available for BASIC.
On startup, a cassette-based CoCo has 24871 bytes available for BASIC.

As you see above, 24871 bytes are available on a cassette-based CoCo on startup, which means there is about 2K of overhead to support Disk Extended Color BASIC. (Note to self: check these numbers.)

If we do the PCLEAR 0 on a cassette-based CoCo, we end up with 31015 bytes available to BASIC, and that is the most we can get (easily). If you do this:

PRINT PEEK(25)*256+PEEK(26)

…you will see what memory location your BASIC program starts at. After a PLCEAR 0 on a cassette-based CoCo, the value returned is 1537. The 32-column text screen is in memory from 1024 to 1536, meaning this is the very earliest in memory that a BASIC program can start. The only way to get more memory would be to extend the end, and we can’t because at the 32K mark, the BASIC ROMs begin. (Thus, 1537 to 32676 in memory is 31230, which is 215 bytes still missing. 200 bytes is reserved for strings, but a CLEAR 0 removes that, meaning there are only 15 bytes of BASIC overhead we can’t actually use.)

Not bad.

BONUS: Here is the nine bytes of assembly that my program POKEs in:

ldb #1
lda <$bc
tfr d,y
jmp >$96a3

Thanks to William Astle (Lost Wizard Enterprises, creator of LWTools) for translating my POKE bytes back in to the assembly code for me. It’ s been so long, I couldn’t remember what it was doing. In this case, it’s setting up the Y register and jumping in to a ROM routine that handles the PCLEAR, which I assume is being done to bypass the “?FC ERROR” check if the value of 0 is used from BASIC.

Here is the routine from Extended Color BASIC Unravelled:

BASIC word wrap test program

This article is part of a series. Be sure to check out part 1part 2part 3part 4 and part 5.

Here is a new word wrap test program. It has new test string cases, and now reports the code space used and variable memory used in addition to time. In order to properly report code space, it may require some tweaking (unless you have it entered 100% byte-for-byte like I typed it). I will make a .DSK image available for download soon.

Your submission should be a subroutine that starts at line 1 and expects A$ to be the string to word wrap, WD to be the screen width to wrap to, and RETURNs and the end back to the caller.

The new test program records the start and end time (to determine speed), start and end memory (to determine variable usage), and displays the code size of the program minus the number of bytes of the test program (line 0, lines 100-end). It has the size of the “empty” test program (nothing from line 1-99) hard coded so it can reflect the overhead of your routine in those lines.

NOTE: The memory usage shown by this program is just variables, and not string space. Each variable used takes 7 bytes, and string data goes in the CLEAR xxx block of memory. If memory used shows 16, but you had to do a CLEAR 600 to make your routine work, you do require more than 16 bytes but I couldn’t

Configuring the Test

  • CODE SPACE: The code space value printed is hard coded to subtract the size of the test program with a value in line 260. If you retype the test program and change any spaces or anything that would alter the size, that constant value needs to be adjusted. You want it to print 0 when you have nothing in lines 1-99 and type GOTO 280. If it does not print 0, adjust the value subtracted at the end of line 280. (If it prints 4, add 4 to the value that is there. If it prints -2, subtract 2.)
  • MEMORY: If your program uses more than the default 200 bytes reserved for variables, adjust the CLEAR command in LINE 100. If you are pre-DIMensioning variables you plan to use, you can also add them to LINE 100 but this will count against your code size. It is a good thing to do for speed.

The Tests

The test program will perform the following tests:

  1. An empty string.
  2. A short string that does not need to word wrap.
  3. A multi-line string of words that will need to word wrap. Its has words with characters ending in position 32 to test if the wrap routine uses that column without skipping extra spaces between lines.
  4. A string with a word longer than 32 characters and one longer than 64 characters to test chopping of long words (where it just splits it in the middle).

I believe these will test all possible conditions, and will help us compare all the versions for code size, variable usage and execution speed.

WWTEST10.BAS – Version 1.0

0 GOTO 100:REM WW-TEST 1.0
100 CLS:CLEAR 200:DIM A$,M1,M2,T1,T2,WD
110 INPUT"SCREEN WIDTH [32]";WD
120 IF WD=0 THEN WD=32
130 TIMER=0:T1=TIMER
140 M1=MEM
150 PRINT "EMPTY STRING:"
160 A$="":GOSUB 1
170 PRINT "SHORT STRING:"
180 A$="THIS SHOULD NOT NEED TO WRAP.":GOSUB 1
190 PRINT "LONG STRING:"
200 A$="THIS IS A STRING WE WANT TO WORD WRAP. EACH LINE CONTAINS EXACTLY 32 CHARACTERS. IT SHOULD USE THE LAST COLUMN AND SHOW FOUR LINES.":GOSUB 1
210 PRINT "WORD > WIDTH:"
220 A$="SUPERCALIFRAGILISTICEXPIALIDOCIOUS IS A WORD TOO LONG TO FIT ON ONE LINE. THIS ONE TAKES OVER TWO: ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890. DID IT WORK?":GOSUB 1
230 A$=""
240 T2=TIMER
250 PRINT"TIME TAKEN:"T2-T1
260 M2=MEM
270 PRINT"MEMORY USE:"M1-M2
280 PRINT"CODE SPACE:"PEEK(27)*256+PEEK(28)-PEEK(25)*256+PEEK(26)-767
290 END

 Current Submissions

Allen Huffman version 1 (MID$):

1 IFA$=""THENPRINT:RETURNELSEZS=1
2 ZE=LEN(A$):IFZE-ZS+1<=WD THENPRINTMID$(A$,ZS,ZE-ZS+1);:IFZE-ZS+1<WD THENPRINT:RETURN
3 FORZE=ZS+WD TOZS STEP-1:IFMID$(A$,ZE,1)<>" "THENNEXT:ZC=0ELSEZE=ZE-1:ZC=1
4 IFZE<ZS THENZE=ZS+WD-1
5 PRINTMID$(A$,ZS,ZE-ZS+1);:IFZE-ZS+1<WD THENPRINT
6 ZS=ZE+1+ZC:GOTO2

Allen Huffman version 2 (LEFT$/RIGHT$) – required additional string space:

1 IFA$=""THENPRINT:RETURN
2 ZE=LEN(A$):IFZE<=WD THENPRINTA$;:IFZE<WD THENPRINT:RETURN
3 FORZE=WD+1TO1STEP-1:IFMID$(A$,ZE,1)<>" "THENNEXT:ZP=0ELSEZE=ZE-1:ZP=1
4 IFZE=0THENZE=WD
5 PRINTLEFT$(A$,ZE);:IF ZE<WD THENPRINT
6 A$=RIGHT$(A$,LEN(A$)-ZE-ZP):GOTO2

Jim Gerrie version 3 (does not use the last character of the row):

1 C1=1:CC=WD+1
2 CC=CC-1:ON-(MID$(A$,CC,1)<>""ANDMID$(A$,CC,1)<>" "ANDCC>C1)GOTO2:C2=CC-C1:IFCC=C1 THENC2=31:CC=C1+WD-2
3 PRINTMID$(A$,C1,C2):C1=CC+1:CC=C1+WD:ON-(C1<=LEN(A$))GOTO2:RETURN

Darren Atkinson version 1 (VARPTR):

1 C1=1:CC=WD+2:VP=VARPTR(A$):VP=PEEK(VP+2)*256+PEEK(VP+3)-1:LN=LEN(A$)-1:SP=32
2 CC=CC-1:IFCC<LN ANDPEEK(VP+CC)<>SP ANDCC>C1 THEN2ELSEC2=CC-C1:IFCC=C1 THENC2=WD:CC=C1+WD-1
3 PRINTMID$(A$,C1,C2);:C1=CC+1:CC=C1+WD:IFC2<>WD ORLN+1<WD THENPRINT
4 IFC1<LN THEN2ELSERETURN

Darren Atkinson version 2 (INSTR):

1 ST=1:LN=LEN(A$)+1:FORPP=1TOLN:LW=INSTR(PP,A$," "):IFLW THENIFLW-ST<WD THENPP=LW:NEXTELSEELSEPRINTMID$(A$,ST):RETURN
2 IFLW-ST=WD THENPRINTMID$(A$,ST,LW-ST);:PP=LW:ST=LW+1:NEXTELSEIFPP<>ST THENPRINTMID$(A$,ST,PP-ST-1):ST=PP:PP=PP-1:NEXTELSEPRINTMID$(A$,ST,LW-ST)" ";:PP=LW:ST=LW+1:NEXT

Current Results (Time/Mem/Code)

  •  AH1 – 129 / 21 / 228
  • AH2 – 119 / 14 / 186 * actually 114 memory (CLEAR 300)
  • JG3 – 308 / 21 / 164
  • DA1 – 260 / 42 / 224
  • DA2 – 72 / 28 / 219

Fastest: Darren Atkinson’s #2

Lowest Memory Usage: Allen Huffman’s #1 and Jim Gerrie’s #3.

Smallest Code Space: Jim Gerrie’s #3.

Configuring the TP-LINK TL-WR702N nano router for Arduino

2015-02-07 Update: Added default WiFi password.

The two most-viewed pages on this site are often the following to Arduino articles:

The first one deals with a bug (?) I found in in the Arduino Ethernet library that prevented it from properly handling multiple incoming connections to the same port. The second was sharing my discovery of the $20 TP-LINK TL-WR702N nano router. It seems I am not the only one not happy that Arduino WiFi shields can be as much as $90, while cheap ethernet shields can be found for around $10.

The TP-LINK can be configured to connect to a WiFi network and then plug in to an Ethernet-only device and link it to the WiFi. Folks use them to get Ethernet printers on WiFi (such as the Lexmark printer I have — the official Ethernet module for it is $50, but I can use this TP-Link and be wireless printing for $20). I use one to get my Arduino on WiFi. Note that the Arduino will not have any control over the WiFi connection and won’t be able to select WiFi

This article is a quick guide to getting the TP-LINK set up for use with the Arduino.

TP-LINK TL-WR702N nano router box.
TP-LINK TL-WR702N nano router box, pictured next to a pen for scale.

1. Buy the TP-LINK WR702N. I got mine from Amazon for $19.99. It comes in a tiny box and is packed almost as nicely as an Apple product.

Inside the box you will find the tiny router (about 2″x2″x.5″), a micro USB cable, an Ethernet cable, and a USB power supply. There is also a mini-CD and a few small quick start guides. The guides are put together very well and have plenty of photos.

On the back of the TP-LINK unit will be the MAC address, but unless you have multiple units, you won’t need to know this.

2. Power up the TP-LINK by either plugging it up with the USB micro cable to a USB port (on your computer or a hub), or via the power supply.

3. The unit will boot up and after a few moments a new wireless network will appear that starts with “TP-LINK_xxxxxx” with the last part being the end of the MAC address of the router. Connect your computer to it. You will be prompted for a WiFi password, which you will find under the tiny barcode on the back of the unit. (It will be the last 8 HEX digits of the Mac address.) Give it a few more moments to connect and get an IP address. (Make sure you aren’t getting an internet connection some other way, like Ethernet. There are also ways to configure this router via Ethernet, but you’ll have to check TL-LINK guides for that.)

4. Open a web browser and go to: tplinklogin.net  It should prompt you for a username and password. You will find these on the back of the router, but they should be admin and admin.

TP-LINK WR702N login
Enter “admin” for the username and “admin” for the password.

5. You should see an admin webpage that is coming from your router. The first thing we need to do is configure the router to connect to your WiFi access point and connect to the internet. Click on Quick Setup under Basic Settings and click Next.

TP-LINK WR702N quick setup
Select Quick Setup.

6. The first screen is to select the Working Mode. We want Client, so choose it then click Next.

TP-LINK WR702N working mode
Select Client mode.

6. Next we will do Wireless Client setup and choose which WiFi network this nano should connect to. You can manually type it all in, but it’s easier to just click the Survey button so it scans for networks that are available. From that list, select your own WiFi network and then you will have an easy spot to enter your WiFi network password.

TP-LINK WR702N wireless client
Click the Survey button to obtain a list of available WiFi networks.
TP-LINK WR702N survey
Select your WiFi network from the list.
TP-LINK WR702N wifi password
Enter the password to your WiFi network.

7. The unit will then reboot and attempt to connect to your WiFi network. When it does, it will begin passing the WiFi connection out to the Ethernet port. To test this, turn off WiFi on your computer, and plug it up to the TP-LINK nano router via the included Ethernet cable. You will need to configure your computer’s Ethernet connection for DHCP. If it is working, after a few moments you will get an IP address assigned to your computer by the nano. Once the connection is made, you can test by going to Google.com or a known-working site.

8. Once you know it’s working, you should update the firmware on the nano to the latest. You can download the firmware here:

http://www.tp-link.us/support/download/?model=TL-WR702N&version=V1

Look for the latest version. It should look something like this:

TP-LINK WR702N firmware
Look for the latest version of the firmware for the TP-LINK TL-WR702N on the TP-LINK website.

Download this .zip file, then extract it somewhere you will be able to find it. It will create a folder with a few files inside, including a “.bin” which is the actual firmware update.

Log back in to tplinklogin.net and go to System Tools and Firmware then browse to the .bin file you just downloaded.

TP-LINK WR702N update
Browse to the .bin file you downloaded and update the firmware.

After it updates, the nano will reboot once again. On mine, this reset all the router settings, and I had to log back in and set it up again. There is probably a better set of steps to do this, but this is how I went through it and took screen shots so that is what I am sharing.

Once this is done, you can unplug and switch your computer back to normal internet connection. Now the TP-LINK can be plugged to power and the Arduino Ethernet shield and you can use the Ethernet library to make connections via your WiFi network.

NOTE: Since the nano requires using a computer and web browser to select which WiFi it connects to, this is not a portable solution. You cannot choose what WiFi to connect with (or the password or anything) from the Arduino. If you wanted to take your Arduino somewhere else and get it online, you would have to have a computer available to connect to the TP-LINK nano and reprogram which WiFi network it connects to. If you have a real WiFi shield for the Arduino, you can do this in software.

I hope these quick notes help…

CoCoSDC for TRS-80 Color Computer part 6

See also: part 1part 2part 3part 4, part 5 and part 6.

When we last left off, I was discussing how the CoCo’s drive controller accessed multiple physical floppy drives by using drive select lines.

In the early days of CoCo disk drives, each drive was configured to respond to the same drive select (drive select 1, for instance). A special ribbon cable was used which flipped some wires at each connection, moving different drive select lines from the controller to the same (drive select 1, for instance) line of the drive. The first plug (for DRIVE 0) would have drive select 1 go to that drive’s drive select 1 pin. The second connector would have some wires twisted and flipped so drive select 2 would go to the drive’s drive select 1 pin. This was done so you did not have to configure each drive (by opening it up and moving a jumper connector) to respond to a different drive selects.

It was this method with a “4-drive cable” that CoCo users could plug up four of the same single-sided drives (all configured as drive 1s) and where they plugged in on the cable would determine which drive they responded to from Disk BASIC.

If you used a normal (and cheaper!) flat cable that passed all four drive select lines to each drive, then the drives had to be configured to know which select they should respond to. A double-sided drive had three drive select options (1, 2 or 3) and also responded to the side select line.

As previously discussed, the CoCoSDC hardware honors some of these drive/side select lines, but SDC-DOS’ disk routines bypass several places where normal Disk BASIC would be using them to pass along to the drive hardware. Because of this, the standard POKEs we used on real hardware to access the back sides of double-sided drives from BASIC do not work. While the hardware is willing the software is not.

But, if you were to boot the CoCo using standard Disk Extended Color BASIC, it will work. The CoCoSDC hardware honors the first two drive select lines and side select. The problem is, without SDC-DOS, you don’t have a way to mount disk images or enable/disable the virtual SD card drives when you want to access a physical drive.

SDC-DOS handles communication with the CoCoSDC firmware. That firmware handles the disk image files and making them look like physical sectors to whatever software is running on the CoCo (Disk BASIC, OS-9, copy protected software using its own disk routines, etc.).

Fortunately, CoCoSDC designer Darren Atkinson has provided a simple BASIC program that can send commands to the CoCoSDC firmware. It’s not as simple as typing in DRIVE0,”GAMES.DSK”,NEW but it does allow the major functions to be done when you are not running SDC.DOS. He shared the following:

Below is a BASIC program I sometimes use when SDC-DOS is not present. It’s a little slow and definitely more cumbersome than entering commands in SDC-DOS, but it gets the job done.  Save this program somewhere on your CF card or SCSI disk so you can run it when using RGB/HDB DOS.
 

The program is:

10 OS=PEEK(&HFF7F):INPUT "MPI SLOT#";SL
20 IF SL<1 OR SL>4 THEN 10
25 SL=SL-1
30 INPUT "SDC DRIVE#";DR
40 IF DR<>0 AND DR<>1 THEN 30
50 LINE INPUT "COMMAND? ";C$
60 IF LEN(C$)<2 OR MID$(C$,2,1)<>":" THEN 50
70 C$=C$+CHR$(0):P=VARPTR(C$)
80 P=PEEK(P+2)*256+PEEK(P+3)
90 POKE &HFF7F,OS AND 240 OR SL
100 POKE &HFF40,67:POKE &HFF49,0
110 POKE &HFF4A,0:POKE &HFF48,DR+224
120 A=&HFF4A:B=&HFF4B
130 FOR I=P TO P+254 STEP2:POKE A,PEEK(I):POKE B,PEEK(I+1):NEXT
140 ST=PEEK(&HFF48):IF ST AND 1 THEN 140
150 POKE &HFF40,0:POKE &HFF7F,OS
160 IF ST AND 128 THEN PRINT "ERROR";ST
 (I sure hope WordPress doesn’t eat the program listing again.)
 
He provides the following instructions:
 
When you run the program you will be asked for the MPI slot number containing the CoCo SDC (1-4).  You could edit line 10 to remove the INPUT statement and just set variable SL equal to the slot number.Next you will be asked for the SDC Drive Number (0 or 1) to which the command will be applied. Enter 0 for commands that don’t apply to a specific drive number, or just press ENTER.Finally you will be asked to enter a command string. Command strings begin with a letter and a colon (:). Immediately following the colon is a path name to a file or directory on the SD card.

 

Commands Available:

D:  set current directory on SD card
K:  create new directory
M:  mount or eject a disk image
N:  create (if necessary) and mount a DSK file
X:  delete a file or an empty directory

Examples:

——————————————–
Set current directory to /GAMES/ARCADE

SDC DRIVE#? 0
COMMAND? D:/GAMES/ARCADE

——————————————–
Mount Donkey Kong image in drive 0

SDC DRIVE#? 0
COMMAND? M:DONKEY.DSK

——————————————–
Eject the disk image in drive 1

SDC DRIVE#? 1
COMMAND? M:

There is also a Rename command (R:).  That one requires a second null-terminated string (new leaf name) to be included in the 256 byte data block immediately following the first string.

 

C$ = “R:PATH/TO/OBJECT.EXT”+CHR$(0)+”NEWNAME.EXT”+CHR$(0)

This will be a key piece to handling RS-DOS doubled sided disks and backing up the individual sides to CoCoSDC disk images.

He also provided a way to call the additional DSKCON routines that SDC-DOS adds:

Here is a Basic subroutine which calls DSKCON to mount the file named DN$ into drive 1. Explanation of the code follows:

1000 DK=PEEK(&HC004)*256+PEEK(&HC005)
1010 SD$=”M:”+DN$+CHR$(0)
1020 P=VARPTR(SD$)
1030 POKE 238,PEEK(P+2):POKE 239,PEEK(P+3)
1040 POKE 234,&H85
1050 POKE 235,1
1060 EXEC DK
1070 ST=PEEK(240):RETURN

1000 assign DSKCON code address to variable DK
1010 build command string (SD$) to mount the file
1020 get pointer to the string descriptor (P)
1030 set DSKCON buffer to the command string data
1040 set DSCKON opcode to transmit a command string
1050 set DSKCON drive number to 1
1060 call DSKCON
1070 read DSKCON status result into ST and return

Meaning of bits in the status code:

Bit 7: set on any error.
Bit 5: set if file is already open in other drive.
Bit 4: set if file or directory was not found.
Bit 3: set on various hardware errors.
Bit 2: set if file or path name is invalid.

– Darren

You may be wondering why we might want to call SDC-DOS’s DSKCON directly. After all, if you are running SDC-DOS, you already have these commands. In my situation, I needed a way to detect if an image exist. There is no such call, so the only thing you can do is attempt to mount the image (DRIVE 0,”IMAGE.DSK”) and if it fails with a not found error, it doesn’t exist. On a CoCo 3, there is an ONERR command one could use to error trap that call so you might do something like this:

100 REM See if image DN$ exists.
110 ONERR GOTO 150
120 DRIVE 0,DN$
130 REM If here, we were able to mount, so it must exist.
140 PRINT "Image exists."
150 END
...
200 REM If here, we were not able to mount.
210 ONERR 'Turn off ONERR
220 PRINT "Error mounting image.":END

This works, but ONERR was only added in the CoCo 3’s Super Extended Color Basic. For the CoCo 1 and 2, this technique wouldn’t work. Thus, Darren provided me his DSKON routine so I could try to mount an image that way and read the returned status code.

Now I should have all the pieces I need to do what I want to do, which means this is a good place to say…

To be continued…

Even more BASIC word wrap versions

(Hello, Reddit.com visitors!)

Be sure to check out part 1part 2part 3 and part 4.

Darren Atkinson's second word wrap routine.
Darren Atkinson’s second word wrap routine.

Behold, the new champion of BASIC word wrap routines! Darren Atkinson sends in this two line wrap routine which makes use of the INSTR() function to find spaces in a string. It uses more integer variables, but does not use any strings. And, it’s FAST! It parses the test cases with a count of around 60 — half the time of the previous fast version!  Size-wise, it clocks in at 231 bytes, which is five bytes smaller than his previous version. Jim Gerrie’s still has the edge in the size category, but to get this much more speed for just a few bytes more might be a worthy tradeoff.

Darren does note:

I’m not sure the speed increase will be as dramatic when printing strings with average length words.

– Darren

I believe this is because his routine zips through long lines immediately, but would spend more time searching for spaces in a normal sentence. I will do some benchmarks using normal sentences to see how it stacks up.

Here is the full version:

0 GOTO100
1 ST=1:LN=LEN(A$)+1:FORPP=1TOLN:LW=INSTR(PP,A$," "):IFLW THENIFLW-ST<WD THENPP=LW:NEXTELSEELSEPRINTMID$(A$,ST):RETURN
2 IFLW-ST=WD THENPRINTMID$(A$,ST,LW-ST);:PP=LW:ST=LW+1:NEXTELSEIFPP<>ST THENPRINTMID$(A$,ST,PP-ST-1):ST=PP:PP=PP-1:NEXTELSEPRINTMID$(A$,ST,LW-ST)" ";:PP=LW:ST=LW+1:NEXT
100 CLS
110 INPUT"SCREEN WIDTH [32]";WD
120 IF WD=0 THEN WD=32
130 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
140 TIMER=0:TM=TIMER
150 PRINT "SHORT STRING:"
160 A$="THIS SHOULD NOT NEED TO WRAP.":GOSUB 1
170 PRINT "LONG STRING:"
180 A$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1
190 PRINT "WORD > WIDTH:"
200 A$="123456789012345678901234567890123 THAT WAS TOO LONG TO FIT BUT THIS IS EVEN LONGER ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ1234 SO THERE.":GOSUB 1
210 PRINT"TIME TAKEN:"TIMER-TM
220 END

Hi approach uses a FOR/NEXT loop to scan through each character position. By doing an INSTR(A$,PP,” “) (PP being the position 1-length), he checks to see if that position would be past the end of the line and, if not, he updates the PP position so it continues from there. This lets the assembly BASIC routine rapidly scan for the spaces instead of the BASIC interpreter doing it one byte a at a time. Very clever!

Great job, Darren!

His routine gave me another idea, and I will be providing an updated test program to try a few other things and see how we all stack up.

Until then…