Happy Christmas Everyone.......

Or, as a Unisonic would display it

HAPPY 
CHRIST   HAPPY CHRISTMAS EVE
MAS EV
ERYONE   RYONE

Everything else

Having addressed the two major problems, there are some upsides.

The main one is the use of GI's CP1610 Processor (also used in the Intellivision). I've always liked this chip. I did some ARM assembler before it and there's actually quite a strong similarity between the two - the CP1610 is quite a nice device to program.
There are, however, problems.

Firstly the processor only operates when the screen is in 'blank'.

A NTSC or PAL TV Signal consists of 60 or 50 frames a second, consisting of 262 or 312 lines per frame. Video is displayed only for some of these (up to about 190 maximum in NTSC) - this comes from the signal driving a CRT whose beam sweeps left to right, top to bottom to paint the picture. When it reaches the bottom, it turns off and goes back to the top, this is the 'vertical blank'.

Each of the double character slots is 32 lines (according to the documents), six of these is 192 display lines, so the processor is only running (262-192)/262 = 26% of the time.  This gives us yet another handicap to overcome.

It does this so the GPU Chip can access the RAM when displaying the screen - so there are no "arguments" if the CPU or GPU want to read memory at the same time. Though most computers of the day avoided this in other ways, this one either can't or won't.

This might be because the RAM chip is accessed via the ROM chip rather than both being on the same physical bus as on virtually every other machine ever.

The Clock Speed is another thing I don't know. The intellivision clocks at 895Khz which is a speed directly related to the 3.58Mhz colour clock that NTSC uses. (a quarter of it). The Unisonic only has one Crystal, this has to be 3.58Mhz otherwise the colour won't work, so I'm having an intelligent guess that it too will be clocked at a quarter of this. This amounts to about 100,000 instructions a second, but because the processor is off most of the time it's more like 25,000 instructions a second which is pretty slow.

The CP1610 is also peculiar in that it is a 10 bit word instruction, so you have to use GIs ROM chips. (everything else being multiples of 8)

Just to complicate things further, the system memory is 8 bit bytes and byte addressed and the processor operates on 16 bit data.

Mattels' Intellivision, very much the big brother of this system, has 3 types of memory - 8 bit scratch, 8 bit graphics and 16 bit system. The Unisonic, though, only has 8 bit RAM, implemented using a pair of 2112s, a standard 256x4 Static RAM chip of the time. (2/3 of this is display memory)

This has unfortunate consequences. The CP1610's subroutine system works at its simplest level by copying the program counter register (r7) about like this.

              call MySubroutine
.
.
MySubroutine: <do stuff>
              mov r5,r7

The "call" instruction does not, unlike most other processors (4004 onwards, 6800, 6502 etc), save the return address on a stack. It copies the program counter (r7) into register (r5) and then does a jump. So to return from subroutine you copy the return address (in r5) back to the program counter (hence mov r5,r7)

Now, this works great, and is very quick, if you only have one level of subroutine call. So if you add another level in , that second one will change r5 when you do the second call, so your subroutine has to save R5 on a stack itself if it calls another subroutine (or itself recursively)

MyOtherSubroutine:
            mvo@ r5,r6
            .....
            call AnotherSubroutine
            .....
            mvi@ r6,r7

The '@' is indirection. The mvo stores r5 at a memory location pointed to by r6 (and r6 is then incremented). The mvi@ pre decrements, and reloads that stored value into r7 (the program counter) - you could copy it back into R5 and then copy it to R7.

Now, in the Unisonic it doesn't work. This is because the CP1610s support for "SBDB" - the system it uses to access 8 bit memory on a 16 bit data register, doesn't work for the stack pointer (R6). So you cannot use the standard CP1610 subroutine system (which is supported by the assembler) and you need four times as much code. You have to do it a byte a a time, save one half of the return address, then the other.

UnisonicSubroutine:
            mvo@    r5,r6               
            movr    r5,r3               
            swap    r3
            mvo@    r3,r6 
..
..
            mvi@    r6,r3                
            swap    r3
            xor@    r6,r3               
            movr    r3,r7               

So each subroutine call requires extra instructions and time. (the above code writes the lower 8 bits, then the upper 8 bits - swap exchanges the upper and lower halves of the 16 bit word). You can jump into a single instance of the exit code, but the preamble has to be in every subroutine.

This makes the 16 bit data on the processor almost completely useless. You can't use the subroutine system, and memory is byte accessed for the graphics (because 1 8 bit byte is the same as 1 character on the screen). You can use the SBDB system to access word data in memory but there won't be much of that - there isn't much scratch RAM so I would reckon most if not all the data access is done byte wide.

Oh joy.

When I write the emulator code I'm not actually going to code the SBDB because it is of so little use, which has the advantage of significantly simplifying it (there are no ROM Dumps, I'm doing the whole thing from scratch)

The sound is very much like the Channel F's. It can play one of three tones - 500Hz, 1Khz and 2Khz. These are quite high pitched (A in the standard scale is 440Hz) but this is just about sufficient for beeps and warbles and so on.

It probably would be better to have all of these an octave lower (2Khz is a very high pitch) but compared to the rest of the system, it's simple and it works.

The Graphics

Well, where do you start ?

A bit of history. The motivation from this console , I think, comes from the hand held card games systems that you could buy - stand alone systems with LCD/LED displays that allowed you to play Blackjack or Poker against the computer. Those of us of a certain age remember the LCD/LED/VFD Handheld games which were the predecessors of things like Game and Watch. For a few years they were everywhere.

This system is a television version of that - it's designed to play Card games on a computer.

Looking at the image, you might think, well actually it doesn't look so bad. The font is a bit odd looking, but it's got colour, graphics characters and the graphics resolution is much better than things like the Studio2 - far blockier and monochrome or Channel F - blockier and a few colours.

What you don't realise until you actually read the datasheet is how limited this is. This is all it can do.

The screen is basically in two bits. The left bit (the BJ2 column) is a fairly ordinary memory mapped screen. It's only 6 characters wide by 12 high, and it only displays 64 characters (mostly ASCII) but it isn't that odd.

It's the right side that's wierd. This is actually 13 characters wide, but only six high. Each character space is double the height of the ones on the left, so the Jack of Diamonds in the picture is one character slot)

Each of those squares can display one of three things. A card (the character pairs on a black/red background), a solid white square occupying the same space, or one of the 64 characters.

But the 64 characters (e.g. the YOU LOSE and the numbers) can only appear in the bottom half of the square.  So the "YOU LOSE" message at the top of the screen has to go there - it is impossible to move it to the row above so it is aligned with "BJ2" - the system is physically incapable of it. Also, if you look at the numbers 14,15,17 they are also aligned with the bottom 'suit' character.

All this is always displayed on a green background (meant to be a gaming table I suppose), with only those colours (White, Red, Black). 

So it is, almost, impossible to do Pong (see last post). The left hand side isn't wide enough. The right hand side only offers 6 characters resolution - you could possibly do an incredibly blocky one with about half the vertical resolution of the Microvision but it'd just look silly.

Below is what Unisonic Football (American Football) would have looked like. This isn't a mock up by me - this is seriously suggested by GI as a possible cartridge release. (I don't know if anyone ever wrote it, I suspect not).  The six character vertical resolution means that there are no 'inbetween' positions in the graphics, so if you changed your line of attack it would jump up or down the screen a lot. (The reason for using the suit characters as graphics is that there aren't any others in the font that aren't alphanumeric or punctuation)

It's actually mad. You can see how you might design a system for TV based card games. But it's completely insane not to change it just a little bit so that the graphics could be used for other things, or the background colour would change. You'd just be adding a few logic gates to the circuitry, the additional cost in an LSI chip would be microscopic. Half of the bit combinations in RAM memory are used - so it displays a white solid block for every character code from 128 to 255, you could use this (say) to split every solid white block into 2x3 bits, so you could get a 38 x 18 block resolution. It wouldn't be hard.

I really would like to know whose idea this was, and what was going through their head when they finalised the design.

Note: Amended ; the RHS is 13 x 6 not 19 x 6 - the whole screen is 19 characters across.

The Controllers

I thought I'd start with the Controllers.

Now this picture is actually misleading.

If you looked at it you might think, right, this machine only has 8 control buttons on it. The three on the controller and the two on the main unit.

Except it doesn't. It only has four things that would classify as control buttons, two for each player. So you could play Pong on it (actually, you can't for reasons I'll explain later) but you can't play anything requiring three button input (you could have press both simultaneously to fire)

On the main console itself there are two buttons. The orange one is the power switch. The big white one is a reset button which is connected to the CPU Reset, so it's basically the same as turning the power off and on.

One each controllers there are three buttons.  What you can't see on this picture (I couldn't find a sharper one) - unless you squint is that the black buttons at the top are also reset buttons. So of the somewhat minimal three buttons on each controller, one of them is useless - all it means is you don't have to reach for the system box when you want to reset the console.

The two buttons that do work are labelled "No" and "Yes".  As you can see, to compound the design decision they are logically the wrong way round - think about every dialogue box you see, the 'Yes' option is normally the Primary one.

There's a reason for this. If you want to be really cheap, you minimise hardware. The CP1610 processor has five pins, four external outputs (EBCA0-EBCA3) and one external input (EBCI). There is a test instruction (BEXT) which puts a value on these pins and tests the EBCI input.  So you can build a really cheap four button input by simply ORing the four lines together because you don't have to have a latch or decoder or multiplexer or anything like that.

If you remove the bits you have to have - the ROM Chip, the CP1610 CPU, the 8800 Graphics processor and the pair of 256 x 4 RAM Chips there's virtually nothing left. A 7402 (Quad 2 input NOR), a 7406 (Hex inverter) and a SN74367AN (A hex tristate driver).

(The first two suggest (perhaps) that they are Oring two lines together, inverting those outputs and using a third NOR gate to produce the result, possibly inverting again. What the Tristate driver is for I don't know - perhaps to deal with voltage loss on the cables ? Guess ?)

This switch layout is actually the only detail about this machine you can't derive from the component list.- which of those four Yes/No buttons is which CP1610 pin, and what the logic level is coming back in. You could use a NOR gate and test for button release.

I don't know this, so all the button testing will go through a routine which will standardise this.

The Worst.Console.Ever

Unisonic Champion 2711

Yes, my first reaction was "What ?" as well.

I actually first came across this (after a fashion) in Bitsavers.org, the repository of old technical documents.

For some reason I can't remember I was looking for the datasheet of the AY-3-8500 - the GI Chip that made Pong consoles cheap : the Pong on a chip which required a few discrete components to make a game console.

Mixed in it was the technical description of a chip known as the AY-3-8800. The idea - I think - was that this was a sort of interim chip between the hardware games - Pong, Stunt Cycle, Tank and so on that were about at the time - chips that could basically do one game and some variants, and the more sophisticated GI chips that came to be used in the Intellivision. It was a programmable graphics chip that was designed to be connected to a processor (it was designed with the CP1610 in mind - perhaps it should be called the Dimwittivision ?)

Out of interest, I read it, and almost uniquely for a chip datasheet it was funny. The idea that anyone, anywhere would spend money designing a console that would do this was ridiculous. Even from reading the spec you could see that such a machine would be - limited.

On the off chance, I googled for it, and to my surprise found that someone had and it had been (partly) documented through the work of David Winter "Mr Pong" and Sylvain DeChantal, aka SlyDC, FAQ writer for systems you've never even heard of.

The Unisonic Champion 2711 is the only machine ever to use this chip.  It's actually quite valuable despite it's sheer awfulness, because it is estimated that at most 500 of these were made (this is guessed from serial numbers on known machines), which makes it worth money on rarity grounds.

Let's not be totally negative. There are some upsides to this machine. Well, one. (The case design is quite nice, albeit it was nicked from one of their other machines, so perhaps that's two).

Even looking at this picture there is one obvious, gob smackingly silly piece of design, which makes it useless as a games machine.  If it had the same graphics and CPU hardware as a Playstation 3, you still couldn't play Pacman on it.

Next up. How it works. If "works" is appropriate....

Is this the worst console ever (Part 3) ?

The RCA Studio 2.

A truly awful piece of hardware. You can look at things like the Channel F and say, well that looks really outdated, really old fashioned.  And it does.

But that's with thirty years of development of games since then.

The truly amazing thing about this machine is that it was out of date when it was released, 35 years ago. The Channel F was released at the same time, and even then there was a chasm between the machines.  Colour. Passable resolution. Half decent controllers.

It's really an outgrowing of the early home machines the Cosmac/Netronics ELF and the Cosmac VIP - much of the hardware is the same. It's programmed in a  variant of Chip 8 which is still popular today.

I know far too much about this machine - I ripped the ROM out ten years ago and wrote the first emulator for it. So I know in great detail how bad it is.

This is what an RCA Studio 2 game looks like.  It's monochrome, 64 x 32 pixels.

This is what Studio 2 Space Invaders looks like.

I actually wrote this game in 1802 assembler and it's way better than any other Studio 2 game. This is the RCA Studio 2's Elite or Doom.

And it's still terrible.

But it is still recognisably Space Invaders though, and if you can ignore the rather primitive graphics it's quite playable. The games that come with it are awful.

Besides the obvious fault, it's got one sound effect - a sort of decreasing pitch wail. The controllers are pretty awful as well - two 10 button keypads.

You could make games a little better. Technically you could up the resolution to 64 x 48 which doesn't sound a lot but actually gives you enough pixel space to make a reasonable game. (You are stuck with the 64 pixels across unless you physically rewire the thing)

Having said that, you are limited by the 1802's processor which is dead slow - and because it generates the Video in a manner similar to the ZX80, only operates about a third of the time anyway. The hard bit with Space Invaders was actually physically moving the invaders across the screen (it actually removes all the bullets, scrolls the whole top 3/4 of the display and then redraws the bullets again - it's too slow to just move the invaders).

On Youtube there are several 'retro gamer' review channels that review this machine and they are incredibly insulting about it, not that it deserves better.

But actually, the worst console ever, even though it actually looks a lot better in screenshots, is worse than this.

Next : no more teasing, the machines identity will be released with an explanation of why it's so bad, because on the face of it, it isn't.

Is this the worst console ever (Part 2) ?

The Milton Bradley Microvision. The first real hand held console machine that had interchangeable cartridges. (You could make a case for the Entex Select-a-Game)  It's bigger than this picture makes you think - it's about a foot long. I've actually got a collection of these.

What makes it terrible ? Well, you can see the graphics resolution on this picture. It's 16 x 16 pixels, which makes games look like a multiplication table that's been shaded in. It's sound is a single channel beeper. It does have a rotary controller and a passable keyboard which wears out very rapidly. (Though this German one looks more solid.I think "Das Computer Spiel-System" is German for "A heap of old junk")

The games are very vulnerable to static so these aren't very robust. There aren't very many games to choose from. The cartridges are massive (the whole grey bit in the picture is the cartridge)

I had considered writing an MB Homebrew game for this Retrochallenge (maybe the next one). For such a simple machine it's actually difficult to program. The upside is the graphics are easy :)

To start with, it uses a TMS1100 4 Bit Microcontroller which is errr..... interesting to program. I did an entry for this retrogaming competition http://minigamecompo.weebly.com/index.html on a Simon (the Milton Bradley sequence toy) which is a TMS1000 (the TMS1100 is a double size TMS1000 with 2k ROM and 128 nibbles (4 bit units) of RAM) and it is challenging. The Microvision is tougher because the screen has to be continually refreshed otherwise it won't work - you don't just say "turn this pixel on", you have to tell the LCD Controller thirty times a second you want these pixels on. Then you have to do it with the opposite polarity on the LCD and if you get it wrong static builds up and it might stop working. (Hats off to the people who managed to get the simple Microvision games working. Simple things like (say) displaying a two digit score on the screen is hard)

A TMS1100 is so slow (about 50,000 instructions/second) that it must spend most of its time doing this. I don't think it's as hard as the Atari 2600, but it runs it close, and the 6502 is quite easy to program. Programming the TMS1x00 series requires you to think differently - you've got one level of subroutine call and its instruction set appears to be half missing. Better than the TMS1000 when you can ADD 1,6,8,10,15 as a constant but not 7 :)

The Microvision originally used the Intel 8021 (a predecessor of the well known Intel 8048) but changed because they couldn't get enough of them I think. This is much easier to code for than a TMS1100 but then what would be the fun if it was easy. Just to make things complicated again, the wiring for the rotary control appears to be different on different cartridges.

I did spend an afternoon trying to bully the ROM images out of a Pocket Simon - the TMS1000 is supposed to have a 'debug' mode that allows you to dump the ROM contents. which is vaguely described by its patent. Wiring it up to an Arduino worked (you could pulse the clock and watch the chip operate) but I couldn't persuade it to give up its secrets.  So not much chance of dumping the Microvision ROMs unless we find an expert (it definitely can be done)

But .... this isn't the worst console ever either.

Next time : the machine usually labelled the worst console ever. 

But it isn't.

Is this the worst console ever ? (Part 1)

This is the Fairchild Channel F. It's one of the very first consoles.  Sold in the UK as the "Grandstand Video Arcade"

It has a display resolution of about 100 x 60 pixels, and a colour palette that is a bit wierd. Those readers old enough to remember PC CGA games will get a sense of Deja Vu.

It does have nice controllers though.

The games look blocky, obviously and a the colour scheme makes them look odd. This Pacman  (actually a homebrew game) shows the problems. But it is still recognisably Pacman. This is about as good as it gets. The F8 CPU is a bit wimpish.

The sound is a bit pathetic - only three tones - but you can do something with that, warbles and beeps.


So, is this the worst console ever ? Not even close.

(The Channel F is emulated by MESS and the majority of the cartridges have been dumped)

Preamble

Before starting on the project proper, I shall look at the various candidates for the worst ever games console. 

Then I shall explain a little about the design, how it came to be, why it is the way it is and so on.

Retrochallenge Winter 2013

For the Winter Warmup Retrochallenge 2013 I plan to recreate the worst ever home console. 

Dozy graphics design, Ridiculous Controllers, Terrible sound, this has it all.

This will involve (time dependent but at least the first three) :-

(1) Figuring out how it works. Because it is so bad this is relatively easy ; there's only one way it can actually be wired up. The games are so simple that you can rebuild them from screenshots.
(2) Writing an emulator for it (none exists)
(3) Rewriting the ROM and Built in Game (not dumped and may never be) working from the screenshots and manual descriptions available.
(4) Attempting to produce a hardware version on an Arduino (by my calculations, possible in real time with the Arduino generating the video because it is so slow and to make it worse the processor only runs in Vertical Blank) so anyone mad enough can play it on their TV.
(5) Trying to create a half decent game for it. This is by far the most difficult challenge.