computer KO

A problem I didn't consider hard enough in advance is that a custom machine could run ONLY custom software. I had no clue how to structure a text editor and had to invent my own; same with the assembler and the paper & cassette tape storage system.

I put all the free space in the text buffer at the cursor, with the text before and after pushed into the ends, so that a typed letter went into the next free byte and DELETE simply backed up the cursor pointer. A side effect was that I could UnDelete EVERYTHING in free space by advsncing the cursor, whether or not I had entered it.

The assembler was built on a table of mnemonic codes with the numerical opcode as the index, which works fine for the simple 8080 set. It assembled line by line as an editor lookup and replace function, and also disassembled the same way, regardless of what was actually in the file. I had to watch closely and stop and reverse it when it spit out junk.

When I was done I had a large collection of useful editing primitives and subroutines. I still haven't seen a more capable macro facility than it had for reformatting text. jsw

True. I missed the first DQ and mis-translated the second. Full flub mode.

Verily.

That's cuz you're a Sun of a b.

That went PSA on me, Don, unless it meant "Do what I meant, not what I said/wrote."

:-)

I used (for the digital cassette tape drive) the Motorola hex format, which was fine until I started doing random updates of data files, and the summer temperatures (no AC in the house at the time) changed the tape speed relative to the clock speed, so I wound up replacing a record with another with the same number of bytes, but shorter on the tape, so the next read hit the end identifier (s0 was the header, s1's were the data records, and s9 was the end of file), so it repeated the previous record which was still in the buffer. :-)

Made floppies really nice when I got them. :-)

Interesting!

No practice of replacing the deleted character with a null? That would have lost the undelete function, but would have avoided gibberish. Did you start out by nulling the whole buffer before entering the first data?

The 6800, which I started by hand assembling, had relative branches -- either intentional, or as a result of a test condition, which could go ahead 127 bytes, or back 126, and these had to be calculated from the target address to the current one (well, the location after the current instruction and its operand, which could be one byte or two, for something like comparing the index register to a constant). So, for hand assembling, you had to put in a marker until you had asssembled your way to the target location, then check whether the offset could be held in a single byte. If not, you had to go back, make the opposite test, and branch over a jump instruction which would take you to the final target. With all the code in a single 1702 EPROM, it pretty much *had* to be within range.

Oh yes -- there was also a "direct page" addresses between

But finally having an assembler to do the bookkeeping made life a lot easier. :-)

And my first serious project was translating ASCII to Freiden Flexowriter codes -- a non-trival project. It took an entire 1702 EPROM for the look-up table, and a good part of another for all the code (I think -- it was done back around 1976 or so, so memory fades a bit. :-)

Sounds nice.

Enjoy, DoN.

Ayup. Currently Caldera Open Dos.

It happens, but very seldom. Too much error trapping in the software and if something untowards happens...it kills the servo amps via an inhibit and dumps the program right NOW!

You have to reload the software and enter the part file name before you can run it again. That also includes killing voltage to the servos via a relay.

Its pretty bullet proof.

Gunner

I was given a digital cassette drive and warned that it might break tapes. Instead I built an analog FSK modem and managed the files manually from the tape counter on a standard audio recorder, with big gaps between files.

I looked into using a WD1771 floppy controller and fooling it into believing there was only one long track of 256 sectors, each containing 256 * 16 bytes. STEP would rewind the tape.

Nope, I assumed I wouldn't confuse whatever I had entered with random noise. The funny thing was that there could be four files in memory simultaneously and I could undelete text left by a previously opened one. It looked normal so I had to be careful.

As a prank I could make the computer appear possessed, undelete revealed eerie warnings the user hadn't typed. I got the idea from a programmer whose screensaver occasionally flashed REPENT, THE END IS NEAR!

That was disconcerting the first time you're walking past and it suddenly calls out to YOU!

I missed having short relative jumps that enabled relocatable code. All 8080 jumps were long and absolute. I had to link multiple programs by hand.

That's the main reason I discontinued working on the computer. It had served its original purpose of teaching me how to design computer hardware and I didn't really need to learn how to write an outdated operating system or imitate the controller that comes on a drive.

jsw

Exactly -- with the last half implied.

Enjoy, DoN.

The tapes needed to have clear leaders so the BOT/EOT sensors would work -- or reflective tabs on the tape for the same function, depending. :-)

The AT&T Unix-PC (a 68010 based machine) actually did that. Called it the "Floppy tape". It used a QIC-60 tape (DC-300 IIRC) and had four tracks. It reversed direction at the end of each track. I forget how many "sectors" it managed to get on there. IIRC, total size of the tape with that format was 23 MB, so 44,921 "sectors" total, or

The one thing which that was missing (for the day) was any kind of SCSI interface. There was one (prototype) in the hands of another member of the newsgroup dedicated to the system. It was called Unix-PC,

It was a great system for hardware hackers, after the AT&T "fire sale", since there was a book available which documented the whole of the hardware and the program's eye view of it.

Maximum physical RAM was 4MB, as was the maximum virtual memory per process. Largest disk supplied with it was a 67 MB one, but information was spread around about a small hardware modification which would allow up to 190 MB (Maxtor or Priam full-height disks). The two limiting factors were the maximum number of cylinders, which was 1024 limited by the WD1010 controller chip, and replacing that with a WD2010 allowed going up to (and beyond) the biggest 5-1/4" MFM drive made. The other was a maximum of 8 heads/surfaces. A bit of wiring allowed accessing 16 heads instead. (There was a special jumper which told the OS that the mods were present.) Maximum of two drives (one external, of course). Floppy drive was built in and hidden behind the keyboard. It was a rather pretty looking desktop system -- a wedge beneath the monitor. A relatively primitive GUI called "UA". Green monitor. Built in modem and dialer, and software to keep track of Mr. Businessman's phone calls -- incoming and outgoing.

And one of the *stupidest* defaults in the history of computing, especially given the target market. :-)

The target market was the businessman. If you did not install an alternate editor (either vi with the optional development set, or a word processor), the default editor was ed(1). You click on a file and it fires up that editor, and loads the file into the editor. That one has no prompt, so you simply see a cursor blinking there. The only man page for it was the dead-tree one in the manuals for the (optional) development set. So -- Mr. Businessman is fumbling around with different keystrokes, leaving garbage in the file, and occasionally stumbling onto a command. He has *no* *clue* how to exit the editor, so he is likely forced into a reboot to get clear of it. :-)

Yes -- a bit tricky.

"Release key to detonate"

:-)

One of the reasons why I never went to the 8080. :-) I started out with a more friendly, and more regular instruction set. (Oh yes, there were a few undocumented opcodes, most of which did unreasonable things as the mirror image of reasonable things, like storing the contents of a register (8-bit or 16-bit) in the one or two bytes following the opcode -- a mirror of "Load Immediate" for A, B, or X.

But the really weird one was one which got dubbed "HCF" (Hang and Catch Fire). It tri-stated the data bus, and sequentially put every address on the address but, repeating and repeating. (Kind of useful for debugging address decoding problems, as you got a train of square waves on each address line from fastest at the LSB to very slow blinking of the LED at the MSB. I actually burned an EPROM with a reset vector which pointed right at that instruction, doing nothing else -- for use when wire-wrapping various controller systems.

I learned a lot from mine, and moved on to more complex systems, starting with the same CPU family -- and then cousins, uncles, and aunts. (6800, 6809, 68000, 68010, 68020). :-) The 68000 system was my first unix box -- v7 unix, as virtual memory was not supported until the

The 6502 is lurking in my little CNC lathe, and I really need to replace that with something smarter and with more storage capacity. Say an open-source LinuxCNC (used to be called EMC (Extensible Machine controller) before a storage company of the same name threatened lawsuits. :-)

Yes -- way off topic, but beats political flame wars. :-)

Enjoy, DoN.

The company bought an 8080 microprocessor training kit for the lab techs to try out. I was the only one to get through it, and they gave me an 8080 chip set and some used wirewrap proto boards. We could sign out other components for home projects, code 20, as long as they were educational and relevant to the company's products; no HBO decoders.

The better source was parts we had experimented with, which became 'unclean' and had to be kept out of the production area so I took them home after lab cleanups, for instance the precision resistors I checked the megger against.

I found a simpler way to measure diode breakdown voltage with it. The diode and parallel voltmeter solidly indicate the meter's 10 Meg input resistance when the diode isn't conducting at low cranking speed. As I speed up the crank to increase the voltage the resistance begins to drop when the diode leaks. The DVM reading when the needle dips is the reverse breakdown voltage at a few microamps, an important and otherwise hard-to-measure parameter for expensive high-power components bought second-hand.

The 8080 was fine with ROM code but needed improvement to run a general-purpose PC, and soon received it as the 8085 and 8088. The register architecture, memory model and little-endian syntax conventions were definitely worth learning as they have survived into the latest processors

"The instruction set is not typical CISC, however, but basically an extended version of the simple eight-bit 8008 and 8080 architectures."

It never bothered me that the registers weren't fully orthogonal, neither are my fingers. Limiting the capability of some registers allowed exclusively 1-byte opcodes.

jsw

Useful and enlightened.

Hmm ... those resistors I would be tempted to mount on a wall hanging between two binding posts, with the legend

Caution, Extremely High Impedance

in very visible letters. :-)

Hmm ... my favorite for determining PIV was a curve tracer. The first one we had (Tek 575, IIRC) would go up to 1.5 KV in both directions. I've got a plugin for my 7000 series 'scope which doesn't go that high, but also doesn't take up a ton of bench space or a cart. :-)

The 8088 was really the 8086 trimmed down to operate on an 8-bit bus, The 6809 had as much claim to being a 16-bit processor as the 8088 did.

The fact that the original 8080 multiplexed the address bus through a single set of 8-bit pins is one of the reasons the S-100 bus is so scrambled. MITS made the original design before the address demultiplexer support chip was available, so they did it in random logic, and things came out from this cloud of chips in a weird enough pattern so they just routed each address pin to the nearest bus pin, with no attention to the logic of the layout. Same for the data bus, with 8-bits outgoing on one set of pins and 8 bits incoming on another.

MITS' later machine, which I have, the "Altair 680b" had the address pins running in a logical sequence from one end of the bus connector (same 100-pin connector, but a different offset to keep someone from mixing boards from the two systems, which would not work. The data bus was a simple 8 bidirectional pins. Made it a lot easier to wire-wrap custom boards, such as the interface to the Oliver Audio optical punched tape reader, or the custom cassette interface. (And the expansion board for the bus was a vertical board which plugged into the

Well ... yes -- but the 6800/6809/68k family all use big-endian, which matches the "net order" for numbers. The SPARC family is also big-endian, and the Power PC (Mac for a while, and still IBM's AIX) had a software switch to decide whether it was going to be big-endian or little-endian -- normally set by the OS when it is loaded.

Full backward compatibility, resulting in the rather klugy segmentation registers.

Motorola bit the bullet when changing from the 6800 to the 6809, to give it a more powerful instruction set. And again, for the 68K family, which they kept with a standard instruction set (expanded as the part numbers grew).

The 6809 had some features in the assembler which would emulate the instructions which had been dropped to make a more general set (e.g. replacing a number of set and clear bits in the status register with a single 8-bit word which would set them all in one instruction. This allowed assembling of any program for the 6800 into the 6809 which did not need to manipulate the stack and registers directly. This obviously excluded the monitor program, which needed to do a lot of that. But most other programs could be dropped into the assembler, and produce a functional (but slightly larger) program. The exceptions were things like one of the vendors' assembly-code implementation of something like nroff. The supplied full source code, but when I tried to port it to the 6809, it blew up. (It also blew up when I modified the banner to mixed case.) I later discovered that they had some code disguised by the comments. Which used negative offsets from the end of the program/beginning of data area to run a checksum on the banner so someone could not easily steal it. Also, there was another similarly hidden one which ran a checksum on the first checksum code block. Once I found those, and figured out the offsets, and checksum values, I was able to make it work -- until I moved to OS-9 from DOS-69. Lots of work running a disassmebler on the code and comparing it to the assembly source. :-)

Also -- individual push and pull instructions were replaced by a single instruction which had an 8-bit operand in which each bit represented a register to push or pull, so a group would be saved or restored in a single instruction. (And as there were two stack pointers, it would always use the bit for the stack to save or restore the *other* stack.

Yes -- which has held back Windows' progression for a long time, especially as long as they retained the ability to run all the old programs. :-) It also kept the number of security holes larger. :-)

The 68K is a *nice* CISC, including single instructions which could access a two-dimensional array. You loaded one register with the starting address of the array, others with the X and Y dimensions, and yet another with how large an item was in the array (byte, 16-bit,

The 6800 had some of those. The 6809 added some relative branch instructions which could hold the offset in the lowest 5 bits of the OPCODE. It also had the 8-bit offsets of the 6800, and full 16-bit offsets as well, to allow a fully position-independent program of any size which would fit in available memory. OS-9 took advantage of that, along with putting all the data on the stack so multiple invocations of the same program could co-exist. And *any* program in OS-9 could live in RAM or ROM -- your choice. You needed enough RAM to handle the stack and the data areas, of course, but the binary code could all live in ROM. (I had quite a bit of my system in ROM, but other parts could be loaded from disk at need.) Once a program is in memory, any number of invocation share the same space.

Enjoy, DoN.

We wore out the Danger, 1 Million Ohms! joke quickly. The uninitiated avoided our ominous secret laboratory and techies knew better, so it had no target audience.

Mine too, but I don't have one at home. The spectrum analyzer already exceeds my quota for boat anchors. Even as the lab tech at Unitrode I didn't need a curve tracer often. I bought the megger to check the safety of old, disreputable motors and transformers and then looked for what else I could do with it. So far I've fixed one golf cart charger with its help. It showed that the transformer insulation was better than it looked and the NOS replacement ferroresonant capacitor could accept and hold 500V.

I can measure very low winding resistances with 1 Amp from a constant-current lab power supply and I think a Variac will find shorted turns, as abnormal magnetizing current.

I can't defend Intel's choices over Motorola's. I preferred the 68000 architecture too. The 8080 evolved from a calculator chip.

I have programming experience on the PDP8, LSI11, VAX, TMS9900 and its in-house TTL ancestor, 68000 embedded and in a Macintosh, PC\AT, and even the HP1000, designed a DRAM controller for the TMS320xx DSP, and I did a little with the PIC, MSP430 and Arduino. They'll all do the job, some aspects of it better than others.

The real question was which one(s) would be worth the effort to learn in more detail, both hardware and software. The Intel / IBM / Microsoft path was the widest, straightest and had the fewest thorns. The others were too narrowly focused.

I had to support the design engineer's religious preference, which was usually a PIC, TMS320 or an ex-front-office PC. They hogged the juicy Digital Signal Processor programming projects for themselves, but sometimes passed on the less interesting parts to me.

. I used that for the Oliver Audio

My bootstrap / monitor loaded in reverse order, top-down, so the final byte overlaid the Jump destination at the 00000000 reset location and started it running. Since assembled apps weren't relocatable one GO command started whatever was in memory. jsw

Which reminds me...one of my clients has a sign on his office door

" Premises Certified Velociraptor Free"

With the numbers penciled in on printed lines

Most people simply glaze over when reading it...I busted up laughing the first time I saw it and got a thumbs up from the owner.

Those are good. I would have preferred to see WARNING! on Don's.

Mine says

Sacrificial Maidens Wanted. Apply Within.

In my woodshop, the sign says "Measure Once, Curse Twice"

I had the pleasure of learning assembler on the 68000 as that was what my computer used and then we covered it on my Mech Eng course but as the computers in the engineering department were BBC micros they taught us assembler on the 6502. That was painful going in that direction and always a pleasure to get back on the 68000. The Motorola article about the design philosophy behind the 68000 is an interesting read, found it here

Never got on with Intel assembler and fortunately had to use it very little, largely just examining the odd bit of assembler, the last time being sorting out what checksum calculation a software provider had used. I found the checksum code in the exe by placing breakpoints and narrowed it down and found the code and as like much of the rest of their code they had wrongly implemented a CRC8. I was able to produce C code to mimic the error in new code so that new software would talk to the old hardware.

A chap I used to know was an extremely competent professional assembler programmer and said that the 68000 was his 2nd favourite processor, the most favourite being an esoteric silicon valley processor. All Intel chips were at the bottom of the list with x86 being at the bottom and every new x86 being added at the bottom. The sort of thing he used to do was when he was programming on a PIC he used a 68000 macro assembler to do it having written the macros to generate the PIC instruction set op codes, IIRC he admitted to getting one macro wrong but quickly sorted.

I get it, but the number is one digit too long. Perhaps he confused Cretaceous with Cambrian. I've done that, and it isn't pleasant.

Days..not years

O.K. We had a few new victims every so often.

How about the illuminated sign "Release to detonate" turned on by a pushbutton? :-)

As a plugin for an already in-house Tektronix 7000 series 'scope, it doesn't take up much room. And it is really light compared to the 575 (which was tube-based, for all that it was for testing semiconductors. :-) And at something like $65.00 at a hamfest, how could I resist?

They're nice for matching pairs of transistors out of a mixed bin of a given type. If you want a push-pull amplifier, better to have them matched.

O.K. The only one I have is battery powered -- maximum applied voltage is 50 V, and it runs from a 67-1/2V battery and a 1.5V D cell.

I wound up with a nice digital multimeter from HP which has four-wire measurement for really low resistances. (Another hamfest item.)

Nice mix of systems/CPUs. All of my assembly-language programming was 6800/6809 (and a 6802 for a minimal system to interface some friend's PET computers to Diablo HyType I daisy-wheel printers. (It just *had* to be IEEE-488, of course. :-) I also used that for interfacing a Fluke HV supply with binary input to selct the voltage to a HP desktop computer (9826 was it?) 9815? Somewhen back in that period. :-)

Better than nothing. I got to pick my CPUs at work, to play to what I knew well at home. :-)

O.K. The 6800 put the reset vector in the top of address space (normally in ROM), and usually dumped you into a monitor if a general-purpose computer, or directly into ROM for an embedded one.

The move from the PDP-11 instruction set to the 68000 one found a lot of bugs in BSD unix utilities. A lot of uninitialized pointers, which thus were pointing to address 0x00000. The PDP-11 apparently just shrugged and let you do it, but the 68000 slapped your wrist -- hard -- because that was where the various interrupt vectors lived. Fine for the OS to change them at need, but absolutely verboten for an application program. :-) So, over the years, as various applications dumped core, they found more and more of those uninitializd pointers. :-)

Enjoy, DoN.

Did he bother updating it daily? :-)

About 6.5 million years, more or less. :-)

Enjoy, DoN.

Nope...but done in pencil with the last 4 digits obviously erased and then rewritten many times....was a gut buster.

Ayup

(Grin)

Gunner