MTE-201 errors

[freewheel]

Finally getting around to testing a bunch of consoles. Man, the controllers really don't like working in all 16 directions. I'm sure this has been discussed in another thread years ago, but I can't find anything - please steer me somewhere if needed.

 

I've got 2 units that seem to "work fine" but show errors with the MTE-201 test routines:

 

A Sears unit that shows failure at tests L and M, and failure on U03/U09.

 

A 2609 unit (Canadian) that shows failure at tests M and P, and failure on U03/U04.

 

The only thing I can dig up on these is a 15 year old post from Joe Z discussing how the "failure at test M" on 2609s might be because they're using the Sears EXEC. I have no idea what any of these other tests actually mean.

[+cmart604]

This thread clearly needs Joe.

[freewheel]

On further digging - do the U0* tests simply reflect what you've pressed for clear/enter at the sound/STIC/etc checks? I'm wondering if slightly flaky controller input is messing them up, if so.

 

Also my 2609 (Canadian) is now passing tests M and P with flying colours. I can, however, sometimes trigger weird failure states if I flail on the keypad. More interesting - I got into some kind of specific diagnostic menu where you can test individual items, but I can't for the life of me figure out how I got there!

[mthompson]

A Sears unit that shows failure at tests L and M, and failure on U03/U09.

 

Now that I've got an LTO Flash, I can finally run that test cart on my Sears. It failed the exact same tests, but in regular use it seems fine.

 

I seem to have read that the Sears units fail certain tests because of their modified chip(s), but It's been too long to tell you where I saw that.

[+Lathe26]

I'm going from memory here, but I believe that V3.0 of the software is what the MTE-201 has and I believe that version is not aware of the Sears EXEC ROMs or the Intellivision II EXEC ROMs. Thus, it will fail those consoles.

 

What I do know for certain is that V4.1b knows about all 3 EXEC variants and will identify which one it is running on (assuming there is not an actual problem with the EXEC ROMs).

[+JasonlikesINTV]

Does the LTO Flash have a console diagnostic ROM on it? I have a few consoles to test.

[intvnut]

Here's the IMI spec, starting at page 174.

In particular, this page is helpful:

 

 

The Sears unit will fail the EXEC tests, because it has a different EXEC image. It's otherwise fine.

 

That unfortunately doesn't list test L.

 

The service manual also lists the codes. It doesn't include L either. I forget what L tests.

 

 

 

 

I got into some kind of specific diagnostic menu where you can test individual items, but I can't for the life of me figure out how I got there!

 

1+7 on the controller, IIRC. I believe the spec I linked above also says that.

[intvnut]

Does the LTO Flash have a console diagnostic ROM on it? I have a few consoles to test.

 

It doesn't. I should find out if Intellivision Productions minds if I distribute one of the MTE-201 images. And, I should just straight-up write my own.

 

One of the neat things about having a serial port is that it could theoretically output some diagnostic info over that, too, in case the STIC display is FUBAR.

[+JasonlikesINTV]

 

It doesn't. I should find out if Intellivision Productions minds if I distribute one of the MTE-201 images. And, I should just straight-up write my own.

 

You know....in your spare time. Is it as simple as making a ROM that lights up when you press certain buttons? I can't believe this doesn't exist yet...as a ROM.

[intvnut]

You know....in your spare time. Is it as simple as making a ROM that lights up when you press certain buttons? I can't believe this doesn't exist yet...as a ROM.

Do you want controller diagnostics, or full console diagnostics? Full console diags are a bit more involved.

[+JasonlikesINTV]

Do you want controller diagnostics, or full console diagnostics? Full console diags are a bit more involved.

Controller diagnostics would be nice since they are common weak spots. I could swap controllers around to make some functional systems, but I probably wouldn't know what to do if a console had bigger issues. Most of the consoles I own will load games, but a few seem to have controller issues. One of my Tandyvisions only goes to a black screen, but I think I have a bad capacitor(s). I have no idea when I'll have time to work on any of this, though. Prob not this year

[intvnut]

The "Hand Demo" that comes with jzIntv, while not intended as a controller diagnostic, serves as one in a pinch.

 

If you don't mind having a somewhat manual procedure, it'd be a really simple matter to whip up something in IntyBASIC to demonstrate that all of the bits change in the expected way for different inputs on both controllers.

 

The advantage of simple code (ie. doesn't try to decode the controllers, just shows you what bits change) is that if you have a short between two lines or one line that isn't changing reliably, it becomes obvious which wires are affected. My "Hand Demo" tries to decode what it sees, which obscures the underlying causes of any failures a bit.

Edited September 21, 2016 by intvnut

[mr_me]

Finally getting around to testing a bunch of consoles. Man, the controllers really don't like working in all 16 directions. I'm sure this has been discussed in another thread years ago, but I can't find anything - please steer me somewhere if needed.

...

If you don't have a controller diagnostic use PGA Golf. There's one case where if all 15 buttons work but you've lost half of the 16 directions then pin 9 has failed. Need to know exactly which of the 16 directions and buttons are failing. It could be the cable rather than the circuit matrix. You can tell which bits are failing by the buttons/directions and referencing the controller pinouts in the intellivision faq. Then you open the controller, check continuity in the cable wires, and then inside the controller.

[+Lathe26]

The "Hand Demo" that comes with jzIntv, while not intended as a controller diagnostic, serves as one in a pinch.

 

If you don't mind having a somewhat manual procedure, it'd be a really simple matter to whip up something in IntyBASIC to demonstrate that all of the bits change in the expected way for different inputs on both controllers.

 

The advantage of simple code (ie. doesn't try to decode the controllers, just shows you what bits change) is that if you have a short between two lines or one line that isn't changing reliably, it becomes obvious which wires are affected. My "Hand Demo" tries to decode what it sees, which obscures the underlying causes of any failures a bit.

+1 for Hand Demo. It's handy.

[intvnut]

+1 for Hand Demo. It's handy.

Ya gotta hand it to him folks.

 

Have A Nice Day.

[freewheel]

The "Hand Demo" that comes with jzIntv, while not intended as a controller diagnostic, serves as one in a pinch.

 

 

Wait, what? I've never seen a ROM like this in the jzintv packages I have. What am I missing?

 

 

If you don't mind having a somewhat manual procedure, it'd be a really simple matter to whip up something in IntyBASIC to demonstrate that all of the bits change in the expected way for different inputs on both controllers.

 

It is, but IntyBASIC handles control input a bit oddly for this. For instance, it can't detect multiple button presses if you use the "simple" controller reading. So people need to be careful, and take the time to fully decode what the controllers are actually doing.

 

Kinda-sorta related to that - I notice that MTE-201 does some interesting things with its controller checking. I'm not sure if it's passing something into the EXEC's controller handling or what. For example, pressing the left (lower) button and 1 should also light up down on the disc, arguably. The appropriate bits are set, and there's no way to know that the disc ISN'T being pressed. Pressing the other buttons and 1 lights up the buttons, keypad, and disc as you'd expect. It's as if the EXEC has some kind of "maximum number of inputs allowed" going on. Unless I'm very much misunderstanding something. Which is usually likely.

[intvnut]

 

Wait, what? I've never seen a ROM like this in the jzintv packages I have. What am I missing?

 

It's in the 'examples' folder. You may need to download jzIntv 1.0 beta 4 source, though, since I still need to get the stable dev source online. It's been part of SDK-1600 for like 15 years. And probably floating around the In-tar-webs under the name "handdemo".

 

 

 

It is, but IntyBASIC handles control input a bit oddly for this. For instance, it can't detect multiple button presses if you use the "simple" controller reading. So people need to be careful, and take the time to fully decode what the controllers are actually doing.

 

For a diagnostic, you should probably just use PEEK($1FE) / PEEK($1FF) and avoid the decoded inputs entirely. That is, write it in IntyBASIC, but still go directly to the hardware for these bits. Just showing the raw 8 bits goes a long way to being a valuable diagnostic, since you can tell if wires are shorted together, or not responding at all.

 

If you want to also show which input / combination of inputs could generate that pattern in addition to the raw value, that's extra credit, IMHO.

 

At least, that's what I'd want if I were writing a dedicated hand controller diagnostic.

 

 

Kinda-sorta related to that - I notice that MTE-201 does some interesting things with its controller checking. I'm not sure if it's passing something into the EXEC's controller handling or what. For example, pressing the left (lower) button and 1 should also light up down on the disc, arguably. The appropriate bits are set, and there's no way to know that the disc ISN'T being pressed. Pressing the other buttons and 1 lights up the buttons, keypad, and disc as you'd expect. It's as if the EXEC has some kind of "maximum number of inputs allowed" going on. Unless I'm very much misunderstanding something. Which is usually likely.

 

If it uses the EXEC (which I imagine it is), then it's probably updating the display based on which dispatches got triggered from the EXEC. I don't think the EXEC resolves two action-button presses simultaneously. Bottom left lights up bits 5 + 6, while '1' lights up bits 7 and 0.

 

To get bits 5 + 6 + 7 lit up together, you need to either press two action buttons, or action button + keypad. I believe the EXEC only handles bits 5+6, bits 6+7 and bits 5+7, and throws its hands up at bits 5+6+7, but I'm not sure.

[freewheel]

Wow, I must be intentionally deleting the examples folder. facepalm.

 

IntyBASIC allows you to hit $1FF/$1FE (albeit complemented) using the built-in constructs CONT1/CONT2. Which is handy to actually see which bits are "on" (I assume these are active-low like the PSG mixer).

 

One thing I don't actually know - do the bitmasks correspond literally to the 8 non-ground pins in the controller cables? Cuz yeah, that'd be super handy to display the bitmask. Hell, draw out a little graphic of the controller plug, and light up the appropriate pins. Especially as the wires are consistently color-coded, if memory serves.

[intvnut]

One thing I don't actually know - do the bitmasks correspond literally to the 8 non-ground pins in the controller cables? Cuz yeah, that'd be super handy to display the bitmask. Hell, draw out a little graphic of the controller plug, and light up the appropriate pins. Especially as the wires are consistently color-coded, if memory serves.

 

Yep, 1:1 correspondence.

[+fdr4prez]

 

It's in the 'examples' folder. You may need to download jzIntv 1.0 beta 4 source, though, since I still need to get the stable dev source online. It's been part of SDK-1600 for like 15 years. And probably floating around the In-tar-webs under the name "handdemo".

 

 

From what I can see, the "Stable Dev Version" comes with a joy-diag.rom but I've never used it.

 

The jzintv 1.0 beta 4 SDK comes with a handdemo.asm, so you have to ROM-ify it?

 

In my jzintv rom list, I've got the "Hand Demo2.BIN", but not sure where I got that one from.

[freewheel]

 

Yep, 1:1 correspondence.

 

Go-go gadget decimal-to-bitmask algorithm that I haven't thought about since literally my first week of CompSci! Interesting that in modern languages they suggest pushing it onto a stack. Sometimes it's more fun to just blit things out to the screen.

[intvnut]

From what I can see, the "Stable Dev Version" comes with a joy-diag.rom but I've never used it.

 

joy-diag is something quite different. It's literally jzIntv joystick diagnostics, that is, for interfacing Windows/Mac joysticks to jzIntv. It uses an emulator backdoor to get raw joystick parameters, to help diagnose issues with mapping analog joysticks to the Intellivision's 16-direction disc, for example. The other ROMs that come in jzintv/rom are similar in purpose: mainly to diagnose jzIntv.

[intvnut]

The jzintv 1.0 beta 4 SDK comes with a handdemo.asm, so you have to ROM-ify it?

 

Yes, you need to assemble it. And I believe it says inside the file what command to run to do so.

 

Since it was part of the Software Developer's Kit and meant to be a programming demo, not necessarily a diagnostic tool, I left it as an exercise to the programmer to at least assemble it.

Edited September 23, 2016 by intvnut

[+fdr4prez]

 

joy-diag is something quite different. It's literally jzIntv joystick diagnostics, that is, for interfacing Windows/Mac joysticks to jzIntv. It uses an emulator backdoor to get raw joystick parameters, to help diagnose issues with mapping analog joysticks to the Intellivision's 16-direction disc, for example. The other ROMs that come in jzintv/rom are similar in purpose: mainly to diagnose jzIntv.

 

That sounds kinda neat.

 

 

 

Yes, you need to assemble it. And I believe it says inside the file what command to run to do so.

 

Since it was part of the Software Developer's Kit and meant to be a programming demo, not necessarily a diagnostic tool, I left it as an exercise to the programmer to at least assemble it.

 

Oh, yeah, I can appreciate that.

 

I am curious if it is the same as that "hand demo2.bin" that I have.

[mr_me]

handdemo2 is the same as handdemo, it just adds a graphical representation of the controllers like the mattel test cartridge.