Fairchild Channel F

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Fairchild Channel F

Post by lidnariq »

I recently read this article on HackADay about the Channel F, which led to me going down the rabbit hole. (Of course.)

I'd already known about it having a framebuffer in an era when this was unreasonably expensive, but there are a bunch of weird things about this console.

Starting with the CPU: it has no address bus. Instead it has a separate 5-bit-wide control bus. These 32 different commands include things like "fetch the next instruction", "fetch the next instruction parameter", "set the return pointer" and a bunch of other instructions.
There are three¹ 16-bit pointers that the CPU expects the ROMs to track. And although there are instructions to set these pointers from the data bus (or to ask the peripherals what they believe these pointers are now), there's no reason that the ROM's concept of where things are has to agree with conventional linear addresses. Instead, you could have 65536 addresses that you can start execution at, more than just 65536 total instructions. Relative branches use their own control signal, so they don't even have to count against the same balance.

¹ instruction pointer "PC0", return pointer "PC1 / stack", data pointer "DC0", and there's an instruction where the CPU asks the peripherals to swap DC0 with another register.

Instead of having 16 physical address lines, the CPU provides two 8-bit wide GPIO (with pullups designed to be overpowered), and 64 internal 8-bit registers ("scratch pad"). These registers and the write-only framebuffer are the only RAM in the system.

edit: fixed this paragraph
The CPU has an accumulator "A", a 5-bit status register "W", a 6-bit internal pointer register "ISAR" (like PIC's FSR). Scratch pad addresses 0-15 and the ISAR can be copied directly to/from A. Addresses 0-11 can be decremented in-place. Addresses 10-15 can be copied directly to/from the external memory pointers. Address 9 can be swapped with the status register. The remaining 48 bytes of scratchpad memory have to go via ISAR, which makes it obnoxious and slow, but at least it supports postincrement and postdecrement.

And the mnemonics suck. Comparable to nocash's joke about "do TerRible branch"

The pixel clock of both the NTSC and PAL versions of the Channel F is approximately 2-ish MHz. There's bizarre logic in the NTSC version that multiplies the 3.58MHz clock by 8/7 (3.6MHz is XORed with the output divided by 4, meaning that each 4 master clocks become 3.5²) and - generating the same 4.09MHz dotclock that the NTSC VIC20 uses before dividing it by 2- and producing slightly fast scanlines of 224 color cycles. (In contrast, the PAL version of the console just adds a 4MHz crystal, generating perfect PAL scanlines of 2MHz÷128 = 15625Hz)
² In simulation, it looks like ^^^^....^^^^....^^^^....^.... The short pulse is safe, because it's the result of XORing the output of the divider with the divider's own clock source

Similarly, the vertical rate is entirely in terms of multiple scanlines of pixels - 4 for NTSC, 5 for PAL - so the PARs for the two regions should be NTSC=3:4 and PAL=59:80 (or basically also 3:4). It just generates a 264 or 320 scanline image. (Skipping the last or first two rows would require either a lot more logic or a counter that can be preset, and the row counter is just a 74'93.)

edit: added raster timing
Hsync is asserted during X=112 through 121 (10 pixels, 5µs PAL/4.88µs NTSC/4.7µs standard). Horizontal blanking from X=112 through X=7 (24 pixels, 12µs PAL (vs 10.4)/11.7µs NTSC (vs 9.5)). Colorburst from X=122 through X=127 (3µs PAL (vs ?)/2.93µs NTSC (vs 2.8)). The extra long back porch is a little odd, but I haven't found anyone else talking about this. There's no front porch at all: it goes straight from active video to sync pulse.

Colors aren't very precise. On NTSC, blue is just an inverted copy of colorburst, with the corresponding real-world delay of a 74LS part. (Maybe 10° hue?). Red is generated with an LC delay of colorburst, but green is just an inverted copy of red.

Vsync occurs during Y=64,65 on NTSC, and rows count 0...65. (i.e. vsync is asserted for 8 scanlines). Vsync occurs during Y=64 on PAL, and rows count 1..64 (vsync is asserted for 5 scanlines)

Composite sync is just hsync XOR vsync, so the timing of the falling edge that marks hsync starting varies between active field and vertical sync. No contemporary TV cared, but more modern ones may.

The framebuffer is stored in four 64x64x1 DRAMs, combined into 4 bits at a time that become two pixels of 2 bits each. Since so much of the RAM is not only off-screen but during horizontal sync, one 4-bit word is used to specify a palette for the upcoming scanline... but they only used 2 of those bits, so it's even worse. Since this is fetched at the end of each physical scanline, the top physical scanline of each 4-or-5 tall pixel should be using the previous row's palette... although I don't think I see this in existing videos I found. Then again, the choice of palettes makes it really hard to see this kind of error.

The master palette is quite restrictive - black, white, red, green, blue, light green, light blue, and light gray - and the per-row combinations even more so. (Your choice of black and white, or RGB and one of the pastels)
Last edited by lidnariq on Sat Jul 25, 2020 3:06 pm, edited 3 times in total.
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Fairchild Channel F

Post by Gilbert »

Checking the screenshots from Mobygames and emulating the games in archive.org I think I owned this system (probably a licensed clone system by another name). That's before I got Apple ][ clones and later, the Famicom.

Too bad it broke and was disposed of decades ago.
Post Reply