intvnut

Would this one be an appropriate replacement? Of course, that's $1 for the fuse, and probably $13.75 in shipping, handling, tax and fees.

Nope. I have tried changing the RF selector to 3 and 4 and back repeatedly while the system is on. It doesn't alleviate the shaking at all. Also - just FYI - I tried this on channels 3 and 4 and it does it on both stations. I meant changing channels on the TV. Some TV's AFTs behave oddly with my Intellivision. If I turn the TV on before the Intellivision, I'll get a crappy signal on the TV. But, if I turn the channel on the TV and turn back, it's fine. I suspect the reason, in part is that the center frequency for the RF modulator's shifted far enough that the AFT won't capture it after it's "settled in" on the station. But, if you tune away and tune back, it makes a wider sweep and hones in on the Intellivision. That's the main thing I can think of. The only other thing I can think of is that you could be getting a crummy ground on the RF connector, but I don't think that'd do this. I don't know what's more amazing... that it's starting to behave, or that you played Vectron for a full half hour. :-)

I've noticed my systems have drifted "off center" for channels 3 and 4. It interacts poorly with the automatic fine tuning on modern TVs. The symptoms are usu. poor reception (hazy picture, buzzing on the sound, sometimes fail to sync with the picture). Have you tried changing channels and changing back? Does that have the same effect as removing the RF cable and reseating it? That sounds like a more generic crash, probably due to some component getting too warm. I think you're right at a high level that the causes are the same. Electrolytic capacitors can "dry out," losing capacitance. That would cause both symptoms, but it'd be different capacitors I'd reckon. Anyone else with insights?

Definitely install a reset button. Even my most reliable Intellivisions often need you to punch reset after powerup to get a game screen. IIRC, the stock reset button just pushes on a piece of metal to make a momentary contact switch directly on the logic board. You could wire a discrete momentary contact switch to those two points, or between GND and pin 12 on the cartridge port. Here's the view from the cartridge's perspective:

Hmm. That sounds like it could be a reset issue also. First question, naturally, is have you tried punching reset when it's powered up with a black screen? Reset is handled by the STIC, AY-3-8900. You can see it in the middle of this schematic: http://spatula-city.org/~im14u2c/intv/tech...s/schematic.png I unfortunately don't know where I put my opened logic board (it used to live somewhere on my projects desk, but I'm not finding it). Otherwise I could tell you more exactly to look. Anyhoo, check the voltages and caps associated with U4 (AY-3-8900) and U1 (CP-1610) first. U4 is the video chip, U1 is the CPU. They're both socketed with epoxied heat sinks. There's a weird thing in the schematic at C26, going to pin 14 of U4, nearly smack dab in the middle of the schematic. That's the capacitor on the reset line. It's a 50V, 1µF capacitor, non-polarized capacitor, as I read it. The symbol for it's kinda goofy. I think the cap they used must be two polarized caps back-to-back under the hood. If you replace that goofy thing, just be sure to use a non-polarized cap there that's around 1µF. (Not sure what justifies a 50V rating there, but they DO mention it in the schematic...) Fun fact: The part numbers are inked on the bottom of the heat-sink-covered chips. So, when you remove them from the socket, you can ID which chip is which. Just keep track of which end gets the notch so you don't put them back in backward.

I just looked at the C64 cartridge pinout. It has GND at all 4 corners. Intellivision puts +5v at one of the corners. (See bottom of second image below.) So, plugging in a C64 cart to an Intellivision would short +5 to ground and probably toast something in the power supply. The Intellivision 2 doesn't have an on-off switch but rather some bizarre combo power/reset switch that's annoying as heck. It also requires holding the button down for 10 seconds (cleanly) to get it to shut off, so it's probably pretty easy to keep that power-ground short active for plenty long to fry it's power supply. (Note: Someone correct me if I'm wrong. The C64 pinouts are numbered with 1 - 22 on one side, and A-Z on the other. This contrasts with the Intellivision, which numbers its pins 1 - 44, with odd on one side and even on the other. I note that 1, 22, A and Z on the C64 are tied to GND, which should correspond to Intellivision pins 1, 2, 43 and 44.)

It certainly didn't have to suck. Carl Mueller, Jr. has an incomplete port he's done here that blows away just about any other home system's version, including CV. It's not complete, sadly. What's missing is the "outer game loop" stuff. The in-game sections are very complete. All four boards are present, even.

Yeah, definitely check the voltages going into the unit, and that all the connections from the power supply board to the logic board are in place solid. I had a "dead" unit that required reseating all the connections firmly. (I suspect oxidation in there.) The CPU requires a fair bit of grunt on its clock lines (something like 10V - 14V!!). The console has an exorbitant number of voltages it needs to operate correctly. Oh, and I think there's a typo on Steve's site (INTV Fun House). That -2V is supposed to be -3V, I'm 99.44% certain. It's V_ss to the CPU, and I'm pretty certain that's supposed to be -3V. That darned CPU takes like 5 voltages all by itself... -3V, 0V, 5V, 12V directly, and 10-14V on its clock lines. If you wanna get really adventurous, you'll have to desolder that sarcophagus and try reseating all the socketed chips. Reseating isn't hard. Finding something to do with the three gallons of solder they use to weld the thing shut's another story. :-)

I'm not sure what you're suggesting here. Are you saying you'd come up with a new board layout based on the original schematics, or even replicate the board layout and stuff it with all the same parts? What do you mean by starting with "an actual still-working NES"? I've thought about making a custom board design for the Intellivision, reducing it to a set of boards with smaller total area/volume, in part by integrating some of the parts into a single microcontroller, only keeping the key original pieces. But, I could also just keep all the original components and come up with a new layout to fit a new form factor. Reproducing the existing layout's a waste of time. I'd rather just scour eBay. :-)

Sorry I didn't mean to imply they are definitely compatible, it's more of an assumption, if anyone can confirm? Of course even if movement was compatible you might be screwed without keypad input?.................... They're not compatible, and I suspect that's part of the reason why the connectors are recessed as far as they are. You can (and indeed must) plug Atari controllers into the System Changer (which is basically an Atari in an Intellivision II-styled shell), but you can't use Atari controllers directly on an Intellivision. The Intellivision II controllers use the same 9-pin wiring as the Intellivision 1 controllers, just with a different connector. (The Inty 1's controllers detach internally from the main board. They're not detachable externally, though.) The pinout is also the same as the Sears version's detachable controllers. The Atari controllers are simple enough that it should be possible to make a really simple converter cable. There are four lines that correspond to N/S/E/W on the Inty's input. You could wire those directly to the Atari's lines for those directions. For the fire button, you'd have to decide which of the three action buttons you want to associate it with. There are three input wires on the Inty to indicate which action button's being pressed. Action buttons are indicated by pulling down a pair of lines, though. I'd suggest doing this through a couple diodes so you don't have a pin-to-pin short. Why? This whole scheme would work best if it were set up as a Y cable, with the original controller on one side of the Y and the Atari-compatible controller on the other. The two can be wired in parallel. That way, if you need to use the keypad for some things (e.g. to navigate a menu), or there's some rarely used option on one of the action buttons you *haven't* mapped to fire button, then you can easily grab the original controller for those inputs. An example of the latter situation occurs in Beamrider: Most of the time you use one action button to shoot at the ships. At the end of the stage, though, you need to fire a different kind of missile at the stage boss, and that uses a different action button. That portion of the stage happens for just a short bit with plenty of time to switch controllers to handle it.

Wow... I've been gaming almost since birth and emulating systems nearly as long. Yet I'd still never heard of emu-docs.org. All aboard the S.S. Failboat, captain G_P_T-0_1. Still, it'd be nice to have some of those docs searchable and such. Thanks for the link 5-11under! That scan is pretty similar to my data book. I'll still scan mine, though, in case there are any updates or clarifications. If nothing else, it'd be nice to have it in the historical record. As far as Intellivision goes, though, emu-docs.org has nothing truly useful whatsoever. :-) That's ok, we've managed to put together a pretty comprehensive set of docs anyway.

Those other points with the fantastic solder job... If I'm not mistaken, they form a route from the RF modulator, through the NTSC mixer circuit back to the VDP. I'll lay odds this guy got hit by lightning. Or rather, the antenna on the TV that this was connected to did. Either that, or one heck of a static electricity snap.

WTF did this guy use to solder with? An arc welder? Acetylene torch? (To show how ignorant I am of the CV lifespan and its (apparently) many revisions. I remembered I had a CV logic board in the garage I had picked up absolute ages ago from some liquidator for like $5. I grabbed it with the thought of comparing notes. HA! Mine is a Rev A-1, and has a completely different layout and shape. Its footprint reminds me of the Stealth fighter plane. At any rate, it wasn't helpful, but I did find it.) As for that line that goes to the sound chip... That's the LSB of the data bus, which actually matches the function of the pin. So, my theory, now that I know what it's actually jumpered to is that this guy blew some traces off the board with his soldering technique. So, presumably you'll need to restore this wire, and tying to that point on the board is actually a perfectly fine thing to do. I'm guessing whoever replaced this chip lifted a trace and replaced it with a jumper wire. If they lifted one trace, they may have mucked up others. Pin 12, BTW, is VSS. This should just be pulled to ground. Can you try restoring the pin 17 patch and giving a nice clean ground to pin 12?

What in the...? That would short the LSB of the CPU data bus to one of the read-data lines on the VRAM bus. The TMS9928A is an NMOS device, which means that its outputs consist (conceptually) of a resistor to +5v and a transistor to ground. (Really, the "resistor" is another transistor wired up to be a dummy load, but work with me here.) Tying these two pins together theoretically shouldn't hurt the chip, since they're both just taking turns switching to ground, but it would definitely cause some weird behavior. That the title screen comes up with the bridge, but not without it makes me wonder if the internal pullup resistor is bad on one of the two lines. If you have, say, a 10K resistor laying around (+/- a couple K), do you mind trying this experiment? Disconnect the bridge wire. Take the resistor and connect one end to +5v, and then connect the other alternately to either pin 17 or to pin 27 (or 28--which ever was the other end of the bridge). My hunch is that when connected to one of the two, it'll make the display correct, and for the other it'll do nothing. Even then, though, it seems like an iffy proposition. Most of the time, pins 27 and 28 should just be in a "high-Z" state, being pulled up by the normal float-high tendency of NMOS and TTL. Those two pins are on the read-data bus for the VRAMs, and only would get pulled low during an actual memory read. In fact, the only time it needs to go low is when a 0's getting read from the RAM. In contrast, the CD7 pin should be getting pulled high and low by the CPU and ROMs and so on, in addition to the VDP. Even if pin 17's pullup was bad, there should be enough other float-high tendency on that bus that if the VDP's pullup was missing you should still be able to read a '1' reliably on that pin. So, that brings me to a different question: Which pin was it that had the crummy solder job, such that it looked like it was "floating in the hole"?

Awesome! I've spot checked it and it looks pretty good! I'll see about scanning those appendices this weekend. I also have this Data Manual here. If I scan that, do you mind OCRing it?

It's not too bad really. I remember not having too much trouble with it back in my teenage years. If you can read C code, then perhaps some model C code (well, pseudo-C code) might be helpful. Here's some off the top of my head. I'll probably get *something* wrong, so watch for falling bits. (In case the forum eats it or munges the formatting, I've put a copy here.) typedef unsigned short u16; typedef unsigned char u8; volatile u8 *VDP0 = (volatile u16*) /* put addr of VDP's MODE=0 loc here */; volatile u8 *VDP1 = (volatile u16*) /* put addr of VDP's MODE=1 loc here */; /* Read the VDP status register */ u8 vdp_read_status(void) { return *VDP1; } /* Write to a VDP write-only control register */ void vdp_write_register(u8 value, u8 reg) { *VDP1 = value; /* Write value first */ *VDP1 = (reg & 7) | 0x80; /* Write reg # second, w/ MSB set. */ } /* Read a single byte of VRAM via the VDP */ u8 vdp_read_byte(u16 vdp_addr) { *VDP1 = vdp_addr & 0xFF; /* Send lower 8 bits of VRAM address */ *VDP1 = (vdp_addr >> 8 ) & 0x3F; /* Send upper 6 bits of VRAM address */ return *VDP0; /* Read the data byte */ } /* Read a block of bytes from VRAM via the VDP */ void vdp_read_block(u16 vdp_addr, u8 *dst, int len) { *VDP1 = vdp_addr & 0xFF; /* Send lower 8 bits of VRAM address */ *VDP1 = (vdp_addr >> 8 ) & 0x3F; /* Send upper 6 bits of VRAM address */ while (len-- > 0) *dst++ = *VDP0; /* Copy out the next data byte. */ } /* Write a single byte of VRAM via the VDP */ void vdp_write_byte(u16 vdp_addr, u8 data) { /* Send lower 8 first, followed by upper 6. Must also force upper 2 */ /* bits of second write to be "01" to indicate "write". */ *VDP1 = vdp_addr & 0xFF; *VDP1 = (vdp_addr >> 8 ) & 0x3F | 0x40; *VDP0 = data; /* Send the data */ } /* Read a block of bytes from VRAM via the VDP */ void vdp_write_block(u16 vdp_addr, u8 *src, int len) { /* Send lower 8 first, followed by upper 6. Must also force upper 2 */ /* bits of second write to be "01" to indicate "write". */ *VDP1 = vdp_addr & 0xFF; *VDP1 = (vdp_addr >> 8 ) & 0x3F | 0x40; while (len-- > 0) *VDP0 = *src++; /* Copy out the next data byte. */ } Now, this does handwave a couple minor details: Interrupts: If an interrupt can occur near where this code runs, you'll want to disable interrupts temporarily while performing one of these operations. Also, you probably only want to read the status register from within your interrupt handler. (Presumably the CV has vertical retrace interrupts triggered by the VDP, does it not?) Timing: If you try to access the VDP during active display, you might need to put some NOPs in various places to keep from accessing it too quickly. I don't know enough about the CV's Z80 speed to comment intelligently. I suppose it wouldn't hurt to also scan the TMS9118/TMS9128/TMS9129 Data Book I have, since it goes into much greater detail about these low-level issues. I guess I'll scan that this weekend. Any CV coders see major issues with my C pseudo-code above?

I would have described the operations as: Set an address for reading Set an address for writing (control register or VRAM) Write data to previously-set address (or byte after last one written) Read from previously-set address (or byte after last one read) Read status Reading or writing the address following the last address read/written will take about 1/2 to 1/3 the time of reading or writing an arbitrary address, so it makes sense to recognize the 'address set' operations as distinct. Fair enough. I was just breaking it down into the same four operations as the VDP Programmer's Guide does. Setting a R/W address is pretty expensive relative to the actual access unless you're moving a a linear block and can rely on the auto-increment mode. I don't know how much CPU addressable RAM the CV has, but it would seem to me this argues for shadowing data structures that tend to get accessed sparsely when updated and which see lots of read-modify-write type behavior on individual fields of a structure. (I'm thinking sprite coordinates, for example.) Doing a block copy of an updated structure, even if some of the fields haven't changed, can be faster than doing "smart" accesses, updating only the individual bytes that need it. I do something similar with the STIC registers on the Intellivision. There, it's much more necessary, since they're only accessible during the vertical retrace interval anyway.

If you do, would you mind terribly sending me a copy for my own archives? Also, if there's interest in scanning the code examples and the sample font, please let me know. I might get around to it this weekend if there's interest.

While they aren't a model of clarity, these three pages of section 4--1, 2, 3--do at least provide a high level description of what to do. The main thing to keep in mind is you're accessing the VDP's 16K of RAM via a very tiny memory window. You have four different things you can do, and there's a careful dance of reads and writes to the two locations in that memory window to make it work. The four operations of interest are: Write a control register Read a control register Write to VRAM Read from VRAM The three pages I linked give the steps involved in each. Some day it might be fun for me to learn Z-80 and write a Coleco game. It would be fun to come back home to the VDP and really put it through its paces. I don't own a CV though, and I've got a lot invested in my Intellivision home brew pipeline at the moment. :-) (I say "come back home to the VDP" because I first learned assembly language on a TI-99/4A, and programmed the VDP in TMS9900 assembly directly. Fun days. Didn't do a whole lot with it as I only had 768 bytes of memory to hold my programs in. Can't fit much of a game in that.)

I have scanned the first 70 pages of Texas Instruments' SPPU004: Video Display Processors Programmer's Guide. This is everything up through Appendix D. Omitted are Appendix E and Appendix F. Appendix E is about 26 pages of example programs written in 4 different assembly languages (6502, 8088, TMS7000, TMS9995). Appendix F is a sample font. Find the scans here. I've also put a zip file here. I scanned this at 300dpi, so it isn't tiny. I did do some cleanup work too, so it should be fairly clean and easy to read. Enjoy. (Mods: If there's a better place to put this, please feel free to move my post. I'm rather a n00b on this site. :-)

Since he worked at APh, I think I know the answer, but I'll ask anyway: Does he have any of the original documentation for the system? I've been programming Intellivision for awhile, and I think it's safe to say we know all there is to know about programming the STIC, for instance, but it wouldn't hurt to be sure. I have yet to see any of the original programmer's guide material for the STIC or the rest of the unit beyond what data sheets have to offer. Does he have any of this sort of documentation? I'd love to have photocopies or a scan. If you could ask, I'd greatly appreciate it. Thanks.

This is awesome, thank you for this. I only hope there's something I can offer you in the future to help you out. If you would be inclined someday, I'd sure be glad to get my hands on scans of your VDP documentation. I'm sure at least a few others would be pleased to have them as well. Well, I went ahead and scanned most of one book and put the scans here. The book I scanned was the Video Display Processors Programmer's Guide (SPPU004). I scanned up through Appendix D, and I scanned all the text pages at 300DPI as line art. At Appendix E, they start giving listings for demo programs for various instruction sets, and so I stopped scanning there. In this whole scanning process, I thought scans 43 and 44 were interesting, because they describe a variant of Graphics II mode that wasn't in the original 9918A docs. Scan number 47 references the AVDP (Advanced Video Display Processor), which was never released by TI. Instead, TI licensed the architecture, leading to the VDPs in the Sega Master System and beyond.

This is awesome, thank you for this. I only hope there's something I can offer you in the future to help you out. If you would be inclined someday, I'd sure be glad to get my hands on scans of your VDP documentation. I'm sure at least a few others would be pleased to have them as well. I'd post them straight away if my scanner were faster. :-) I have two interesting books: The TMS9118 / TMS9128 / TMS9129 Data Manual, and the Video Display Processors Programmer's Guide. Each is a bit over 100 pages, which would take a few hours to scan each with my scanner. Doable, but slow. I wouldn't mind getting these out on the 'net though eventually. BTW, you did read that right. The data book is for the TMS9118 etc., not TMS9918. The two are related. The TMS9118 has a modified DRAM interface (so it's not a drop in replacement), but it can, as a result, use 2 4416 DRAMs instead of 1 4116 DRAM. The data book also goes into detail about the memory timings, so if someone does do a custom board, this might be an interesting set of chips to find for compactness sake. I don't think they will make a noticeable difference. IIRC, the DRAMs were socketed in my TI-99/4A. I know the VDP itself was. I do know from one of the members of the VDP design team that the VDP did really push the DRAM timing specs, so if you do have a flaky DRAM, I imagine the VDP will notice it sooner than anything else. (I was hired into Texas Instruments by a guy who was on the TMS9918A VDP design team. He's the guy that added the bitmap mode to the TMS9918A. It cost 50 transistors, in case you're curious. :-) ) He also mentioned that since it was pushing the process technology of the time (the 10.73MHz was pushing it a tad), it was sensitive to its power supply level. I imagine this explains the recurring "Clean your power switch!" suggestions for CV owners. Honestly, I have no idea. 4116s are a mystery to me. I remember when I was first starting to learn digital logic 20 years ago, and I saw the +12v and -5v going to those chips and a mention in a hobby magazine that "DRAMs are hard to interface to," and I kinda swore them off then and there. (For a jr. high kid with no budget, I think it was the right move at the time.)

Hmm.... You mentioned some bad soldering on the chip. If the same letters are constantly corrupt, then this could be due to the poor soldering. (Or, if you're really unlucky, someone burned out a pin on the device. That seems less likely.) According to my TMS9118/9128/9129 book (SPPS002, June 1984), the pinout for the TMS9928 is as follows. (The 91xx family was a software compatible family, and the book includes some 99xx documentation for comparison.) Hopefully, armed with these details you might be able to focus in on the likely bad pins / bad chips. I assume that armed with knowledge of the boot-time config you can work out what the pattern table and name table addresses are, etc? Oh, and one word of caution: This is the TI documentation, and bit 0 is the MOST significant bit rather than LEAST significant bit. So, in the 8 bit number 0x80, bit 0 is 1 and bits 1 through 7 are 0. I've had this book for over 20 years. It's fun dusting them off to put them to good use. Maybe it might be worth scanning both VDP guides I have for the Coleco crowd someday? (In case you're wondering, I did my first VDP programming in TMS9900 assembly language around 22 years ago with a TI Mini Memory Cartridge on a TI-99/4A. It was a great way to keep a 7th grader out of trouble, I guess.)

Hmmm... It sounds like the RF modulator might be the issue, or maybe a capacitor. The Inty 1 has a 200pF cap to ground on the video line. The Inty 2 probably has the same cap. If it's shorting out, then maybe it's the culprit. You can tap the raw video out (roughly line-level but not quite) right as it goes into the RF modulator. If you have a monitor with a "high impedance input" mode (as opposed to the more typical 75 ohm input mode), you can feed the video to it to see what's going on. You can see the pinout of the RF modulator here: http://intelliwiki.kylesblog.com/index.php...ge:Um1285-8.png You can hack the ROM image if you want to play it from an Intellicart or Cuttle Cart 3. There isn't a way to bypass it on the board. The Inty 2 uses a custom EXEC which has an extra 256 words of ROM at $0400 - $04FF that implements the lockout. You can't swap in an Inty 1 EXEC because the Inty 1 EXEC is two chips whereas the Inty 2 EXEC is a single chip, IIRC.