Tutorvision detection ROM

[intvnut]

Isn't that what CART.MAC does? For what it's worth, I always thought this was a good thing to do anyway during boot up since the whole point is to take over command from the EXEC.

 

cart.mac doesn't intercept any ISRs under normal circumstances. It only intercepts the ISR in case of a boot error (ECS or JLP not present) so that it can change the screen color to red.

 

They are very rare, four or five are known to exist. The extended rom include graphic characters, and a narrow text writing routine. Tutorvisions have more graphics ram, enough to bitmap the screen.

I know of 2 actual TutorVisions (beige shell and all), and 3 more complete INTV88 boards. I also have the 1 incomplete INTV88 board I acquired from Earl Ruffa. That board's pictures are what you'll find in my reverse engineering doc. The one exception is the picture of the STIC1A ASIC: Earl's board was missing the ASIC, so I took the picture of Chuck Gill's STIC1A ASIC instead.

 

Pardon my ignorance, what makes a Tutorvision special? What did they extend in the roms?

 

• It has 2K GRAM instead of 512 bytes. That sounds like a blessing, but it's a double-edged sword, as it causes some games to play with corrupted graphics.
• The GROM font was changed out, with a modified version of the CGA font in its place.
• It adds additional 16-bit RAM at $360 - $4FF.
• It has a custom ASIC that replaces the STIC and PSG; that ASIC has bugs.
  • Interrupt generation is dodgy, leading to the IntyBASIC hang mentioned above.
  • PSG emulation behaves oddly if you set your volume to certain settings. (To be fair, those settings were only supported on the earliest AY-3-8914 PSGs, and none of the AY-3-8910s.)
• And, full Tutorvisions have an additional 4Kx10 ROM at $2000 - $2FFF. Other INTV88 boards have the Intellivision 1 EXEC instead.

 

I have a full 27-page reverse engineering doc on Google Docs that I've updated as I learn more. Attached is a PDF of the latest version.

 

(EDIT: I made a few minor updates to the PDF, so if you downloaded it before you saw this EDIT, download it again for the latest. Nothing earth shattering; just added some comments on the IntyBASIC bootup double-interrupt issue, and fixed some formatting.)

TutorVision _ INTV88 Reverse Engineering Notes - Google Docs.pdf

Edited January 22, 2018 by intvnut

[+DZ-Jay]

 

cart.mac doesn't intercept any ISRs under normal circumstances. It only intercepts the ISR in case of a boot error (ECS or JLP not present) so that it can change the screen color to red.

 

I know of 2 actual TutorVisions (beige shell and all), and 3 more complete INTV88 boards. I also have the 1 incomplete INTV88 board I acquired from Earl Ruffa. That board's pictures are what you'll find in my reverse engineering doc. The one exception is the picture of the STIC1A ASIC: Earl's board was missing the ASIC, so I took the picture of Chuck Gill's STIC1A ASIC instead.

 

 

• It has 2K GRAM instead of 512 bytes. That sounds like a blessing, but it's a double-edged sword, as it causes some games to play with corrupted graphics.
• The GROM font was changed out, with a modified version of the CGA font in its place.
• It adds additional 16-bit RAM at $360 - $4FF.
• It has a custom ASIC that replaces the STIC and PSG; that ASIC has bugs.
  • Interrupt generation is dodgy, leading to the IntyBASIC hang mentioned above.
  • PSG emulation behaves oddly if you set your volume to certain settings. (To be fair, those settings were only supported on the earliest AY-3-8914 PSGs, and none of the AY-3-8910s.)
• And, full Tutorvisions have an additional 4Kx10 ROM at $2000 - $2FFF. Other INTV88 boards have the Intellivision 1 EXEC instead.

 

I have a full 27-page reverse engineering doc on Google Docs that I've updated as I learn more. Attached is a PDF of the latest version.

 

(EDIT: I made a few minor updates to the PDF, so if you downloaded it before you saw this EDIT, download it again for the latest. Nothing earth shattering; just added some comments on the IntyBASIC bootup double-interrupt issue, and fixed some formatting.)

 

Wow, that's wild! I don't know much about the history of the TutorVision itself. I thought it was some late and failed collaboration between Mattel and the World Book Encyclopædia, but your data-sheet points out references to INTV Corp. in the ROM. I'll have to get more acquainted with this console.

 

Do you suppose that the motivation for the STIC1A was just pure cost-cutting? I ask because it seems so buggy and prone to glitches, and so incompatible in some regards.

 

Based on your analysis, Christmas Carol won't work on the TutorVision either because it uses the previously unused GRAM bits in the BACKTAB word for game state flags. I wonder how it would look, though.

 

Thanks for that detail analysis, it's very interesting (although most of it went way over my head).

 

-dZ.

[intvnut]

Wow, that's wild! I don't know much about the history of the TutorVision itself. I thought it was some late and failed collaboration between Mattel and the World Book Encyclopædia, but your data-sheet points out references to INTV Corp. in the ROM. I'll have to get more acquainted with this console.

 

It was a failed venture between INTV Corp and WorldBook in 1989. (Scroll down to TUTORVISION.) Mattel Electronics had folded several years earlier. Steve Ettinger apparently programmed 5 of the TutorVision games. I imagine David Warhol is the reason TutorVision titles are loaded with rich classical music arrangements.

 

The STIC1A apparently went through a couple revisions—at least two date codes are known, far enough apart in time to support the idea that a respin happened—but I imagine the main goal was a combination of cost reduction, and modest feature improvements. The two known date codes are 8912 (1989, week 12) and 8930 (1989, week 30). Those are 18 weeks apart (just over 4 months), which is about the time it takes to get a chip spin put together and pushed through the fab, especially in 1989 process technologies. I only have limited access to the 8912 datecode system; however, if I could construct a concrete slate of tests to run, I could probably talk the owner into running them.

 

By 1989, most of the components in the Intellivision were a decade old or older. The STIC and AY-3-8914 (or AY-3-8916) PSG were only being produced for the Intellivision. Likewise for various ROMs. Meanwhile, GI had spun off its semiconductor division as Microchip, and they were probably looking to streamline their catalog to what sells to a large audience; everything else would likely get collapsed down to a customer-specific ASIC engagement or dropped. For instance, Microchip has never listed the CP1610, AY-3-8900, RA-3-9600, or other Intellivision-specific components under its catalog. It has listed the SP0256-AL2, however, likely because it had enough business through Archer (aka. Radio Shack), and other companies that were putting together bespoke SP0256 versions for their particular application. (Apparently, SP0256 was popular in defibrillators, public trans, clocks, elevators, and a few other places.) So, likely Microchip put together an ASIC development contract w/ INTV Corp to streamline the CP1610 into the CP1610A, produce a few GI ROMs, and integrate the PSG + STIC + glue logic into the STIC1A.

 

Anyway... Christmas Carol would not work on a full TutorVision due to ROM conflicts in $2000 - $2FFF. Christmas Carol will not run properly on a full TutorVision due to that ROM conflict.

 

On a jzIntv emulation of an INTV88 board that lacks WBEXEC, though, so far I didn't see any real differences. (Granted, I was checking in jzIntv, and I didn't venture very far in.) You could check for yourself with a recent version of jzIntv. Just append 8KB of 0xFF to your EXEC image, and that'll force jzIntv into INTV88 mode. You don't need to worry about ROM conflicts in jzIntv, as I just bit-AND the return value from all peripherals. So, if you pad out the EXEC with 0xFF, that 0xFF will get ANDed with your game contents, yielding... your game contents!

 

So... go ahead and try Christmas Carol on jzIntv in INTV88 mode. Just modify your EXEC.BIN to add 8K bytes of 0xFF to it. You should see this additional line when jzIntv boots up:

.

WBEXEC ROM       [0x2000...0x2FFF]

.

As long as you see that, you know the INTV88 extensions are enabled.

Edited January 22, 2018 by intvnut

[+DZ-Jay]

 

It was a failed venture between INTV Corp and WorldBook in 1989. (Scroll down to TUTORVISION.) Mattel Electronics had folded several years earlier. Steve Ettinger apparently programmed 5 of the TutorVision games. I imagine David Warhol is the reason TutorVision titles are loaded with rich classical music arrangements.

 

The STIC1A apparently went through a couple revisions—at least two date codes are known, far enough apart in time to support the idea that a respin happened—but I imagine the main goal was a combination of cost reduction, and modest feature improvements. The two known date codes are 8912 (1989, week 12) and 8930 (1989, week 30). Those are 18 weeks apart (just over 4 months), which is about the time it takes to get a chip spin put together and pushed through the fab, especially in 1989 process technologies. I only have limited access to the 8912 datecode system; however, if I could construct a concrete slate of tests to run, I could probably talk the owner into running them.

 

By 1989, most of the components in the Intellivision were a decade old or older. The STIC and AY-3-8914 (or AY-3-8916) PSG were only being produced for the Intellivision. Likewise for various ROMs. Meanwhile, GI had spun off its semiconductor division as Microchip, and they were probably looking to streamline their catalog to what sells to a large audience; everything else would likely get collapsed down to a customer-specific ASIC engagement or dropped. For instance, Microchip has never listed the CP1610, AY-3-8900, RA-3-9600, or other Intellivision-specific components under its catalog. It has listed the SP0256-AL2, however, likely because it had enough business through Archer (aka. Radio Shack), and other companies that were putting together bespoke SP0256 versions for their particular application. (Apparently, SP0256 was popular in defibrillators, public trans, clocks, elevators, and a few other places.) So, likely Microchip put together an ASIC development contract w/ INTV Corp to streamline the CP1610 into the CP1610A, produce a few GI ROMs, and integrate the PSG + STIC + glue logic into the STIC1A.

 

Anyway... Christmas Carol would not work on a full TutorVision due to ROM conflicts in $2000 - $2FFF. Christmas Carol will not run properly on a full TutorVision due to that ROM conflict.

 

On a jzIntv emulation of an INTV88 board that lacks WBEXEC, though, so far I didn't see any real differences. (Granted, I was checking in jzIntv, and I didn't venture very far in.) You could check for yourself with a recent version of jzIntv. Just append 8KB of 0xFF to your EXEC image, and that'll force jzIntv into INTV88 mode. You don't need to worry about ROM conflicts in jzIntv, as I just bit-AND the return value from all peripherals. So, if you pad out the EXEC with 0xFF, that 0xFF will get ANDed with your game contents, yielding... your game contents!

 

So... go ahead and try Christmas Carol on jzIntv in INTV88 mode. Just modify your EXEC.BIN to add 8K bytes of 0xFF to it. You should see this additional line when jzIntv boots up:

.

WBEXEC ROM       [0x2000...0x2FFF]

.

As long as you see that, you know the INTV88 extensions are enabled.

 

Cool! Thanks for all that interesting info. I will certainly try Christmas Carol in INTV88 mode just for kicks.

 

By the way, I'm sure I can figure out some silly way to do it, but do you have a particularly simple way to add those extra 8KB of $FF to the EXEC.ROM?

 

-dZ.

[intvnut]

 

By the way, I'm sure I can figure out some silly way to do it, but do you have a particularly simple way to add those extra 8KB of $FF to the EXEC.ROM?

 

 

I literally created a file that had 512 lines containing the following:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

I then ran that through fromhex, and that created a file with 8192 0xFF bytes. I then did "cat exec.bin ff.bin > exec_ff.bin" to create the final fake WB EXEC.

[+DZ-Jay]

 

I literally created a file that had 512 lines containing the following:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

I then ran that through fromhex, and that created a file with 8192 0xFF bytes. I then did "cat exec.bin ff.bin > exec_ff.bin" to create the final fake WB EXEC.

 

Hahaha! That's kind of what I was going to do. Thanks!

[+DZ-Jay]

 

I literally created a file that had 512 lines containing the following:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

I then ran that through fromhex, and that created a file with 8192 0xFF bytes. I then did "cat exec.bin ff.bin > exec_ff.bin" to create the final fake WB EXEC.

 

OK, I just tried it and it looks and work reasonably well. The only things I noticed was that some (most?) of the candy bon-bons on the mazes were invisible, presumably because they encode their "eaten" state in the extra card bits of the BACKTAB word, which the INTV88 interprets as some GRAM card far off into the nether regions of memory.

 

I also saw a brief glitch at some point where the background flickered for a frame, reminiscent of a bug we encountered during development having to do with the Color Stack Advance flag not being handled properly when picking up a specific type of present which uses the GROM solid block in reverse video. There may be something strange going on there because those bugs were eradicated, as far as I can recall. Except that this time, it happened while just standing there, so perhaps an interrupt timing issue?

 

Other than that, it seemed perfectly fine, music, sound effects, and all, which is wild.

 

Thanks for all that research and analysis, it's fascinating to learn about an alternative history that could have been.

 

-dZ.

[freewheel]

Realizing that this thing has an ASIC ... I wrote a cryptocurrency miner for my INTV88 board. I should have a couple of dollars by 5018 or so. Although I might be off by several orders of magnitude here. Like 10.

[intvnut]

Realizing that this thing has an ASIC ... I wrote a cryptocurrency miner for my INTV88 board. I should have a couple of dollars by 5018 or so. Although I might be off by several orders of magnitude here. Like 10.

 

Surely your Intellivision could outpace Ken Shirriff.

 

Edited January 24, 2018 by intvnut

[Zendocon]

I opened up the Little Man Computer code since posting and embellished my autodetection script to include STIC1A as well as WBEXEC.  What about the extra RAM though?

 

So there's extra 16-bit RAM in the range $360-4ff.  It seems when not present, I keep getting the value $ffff all throughout this range.  The same thing is true when WBEXEC is not present; the address range $2000-2fff gives me the value $ffff, which is how I do autodetection here.

 

Fortunately, I don't put this RAM to use, so I dodged another bullet with regard to compatibility between full TutorVisions and the mixed-bag Tutor Pro units.  I couldn't use it anyhow, because my program needs 1.2K, so I'm getting it from JLP.  But I'd like to know how to enable it and autodetect it at least.

 

I read the Reverse Engineering Notes, and it seems to suggest that the STIC1A enables that expanded memory range.  Is there a way to enable STIC1A in jzIntv?  There's no switch for it that I can see.  I don't see how writing $ff to the whole $2xxx range would do anything, and it that were the case, the two game ROMs + WBEXEC should have actual values in the expanded RAM range other than $ffff.

[+Lathe26]

At this point, the only variations known of with Tutor Pros is whether or not they have the original Mattel EXEC or the larger Tutorvision REX ROM.  As far as anyone knows, there are no Tutor Pros that exist with other combinations of mix-and-match parts, which makes sense since the 3 minor circuit board variations of the INTV88 circuit board are almost the same and have the same parts.

 

Maybe there are unknown variations out there or maybe some of the mysterious jumpers activate/deactivate things.

[Zendocon]

7 hours ago, Lathe26 said:

At this point, the only variations known of with Tutor Pros is whether or not they have the original Mattel EXEC or the larger Tutorvision REX ROM.

That's good to know.  I implemented LMC for the worst-case scenario, not putting REX to use and staying out of the $2xxx address range, so it shouldn't matter whether or not it's there.

 

I tried expanding the one <2K block to start at $4040 instead of $4100, and it's fine.  The earliest subroutines in that block didn't break.  Altogether, my memory map would allow the ROM to reach ~39.6K in size without bankswitching.

 

I'm not really worried about STIC1A since LMC doesn't use collision detection at all, but I still would like to know how to enable and autodetect the extra RAM.  @nanochess, are there any plans to add "Tutorvision RAM" functionality to IntyBASIC?

[Zendocon]

For the fun of it, I decided to start looking at a disassembly of WBEXEC.  If I ever decide to create another Tutorvision title in the future, would there be any merit to putting it to use?  If so, I would have to maintain two separate ROM images, one with WBEXEC bundled and one without.  As a starting point, I decided to see the graphics for myself, as displayed on the fifth page of the Reverse Engineering Notes.

 

Took me a while to figure out how it's working.  The ranges didn't seem to add up.  Apparently at bootup, there's code somewhere (as of right now, I haven't started looking at the code yet to decipher possibly useful entry points) to unpack these characters into GRAM cards 58-239 ($3a-ef).  But I didn't find any 8-bit data until I reached $2400.  The character there turned out to be the one that looks like the top half of a '2' in the large Tutorvision font.  The character after that was the copyright symbol, and that's where I got oriented.

 

But working my way backwards, the bottom 8 bits starting at $2000 gives us the graphics for the character loaded at $5a rather than $3a.  Where do the first 32 characters come from?  Certainly not $1fxx!  And why were the extra two bits seemingly raised at random between $2000-23ff?  Then it hit me; the top two bits at every 32 locations unpack into the 64 pixels forming each 8x8 graphic.  I studied these bits, and that does turn out to be the case.  Mystery solved.

 

Would WBEXEC have been useful for LMC?  Probably.  As it is, I use the $fxxx address range for nothing but graphics and metadata.  All the graphics get happily loaded from ROM into GRAM at bootup, before the title sequence.  Between that and the autodetection script, I take about a half second of time before starting the title's musical sting, in case we're using a TV that needs that much time at power on before anything plays through the speakers.  I learned that lesson after Blix & Chocolate Mine.

 

If I had put these WBEXEC graphics to use plus the procedures to pack the characters into the GRAM cards, that would have shrunk my ROM by ~1.2K, allowing me enough room to pack the menu text and lookup tables starting at $f000, instead of having to shoehorn it all somewhere else.  What else is out there that might be useful?  Time for me to go spelunking.

[mr_me]

17 hours ago, Zendocon said:

...

 

I read the Reverse Engineering Notes, and it seems to suggest that the STIC1A enables that expanded memory range.  Is there a way to enable STIC1A in jzIntv?  There's no switch for it that I can see.  I don't see how writing $ff to the whole $2xxx range would do anything, and it that were the case, the two game ROMs + WBEXEC should have actual values in the expanded RAM range other than $ffff.

 

Jzintv will automatically emulate the Tutorvision board (INTV 1988) including the ram and new STIC if it detects the Tutorvision Exec.  I don't know how much of the new STIC it emulates but it does display the 160th pixel.  I also don't know if you can manually turn on INTV 1988 board features in Jzintv other than the extra gram.

 

The STIC in the Tutorvision is part of a larger ASIC that includes a few things several chips do in a standard intellivision.  That includes the STIC, sound generator, and part of  

RA-3-9600.

Edited July 16, 2021 by mr_me

[+nanochess]

2 hours ago, Zendocon said:

I'm not really worried about STIC1A since LMC doesn't use collision detection at all, but I still would like to know how to enable and autodetect the extra RAM.  @nanochess, are there any plans to add "Tutorvision RAM" functionality to IntyBASIC?

If you find how to enable the extra RAM section, it would be easy to add the code and a switch to IntyBASIC.

[Zendocon]

2 hours ago, mr_me said:

Jzintv will automatically emulate the Tutorvision board (INTV 1988) including the ram and new STIC if it detects the Tutorvision Exec.

That seems to be the issue.  It's not doing that.  I tried creating a dummy file with 4K of $ff values and added it to LMC at $2000, and it didn't make a difference.  Then I fired up one of the two released TV games and broke to the debugger and looked at $22, and I got a value of $3fff when I should have gotten $3ff7 for STIC1A.

 

I'm using the ROM images with the Half WBEXEC appended.  My understanding is that the other half of the TV EXEC is no different than the EXEC on a standard Intellivision.  So either the logic to detect REX isn't working, or it's looking for something else I'm not aware of, or I'm wrong and there's a different EXEC image I should be using instead.  I'm using the 20200712 release of jzIntv, the first one that switched from SDL1 to SDL2.

[mr_me]

Are you getting the 160th pixel displayed?  If not then tutorvision emulation in Jzintv is not being triggered.  If that's the case then maybe Jzintv is checking the file designated as exec rather than the memory area.

[Zendocon]

1 hour ago, mr_me said:

Are you getting the 160th pixel displayed?  If not then tutorvision emulation in Jzintv is not being triggered.  If that's the case then maybe Jzintv is checking the file designated as exec rather than the memory area.

I didn't check the far right column of pixels just yet.  I heard there are other EXEC dumps out there, particularly for MESS I think.  I'll go fetch a different one and try that.

[mr_me]

If you don't have the tutorvision exec file, here it is.  You won't find it in any Mame/Mess collection.  You could probably make  one by cutting and splicing files.

exec_tutorvision.zip

[Zendocon]

I took a screenshot from the AD&D Cloudy Mountain title screen.  As you can see, jzIntv does seem to be detecting TutorVision based on the GROM file I'm using; "Mattel" is replaced with " INTV ".  So I would think it would enable SITC1A.  However, the asterisk after "DRAGONS" is clipped.

 

UPDATE: it looks like our messages crossed.  I see you posted the 8K EXEC just now.  I'm renaming it "wbexec.bin" since that and exec.bin I'm keeping in the same folder.  I'll try it with LMC now.

Edited July 16, 2021 by Zendocon
Messages had crossed

[mr_me]

And the INTV text comes from the grom file, not the exec.  Jzintv can still emulate a Tutorvision with a regular Mattel grom, and emulate a regular Intellivision with the Tutorvision grom.

[Zendocon]

Yes, that bigger EXEC file is what jzIntv was looking for.  I thought this whole time that it was looking at the GROM or the EXEC.  Now the expanded memory range is initialized to 0, and my program is autodetecting the STIC1A.  That's all I needed, thanks!

Edited July 16, 2021 by Zendocon
Typo

[Zendocon]

Quick question: do all the Super Pro systems have the INTV GROM?  What about the extra GRAM?  So the only open question with an individual unit is whether ot not it has the expanded EXEC, right?

[mr_me]

Only a handful of INTV systems have been found with the extra gram and INTV grom.  They seem very rare.

[Zendocon]

Okay.  Somebody posted a Super Pro System.  I asked him about the GROM, and he sent me a screenshot with the INTV font.  So it's a safe bet his is a Tutor Pro then, probably only missing REX?