❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

Forty Years of Personal Computing - V2 Floppy Disk Controller

By: AA4LR
31 August 2023 at 12:00

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.

Forty Years of Personal Computing - MC6800 years - Cassette Tape and BASIC

By: AA4LR
27 January 2022 at 13:00
Percom CIS-30+. Note that the handles of two
switches have broken off.
I don't have a lot of records about the early use of my Β my first personal computer - theΒ SWTPc 6800 Computer System. I purchased it in November of 1977, built initially with 8 KB of memory, shortly upgraded to 12 KB.

Around December 1977, I purchased the Percom CIS-30+ cassette tape interface. These interfaces allowed one to store and load programs on audio cassette tapes.Β 

The CIS-30+ had major advantage over the SWTPc AC-30 cassette tape interface. Like the AC-30, the CIS-30+ supported the 300 bps Kansas City standard, but it could also record and decode at 600 and 1200 bps. This allowed programs to be stored and loaded two to four times faster.Β 

Insides of the CIS-30+.
One early modification I made to the CIS-30+ was a small LED for the Tape On switch. This switch changed the serial input from the keyboard to the tape interface. More than once, I had left the switch in the on position and wondered why I couldn't type anything from the keyboard.

Originally, the CIS-30+ sat on top of the SWTPc 6800 Computer System. At some point, before I moved to Atlanta, I removed the board from the small aluminum case, and mounted it on the front panel of the SWTPc 6800 Computer System, in a space right above the power switches. This made the whole unit more compact, and reduced the number of cables that had to be dealt with.Β 

I've since removed the cassette interface, and the holes that remain in the computer font panel.Β 

The first program loaded was Rob Uterwick's Tiny Basic, which required 4 KB of memory. That was perfect for my machine, as it left 8 KB of space for programs.

Tiny Basic was distributed uniquely. Β The May 1977 issue of Interface Age contained a thin plastic record with Tiny Basic in Kansas City standard format. I jigged up a circuit so I could play the record on my family stereo and record it on a cassette tape. It took several tries to get the levels right, so the recording was readable. The magazine also had a hex dump of the program, so I verified that everything loaded correctly.

Tiny Basic was fun, but very limited - no string variables or functions. In the spring of 1978, I purchased SWTPc's 8K BASIC and the 6800 Co-Res Assembler / Editor.

Rob Uterwyk's 8K
BASIC Manual.
With a full-featured BASIC interpreter, I amused myself by entering games. I had a copy of David Ahl's 101 BASIC Computer games. The dialect of BASIC was slightly different than that in the book, so minor changes had to be made. Still it was fun. I also entered programs that were published in magazines. Hunt the Wumpus was one of my favorites. As was Lunar Lander.Β 

6800 Co-Res Manual.
The Lunar Lander game was amusing. It prompted you for an amount of fuel to burn at each step, as you headed toward the moon. One time I let the lander get really close, then entered 1.0E+99 -- the largest possible number -- as the amount to burn. The result must have caused some kind of weird numerical overflow, since the next step had the lander successfully on the surface!

One of the magazines published a Fantasy Adventure text game in BASIC, and I managed to get it running on my computer. At school we had a "Fantasy and Renaissance Fair", and my computer was featured running this game as one of the exhibits.Β 

Setting up the computer to run this game was an involved process. First, you had to load the BASIC interpreter. The first part of the 8K BASIC tape had a binary loader program (which was twice as fast as the Motorola S1 format). With that program loaded and executed, you would load BASIC. The second step, after BASIC was running, one loaded the game from a different cassette tape. Then one could execute the game. All of this was done at 1200 bps speed, and the process took nearly 30 minutes.Β 

Someone managed to kick the power button on the computer in the middle of playing, turning it off. I spent the next 30 minutes of the festival re-starting the game....


❌
❌