Li'l Bro - A Unisonic Champion Simulator for the INTV

[decle]

Hi folks!

 

Just tested out the lilBro.rom and i must congratulate decle of doing a heck of a good job!

Seems there's no sounds but that's OK, it's not if any Champion 2711 are games of the year...lol!

 

I would like to help out but when it comes to programming...well, let's just say that's a skill that

i suck real hard. Just know BASIC (yes...i'm almost prehistoric...LOL!!), HTML and LUA.

 

And i must also thank intvnut as he given me a few years back documents about the

Gimini Challenger 8950 Programmable Game System aka the Champion 2711.

I just uploaded all the docs from his web site regarding the Challenger 8950 on archive.org:

 

https://archive.org/download/unichamp/gimicro.zip

 

And if anyone wants to read the FAQ (last version is UC-03), just go here:

http://www.ccjvq.com/slydc/index/faq/2711/index.htm

 

Can't wait to see the other four PACs converted to the Intellivision! =)

 

--- Sly DC ---

 

Hi Sly DC

 

There should be some suitably authentic and annoying sound when playing Li'l Bro. Which emulator are you using, and on which platform (Windows, Mac, Linux)? Are other people getting sound?

 

 

cheers

 

decle

[decle]

 

Is there any point "converting" them to the Intellivision? I mean, I guess the real challenge is in getting the ROMs to run in a Unisonic Champion emulator/simulator. If the games are simple enough, why not just re-implement them natively on the Intellivision. That's probably a lot simpler, no?

 

Or is the goal of your suggestion to emulate them on the Intellivision itself?

 

-dZ.

 

Nope, absolutely no point, but since when have we allowed that to stop us?

 

I think you can play all the games on MAME / MESS right now if you want, using the unichamp driver and optionally the -cart flag to specify one of the pacs.

 

The reason I converted the original ROM is because I was intrigued by Sly DC's description of the Unisonic as the Intellivision's little brother. I wondered how different the architecture was and it seemed to me that it would be possible to create an authentic experience on the Intellivision. As you might have guessed by now, I enjoy emulators, simulators and the like. In doing this I wanted to see if a vanilla Intellivision game (like the early APh games) could mimic the Unisonic. There are some differences, for example the characters are 6x8 pixels on the left side of the screen and effectively 9x8 on the right, so Li'l Bro's font is not spaced out quite right, but it is not bad. It does run and play the game, using only the resources of an unexpanded Intellivision (the complete game is <4K words like an original APh title). I had a similar objective for Nybl, which also does not use additional RAM and despite the liberal use of ROM to get performance to an acceptable level weighs in at <16K words.

 

I think it is definitely simpler to convert the existing code, than write an equivalent from scratch. The process is mainly one of remapping addresses, data values and registers. However, it is not the most interesting programming exercise, and while some bits of it could be automated, there are some bits that could be difficult. For example there are some places where screen addresses are stored in memory. On the Unisonic the BackTab runs from $00 to $95, so obviously you have to shift any references up to $200 - $2F0, and sort out the left / right hand screen thing (that is really just maths). However, the Unisonic's RAM is only 8 bit. So you cannot store Intellivision screen addresses directly in it (I naively mapped the Unisonic RAM into the Intellivision scratch RAM), at which point you need to tweak the results when you read them back. If I was doing this again I think I'd simplify things by adding 256 words of 16 bit RAM, but as I said at the time I wanted to see if I could get a vanilla Intellivision to simulate the Unisonic.

Edited June 2, 2016 by decle

[slydc]

Hi decle,

 

I used MAME 0.167 for Windows (32-bit) to try out your lilBro.rom and didn't heard any sounds.

 

Quote: "I think you can play all the games on MAME / MESS right now if you want, using the unichamp driver and optionally the -cart flag to specify one of the pacs."

 

Exactly, you need to specify which cartridge with the "-cart" flag like this: MAME unichamp -window -video ddraw -cart pac-02

 

But if you want a crisp resolution instead of a smeared one, than type this: MAME unichamp -window -resolution 696x448@60 -video ddraw (and add "-cart xxxxx

if you want to play with a specific cartridge without the extension).

 

[+DZ-Jay]

I think it is definitely simpler to convert the existing code, than write an equivalent from scratch. The process is mainly one of remapping addresses, data values and registers.

 

Just for the record, I wasn't questioning your motivations: it is clearly interesting to work on obsolete hardware and software and to take it to new heights. After all, I am a home-brewer on a 30 year-old platform as well.

 

I only thought that it may have been just as interesting (and perhaps easier) to re-create the games from scratch, using common and widely used techniques on the Intellivision platform to replicate the functionality of these rather primitive games.

 

Personally, I thought "remapping addresses, data values, and registers" may be a more daunting task than to just take a look at the final function of the program take advantage of the SDK-1600 library (or any number of similarly well-documented techniques) replicate the game logic, read input, and write output to the screen -- in a purely "Intellivision-y" way. With the ultimate goal to see how the games play and to enjoy them, not necessarily to play the original code. Even in IntyBASIC it would be an easier endeavor, no?

 

My question was then, would that not be an interesting project as well? Or are the games too primitive to stand on their own and are only interesting within the context of their original software and hardware constraints? It is an honest and sincere question. I do not now enough of the Unisonic Champion or its games to tell myself.

 

I liken this to, say, Pong. Not many people try to "port" the original code of Pong, but many people just try to re-implement it (as closely as possible to the original) in a multitude of platforms. All for the sake of the technical challenge it brings, as well as to enjoy a truly timeless classic that is fun and interesting by its sheer simplicity.

 

-dZ.

Edited June 5, 2016 by DZ-Jay

[decle]

Hi decle,

 

I used MAME 0.167 for Windows (32-bit) to try out your lilBro.rom and didn't heard any sounds.

 

Quote: "I think you can play all the games on MAME / MESS right now if you want, using the unichamp driver and optionally the -cart flag to specify one of the pacs."

 

Exactly, you need to specify which cartridge with the "-cart" flag like this: MAME unichamp -window -video ddraw -cart pac-02

 

 

Ahh, interesting. Yes, if I use the intv driver in MESS:

 

mess64 intv -cart lilBro.rom

 

I don't get any sound either, but I do get sound for other games. Weird that I get sound when I use Jzintv. Obviously I'm doing something wrong. I'll have to take a look at that.

 

Thanks for the bug report.

 

decle

[intvnut]

Hi decle,I used MAME 0.167 for Windows (32-bit) to try out your lilBro.rom and didn't heard any sounds.

 

FWIW, I hear sound just fine in jzIntv with the posted lilBro.rom. It's not quite as harsh as the sounds from the original (which sound like a smoke alarm having a bad day), but they're definitely there.

 

 

Personally, I thought "remapping addresses, data values, and registers" may be a more daunting task than to just take a look at the final function of the program take advantage of the SDK-1600 library (or any number of similarly well-documented techniques) replicate the game logic, read input, and write output to the screen -- in a purely "Intellivision-y" way. With the ultimate goal to see how the games play and to enjoy them, not necessarily to play the original code. Even in IntyBASIC it would be an easier endeavor, no?

 

I think it's cool that CP-1610 code from the only other CP-1610-based system we know of is running more or less natively on the Intellivision with minimal changes. :-)

 

Developing fresh ports is its own thing, but IMHO, it loses the one thing that truly connects the Unisonic to the Intellivision: the shared instruction set.

 

I had a look at the code, and it doesn't look like much remapping is necessary for most of it. Of course, the devil's in the details, naturally. But, by the time you've worked through the game's logic well enough to rewrite it, you're also at a pretty good point to just adjust the assembly code to match the Intellivision, I'd imagine. (And yes, I disassembled lilBro and lined up the code... the bits I looked at are quite largely unmodified!)

 

If you look at the Unisonic EXEC/PAC-01 disassembly, you can see the logic for Blackjack and Baccarat are actually rather closely intermingled. Also, reading up on Baccarat, it sounds like there's quite a number of different variants, so to implement variant that is in the Unisonic (which I'm not even sure matches one of the ones described on Wikipedia exactly), you either have to fully understand its logic, or just find the parts that interact with the screen and the GIC and adjust them.

 

(I'll be honest, I read the Wikipedia page, and I'm still not sure I understand the game...)

 

In some ways, this reminds me a little of the 6502 Microsoft BASIC "computer archaeology" project Michael Steil undertook awhile back. He took ROM dumps of several different versions of Microsoft BASIC for different computers, including the Apple ][, various Commodores, the KIM-1, and even the Intellivision Keyboard BASIC, and reconstructed their shared history. He also produced a merged codebase from which you could build bit-exact images for most of the systems.

 

This is somewhat like doing that in reverse: Suppose whoever wrote the original was asked to write it for both the Unisonic and the Intellivision. What would that look like? To a first order, this provides an answer.

[intvnut]

 

Ahh, interesting. Yes, if I use the intv driver in MESS:

 

mess64 intv -cart lilBro.rom

 

I don't get any sound either, but I do get sound for other games. Weird that I get sound when I use Jzintv. Obviously I'm doing something wrong. I'll have to take a look at that.

 

Thanks for the bug report.

 

decle

 

Looking briefly at your code, it appears you write $1F to the volume register. jzIntv models the PSG behavior documented in the preliminary AY-3-8910 datasheet that was linked upthread: The two MSBs of the sound register form a "shift value" for shifting the envelope volume right. $3x will give you a normal envelope, $2x gives you an envelope whose volume is cut in half*, $1x gives you an envelope whose volume is cut by a factor of 4.

 

(See the table at the top right involving C1 and C0 in the datasheet to see what I mean.)

 

It looks like MAME implements this too. But, it could be that the resulting tone is just too soft.

 

 

____________

*EDIT: By "cut in half", I mean the numeric values are cut in half. In terms of voltage, it's cut much further than that, since every 2 steps halves the voltage output. So going from 15 to 7 is 1/16^th the voltage (halved four times). Going from 15 to 3 is 1/64^th (halved six times). You gang up 2 channels with the same output, which would make the output louder (but not twice as loud!) if they are in phase. However, if you're unlucky enough to have them exactly 180 degrees out of phase, it would be completely silent. I suspect that may be a factor here too.

Edited June 5, 2016 by intvnut

[decle]

 

Just for the record, I wasn't questioning your motivations: it is clearly interesting to work on obsolete hardware and software and to take it to new heights. After all, I am a home-brewer on a 30 year-old platform as well.

 

I only thought that it may have been just as interesting (and perhaps easier) to re-create the games from scratch, using common and widely used techniques on the Intellivision platform to replicate the functionality of these rather primitive games.

 

Personally, I thought "remapping addresses, data values, and registers" may be a more daunting task than to just take a look at the final function of the program take advantage of the SDK-1600 library (or any number of similarly well-documented techniques) replicate the game logic, read input, and write output to the screen -- in a purely "Intellivision-y" way. With the ultimate goal to see how the games play and to enjoy them, not necessarily to play the original code. Even in IntyBASIC it would be an easier endeavor, no?

 

My question was then, would that not be an interesting project as well? Or are the games too primitive to stand on their own and are only interesting within the context of their original software and hardware constraints? It is an honest and sincere question. I do not now enough of the Unisonic Champion or its games to tell myself.

 

I liken this to, say, Pong. Not many people try to "port" the original code of Pong, but many people just try to re-implement it (as closely as possible to the original) in a multitude of platforms. All for the sake of the technical challenge it brings, as well as to enjoy a truly timeless classic that is fun and interesting by its sheer simplicity.

 

-dZ.

 

No problem, no offence taken. I agree that people come to the "scene" for all sorts of reasons, it is one of the cool aspects of it. In many respects I think the work of Paul Robson back in 2012 is the kind of reimplementation of the original games that you suggest, and his technique of using the VM to get around the annoyances of the Unisonic was inspired. I can't compete with work like that

 

To be honest I think the games only work within the confines of the Unisonic. For example Poker and Blackjack on the INTV is far superior to the Unisonic version, as such this only really works as an engineering exercise. At least in my head. I think it probably is interesting to see what could have been written for the Unisonic, perhaps a snake type game as Carlsson suggested. As Paul Robson has shown it is possible to use the SDK1600 toolchain to do such development and it is now possible to use MESS as a test platform.

 

However, I have something else in mind for my next big project.

[+DZ-Jay]

I think it's cool that CP-1610 code from the only other CP-1610-based system we know of is running more or less natively on the Intellivision with minimal changes. :-)

 

I agree, it is very cool.

 

Developing fresh ports is its own thing, but IMHO, it loses the one thing that truly connects the Unisonic to the Intellivision: the shared instruction set.

 

I understand. At first, I took the point of the exercise to be purely for the games. For some reason, I got the idea that the goal was to discover what sort of games were playable in the machine, so that's why I asked.

 

-dZ.

 

[decle]

 

FWIW, I hear sound just fine in jzIntv with the posted lilBro.rom. It's not quite as harsh as the sounds from the original (which sound like a smoke alarm having a bad day), but they're definitely there.

 

 

 

I think it's cool that CP-1610 code from the only other CP-1610-based system we know of is running more or less natively on the Intellivision with minimal changes. :-)

 

Developing fresh ports is its own thing, but IMHO, it loses the one thing that truly connects the Unisonic to the Intellivision: the shared instruction set.

 

I had a look at the code, and it doesn't look like much remapping is necessary for most of it. Of course, the devil's in the details, naturally. But, by the time you've worked through the game's logic well enough to rewrite it, you're also at a pretty good point to just adjust the assembly code to match the Intellivision, I'd imagine. (And yes, I disassembled lilBro and lined up the code... the bits I looked at are quite largely unmodified!)

 

If you look at the Unisonic EXEC/PAC-01 disassembly, you can see the logic for Blackjack and Baccarat are actually rather closely intermingled. Also, reading up on Baccarat, it sounds like there's quite a number of different variants, so to implement variant that is in the Unisonic (which I'm not even sure matches one of the ones described on Wikipedia exactly), you either have to fully understand its logic, or just find the parts that interact with the screen and the GIC and adjust them.

 

(I'll be honest, I read the Wikipedia page, and I'm still not sure I understand the game...)

 

In some ways, this reminds me a little of the 6502 Microsoft BASIC "computer archaeology" project Michael Steil undertook awhile back. He took ROM dumps of several different versions of Microsoft BASIC for different computers, including the Apple ][, various Commodores, the KIM-1, and even the Intellivision Keyboard BASIC, and reconstructed their shared history. He also produced a merged codebase from which you could build bit-exact images for most of the systems.

 

This is somewhat like doing that in reverse: Suppose whoever wrote the original was asked to write it for both the Unisonic and the Intellivision. What would that look like? To a first order, this provides an answer.

 

Yup, as you say much of the code in Li'l Bro is straight from the original ROM. My basic approach was to disassemble the original. Put an INTV bootstrap on the front and a simple ISR to keep the screen active and then repeatedly document the next block of Unisonic assembly, tweak where required, run it and debug. Keep going until done. If I can find the motivation to tidy the source of Li'l Bro to a point where I'm not embarrassed by it I'll release it. As you say most of it is not mine to keep anyway. Although I would not advise people to use it for anything other than "for interest" purposes.

 

Yes, I've seen Michael's work. A real labour of love, if such a thing is possible for a Microsoft product

[intvnut]

Yes, I've seen Michael's work. A real labour of love, if such a thing is possible for a Microsoft product

 

As much as we all rag on Microsoft now, there was a time when I sincerely felt they produced some of the best products around. That phase ended around the time I graduated high school, though.

 

Since I cut my teeth on a range of Microsoft BASICs, I thought it was extremely fascinating. Even more fascinating is to see Bill's original source code. It's turned up on the web recently. The most amusing item I spotted in there is a label named "GRODY." (It seems to be a hack to overcome the limited branch distance of conditional branches, when jumping to the "READY" code.) That, and he calls Commodore "COMMO," which also amused me for some reason. Oh, and an all too familiar complaint: "MACRO DOESNT LIKE ('S IN ARGUMENTS."

Edited June 5, 2016 by intvnut

[decle]

 

Looking briefly at your code, it appears you write $1F to the volume register. jzIntv models the PSG behavior documented in the preliminary AY-3-8910 datasheet that was linked upthread: The two MSBs of the sound register form a "shift value" for shifting the envelope volume right. $3x will give you a normal envelope, $2x gives you an envelope whose volume is cut in half*, $1x gives you an envelope whose volume is cut by a factor of 4.

 

(See the table at the top right involving C1 and C0 in the datasheet to see what I mean.)

 

It looks like MAME implements this too. But, it could be that the resulting tone is just too soft.

 

 

____________

*EDIT: By "cut in half", I mean the numeric values are cut in half. In terms of voltage, it's cut much further than that, since every 2 steps halves the voltage output. So going from 15 to 7 is 1/16^th the voltage (halved four times). Going from 15 to 3 is 1/64^th (halved six times). You gang up 2 channels with the same output, which would make the output louder (but not twice as loud!) if they are in phase. However, if you're unlucky enough to have them exactly 180 degrees out of phase, it would be completely silent. I suspect that may be a factor here too.

 

Ahh, cool, cool, cool. Thanks Joe. I'll take a look. I did notice that the sound was rather quiet, I assumed it was the triangle envelope I was using to get the warble effect, as it did not seem to be quiet without the envelope. I tried to get round this by using multiple channels which helped a bit. However, your description highlights a different cause of the same symptom.

 

I think I was working from the description of the amplitude control registers in:

 

view-source:http://spatula-city.org/~im14u2c/intv/jzintv-1.0-beta3/doc/programming/psg.txt

 

and I got confused.

 

 

decle

[intvnut]

I think I was working from the description of the amplitude control registers in:

 

view-source:http://spatula-city.org/~im14u2c/intv/jzintv-1.0-beta3/doc/programming/psg.txt

 

and I got confused.

 

You know what, that's a direct transcription of the GI AY-3-8912 datasheet, pretty much. That describes the final AY-3-8910/8912/8913 (including the different register order). It doesn't describe the peculiarity of the AY-3-8914's envelope select. I should add a note to it. I may not have been aware of the peculiarity when I did that transcription.

 

Thanks for pointing that out!

[intvnut]

I think I was working from the description of the amplitude control registers in:

 

view-source:http://spatula-city.org/~im14u2c/intv/jzintv-1.0-beta3/doc/programming/psg.txt

 

and I got confused.

 

OK, I've added the following bits to the psg.txt document. In the INTELLIVISION SPECIFIC DETAILS section, I added:

.

The AY-3-8914 volume control differs slightly from the AY-8910/8912/8913
in one important way:  It provides *two* bits for the envelope select.  The
two bits function as follows:

  Bit 5   Bit 4   Behavior
 ------- ------- -------------------------------------------------------
    0       0     Use the volume specified in bits 3:0 (no envelope)
    0       1     Use the envelope volume right shifted by 2
    1       0     Use the envelope volume right shifted by 1
    1       1     Use the envelope volume directly

Most programs will want to set both bits.  The envelopes generated by
setting only one of these two bits tend to be very soft; too soft to be
useful in most cases.

.

And in the description of the volume registers, I added this note:

.

    >>> NOTE: AY-3-8914 behaves differently here; see table describing <<<
    >>> the envelope bits in the Intellivision-specific section above. <<<

.

I had committed so much of this to memory, I hadn't looked at the file in eons. It appears the last time I touched that file was in 2006, to add the information on how to compute tone periods. It otherwise hadn't been touched since I first checked jzIntv into SVN, and probably hadn't been touched for years before that.

[decle]

 

OK, I've added the following bits to the psg.txt document. In the INTELLIVISION SPECIFIC DETAILS section, I added:

.

The AY-3-8914 volume control differs slightly from the AY-8910/8912/8913
in one important way:  It provides *two* bits for the envelope select.  The
two bits function as follows:

  Bit 5   Bit 4   Behavior
 ------- ------- -------------------------------------------------------
    0       0     Use the volume specified in bits 3:0 (no envelope)
    0       1     Use the envelope volume right shifted by 2
    1       0     Use the envelope volume right shifted by 1
    1       1     Use the envelope volume directly

Most programs will want to set both bits.  The envelopes generated by
setting only one of these two bits tend to be very soft; too soft to be
useful in most cases.

.

And in the description of the volume registers, I added this note:

.

    >>> NOTE: AY-3-8914 behaves differently here; see table describing <<<
    >>> the envelope bits in the Intellivision-specific section above. <<<

.

I had committed so much of this to memory, I hadn't looked at the file in eons. It appears the last time I touched that file was in 2006, to add the information on how to compute tone periods. It otherwise hadn't been touched since I first checked jzIntv into SVN, and probably hadn't been touched for years before that.

 

 

Cool, should the original description

                b5 Amplitude Mode (0: fixed, 1: envelope-variable)
                b4-b0 4-bit fixed amplitude level

actually have been:

                b4 Amplitude Mode (0: fixed, 1: envelope-variable)
                b3-b0 4-bit fixed amplitude level

that is what I assumed, and it seemed to work (barring the additional bit 5). And that was the problem. Here is a patched code that has sound in MESS, and louder sound in Jzintv.

 

lilBro.rom

 

Thanks Joe

 

Something else I have noticed fiddling with MESS. I had always assumed that player 1 was the left hand controller, and player 2 the right. Have I had things back to front all this time?

[intvnut]

Cool, should the original description

                b5 Amplitude Mode (0: fixed, 1: envelope-variable)
                b4-b0 4-bit fixed amplitude level

actually have been:

                b4 Amplitude Mode (0: fixed, 1: envelope-variable)
                b3-b0 4-bit fixed amplitude level

that is what I assumed, and it seemed to work (barring the additional bit 5). And that was the problem. Here is a patched code that has sound in MESS, and louder sound in Jzintv.

 

Oof, I didn't even notice that typo! On the AY-3-8914, of course, it's b5-b4 for the amplitude mode. I've fixed the typo, so now it reads correctly for a 5 bit field (as found on the AY-3-8912). I suppose I should just rewrite this document to describe the Intellivision (including the Intellivision register order) and dispense with fidelity to the AY-3-8912 datasheet.

 

BTW, another detail that I should cover: IIRC, the PSG in some later units and in the ECS (AY-3-8916, AY-3-8917) goes back to having a single envelope select bit. That's yet another reason to just set both bits.

 

 

Something else I have noticed fiddling with MESS. I had always assumed that player 1 was the left hand controller, and player 2 the right. Have I had things back to front all this time?

 

I'm not sure!

 

$1FF is the left player, $1FE is the right player. How do you have it wired up in your code?

[decle]

Oof, I didn't even notice that typo! On the AY-3-8914, of course, it's b5-b4 for the amplitude mode. I've fixed the typo, so now it reads correctly for a 5 bit field (as found on the AY-3-8912). I suppose I should just rewrite this document to describe the Intellivision (including the Intellivision register order) and dispense with fidelity to the AY-3-8912 datasheet.

 

BTW, another detail that I should cover: IIRC, the PSG in some later units and in the ECS (AY-3-8916, AY-3-8917) goes back to having a single envelope select bit. That's yet another reason to just set both bits.

No problem, the description was good enough, sound was produced. And when it comes down to it that is the bar, at least in my book.

 

I'm not sure!

 

$1FF is the left player, $1FE is the right player. How do you have it wired up in your code?

My assumption is that $1FF / left is "player 1". So in a two player game I would only listen to the left controller when receiving input for player 1 and vice versa. However, judging by the controller configuration the assumption in MESS seems to be that the right hand controller is player 1. On reflection Jzintv also provides the same hint in that it defaults to a keyboard mapping that places the right hand controller onto the obvious keys (0-9 for the keypad for example). I must check out a few 2 player Mattel games and see what their assumptions are, but I'm guessing that Jzintv and MESS are this way round exactly because games make this assumption. In Li'l Bro I think I have an excuse in that I believe the Unisonic maps the left controller to player 1, so I'm just "being authentic" , but in future it is something I should bear in mind.

 

 

[+nanochess]

The right thing is $1ff for player 1 or controller left. Also I had this doubt while developing IntyBASIC.

 

Jzintv was the reference. Fortunately the hardware agrees

[decle]

Ahh, I get it. Man I'm dozy at times. No change from normal there. I think I was confused by the default Jzintv mapping of keypad and action buttons, because I typically develop and play on a laptop keyboard, doh!

 

Thanks for putting me straight.

[paulrobson]

I didn't know that, I must try it out. My 2711 project was actually running on a genuine CP1610 emulator but I rewrote the whole thing, It was actually running an RISC VM on top of the CP1610 and the game cartridge run on that. I worked the game out from the box pics and the instructions and I suspect it's pretty accurate

 

The AY-3-8800 is so bad a design that it's instant-sacking. Given the expense of producing the chips. It's horribly limited in ways you can't begin to believe until you understand the datasheet. If it wasn't for the fact that it was in a databook with a bunch of other GI chips I'd have assumed it was a wind up.

 

The design of the 2711 is also horribly botched. Externally and internally. It throws away a lot of the advantages of the 1610.

 

I'm quite surprised the carts were dumped. Unisonics are incredibly rare.

[intvnut]

The AY-3-8800 is so bad a design that it's instant-sacking. Given the expense of producing the chips. It's horribly limited in ways you can't begin to believe until you understand the datasheet. If it wasn't for the fact that it was in a databook with a bunch of other GI chips I'd have assumed it was a wind up.

 

The design of the 2711 is also horribly botched. Externally and internally. It throws away a lot of the advantages of the 1610.

 

I really wonder what the thought process was behind the AY-3-8800 GIC. It's essentially a TV version of a handheld LED/LCD game. It's pretty crippled chip.

 

The processing demands are so low that I'm surprised they used a CP-1610 with this. A PIC1650 or LP8000 probably could have driven this just as well. Both were also in GI's stable of devices at the time, I believe. Maybe the AY-3-8800 was a test design that escaped the lab while GI was figuring out how to build the GIMINI 8900 system.

 

FWIW, the cost of fabbing a new chip back then wasn't like what it is now. It was several thousand $$, as opposed to many millions these days. And with chips clocking in at only a few thousand transistors, it wasn't the long, crazy design cycles we see with modern silicon. If you look at a GI catalog from the late 1970s / early 1980s, it looks like they were throwing as much as they could at the wall to see what stuck. They had all sorts of crazy ASICs for fairly narrow purposes. (Our favorite Intellivision GIMINI system shows up in the catalog I linked over there as the "8900" Home Information System!)

 

 

The Unisonic 2711 hardware design doesn't surprise me too much. Looking at their Pong clones (also based around GI chips), they really are a study in how to put as little as possible into the product. IIRC, they even used single-sided PCBs.

 

Of course (and I'll probably ruffle some feathers here), I feel the Atari 2600 design also cut some crazy corners too. (No R/W strobe on the cartridge port, for example.) But, by making the video generation almost entirely software driven, they avoided painting themselves into a corner in a huge way. You could actually do things with that hardware that the designers hadn't thought up in advance. The AY-3-8800, OTOH, is forever stuck playing some crappy card games.

 

And then there's the Odyssey², which sits somewhere between them in terms of limitations.

 

On a different note: I wonder if you can change the character table out from under the GIC between scanlines? That might allow for some more display possibilities, although not many.

[carlsson]

Perhaps some of the card and other games against the computer requires some computational power? I don't see any Bridge game in the list, but even a serious poker player will have to keep track of card counts and a lot more that possibly a simpler MCU would not have been able to.

 

I visited The Chess Variant Pages and found at least one modern (2002) variant called Ziggurat that can be displayed within 5x13 which is the portion of the screen on which I believe every column and row is addressable, and also is the size of the promised Battleships game. This game uses five different pieces, although I'm not sure that the Unisonic character ROM would be suitable anyway. There also is the Two Pipe Chess (2001) on a 5x9 board. Imagine if either of these variants had existed back then and had been offered on a cartridge, it most likely would've represented a unique game for this system.

[intvnut]

Perhaps some of the card and other games against the computer requires some computational power? I don't see any Bridge game in the list, but even a serious poker player will have to keep track of card counts and a lot more that possibly a simpler MCU would not have been able to.

 

I doubt any of the card games really require that much compute power.

 

Memory is more important for games with a large "search space." The chess variants you mentioned, for example, probably would benefit from more RAM (and an actual processor stack!) to allow running, say, a simple MiniMax search.

[decle]

I didn't know that, I must try it out. My 2711 project was actually running on a genuine CP1610 emulator but I rewrote the whole thing, It was actually running an RISC VM on top of the CP1610 and the game cartridge run on that. I worked the game out from the box pics and the instructions and I suspect it's pretty accurate

 

The AY-3-8800 is so bad a design that it's instant-sacking. Given the expense of producing the chips. It's horribly limited in ways you can't begin to believe until you understand the datasheet. If it wasn't for the fact that it was in a databook with a bunch of other GI chips I'd have assumed it was a wind up.

 

The design of the 2711 is also horribly botched. Externally and internally. It throws away a lot of the advantages of the 1610.

 

I'm quite surprised the carts were dumped. Unisonics are incredibly rare.

 

Hey Paul,

 

Just wanted to say many thanks for the Unisonic blog and RetroChallenge entry. I enjoyed following it greatly and it was the inspiration for my toying around with Li'l Bro. Prior to finding the Unisonic ROMs online I was considering using your reimplementation as the basis of Li'l Bro. I think your approach of implementing a VM to overcome the shortcomings of the Unisonic architecture is insane and brilliant. Kudos

 

I'm looking forward to following your next RetroChallenge adventure in a couple of weeks.

 

decle