I also wrote a lot of 6809 assembly in the 80s- for broadcast character generators. I wrote a multi-tasking operating system for it at one point- I used the DP register to point to per-task local storage (exactly like errno in multi-tasking UNIX).

My co-workers went nuts with the PC-relative capabilities, but I didn't bother- those addressing modes were pretty slow.

We had a cool piece of hardware: an in-circuit emulator. The 6809 version of this one:

http://www.decadecounter.com/vta/articleview.php?item=1064

That thing was the bomb, because it had trace memory so you could watch what led up to an interrupt causing your system to crash. Non-symbolic though, you needed the linker map and assembly listings by your side to do anything.

There were some great tools for that platform. I used a different brand ICE, but also an HP1630D logic analyzer with a processor chip-clip and a built-in disassembler so you could see where your code failed. (Worked great for finding hardware problems too.)

So if all you have is a Tek 465 scope, you can make a poor-man's logic analyzer by connecting an oscillator to the reset pin, and trigger off of this pin on the scope. Then use the delayed sweep knob to scan through the bus, one or two bits at a time.

This is a cool trick! I plan to try it next chance I have my Tek 4 channel out for a play.

> I also wrote a lot of 6809 assembly in the 80s- for broadcast character generators.

I got into broadcast character generators in 1989. Mind telling me who you worked for, and what you worked on?

Video Data Systems- a small company in Hauppauge, NY. They made titlers "Chyrons", ad machines and community bulletin board things, oh and the NY Off Track Betting video stuff.

Oh, I bet you had this experience: 100s of monitors whining at near 15734 Hz, damaging your young ears..

I worked for Quanta in Salt Lake. They made the Delta character generator, and the Orion, and some others before my time.

Yeah, I've heard that whine. Haven't heard it in years, though. Both monitors and my ears have changed...

Did you ever go to the National Association of Broadcasters trade show? That was loud. Hundreds of monitors, but dozens of booths, each trying to play catchy audio loud to attract attention.

I used to work with a QCG-500 at a local TV station about twenty years ago. I can still pick out the way certain fonts looked at certain sizes on that thing. It eventually got replaced by a Chyron Maxine.

Prosumer and professional character generators are woefully underdocumented. Anyone wanna donate any old functional ones to me? I'll set up and make a Youtube series about them lol. I'd love to see them eventually be emulated in the way that classic game consoles and home computers have been.

I'm 40 years old and I can still hear flyback. I actually have a Roku Express+ hooked up to a 27" Trinitron. I miss the days of CRTs, except for their weight.

I am 52, and it's getting tough to hear flyback.

I miss CRT's too, and I have a couple. One, near my work desk, is a lightly used SONY PVM, high pitch Trinitron. I love to have movies playing on it when working. Above it, on a shelf, are a reasonable VHS that I use for capturing tapes and watching movies on as well as some not so special DVD/Blu-Ray player I should hook up via RGB, but is running S-video.

Rambling aside, I would enjoy a video series on character generators. Lots of us geeked out on broadcast details.

Personally, I would enjoy any tech info on how the characters were done and what trade-offs got made any why. Some of what was out there looked very good. Other gear, not so much. Bet it's a few minor details that differentiate those outcomes too.

It's been 24 years. I probably don't owe a duty of confidentiality any more. So...

We had descriptions of each character of each font in a scalable, vector form. To draw a character, we'd draw it as a bitmap (1-bit depth) at 4 times the size. Then we would shrink each 4x4 cell down to one 8-bit value (weighting the center more than the edges). That 8-bit value was the alpha (transparency) value for drawing the character over whatever was already there in the frame buffer.

When drawing (compositing) one thing over another with an alpha channel, we used true Porter & Duff compositing, with pre-multiplied colors. We had a custom ASIC that would do it, so it was fast.

One of the trade offs was the rise time (or number of pixels, same thing) of the edge of a character. Too fast and the NTSC video signal couldn't handle it (and you'd have visually obvious stair-steps on the diagonals). Too slow and the characters looked soft rather than crisp.

At VDS, there was 68000-based titler called Vidstar or Videostar, something like that. This was before the great DRAM price decline, so every effort was made to reduce the memory including the frame buffer. (on previous products they experimented with bubble memory and even shipped a product using CCD memory).

So the frame buffer was compressed using run-length coding. The hardware decoded it on the fly when generating the video. Anyway, we could get very high resolution this way with a tiny fast SRAM frame buffer, it looked great.

A problem was that even with the 68000, composing a page from text was quite slow: 10 seconds for single line, something like that.

One of the products was a teleprompter. To make smooth slow scrolling without complex sampling we moved the screen by changing the vertical sync position. This is not so easy to do well because the vertical sync detector in the monitor is pre-charged by the nearest horz sync (this is why NTSC has the double-rate serration pulses for interlace).

On the other hand, we did roll and crawl effects using fast 6809 assembly on other products. The font on this type was very crude- either fixed width characters like a terminal or semi-proportional spaced, where the width had to be a multiple of some number of pixels (so still character cells). You could get away with it on CATV bulletin board devices, but not in high quality titlers.

Cool. Thanks. That all makes a ton of sense.

It also explains some of what we would see on various systems too.

If, say target frame buffer was some multiple of the color clock, it would be 320, 640, maybe as low as 160 pixels. (We had a couple of those and it was crappy obvious)

That ramp seems like it needs to align with that clock too, or there would be color fringing. Avoiding it entirely is gonna be soft, or strict limits on color combos.

(How many TV newscasts went with blue and white?)

Going sharper would mean a potential color artifact amd or different ones, depending on the alignment between the color clock and the ramp pixel start?

Say it was a blue fringe. Placing the glyph on an even pixel start might generate a bluish artifact, and a reddish one on an odd pixel. (Assuming 320 pixels for illustration)

Good placement against say a blue background, maybe gradient to also mask even odd line effects...

Were there placement limits per glyph to keep these things consistent? Did you guys get down to that detail?

Some of the graphics seen near the end of SD were sweet! Like almost every issue woven into a nice looking, very clever package.

That emulator looks amazing. It must have cost a fortune at the time!

Here is another site with links to a price list:

http://www.iobium.com/applied_microsystems_em189_e.htm

$3750 in 1983.. $10,106 in today's money..

> Sign extension (SEX instruction!)

We were definitely into SEX in those days.

In the late 1970s I was working at Tymshare, and one of my tasks was maintaining the assembler and linker. (I think this was on the PDP-10 but it could have been another machine.)

We wanted a "weak external" feature, somewhat akin to a "weak reference" in modern languages: instead of failing to build if the external symbol was not defined in another object file, it would link OK but leave a null value that you would check at runtime.

The assembly directive for a regular external was EXTERN. I thought of calling the weak external WEXTERN but that looked silly. So I decided to call them Secondary Externals, with the directive being SEXTERN.

And as far as I know, no one complained!

I just finished a project that introduced features for both signal injection and signal extraction. So now we can enjoy both SIN and SEX, sometimes at the same time.

The 1802 had a SET X REGISTER (SEX) instruction, as well as a GET HIGH (GHI) instruction.

https://www.atarimagazines.com/computeii/issue3/page52.php

John Draper (Cap'n Crunch) once creepily invited a friend of mine (who was a strapping young lad at the time) into the back of a van to "execute some 1802 instructions".

Ah yes, I knew John well in those days. Not nearly as well as he wanted to know me!

We used to drive around in his VW microbus finding interesting payphones. Then when he was learning to program, I visited him once in a while at his place in Berkeley to help him with his code.

My motivation was that he usually had some decent weed. Then one time he asked if I wanted to "work out". That lasted about two minutes until I found out what he really meant.

Many years later, I ran into John at the Homebrew Reunion. He didn't recognize me at first, so I reintroduced myself and mentioned how we used to hang out and write code.

His eyes lit up and he asked, "did we work out?"

https://www.flickr.com/photos/geary/10861963196/

> (Integer) Multiply/Divide.

As I remember it, it had the instruction MUL, which did 8 by 8 bit unsigned multiply, but no divide.

Maybe the Hitachi CMOS version had it? I know this version had undocumented additional instructions.

EDIT: WP says it had hardware division:

https://en.m.wikipedia.org/wiki/Hitachi_6309

That is exactly correct. You beat me by 60 seconds, while writing up my comment, I saw yours after posting. Interesting, I wonder how many neurons I'm wasting on useless 8 bit instruction set trivia.

Same here :), but a beauty like 6809 is worth remembering.

Yes, and it actually is one of the easiest sets to remember because there are so few exceptions. Everything that you expect to be there is there and works like you expect it to.

I always thought of the 6809 as the Chrysler Cordoba of 8 bit microprocessors, with soft Corinthian Leather upholstery and a luxurious automatic multiply instruction.

https://www.youtube.com/watch?v=Vsg97bxuJnc

"I have much more in this small CPU than great comfort at a most pleasant price. I have great confidence, for which there can be no price. In 6809, I have what I need."

The BS marketeers come up with never ceases to amaze me.

I just got one of these on a flash sale Color Computer upgrade kit. Should be fun to bang around on one of these days.

Then you need to know POKE 65495,0 :-)

If I recall correctly, that instruction doubled the clock speed of the M6809, usually at the expense of making it go out of sync with the woeful 6847 video chip, putting colorful garbage on the screen.

When that happened, I think it was on the CoCo 1 and maybe 2. The three can do it with no worries.

And the 3 didn't use the 6847, but a custom ASIC.

It was OK on the CoCo2. ISTR doing it for some games I wrote in BASIC.

Good to know, LOL. We are so late on this chat.

Fun stuff.

Indeed.

I just got a nice, old CRT for use with my retro machines. A CoCo upgrade and jam session is in my future.

There is no divide instruction. You had to write a subroutine for that, you could mask it as a macro on a half decent assembler but the CPU did not have it natively, it did have 8x8 multiply.

Don't forget the addressing modes. The M6809 had double indirection even for two memory addresses!

Wonder how difficult it would have been to get OS/9 or Flex running on a custom build like this.

Probably not too hard. There's a port of NitrOS-9 to this crazy thing, for example: https://www.frontiernet.net/~mmarlette/Cloud-9/Hardware/Libe...

I haven't tried his CUBIX on his emulator yet, but there's a certain richness to systems that start with a full fledged debugger on the bare metal. And he's got his own assembler, Forth, BASIC, APL, C compiler...

OS/9 should be trivial to port, it was written with that goal in mind.

> Internal 16-bit registers.

What does this mean? Aren’t all registers (for any mainstream processor) internal?

It is really an 8-bit CPU from a bus (external connections) perspective...but internally, there were 16 bit registers (sort of...) Perhaps this was why he made the distinction.

The 8-bit A and B accumulators could be addressed together as a 16-bit D accumulator. The contents of A and B could be multiplied with the product stored in D. There were also two 16-bit index registers with advanced and versatile addressing modes, X and Y, along with 16-bit user and system stack pointers, U and S.

It's the link between 8-bit and 16-bit: at least that's what Motorola marketing said, look at the cover of this book:

https://www.amazon.com/MOTOROLA-MC6809E-MICROPROCESSOR-PROGR...

I have a copy of that book near me. For a very long time, Moto would send docs out for the mere asking. Free of charge. I got mine as a high schooler. Didn't use the mail though. Instead, I visited a local Moto office and they handed me the ones I wanted and I got to talk chips with the people there for a while.

For a small town kid interested in all this stuff, that made quite an impression. Instant Moto fan.

The 6809 and the 6502 had a 'fast register file' page aka the 'zero' page on the 6502 which could be relocated anywhere in memory in the 6809. These were looked at as an external extension of the register set and lots of instructions could use the data there as 8 or 16 bit data or pointers.

Not all. The Texas Instruments TMS9900 designed as a single chip version of the TI 990 minicomputer series had three internal 16 bit registers, but 16 general purpose registers in RAM.