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

[decle]

Hey all,

This is a bit of a quickie project in between bigger things.

Last year David Viens dumped the ROM in the Unisonic Champion and its cartridges:

http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=95976

And subsequently it has made its way into MESS as the "unichamp" driver.

Armed with the system ROM image, and GI datasheets I thought it should be possible to get the Intellivision to mimic its little brother. How hard could it be?

The result is "Li'l Bro", a Unisonic Champion simulator for the Intellivision. It can be played on JzIntv or other emulator using this ROM image:

 

lilBro.rom

 

I should warn you that the Unisonic is utterly underwhelming and is a serious contender for the title "Worst Console Ever", as described by Paul Robson:

http://worstconsole.blogspot.co.uk/2012/12/the-worstconsoleever.html

Li'l Bro only plays the card games Blackjack and Bacarat that were built into the console at the moment. This is because it was the only ROM I could find; it is mind bendingly boring to convert the games, and the end result, while technically interesting, is no fun to play.

 

To play the ROM each player has only 2 controls. "Yes" is mapped to controller keypad buttons 1, 2 or 3 on the each controller and "No" to buttons 7, 8 and 9. If you are playing on Jzintv with a qwerty keyboard I recommend the following keyboard hack file, this saves having to switch backward and forward between keyboard maps. This maps:

• Left controller "yes" -> q, w or e
• Left controller "no" -> z, x or c
• Right controller "yes" -> y, u, i or o
• Right controller "no" -> b, n, m or comma

kbd.txt

 

Unlike my previous project, Li'l Bro is not an emulator. Although the majority of the code being run is the same as that in the Unisonic Champion, it has been tweaked to take account of the different architecture and memory map in the Intellivision. So, technically Li'l Bro is a simulation, rather than an emulation. That said, I think it is pretty faithful to the original. You can see a video of a real Unisonic being played here:

As always, all feedback, good, bad and indifferent is most welcome.

Enjoy! (you probably won't, but at least the sentiment is there).


decle
Edited June 5, 2016 by decle

[intvnut]

Heck, if it's running the CP-1610 code natively, just adapted for memory map and the difference between the AY-3-8900 vs. AY-3-8800, it's better than a simulator. It's actually much closer to being an actual high-fidelity port! (High-fidelity in the sense of being very true to the original, that is.)

 

Coolness!

[decle]

Heck, if it's running the CP-1610 code natively, just adapted for memory map and the difference between the AY-3-8900 vs. AY-3-8800, it's better than a simulator. It's actually much closer to being an actual high-fidelity port! (High-fidelity in the sense of being very true to the original, that is.)

 

Coolness!

 

Yup, that's what it is up to. The other interesting tweak is that the Unisonic does not make use of a stack, because it only has 8 bit RAM. As a consequence there are limits to the number of levels of subroutines in the code, and it makes use of R6 as a general purpose register. Obviously this requires a bit of register renaming to get things to work on the INTV.

 

On the off chance you are interested, here is the disassembly of the original ROM with my annotations:

 

original.asm

[intvnut]

Indeed, I was rather morbidly curious. :-)

 

Using R6 as a GPR does cause... issues on the Intellivision, since the STIC and System RAM insist you take an interrupt in order to enable the display. No INTAK == no display. But, INTAK means writing @R6.

 

I guess I'm surprised someone actually made a system out of the AY-3-8800. I wonder if Unisonic did any engineering on this at all, or if they took an eval board design from GI and fit it into one of their existing cases. From that worst-console-ever page, it sounds like they reused a case they already had.

 

The reset button on the controllers is interesting. I guess it's a (╯°□°)╯︵ ┻━┻ rage-quit button of sorts...

Edited May 31, 2016 by intvnut

[intvnut]

BTW, on this guy:

.

; It is not clear what this decle does

    MVI@    R5,     R0                  ; $0CEE  02A8            [.  ]

.

Since that falls into ScrPrintCard, which prints R0, it would allow you to do something like:

.

    CALL  ScrPrintCard-1   ; aka. $0CEE
    DECLE card_to_print

.

Maybe this entry point was used by one of the cartridges?

[intvnut]

Oh, and I should say... that's some very well documented disassembly. I'm duly impressed.

[decle]

BTW, on this guy:

.

; It is not clear what this decle does

    MVI@    R5,     R0                  ; $0CEE  02A8            [.  ]

.

Since that falls into ScrPrintCard, which prints R0, it would allow you to do something like:

.

    CALL  ScrPrintCard-1   ; aka. $0CEE
    DECLE card_to_print

.

Maybe this entry point was used by one of the cartridges?

 

 

 

Ahh OK, yes that makes sense. Unfortunately I don't have access to the cartridges, so I cannot check. Kudos for finding that little comment amongst the 1000+ lines as well.

 

The other thing I have not fathomed is the full meaning of game type. Blackjack is 3 and Bacarat is 2. There are then tests for the game type:

    MVI     Usc.gameType, R0            ; check for bacarat
    SARC    R0                          ;
    BNC     NoDouble                    ; if bacarat, goto NoDouble

However, occasionally you see SARC R#, 2:

    MVI     Usc.gameType, R0            ; check for ???
    SARC    R0, 2                       ;
    BNC     @@bacarat                   ; if ???, don't offer double

I can't see any particular reason for doing this. The distinguishing bit 0 still ends up in Carry. Am I missing something subtle?

 

 

decle

Edited May 31, 2016 by decle

[+DZ-Jay]

 

 

Ahh OK, yes that makes sense. Unfortunately I don't have access to the cartridges, so I cannot check. Kudos for finding that little comment amongst the 1000+ lines as well.

 

The other thing I have not fathomed is the full meaning of game type. Blackjack is 3 and Bacarat is 2. There are then tests for the game type:

    MVI     Usc.gameType, R0            ; check for bacarat
    SARC    R0                          ;
    BNC     NoDouble                    ; if bacarat, goto NoDouble

However, occasionally you see SARC R#, 2:

    MVI     Usc.gameType, R0            ; check for ???
    SARC    R0, 2                       ;
    BNC     @@bacarat                   ; if ???, don't offer double

I can't see any particular reason for doing this. The distinguishing bit 0 still ends up in Carry. Am I missing something subtle?

 

 

decle

 

When you shift twice, it moves the LSB into the Carry and the second LSB into the Overlow status flag. It could be making the distinction between %01 (Carry), %10 (No Carry, Overflow), and %11 (Carry, Overflow). I don't know...

[decle]

 

When you shift twice, it moves the LSB into the Carry and the second LSB into the Overlow status flag. It could be making the distinction between %01 (Carry), %10 (No Carry, Overflow), and %11 (Carry, Overflow). I don't know...

 

Agreed, however, I cannot see obvious evidence either in the source, or when using a memory watch in Jzintv, that the game type is changed from its initial value of 2 or 3. Which would suggest that the overflow flag is always set to 1. There is a suggestion that the code is expecting a different value, as within HandEnd the overflow is checked:

    MVI     Usc.gameType, R2            ; load game type
    SARC    R2, 2                       ;
    BNOV    @@done                      ; if ???, goto done

I guess a possible reason is that this is another example of the cartridges using additional functionality. I believe the ROM within the console was described as being both an EXEC and PAC-01 (the first game cartridge). So perhaps HandEnd is intended to be one of the reusable services.

 

That said it all seems to work

Edited May 31, 2016 by decle

[carlsson]

I remember Paul's entry to the Retrochallenge. My mind still is boggled at the idea of recreating a game entirely based on screenshots. Now that the actual game has been dumped, did anyone compare the original code with his recreated one? The graphic capacities are limiting, but the two button controller should be fine even for action games where you rotate 90 degrees at a time, something like Snake/Surround/Snafu.

[decle]

I remember Paul's entry to the Retrochallenge. My mind still is boggled at the idea of recreating a game entirely based on screenshots. Now that the actual game has been dumped, did anyone compare the original code with his recreated one? The graphic capacities are limiting, but the two button controller should be fine even for action games where you rotate 90 degrees at a time, something like Snake/Surround/Snafu.

Yup, Paul's work was absolutely awesome. I don't think his ROMs will be anything like the originals as if I understand correctly he did something way more bonkers and clever.

 

According to his post here

 

http://worstconsole.blogspot.co.uk/2013/01/day-24-not-much-game-development-cont.html

 

He designed and then implemented a RISC virtual machine in CP1610 machine code, ran that within a Unisonic emulator and then wrote his version of the EXEC and game code in RISC machine code. A totally insane, wonderfully convoluted and utterly brilliant solution.

Edited May 31, 2016 by decle

[intvnut]

 

Agreed, however, I cannot see obvious evidence either in the source, or when using a memory watch in Jzintv, that the game type is changed from its initial value of 2 or 3. Which would suggest that the overflow flag is always set to 1. There is a suggestion that the code is expecting a different value, as within HandEnd the overflow is checked:

    MVI     Usc.gameType, R2            ; load game type
    SARC    R2, 2                       ;
    BNOV    @@done                      ; if ???, goto done

I guess a possible reason is that this is another example of the cartridges using additional functionality. I believe the ROM within the console was described as being both an EXEC and PAC-01 (the first game cartridge). So perhaps HandEnd is intended to be one of the reusable services.

 

That said it all seems to work

 

There was another WTF test in there for gameType <= 1, also, from what I remember seeing glancing through. It seems weird that the Blackjack and Baccarat are 3 and 2, so it makes sense some other game(s) are assigned 1 and 0. :-)

 

So, yeah, you'd need to see the other ROM dumps to know for sure whether these routines are called from the outside w/ different parameters.

 

 

This ROM is also the first one I remember seeing a JSR R6 in. (Although I will say it's not the first I've seen use R6 as a GPR. That would be Beamrider.)

[decle]

I contacted slydc, the maintainer of the Unisonic FAQ and poster of the original Unisonic thread in the main Intellivision forum, asking if he might have access to the additional cartridge ROMs. He does and he very kindly pointed me to them here:

 

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

 

They are part of a larger collection of Unisonic material (https://archive.org/download/unichamp) he contributed to archive.org. Very cool!

 

A quick download and disassemble later. Joe is correct about the use of the MVI@ R5, R0 instruction at $0CEE, just before ScrPrintCard. This entry point is used several times by pac-04 (and only pac-04).

 

The mystery around the full meaning of $00E6 (game type) remains. It does not look as though HandEnd (or any other address greater than $0FA0) is called directly from any of the other cartridges. Meaning that the block of code

    MVI     Usc.gameType, R2            ; load game type
    SARC    R2, 2                       ;
    BNOV    @@done                      ; if ???, goto done

(can someone explain to me how to space the code blocks out a little bit, so that my text does not run right next to them, blank lines don't seem to work?)

 

is probably only used by the EXEC / pac-01 (I have not ruled out indirect calls from computed targets, but this seems unlikely), and therefore, there is an expectation that under some circumstances bit 1 of game type is not 1.

 

pac-03, pac-04 and pac-05 make use of $00E6. It looks as though pac-03 and pac-04 set it to 0 and expect it to have values up to at least 2. The use in pac-05 looks to be rather different, but I've not had a chance to really look at it.

 

And of course the elephant in the room. There are now 4 more cartridge ROM images that could be converted to the Intellivision. If you are tempted, I'd happily explain the approach I used and how the problems caused by differences in the Unisonic and Intellivision can be overcome. However, you should know that converting a ROM in this way is an exercise in patience.

Edited June 1, 2016 by decle

[freewheel]

I'll only start caring about this Unisonic if someone tried to make a crappy computer add-on for it.

 

Seriously, the shit that came out of the 70s and early 80s is mind-boggling. And people have ROM dumps for it all! My hat's off to whomever did that.

[pimpmaul69]

I contacted slydc, the maintainer of the Unisonic FAQ and poster of the original Unisonic thread in the main Intellivision forum, asking if he might have access to the additional cartridge ROMs. He does and he very kindly pointed me to them here:

 

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

 

They are part of a larger collection of Unisonic material (https://archive.org/download/unichamp) he contributed to archive.org. Very cool!

 

A quick download and disassemble later. Joe is correct about the use of the MVI@ R5, R0 instruction at $0CEE, just before ScrPrintCard. This entry point is used several times by pac-04 (and only pac-04).

 

The mystery around the full meaning of $00E6 (game type) remains. It does not look as though HandEnd (or any other address greater than $0FA0) is called directly from any of the other cartridges. Meaning that the block of code

    MVI     Usc.gameType, R2            ; load game type
    SARC    R2, 2                       ;
    BNOV    @@done                      ; if ???, goto done

(can someone explain to me how to space the code blocks out a little bit, so that my text does not run right next to them, blank lines don't seem to work?)

 

is probably only used by the EXEC / pac-01 (I have not ruled out indirect calls from computed targets, but this seems unlikely), and therefore, there is an expectation that under some circumstances bit 1 of game type is not 1.

 

pac-03, pac-04 and pac-05 make use of $00E6. It looks as though pac-03 and pac-04 set it to 0 and expect it to have values up to at least 2. The use in pac-05 looks to be rather different, but I've not had a chance to really look at it.

 

And of course the elephant in the room. There are now 4 more cartridge ROM images that could be converted to the Intellivision. If you are tempted, I'd happily explain the approach I used and how the problems caused by differences in the Unisonic and Intellivision can be overcome. However, you should know that converting a ROM in this way is an exercise in patience.

do you happen to have a rom of the pac-01? Im trying to get this running in mess and would like to have it too if it is available. I still have to check out lilbro. I love obscure systems like this. Everyone sees them as crap and i find joy in being able to play them. I was hoping it wasnt as super rare as they are. I would have bought one just to use the controllers in an emulator. If you know/ run accross anyone that has a broken one that is willing to sell the controllers let me know.

[decle]

do you happen to have a rom of the pac-01? Im trying to get this running in mess and would like to have it too if it is available. I still have to check out lilbro. I love obscure systems like this. Everyone sees them as crap and i find joy in being able to play them. I was hoping it wasnt as super rare as they are. I would have bought one just to use the controllers in an emulator. If you know/ run accross anyone that has a broken one that is willing to sell the controllers let me know.

 

Hey, pac-01 is combined with the EXEC within the machine itself. The resulting 2K image is called 9501-01009.u2 and can be found within unichamp.zip provided by slydc. I believe this is the only ROM required to play the unichamp MESS driver in its basic form, certainly I've had MESS running with just this ROM. I've not tried the pac-02 through pac-05 ROMs in MESS yet, but I see no reason why they would not work David Viens seems to have done a great job dumping them.

[decle]

I'll only start caring about this Unisonic if someone tried to make a crappy computer add-on for it.

 

Seriously, the shit that came out of the 70s and early 80s is mind-boggling. And people have ROM dumps for it all! My hat's off to whomever did that.

 

Add on wise, what did you have in mind?

 

The person responsible for the ROM dumps is David Viens aka plgDavid. All hat tips should be directed to him

[intvnut]

Looking at the cart pics on there, I see the cartridges say "Fully programmable for unlimited family fun!" However, the reality seems to be "Barely programmable for limited family fun!"

 

 

EDIT: Also I like how there's two copies of MNBDR on PAC-03. That's... mind bending!

Edited June 2, 2016 by intvnut

[intvnut]

I'll only start caring about this Unisonic if someone tried to make a crappy computer add-on for it.

 

Hmmm... LTO Flash! in its current form won't work, but with a few tweaks....

[carlsson]

Was the AY-3-8800 cheaper or easier to integrate, compared to using the AY-3-8900 which would've made this system even more of an Intellivision sibling?

[slydc]

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 ---

[intvnut]

Was the AY-3-8800 cheaper or easier to integrate, compared to using the AY-3-8900 which would've made this system even more of an Intellivision sibling?

 

Definitely much cheaper. The AY-3-8900 requires a minimum of 3 external chips to function (beyond the CP-1610 itself):

• AY-3-8915, or similar, to generate clocks and convert 5-bit color codes to video
• RA-3-9600, to isolate STIC private bus from CPU bus, as well as feed character tiles from BACKTAB
• GROM of some form (RO-3-9502, IIRC), with add'l logic to understand how to shift between CSTK/FGBG modes (yes, that's partly implemented in the GROM's address decode logic.)

Also, I believe the AY-3-8800 was available much earlier.

 

Check out this PDF with all GI's offerings: http://spatula-city.org/~im14u2c/intv/dl/GI-Games-1978.pdf

 

EDIT: Hmm... that one's missing the AY-3-8800. I know I have that one somewhere too. Grr..

Edited June 2, 2016 by intvnut

[carlsson]

Aren't AY-3-8950 (page 61) and AY-3-8800 the same chip?

Edited June 2, 2016 by carlsson

[intvnut]

Aren't AY-3-8950 (page 61) and AY-3-8800 the same chip?

 

I think you're right. I'd forgotten that.

 

Anyway, here's some more scans, showing more info on the GIC and the "8900" system (which grew into the Intellivision): http://spatula-city.org/~im14u2c/intv/gi_micro_programmable_tv_games/

 

In particular, the AY-3-8910 they describe in these sheets matches the AY-3-8914, and not the part they later released as AY-3-8910. (See page 101 for the description of the extra bit in the volume register, for example, and the memory map that matches Intellivision's AY-3-8914, but not the final AY-3-8910...)

 

 

EDIT: And I should have noticed that Sly DC posted links to the same information as my link above with the scans. I think our posts crossed. That's what I get for not refreshing the page.

Edited June 2, 2016 by intvnut

[+DZ-Jay]

And of course the elephant in the room. There are now 4 more cartridge ROM images that could be converted to the Intellivision. If you are tempted, I'd happily explain the approach I used and how the problems caused by differences in the Unisonic and Intellivision can be overcome. However, you should know that converting a ROM in this way is an exercise in patience.

 

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.