Update July 1, 2024. LoTW is back up! It is running slow, but it is available. Thank goodness.
--
When I wrote the article back in May, I hardly thought that LoTW would be down a month later.
Sadly, the outage continues.
My suspicions were correct, however, that this was something more than a simple networking problem. The ARRL has since admitted their network was viciously and uniquely hacked. I can certainly understand their caution to make sure that every system linked to LoTW is given a clean bill of health before turning the system back on.
Earlier this week, on Tuesday there was apparently a brief period of time when LoTW was accessible. A couple of my ham buddies managed to upload some contacts. They'll have to wait for confirmations when the rest of us can get in.
I do hope it is soon. I'm really missing this service.
Just over three years ago, I figured out how to Remotely operate FT8 using a product called RealVNC.
RealVNC had a Home plan that allowed up to 3 users and up to 5 devices for non-commercial use. Perfect for remotely controlled computers in a ham radio shack.
Today, without any notice, RealVNC disabled my Home plan, and I had to choose between paying each month for a plan, or adopting their Lite plan, which allows 1 user and up to 3 devices for non-commercial use.
That's fine. They allow me to use their secure remote access software without fees. I can understand they might want to change the terms.
The Lite plan fits my usage. I've only ever had two devices active anyway, and it's just me as the user.
But, without notice - that is just damned inconvenient. Since I switched plans, I need to visit each device and re-configure them to be part of the new plan. Which means I can't remote into those computers until that is completed.
FT8 has been a revolution. The technology has made DXing really easy. Or has it? I continue to be amazed at how much difficulty people have working DXpeditions on FT8.
Last year, there were DXpeditions to Bouvet (3Y0J), Crozet (FT8WW) and Sable Islands (CY0S). The most recent DXpedition to Glorioso Islands (FT4GL) has brought it all back to me.
Let's start off with a few observations on people trying to work these DXpeditions:
Wrong Cycle - It's amazing the number of folks trying to work DX that are calling on the wrong cycle. FT8 has even and odd cycles. Even cycles start at 00 or 30 seconds, and odd cycles start on 15 and 45 seconds. You always call on the cycle the DX station is NOT transmitting. Indeed, if you double-click on a decode of the DX station, WSJT-X will set up the correct cycle. So how are people getting it wrong?
Endless Calling - I've noticed some stations keep calling the DX after the DX station has QSYed or QRTed. A little bit of hopeful calling isn't unusual on Phone or CW, or even RTTY. But stations continue to call much later -- like an hour later, and they are still calling.
Calling without Response - Some stations don't respond when the DX station calls them. They keep calling instead of advancing to the next step. This can get really bad. During the FT8WW expedition, I saw FT8WW keep responding to the same station for more than 10 minutes. Each response had a different signal report. This made it clear that FT8WW was heading this caller quite well, but the caller wasn't hearing FT8WW at all. Instead, that station took up a valuable response slot for 10 minutes -- denying perhaps 20-40 stations from working FT8WW.
Confusing Fox/Hound (FH) and MSHV - Most DXpeditions using FT8 use either FH or MSHV in order to maximize the number of contacts they can make. It is easy to get confused with these two modes. They appear similar. Both allow for the DX station to transmit multiple FT8 carriers at the same time. FH imposes additional behavior to both the Fox and Hound ends of the contact. In particular, there are audio-frequency dependencies that FH enforces. But, it is perfectly possible to work a Fox station even if you are not in Hound mode. MSHV requires no special modes. And yet someone accused people of DQRM, calling FT4GL below 1000 Hz, when the DX was using MSHV, not FH.
What causes all these odd observations? I believe they all resolve to a single cause -- people are calling DX they cannot hear. That's right, people are calling DX stations they aren't decoding at all.
This is fundamentally wrong. I wrote about this years ago on how to bust a pileup. You cannot work DX if you cannot hear them. If you aren't decoding the DX station, stop calling. Yeah, that's hard, but your calls won't net you a contact, and you may be actively depriving someone who can hear the DX from making one.
I think FT8 has made some people lazy. They hear some DX station is active on some frequency, probably through a spotting network. So they switch to that frequency, set their watchdog timers to an hour or more, and enable their transmitter. Then they go off and drink a few cool 807s while their computer works the DX for them.
Farfetched? No, it explains all the observations above.
Be a good FT8 operator -- don't call DX when you cannot decode them. Wait until you can decode them reliably, just about every cycle -- then start calling.
May 16th, there was an issue with Logbook of The World (LoTW). I could not load the main page at all -- receiving an error indicating the server wasn't responding.
That's pretty normal stuff, actually. There are dozens of problems that can result in this kind of error, so I wasn't surprised. I figured the ARRL staff would address it quickly. But, after much of the day, I was still getting the error.
So, I sent a message to lotw-help@arrl.org, informing them that the web site wasn't responding, kindly asking when they expected it to be back up. I mentioned I was surprised there was no notice of the outage on the ARRL.org web site.
Later that day, the ARRL put up a notice that there was a service disruption involving access to the network, and that it affected LoTW and the ARRL Learning Center. They even updated it the next day, addressing concerns users had over information privacy.
But then, nothing happened. Not until May 22nd, when they updated the notice without really adding any information.
Now, part of this delay may be due to the fact that much of the ARRL staff were all out at the Xenia Hamvention. But, that was a week ago.
What gives? Sure, networking problems. Honestly, though, as a computer professional, networking problems generally don't take more than a week to solve. I'm beginning to suspect there's something more than the ARRL hasn't told us, but I can't be sure.
I'm really missing access to LoTW. In the last 20 years, it has really become central in my enjoyment of the hobby. I do hope I'm wrong, and that ARRL manages to fix this problem soon.
A50-3S standing tall and straight next to the house.
Last year, I moved the A50-3S out of the yard and up next to the house. I used a 19 foot mast made of two pieces of EMT. While putting it up the reflector bumped against the roof and turned askew about 15 degrees.
Never the less, it worked well. I worked a few Europeans and several South and Central American using this antenna.
Still, it needed a bit of work. A one-piece mast would be better, and I could straighten out the reflector when I swapped masts. A bead balun at the feed point wouldn't hurt either.
So, I researched these. You would not believe what a 20 foot piece of 1 1/2" 0.058 wall aluminum tubing goes for these days. A few years ago, I purchased a 12 foot piece of 2" diameter 1/4" wall 6061-T6 tubing for my gin pole. It was about $150, which seems right for such a substantial piece of metal.
But 20 feet of the thinner mast? They quoted me $500! If I went with the 1/4" wall, well that was manufactured with a different process -- extruded instead of rolled, so it would be $250. Ridiculous. There had to be another solution.
I did have 20 feet of mast in two 10 foot pieces. This was from an earlier experiment. I had an old Butternut HF4B that I had rebuilt, and was hoping to erect in Fulton County. I bought two pieces of Rigid Metal Conduit (RMC) for this purpose.
EMT and RMC are easily found at your local Home Depot. But it isn't exactly what you would call structural. EMT is design to bend. Easily. I have had some success using it as masting for very small, light antennas. The two pieces I used on the A50-3S lasted for over eight years, plus the several years holding up a 19 element 2m boomer Yagi. RMC is more substantial, and comes with threaded couplings to connect them together.
Two pieces of 10 foot RMC was $30 a pop, so this wasn't a cheap experiment. Even with the coupling tightened all the way down, the 20 feet of mast had a substantial wobble in the top section. I tried inserting a solid piece of HDPE. That helped, but not enough to hold up the HF4B.
It occurred to me that this might work with the A50-3S, even with the wobble. The A50-3S is held upright by a wall bracket at the eve of the house, well above the wobbly union. I just needed the vertical support, and not so much lateral rigidity. Besides, I already had $60 invested.
First order of business was to find the doggone things. I put them away three parsonage moves ago, and had hidden them well. They were hiding in my basement. After that, I had to locate the piece of HDPE, which I found in another box.
It all came together this week. My youngest daughter Lauren helped me to lower the existing A50-3S and mast to the ground. Off came the antenna and the feed line, and the old mast was disassembled and put away. Then I coupled the RMC together with the HDPE stiffener and taped the coupling joints against any water intrusion. With the A50-3S mounted on the new mast, the reflector was aligned with the rest of the elements.
For a balun, I used five snap-on ferrite beads. I measured these at about 100 ohms resistive at 50 MHz. Five conveniently fit on the 9913 coax from the driven element to the mast, so that is what I used.
A50-3S facing South East.
Swinging the new mast up into place without bashing the antenna against the house took some patience. The RMC mast is much heavier than the two pieces of EMT. Once vertical, I positioned the mast in the eve bracket and loosely connected the u-bolt clamp. Both my daughter and I lifted the assembly to the top of the railing. From there, I tightened the bracket to eliminate play, but loose enough to allow the antenna to rotate. I used a couple of extra 1/4" nuts as jam nuts so the bracket could not tighten or loosen.
The antenna is easily Armstrong rotated from the base. Eventually, I'll mount a rotator on the top of the railing and retire my arms.
A quick SWR check showed a 1.2:1 SWR at 50.313 MHz. The antenna is pretty broad. Minimum SWR is around 50.8 MHz at 1.07:1. I suppose I could mess with the matching network to get a better match on the FT8 frequency, but the whole bottom 2 MHz of 6m is less than 1.5:1.
The antenna is 28 feet (8.5m) off the ground with clear shots from the North clockwise to the South West. Points to the West and North West have to pass through the house roof.
In 1984, I was working at Hayes Microcomputer Products. They were the premiere modem manufacturer for small computers, back in the days when modems over telephone lines were a primary means of computer to computer and user to computer communications.
In my job, I created communications software to talk to the modems. The software dialed the modem, established connection, provided terminal emulation (my specialty), allowed for the capture of the data stream to files, printing, file transfer with the remote computer (using protocols like XMODEM and YMODEM), and other features.
These were the early days of personal computing. IBM introduced the PC in 1981, and it had rapidly evolved into a defacto standard computer, shoving out various CP/M designs from the previous decade. Personal computers were so new, people were trying to figure out what to do with them. Word processing, spreadsheets and other office applications had just been introduced.
Hayes was trying to stay at the forefront. We had a laboratory filled with pretty much one of every personal computer, and when new ones came out, we would buy one. In late 1983, we got an Apple Lisa. It was a very different kind of computing experience. It was a curiosity to us, and as there was no programming environment available, we didn't see how we could build software to talk to a modem. Plus, at the price point, there were few buyers.
The Macintosh
Though the Macintosh was introduced in January of 1984, I didn't get hands on one until the late spring of 1984. Yes, we brought one into the lab, and it immediately garnered a lot of attention.
While there were similarities to the Apple Lisa, the small screen with square pixels just seemed sharper and more distinct. The whole interface was friendly and approachable. We messed with MacWrite, MacPaint, and MacDraw. We printed on an ImageWriter, making appreciably decent images unlike anything we could do on another type of computer. There were several of us hooked and enthusiastic.
It's hard to describe those days. At this point, everyone has had decades to become familiar with computers that use a graphical user interface and a mouse or other pointing device to interact. Back then, it was a revelation. It was much more approachable than the command-line interfaces of the day.
As I described it to someone in the early 90s -- other computer interfaces required one to reach toward the computer. You had to learn the special language and commands of that computer. The Macintosh was the first computer that reached back toward you -- the user.
The Machine
The Macintosh was based on a 16-bit Motorola MC68000 processor, running at 8 MHz. This was more than competitive with the Intel-based IBM clones circulating at the time. This processor was a great choices by Apple. It had many registers and powerful instructions for manipulating the bit-mapped screen.
Biggest constraint was memory. The 128 KB in the Macintosh was shared with 24 KB used for the screen, several more KB for operating system usage, leaving about 90 KB to run your program. Most of the critical operating system routines were in the Macintosh ROMs, which saved space. Building a program of any sophistication was difficult -- It was very tight to work with.
The single 400 KB floppy disk drive was also a limitation. Trying to save a file to another diskette could produce an endless amount of swapping. It was the lack of addition storage that kept me from buying a Mac until the Mac SE/20 was introduced in 1987.
Next Steps
By summer, Hayes hired some consultants to look into the feasibility of developing communications software for the Macintosh. In just a few weeks, they had some rudimentary software going and concluded that it was quite feasible.
We were soon green lighted to create a product for the Macintosh.
In 1991, my employer moved to a new building. Before the move, we cleaned out storage closets containing old equipment. Much of this was obsolete gear. Things like pairs of "twiggy" disk drives removed from early Apple Lisa systems upgraded to 3 1/2" disks in 1985.
In one closet, we discovered something unusual. It was a complete Gimix III "Ghost" system. This was a 2 MHz 6809 system sporting a fifteen-slot SS-50 motherboard and eight SS-30 slots and floppy disks: a top-of-the-line 6809 system from the early 1980s.
By 1991, the company had no use for this equipment. I had the impulse to take the entire system home, but I didn't have room. My wife and I were living in a small house and the garage was already packed. She would not have been happy if I brought home a bunch of equipment.
Instead, I salvaged exactly one board -- a Gimix 256K CMOS Static RAM board. It sported 256 KB of memory, with several options, including battery backup. The rest was scrapped by an electronics recycler.
Obtaining the board, I tried it out in my system. I was able to map in 4 KB blocks of memory and test them. They all worked. I might use the additional memory as part of a virtual disk drive.
In 1994, I moved, and the entire system was stored away for over 25 years. Looking at it recently, I found it needed repair. Over the years, the backup battery failed and leaked electrolyte on the board and motherboard. Several Molex connectors are damaged, and need to be replaced. Some of the components show signs of corrosion from the battery electrolyte.
I removed the failed battery. I do hope the rest of the board still works once the repairs are complete. Perhaps I'll fix it in my retirement.
By March 1988, the MC6809E V1 card I designed in 1983 needed updates. I built an entirely new card with new features intended to run OS-9 more effectively.
CPU
A MC6809 chip simplified things with the on-chip clock oscillator. The chip handled M.RDY without extra logic, and the rising edge of the Q clock did not need delay.
Memory
The MC6809E V1 card had no on-board RAM. There wasn't room. By 1988, a number of manufacturers had 32 KB static RAMs in 28-pin packages. 64 KB of memory is realized with a couple of chips.
For the V2 board, I allowed for eight chips, totaling 256 KB of memory. This was a good compromise between cost and the space available. The memory is logically separate from the rest of the card -- decoding from the physical address and data bus, using appropriate buffers. In this way, the memory can be accessed by a bus master other than the CPU. It responds to physical addresses C0000-FDFFF or FEFFF, jumper selectable. For years, it held two chips -- 64 KB on the board -- with only 56 KB accessible. The six remaining chips were added recently, making 248 KB or 252 KB accessible.
Buffering
20-pin bus driver chips reduced the chip count, even with two sets of bus drivers, one for the CPU, and one for the memory array.
Program ROM
The design allows for a much larger ROM. The MC6809E V1 card originally had two 2KB 2716-compatible sockets -- one for a ROM and another for ROM or RAM. To make swapping OS-9 and BBUG easier, I changed this to a single 4 KB 2732-compatible ROM socket
For the MC6809 V2 board, the ROM can be a 2764, 27128 or 27256-compatible device, holding 8 KB, 16 KB or 32 KB, respectively. The larger ROM permitted more OS-9 modules to reside there, if desired.
As built, a 2764-compatible EPROM is used, containing a BBUG image in one 4 KB half, and the OS-9 ROM image in the other 4 KB half. A jumper selects which half is active. This is much easier than swapping chips to go between BBUG and OS-9.
Accessing the correct amount of the ROM requires clever decoding.
Decoder
A hard-wired decoder would limit the flexibility of the system, and it would be complex and difficult to change. Rather than discrete logic, the decoder consists of a Cypress Semiconductor CY2C291 2Kx8 EPROM. This is a fast device with a 70ns access time. The CPU address lines A5 to A15 are connected directly to A0 to A10 on the chip. The decoder is enabled with the logical OR of E and Q, which asserts during three quarters of the memory cycle. This way, the eight data output pins can be used as decoder selects programmable on every 32-byte segment of memory.
Three select lines are used: one for bus access (including the on-board memory array), one for the program ROM, and one for the DAT. Each select line is pulled up to +5v. Placing a 0 bit in the decoder ROM data array makes the select line active for that 32-byte memory segment.
Modifying the memory map becomes a simple matter of programming the decoder ROM. I programmed the following logical memory map:
0000-EFFF - Bus
F000-F77F - Program ROM
F780-F7FF - Bus
F800-FFFF - Program ROM
FFE0-FFFF - DAT (writes only)
This configuration is compatible with the existing ROMs for BBUG and OS-9, which require I/O at E000-E07F. It has 4KB of program ROM, except for the hole at F780-F7FF. This hole deserves a bit of explanation.
I/O Port Address Migration
BBUG occupies the top 2 KB of ROM. The OS-9 ROMs take up nearly 4KB. However OS9p2 doesn't use the last 128 bytes of that space. This unused space became an alternate location for the I/O ports. If the I/O ports moved from E000-E07F to F780-F7FF, the MC6809 could use RAM in the logical E block (E000-EFFF), for a total of 60 KB of RAM, up from 56 KB.
Moving the I/O address requires motherboard decoder changes and software changes to the BBUG and OS-9 ROMs, as well as revision to Flex09 and OS-9 I/O configurations. The V2 board decoder ROM would work with the existing motherboard, or with the motherboard and ROMs altered for the new I/O addresses.
Larger ROM
Once the I/O addresses are moved, the decoder can be reprogrammed to allow for more ROM space. This opens the option of moving OS-9 modules into ROM. The decoder allows the lower limit of the ROM to be changed in 32-byte increments. This allows an OS-9 system to be entirely in ROM. OS-9 would start from the reset button without requiring a boot disk.
DAT
Back side of MC6809 V2 card.
The DAT configuration is similar to the MC6809E V1 board, with one important difference. In the SWTPc MP-09 board, as well as my V1 board, the outputs of the DAT are inverted on the lower four bits (A12-A15), but non-inverted on the higher four bits (S0-S3).
This means that values programmed into the DAT must be one's complemented on the lower four bits (A12-A15), with the higher four bits (S0-S3) not complemented.
For the V2 board, all eight bits of the DAT are inverted on the bus. Thus, the value programmed into the DAT is the one's compliment of the highest eight physical address bits (A12-A15, S0-S3).
Which makes programming correct DAT values simpler, since the entire byte is complemented.
I introduced a hardware bug in the DAT decoder. More on this later.
Building
Rather than wirewrap, I opted to try something new. A technician from work gave me a couple of 3M Scotchflex Breadboarding kits. This breadboarding system was brilliant. Chip sockets connected to IDC pins. Wiring is accomplished by forcing wire-wrap wire between the IDC pins with a special tool.
It is way easier than wire-wrap, because there's no tedious cutting, stripping, threading and winding of wire. One lays the wire down and pushes it on to the pins. Wiring several connections in succession, such as with a bus, is a breeze. The results also look great. The IDC pins are low profile, so there's less chance of shorting a connection than with wire-wrap.
It's sad 3M discontinued this product. It was great. 3M has since re-used the Scotchflex brand on three other products.
Fixing the Bug
The MC6809 V2 board worked great. There were no wiring errors. I did find a problem with the DAT.
In the default BBUG and OS-9 configuration, the DAT is written once during reset and never touched. And that seemed to work just fine.
Then I started playing with an OS-9 driver called VDisk. It created a virtual disk from selected extended memory blocks. At the time, I had 56 KB of memory from the MC6809 V2 card, plus another 60 KB from the Digital Research Computers / Tanner card. That made possible a 60 KB virtual disk.
Every time I tried to access the virtual disk, the computer would crash. This took a while to track down.
I eventually realized the new decoder did not take into account the clock cycle when accessing the DAT. Transients on the R/W* line early in the clock cycle could cause bad data to be written to the DAT. After I added the missing gate, the Disk driver worked perfectly.
Usage
Like the MC6809E V1 board, this V2 board was exactly how I wanted it. There are only two jumpers.
The jumper at the top edge of the board selects the 4KB portion of the EPROM. This makes it easy to switch between OS-9 and BBUG. No more hassle of changing out chips - just move a jumper.
The jumper in the middle of the board, just above the decoder ROM enables the FE000-FEFFF block of on-board memory. This would be installed once the motherboard I/O addresses are moved out of the E-block of memory and would allow 60 KB of RAM to be used.
Future
Moving the I/O addresses out of the E-block gains 4KB more usable memory for OS-9. Perhaps I'll try that in my retirement.
Another fun project would be to put a full OS-9 Level I system into ROM. Unfortunately, all of the essential modules take up just over 16 KB of memory, so the division doesn't fall on a natural 4 KB boundary. This might cause a conflict accessing extended memory with the DAT. I'd also have to figure out how to program the decoder ROM. There are not many EPROM programmers that can program the Cypress Semiconductor CY2C291 devices, and I no longer have access to the ones I originally used.
OS-9 Level II
This design works well for OS-9 Level I. To run OS-9 Level II, which allows each process to have a full 64 KB address space, requires more hardware. First, a second set of DAT memory chips allows the user and supervisors states to have separate memory maps. Second, a means of switching between those maps automatically -- like when servicing and returning from interrupts. Third, would require ROM to be accessible from an extended memory address, and then mapped into the supervisor space.
Those requirements go beyond the scope of this design. Perhaps there's room for a V3 board. All of this assumes access to a copy of OS-9 Level II, which may be difficult to find.
To work on OS-9, I borrowed some 5 1/4" drives, and used the SWTPc DC-2 controller. This allowed me to boot up OS-9. Single-sided, single-density, 40-track diskettes hold about 100 KB -- they were quite limited on space.
Running OS-9 on single-sided, single-density 8" disks, the situation was a little better, as each drive has about 300 KB of storage. But my two-drive system was limited. Plus, I was something of an island. None of my friends using OS-9 had 8" disks, so I couldn't exchange data with them. It was time to consider 5 1/4" drives.
5 1/4" disk drives went through considerable evolution since their 1976 introduction. The early drives were single-sided, single-density with only 35 tracks. By 1987, double-sided, double-density drives sporting 80 tracks were common. These disks could hold about 640 KB, more than twice what my single-sided, single-density 8" drives held. (And more than single-sided, double-density 8" drives could as well)
Disk Controller
In August 1987, I designed a 5 1/4" floppy disk controller. The 5 1/4" controller is very similar to the 8" design, with appropriate changes for the disk interface.
A MOTOR ON* signal is generated any time the WD2797 is accessed, with a one-shot multivibrator holding that signal for 10 seconds. Another one-shot asserts the READY signal on the WD2797 after a second of MOTOR ON*. 5 1/4" disks always have the heads loaded, so HLD is tied to HLT.
Back side of 5 1/4" controller
Double-density is jumper-selectable to either follow drive select bit 7, or the SSO output. Side selection is controlled by drive select bit 6. Write pre-compensation isn't used, as it was unnecessary for 5 1/4" disks.
I built the controller the same piece of 0.1" perfboard that originally held the FD1771 disk controller for 8" disks. The board is a little bit smaller than the WD2797 controller for 8" disks, so it appears more densely packed. Wire-wrap techniques are used for the wiring, and a handful of connectors and discrete parts are soldered.
Drives
For initial troubleshooting, I borrowed the two drives and power supply from a Sage II computer from work, which I had to return. I needed my own drives.
How many drives did I need? I decided three drives would be sufficient -- one boot disk, and two working disks. This would allow me to copy disk to disk, while still having the boot disk with commands in place. (and no crazy disk-swapping for copies like the original Macintosh that had one disk drive!)
I bought two Tandon TM100-4 drives at a local hamfest. These were common surplus from Lanier word processing units at that time. When I went to buy a third drive, I could no longer find any. I ended up with a Mitsubishi M4853 drive. The specs of the drives are virtually identical, except the Mitsubishi is a half-height drive.
Drive Cabinet
5 1/4" Drive Cabinet
Finding a cabinet to house three drives was a problem. New metal cabinets are very expensive, particularly in larger sizes, and I couldn't find anything suitable on the surplus market.
September 1987, I built a wooden cabinet to proper dimensions for three TM100-4 drives. I used 1/4" plywood, reinforced at the corners with 1x1/2 strips. The bottom, back, sides and one quarter front panel are all glued together as one unit. The top screws on to the four corner posts. The finished unit is quite sturdy.
As originally built, the cabinet was plain unfinished plywood. I recently sanded and finished it with a couple of coats of polyurethane.
Inside the box, plenty of room.
Power comes from a 12 volt, 5 amp supply. 5 volts is provided from a single LM7805 regulator mounted to that supply. In retrospect, the LM7805 might be a bit over-taxed. I suspect the drives draw less power than their maximum specifications. Heat is removed from the cabinet by a small (but noisy) muffin fan on the back panel.
A power switch and neon pilot light round out the front panel, giving a clear indication the unit is on.
The controller and drives work great, easily formatting double-side, double-density disks using 80 tracks.
Drives & Software
In April of 1989, I revised all the disk drivers to handle double-density, double-sided drives. The BBUG monitor "D" command code was updated to look for double-density sectors, and the boot loader for Flex09 updated to read double-density, double-sided disks.
For OS-9, I modified an existing driver (FD2) for the Processor Technology PT69 to work with my disk controller and created a new boot disk with several drive descriptors. The drivers and descriptors allowed for 40-track disks (which required double-stepping of tracks, and adjusting the track register), and SWTPc format, where track 0 is formatted single-density -- as well as the standard, double-density, double-sided, 80-track format.
I updated the Boot module to handle double-density, double-sided disks and burned a new OS-9 ROM.
The result is a smart, efficient unit roughly the same size as the SWTPc 6800 Computer System cabinet. The fan is a little noisy, but was typical for the day.
Future
The Tandon and Mitsubishi drives only require 250 ms to get up to speed after MOTOR ON*. I can shorten the timing on the one-shot driving the READY signal.
If I can manage to find a second Mitsubishi M4853 drive, four drives would fit into the cabinet. I'd need to add a second LM7805 regulator for the 5-volt supply, and split the 5-volt output across two drives for each.
One limitation of the WD2797 is the track to track and head settling time. These drives can move track to track in 3 ms and need 15 ms for the head to settle. The WD2797, using a 1 MHz clock for 5 1/4" drives, can only do 6 ms and 30 ms, respectively.
Western Digital did manufacture another device, the WD1772-00. This was a 28-pin floppy disk controller for 5 1/4" drives that is software compatible with the WD179x and WD279x devices. The WD1772-00 allows faster track to track and head settling times -- up to 2 ms and 15 ms.
The biggest problem is finding one, as the WD1772-00 wasn't used in a lot of designs, and Western Digital stopped manufacturing them over a decade ago. Might be interesting for a V3 floppy disk controller card.
Twenty years ago, when I first started uploading my logs to Logbook of the World, I began to pursue the DXCC Challenge award. I created lists of confirmations that I had, and began to try to fill in the band / countries I was missing. This has continued for years.
In April of 2016, I gathered sufficient confirmations to earn the DXCC Challenge award. Since then, I've continued to pursue new band / countries practically every time I am on the air.
This month, I passed another milestone. Currently, there are 340 entities on the DXCC list. And the DXCC Challenge counts on ten bands, from 160m through 6m. That makes 3400 total items for DXCC Challenge.
I recently collected confirmations over 1700 items on the DXCC Challenge. That's the half-way point. It's only going to get harder after this.
I learned about OS-9 in early 1983, when it was new. What I heard mainly concerned BASIC09 and at that time BASIC didn't interest me. That was unfortunate. OS-9 is a miniature Unix clone, optimized for the 6809.
Baud rate generator and counter/timer board
Requirements
By fall of 1986, I tired of the limitations of Flex09, and started looking at OS-9. Bringing up an OS-9 system didn't have the same challenges as Flex09, since OS-9 can format 8" diskettes. OS-9 does have additional hardware requirements. It needs a periodic source of interrupts.
Interrupt Logic
The OS-9 CLOCK module has logic for several interrupt sources, using chips available at the time. The MC6840 programmable counter/timer chip, with three 16-bit programmable counter/timers, was one option. The MC6840 fit nicely on the bit rate generator board. The driver allowed two circuit variations.
The circuit I chose exercises all three counter/timers. Timer 1 counts 50,000 cycles, then trips Timer 2 and 3. Timer 2 counts twice and signals an interrupt. Timer 3 counts down from 90. In this way, Timer 2 provides regular interrupts every 50 ms on a 2 MHz system. Timer 3 counts interrupts and adjusts the system clock whether or not the Timer 2 interrupt is serviced every 50 ms.
ROMs
The OS-9 kernel has two modules burned into ROM: OS9p1 and OS9p2. I obtained two 2KB ROMs and programmed them with the images. OS9p1 resides at F800. OS9p1 initializes the kernel, then searches for installed modules, which are position-independent. The second ROM contains OS9p2, Init and Boot. Once OS9p1 finds the OS9p2 module, it initializes it. OS9p2 looks for certain key modules, like IOMan. If they cannot be found, it uses the Boot module to load the rest of OS-9 from a floppy disk.
Once initialized, OS9p2 uses the information in the Init module to start executing. During a soft reset, OS-9 does not always load from disk. If the modules are not altered, OS9p2 can find them and bypass the boot process.
The modular structure of OS-9 allows great flexibility. Modules can be in ROM or loaded from storage devices. The Init module provides the configuration to execute the first module.
Bootstrapping
With a little help from a working OS-9 system, bootstrapping was straightforward. The ROMs I started with were pretty generic SWTPc system ROMs. The MC6840 occupied the bit rate generator board. I borrowed a 5 1/2" disk drive and plugged the DC-2 controller into I/O slot 1, with the 8" controller in I/O slot 2. Armed with a single-sided, single-density 5 1/4" boot disk, I successfully booted OS-9. That was the hard part.
From there, I created a new 5 1/4" boot disk with drivers and configuration for my 8" drives. Booting from this new disk, I formatted 8" disks and moved the OS-9 files to them. I then created an 8" OS-9 boot disk with a new I/O configuration and drivers for both 8" and 5 1/4" drives. At that point, I swapped the floppy disk controller slots, with the 8" controller in I/O slot 1, and the DC-2 in I/O slot 2. (The Boot module is configured to find a WDC-compatible floppy disk controller at the address for slot 1)
At that point, I could boot OS-9 from my 8" drives, and was able to copy files from the 5 1/4" disks. Compared with bringing up Flex09, this was easy.
I tailored my configuration to suit my hardware, and updated the ROMs with customized modules.
Swapping BBUG/Flex09 and OS-9
While I was using OS-9, I would swap back to BBUG and Flex09 on occasion. This was a pain. I would swap out the two 2 KB ROMs and use a different boot disk.
In late October of 1986, I modified the MC6809E V1 board to use a single 4 KB 2732 ROM. This put all of the OS-9 kernel on one chip, and allowed room to expand BBUG. With this modification, only one chip was swapped.
Extended Memory
Working with OS-9 uncovered an issue with extended memory addressing. December 1986, I installed a 74LS21 4-input NAND gate on the SWTPc motherboard to decode the top address bits S0-S3. This placed the I/O addresses at FE000. With the MC6809E V1 board, this worked great with BBUG and Flex09. BBUG initialized the E-block of the DAT with a value F1 -- which the board would interpret as physical address FE000.
However, I found I could not boot into OS-9 any more. Turns out, OS-9 initializes the E-block of the DAT using a value 01, which the board interpreted as physical address 0E000. With the extended addressing decoder on the motherboard, the OS-9 Boot module could not communicate to the I/O devices. This forced me to disable the 74LS21 decoder.
User Experience
OS-9 Level I uses a single 64 KB memory space for the operating system, programs and data. That's not a lot of memory. Many OS-9 programs are small, being written in assembly language. Larger programs, like a compiler, load in as multiple passes, to conserve memory use.
Using OS-9 is cool. It is a real-time, multi-tasking operating system, first available in 1982. Windows wouldn't have comparable functionality until 1989 (Windows NT), and the Mac in 1999 (MacOS X). Like Unix, you can spawn off programs to run concurrently in the background.
Using a second serial port, I ran two users simultaneously, one from the main terminal, and one from the second serial port. I used a Wyse-85 terminal on the main port, and the old CT-64 on the second port. Amazing on an 8-bit machine with 56 KB of memory!
At some point, I hung a modem on the second port. I could leave the machine running at home and dial into it from work.
By the summer of 1985, my original CT-64 terminal felt limited. Sixteen rows of 64 characters didn't seem like enough. Especially when at work I regularly used screens with at least 25 rows of 80 characters. In 1977, terminals with such capabilities were around $1000 -- way beyond my modest budget. By 1985, much more capable terminals were available for about half that price. It was time to upgrade.
August of 1985, I purchased a Wyse-85 terminal for about $700 -- a good price for the time. The terminal offed a DEC VT-220, VT-100 and VT-52 emulator, so it was plenty capable. It sported 24 or 25 rows of 80 or 132 columns on the screen. I purchased the green phosphor screen.
The most important thing, however, about the Wyse-85 compared to the CT-64 was speed. The CT-64 was limited to a paltry 1200 bps. The Wyse-85 had a top speed of 38400 bps. Thirty-two times faster. The CT-64 would take more than eight seconds to write every character on the 16 x 64 screen. The Wyse-85 could write an entire 25 x 132 screen in less than a second.
The Wyse-85 was such a joy to use compared to the CT-64, I couldn't believe I hadn't done this sooner.
I did have trouble with this terminal when I tried to use it in the shack back in the late 1980s. The keyboard scan generated a fair amount of RFI. Putting several ferrite toroids on the keyboard cable helped a little, but did not eliminate the problem.
I still have this terminal. It's been stored in the original box since November of 1994. I hope it still works.
I was QRV in Gordon county briefly - only a couple of weeks. I managed to erect the 80/40/20m dipole I had up in Warren county, which previously flew over Fulton county. It was a cobbled-together mess, made from wire left over from the original 80/40m dipole, newer traps, and old insulators and rope.
Using the Mark III Antenna Launcher, I did a good job casting over a tree in the front yard. Weight sailed up over the tree and came right down beside the trunk. The 1/16" guide line went back out to the antenna launcher, and then the 1/4" nylon halyard came back over. Perfect.
At the far end, I had more trouble. Not wanting to crawl over a fence, I cast sideways to branches overhanging the edge of the yard. The first toss wasn't great, so I pulled it down. Second toss got stuck in the tree, and I lost the weight. I was down to my last antenna weight. I confidently tied it on, pulled back, let it fly, only to watch it sail off the end of the fishing line and into oblivion. Nuts.
With no weights handy, I couldn't use the antenna launcher. I opted to use a small hammer and toss the halyard over a branch about 20 feet up in the tree. At least I didn't lose the hammer.
The resulting installation sloped the dipole from about 25 feet on the south end, to about 60 feet on the north end. No matter - it would work. At least, until I could make more weights and get it higher in the air.
I used it to make about 100 contacts for the NAQP Phone in August, plus a little casual operating. Then I found most of it lying on the ground after a few windy days. Inspecting the remains showed that the wire between the 20 and 40 meter traps had broken. That particular segment was pretty old, being part of the original 80/40m dipole, and might have used wire from the ancient untuned doublet before it.
This meant that one of the 40m traps was still up in the tree. Looking carefully, I could see it about 50 feet up. Untying the rope, I could not get it to drop, and instead pulled the halyard to recover the rope. The wire ended up coming off the insulator, leaving wire and one trap stuck in the tree. Drat.
The rest of the antenna lay across the yard and lower driveway. I don't use that driveway, so I didn't think about it. However, some folks came to visit the parsonage and apparently didn't see the traps laying there. Two of the trap forms got crushed in the process. Doggone it.
I guess I have to rebuild this antenna from scratch, using new wire and traps. That will take some doing, as most of the parts are back in Gwinnett county. Plus, I have to make more antenna weights to put it back up.
In the meantime, I'm off the air in Gordon county.
WD2797 controller card for 8" Pertec drives in the Icom Peripherals FD360
The FD1771 disk controller works well with the Pertec 8" drives. The single-density drives each hold around 300 KB of data.
Single-density encoding is FM, which has regular clock pulses, with a data pulse placed between. A data pulse indicates a "1", a missing pulse is a "0".
Double-density uses Modified FM (MFM) encoding. It eliminates the clock pulses entirely, leaving only the data pulses. To keep synchronization during runs of zeros, extra pulses are inserted between each pair of zeros. Encoded in this way, the clock can be recovered from the data pulses alone.
Western Digital followed the FD1771 with the WD179x chips, which support double-density with a two device solution. The later WD279x chips offer the same features on a single device. Double-density allows 500 KB on the same disks, with the data transfer rate also doubled.
WD2797 8" Controller
Back side of the 8" controller
September 1986, I built a new controller using the WD2797 to support the Pertec FD400 drives. While the drives were designed for single-density, I hoped they would work using double-density.
In keeping with my other home brew cards, it's built on a piece of 0.1" perfboard with the Molex connectors epoxied to the bottom edge. Wire wrap sockets are used.
Naturally, I broke out the WWARP program I used years before to build the MC6809E V1 card.
The WD2797 design borrows from the FD1771 design. I kept the latching data bus buffer, but eliminated the redundant data bus buffers in front of them. The WD2797 performs the clock/data separation, which eliminates several gates. Fourteen total chips on this board, whereas the FD1771 board used more like eighteen.
Double-density is enabled through an option jumper. The SWTPc DC-4 controller used the SSO output to drive the DDEN* pin through an inverter. (SWTPc offered double-density before double-sided disks) One side effect of using SSO is the sector address markers will have side 0 for single-density sectors and side 1 for double density sectors.
Other designs used bit 7 of the drive select latch, controlled through software. SSO isn't connected to anything, as the Pertec drives only have one side.
A jumper at the top of the card chooses the DDEN* signal source: the SSO pin, or bit 7 of the drive select latch. Both paths go through an inverter, so double-density is selected with a 1 on either the SSO pin or bit 7.
Bit 3 of the drive select latch controls ENP - the pin for write pre-compensation. Generally, ENP would connect to the TG43 output of the floppy drive interface. Using a separate bit allows write pre-compensation to be enabled or disabled at any time, through software. I didn't know if write pre-compensation would be required or desired. It seemed like a good plan to allow write pre-compensation on any track, since the Pertec drives weren't designed for double-density.
Reading the drive select latch address returns the state of the INTRQ* and DRQ* pins, on bits 7 and 6, respectively. Using these separate bits allows more efficient loops than reading and interpreting the status bits of the WD2797. The SWTPc DC-4 introduced this feature, and is common to controllers of that era.
The WD2797 calibration starts by grounding the TEST* pin and checking three signals with a scope. A set of four pins at the base of the WD2797 chip bring these signals out making calibration easier.
To support the new controller, I re-wrote the Flex09 disk drivers to allow double-density operation.
Do the Pertec drives work at double-density? I don't know. Supporting double-density meant re-writing NEWDISK to initialize in double-density format. Before I figured that out, my interest shifted from Flex09 to OS-9, and I did not complete that project. But the card works great with single-density.
September 1985, I purchased a Kenwood TS-430S and became more active in amateur radio. In the apartment where I was living, I snuck wires out of a second floor window and began to make contacts.
In October, I got the notion to try some Radio Teletype (RTTY). I built a demodulator using a circuit I've forgotten. Perhaps it used a couple of NE567 chips. Having a demodulator, I needed to translate the five-level Baudot characters into ASCII that I could display on the terminal.
(I purchased a Wyse 85 VT-220 emulator terminal in August of 1985, so I was no longer constrained by the 64x16 screen and 1200 bps limitations of the CT-64)
RTTY Decoder
I wrote a program for Flex09 to decode 45 Baud RTTY by bit-banging a PIA pin. I couldn't use the MC6850 ACIA, because it does not support 5 bit characters.
A delay loop established character timing:
LOOP LEAX -1,X BNE LOOP
Each pass through the loop consumes 8 clock cycles. With the right value loaded in X, fairly precise timings could be accomplished. A value close to 250 would be 1 ms on a 2 MHz machine. By calling this loop repeatedly, timings of 11 and 22 ms are measured.
I connected the demodulator output to PIA Port B, pin 0. The program looks at this pin, waiting for a zero. Finding one, it calls the delay loop for 1 ms and checks again. If the pin is still zero, it waits 10 ms and checks Port B pin 0. A continued zero at this point indicates a start bit. The 11 ms total delay places us right in the middle of the start bit.
The next sequence waits 22 ms and then samples of value of Port B, pin 0. It does this five times. These samples are shifted into a byte value, which used to look up an ASCII character in one of two tables -- one for letters, and one for figures -- according to the shift mode. This character is then sent to the terminal, and we go back to waiting for a start bit.
The resulting program is about 300 bytes long. Despite the simplicity, I had little success decoding RTTY signals.
In hindsight, there are several reasons for this.
Decoding signals off the air that might have been noisy.
Demodulator circuit was completely untested and might not have worked.
No experience with RTTY, so signals might not have been properly tuned.
Precise value of the 1 ms time delay not known. I used values of 230 and 240, allowing cycles for other program logic.
At some point, I distinctly copied "RY RY RY RY RY RY RY" from someone, but not much else. Later, I figured out this meant my program, at least, was working.
Hardware Solution
In November 1986, I decided to use serial chip that could do five-level Baudot. The MC6850 only allows 7 and 8 bit characters, so I needed a different chip. The NS8250 could do 5, 6, 7 and 8 bit characters, and sports a programmable bit rate generator for all the common RTTY rates. Hence, I added an NS8250 UART to the baud-rate generator board.
Funny, though -- I never wrote software to use the NS8250. In February 1989, I removed the NS8250 and its associated circuitry.
I didn't become active in RTTY on the air until 2005, using Cocoamodem.
Some time in 1985, I had one of those moments I regretted.
I'd gotten my MC6809 system running in late 1983, running the Flex09 operating system on 8" floppy disks. I had a full set of documentation for several pieces of hardware and software. My new job kept me busy, so I didn't have much time to work with my system at home.
August of 1984, I began programming the Macintosh at work. We published our first product in March of 1985. The Macintosh was a revelation -- it completely changed the metaphor for computing. I saw early on that it was the future. But, I couldn't afford one right away. I wouldn't buy my first Mac until the summer of 1987 -- a Macintosh SE. I've only purchased Macintosh computers since that time.
In the late spring of 1985, I prepared to move to a new apartment. I had bulky boxes of documentation in my closet. I figured that I'd never do anything more with that MC6809 system -- the Macintosh was the future.
I threw nearly all of the documentation away.
Two months later, in the new apartment, I regretted my decision. There were things I could do with my MC6809 computer. I had to replace the missing documentation.
To this day, I'm not sure I found replacements for everything I had.
I graduated from Georgia Tech in the fall of 1983 and got a full-time job. By 1984, 20 KB of memory didn't seem like enough for the MC6809E V1 board. My attempt to expand the 8 KB MP-8M to 16 KB didn't work. And I never built the dynamic RAM circuits I designed. I wanted more memory.
Digital Research Computers marketed an SS-50 card designed by Tanner Computers in the early 80s. It sported thirty-two sockets for 2 KB RAM or ROM chips. These 2716-compatible chips were quite popular at the time.
I bought a kit for about $225 with a full 64 KB of RAM in June 1984.
Assembling the kit was straightforward, along the lines of the SWTPc kits. The board worked right away, with no soldering issues -- largely due to the excellent solder mask on the board.
For SS-50 systems, this board has several flexible options. The first 48 KB presents as three 16 KB banks that are enabled individually. Each 2 KB segment in the top 16 KB is enabled individually, allowing one to navigate conflicts in the C, D, E and F blocks of memory. This allowed for I/O on the motherboard, or perhaps RAM or ROM on the CPU board.
The board supports extended addressing on the S0-S3 pins. When enabled, the entire board responds as one 64 KB block. Each socket can contain either RAM or ROM chips, selectable by the jumper next to each chip.
Initially, I used this board without extended addressing as a 56 KB board. I later enabled extended addressing to access the full 64 KB, after modifying the MP-B motherboard to decode the 20-bit address for the I/O slots. This allowed me to use that 8 KB of RAM for a virtual disk drive, briefly.
I discovered some extended memory issues between BBUG/Flex09 and OS-9, so I disabled the MP-B decoding.
As pictured, the board has the E000 and E800 blocks disabled, with F000 enabled, and F800 disabled. This configuration was appropriate for the MC6809E V1 CPU board and MP-B motherboard without the 20-bit address decoding, although, technically, the E800 block could be enabled, and the F000 block would not be accessible after I modified the MC6809E V1 CPU board for a 4K ROM.
By August 1983, I had a working MC6809 computer with no storage. My BBUG monitor eschewed audio cassette tape. Floppy disk drives were expected -- BBUG included a Disk Boot command. Any disk controller needed to be compatible with that code.
In 1983, a friend of mine gave me an Icom Peripherals FD360 Dual Floppy drive box. A client of his had purchased the Icom, but opted to use another disk system instead. His client couldn't use the Icom box, but perhaps I could.
Icom was one of the first floppy disk suppliers with their "frugal floppy" system. The FD360 contained two Pertec FD400 8" disk drives, a couple of interface boards, and a large power supply. It is huge and heavy, larger than the SWTPc 6800 Computer System, and weighed about 70 lbs.
Pertec FD400
The Pertec drives differ from the popular Shugart SA800/801 of the same era. They have a 44-pin edge connector, as opposed to Shugart's 50-pin edge connector. The signals and power supply requirements are different. Icom's interface boards translated those connections into a 34-pin IDE connection, quite similar to what was later used with 5 1/4" floppy disks. There were a few important differences:
Data plate from the Icom FD360
- Step In and Step Out signals, instead of Step and Direction.
- Erase Enable in addition to Write Enable.
- 8" media data rates (250 kHz), instead of 5 1/4" data rates (128 kHz)
- Head Load signal (not present on 5 1/4" disks)
The FD400 has a single metal head, designed for single-density recording.
Western Digital FD1771
The FD1771 was the first in a series of LSI floppy disk controllers from Western Digital. It simplified the interface and operation of floppy disk drives. Designed for Shugart-style drive signals, it could accommodate the signals from the Icom with a bit of logic.
I had schematics for the SWTPc DC-2 controller, and borrowed from that design. The FC1771 data sheet convinced me that the data bus hold times meant data bus latching was required, so I had an extra layer of buffering on the data bus using a 74LS373 matched with a 74LS244 (for reads). These were on top of the pair of 74LS242s that buffered the data bus to the card.
Following the FD1771 data sheet recommendations, I used an external hardware clock/data separator. (The SWTPc DC-1,-2 and -3 all used the inadequate internal clock/data separator) I used the circuit from Figure 6 of the FD1771 application note. It has a 4 MHz clock, 74LS175, 74LS161 and a few other gates. Dividing the clock oscillator by two fed the FD1771 with 2 MHz necessary for 8" drives. A 74LS221 one-shot multivibrator supplied the head-load timing (HLT) signal after about 40 ms. A 74LS175 captures data bus D0 and D1 to a two-to-four decoder to allow drive selection -- up to four drives, but I only have two.
I built this controller using wire-wrap techniques on a piece of perfboard, with 30 pin Molex connectors glued to the edge. The same construction as I had used on the MC6809E V1 board. A 34-pin dual pin connector provided the connection to the Icom drives.
In my schematics, I included a 74LS221 one-shot to trigger the M.RDY line on the SS-50 bus when accessing the FD1771. But this pin is not available on the SS-30 bus. So I omitted the circuit during construction. The FD1771 did not need this additional delay.
The I/O slot memory map is simple:
01xx - Drive select latch (bits D0 and D1)
1000 - Command / Status Register (FD1771)
1001 - Track Register (FD1771)
1010 - Sector Register (FD1771)
1011 - Data Register (FD1771)
After building, I tested the controller by writing a few commands to the FD1771 by hand using the BBUG monitor. I could select each drive, move and load/unload the head. It seemed to work. Using the drives required a disk operating system.
Disk Operating System
At that time, 6809 systems generally ran TSC's Flex09 or Microware's OS-9. BBUG's disk boot command was designed for Flex09. OS-9 required a completely different set of ROMs. My friend Carl was already using Flex09, so that was my choice.
Upgrading from using cassette tape, a disk operating would seem like a bit step upwards. But Flex09 was very primitive, especially compared to the work I was doing with MS-DOS at the time.
Bootstrapping
SWTPc DC-2 Controller
Carl had Flex09 on 5 1/4" disks. As my disks were 8", bringing up Flex09 took some doing.
Carl gave me a SWTPc DC-2 disk controller, and loaned me his 5 1/4" drives for a couple of weeks. The DC-2 was surplus to his needs. He'd upgraded to double-sided, double-density controller, and the old controller was useless to him.
With the controller and disk drives, Flex09 booted up easily from the floppies Carl supplied. I just needed to get them on the 8" drive. The motherboard gave each controller a separate address, as they plugged into different slots. Some configuration changes let Flex09 know about the additional drives. Before anything could be copied to an 8" diskette, it had to be initialized. The 5 1/4" NEWDISK program didn't work for 8" disks as their formats were different.
I wrote my own version of NEWDISK. This required understanding the FD1771 Write Track command. NEWDISK generated all of the data for each track, with the proper address marks, gaps and codes that permitted the FD1771 to properly read and write the disk. Then it would issue a Write Track command to the FD1771 and the track data delivered. This process repeated for each track on the disk.
At the time, there was no defined format for 8" disks. Flex09 required 256 byte sectors. The 5 1/4" format used ten sectors per track in single-density. 8" disks had room for more. With very generous gap sizes, fifteen sectors per track fit easily.
After track initialization, NEWDISK would write the volume information, and then the boot loader into the first sector. A disk was made bootable simply by copying the Flex09 system files to the disk.
Experimentation
Reaching the point where I could boot Flex09 from my 8" disks, I reconfigured the system and gave 5 1/4" disks back to Carl. The work done on NEWDISK led me to experiment. With 77 tracks of fifteen sectors per track, my 8" drives held a little more than 288 KB each.
Reducing the gap sizes, seventeen sectors would fit on each track. This increased the storage capacity to 327 KB for a 77 track disk.
Doing some tests, I found that the Pertec drives were mechanically capable of 78 tracks. Trying to step out to the 79th track resulting in a very alarming klunk as the head reached its mechanical limit.
While I confirmed that diskettes formatted for 78 tracks were valid and reliable, I decided this was not recommended. Such diskettes might be unreadable on other disk drives. My final version of NEWDISK formatted 77 tracks, with either fifteen or seventeen sectors per track.
Success
By the fall of 1983, I had a working 6809 system, complete with 8" floppy disks drives running Flex09.
SWTPc 6800 front panel, sporting sixteen LEDs. Each LED indicates a 4 KB address block access. You can also see a yellow power LED was added.
The SWTPc 6800 Computer System sports a rather spartan black and silver front panel. Unlike contemporaries of its day, there were no lights.
I'd already modified the front panel of my computer. I mounted the CIS-30+ cassette interface inside the case, which accounts for the assortment of holes in the upper right. There's a yellow power LED next to the reset button. Before I went to the ISEF 1979, I replaced the power switch with a key switch. I added the yellow LED so I could tell when the machine was on.
While building the MC6809E V1 board, I decided to add some lights. Hooking up LEDs to the address bus didn't seem useful, since addresses change quickly. Plus, the DAT complicated the issue -- do you show logical or physical addresses?
I ended up with a simple solution. Running the top four CPU address lines into a 4:16 decoder, each LED indicator represents a logical 4 KB address block. This connects to the CPU board directly, before the address signals enter the DAT.
Board holding 74LS154 and LEDs.
I drilled the front panel for sixteen LEDs. On the backside of the front panel, I mounted a 74LS154 4:16 decoder and wired up the LED cathodes. The board is held in place by the LED wires. A 16-pin ribbon cable goes back to the CPU board and attaches to a socket.
This socket has address pins A12-A15 from the CPU, the VMA* signal, the DAT write decoder signal, +5 volts, and ground. The VMA* and DAT write signals go to the two Enable* pins on the 'LS154. This means the address must be valid, and not writing to the DAT to enable.
The LEDs anodes are connected together to a resistor to +5 volts. Originally, this was a 470 ohm resistor. I found that the LEDs lit very dimly. Each LED is not asserted all the time. VMA* is not asserted at all times, and pulses every clock cycle, which limits how bright the LED can illuminate. I decreased the resistor value and experimentally arrived at a value of 22 ohms.
The resulting front panel is informative. I can see when the CPU is busy-waiting on I/O ports, if it is crunching away at some calculation, or if it has crashed entirely. And if the CPU executes a CWAI instruction to wait for interrupts, all the LEDs go dark.
Login
