intvnut

Well, unfortunately, I have little more information than what's in those scans. For the scans I made: Those are actually scans of photocopies of a GI databook, circa 1978. I received these photocopies from Karl Guttag, who was on the TMS9918 VDP design team. He had these as part of his competitive analysis folder at the time. I inherited the photocopies when he cleaned out his office. :-) The PDF file (the one with the color cover) came from Frank Palazzolo. Again, I have no further information than what's in the PDF itself. Feel free to update the FAQ with my scans. That's why I posted them: To be as useful as possible to as many people as possible. :-)

GroovyBee: I changed the license of many of my examples in jzIntv to "public domain" back just to remove one more excuse for people not to use the code. :-) Mainly I've just kept the emulator and whole games as GPL now. Also, I have the right to redistribute the SP-0256-AL2 samples / ROM data, but the copyright remains Microchip's. You want to use my task scheduler or controller reading code? Knock yourself out. Want to use that 700 cycle fixed-point square root or fast Euclidean distance approximation? Be my guest. It appears I need to do a major update to the SDK-1600 site (and release a new jzIntv!), since the copies there still show the GPL on them. The versions in the current jzIntv SVN repository (as linked to above) all have been updated. That said, I'm sure you could learn a few things by reimplementing some of those pieces. Of course, I'm of the opinion that you can learn plenty implementing the pieces that aren't already covered by SDK-1600, such as playing music, getting MOBs on-screen, and so on.

Indeed, I'm always glad to provide technical help. I'm also working on getting a cart design out there so that anyone can publish their games in physical format, as I have in the past w/ my previous titles. I'll keep everyone posted.

Also, the IntelliWiki is quite handy for that crowd.

If you don't mind, could you copy the INTVPROG Yahoo group on your major updates? You can find it here: http://games.groups.yahoo.com/group/intvprog/ I personally don't have a lot of time to follow a lot of blogs, and I think INTVPROG would give you some additional exposure among other folks that are trying to learn Intellivision programming. Also, the IntelliWiki is back up. If you end up writing tutorial-focused material, would it be OK to include copies of it there, or perhaps link back to your blog?

And then there's this low, low $999 price on a well loved, ultra rare Intellivision 2 + ECS system... eBay Auction -- Item Number: 370427871419 (Not mine...)

Its a bit of extra hassle to get one because last time I checked he didn't take paypal. Thanks for the development hints. Yeah, you can thank Nintendo for that one. If it ends up being a real difficulty, let me know in a PM. I may be able to help.

I originally posted this to INTVPROG, but I figured some of you here might find it interesting too if you don't normally hang out there. I meant to do this literally YEARS ago. In fact, I apparently started on this about 4 years ago, actually, almost to the day. Anyway, I had talked Chad into making the CC3's serial port accessible to software on the Intellivision. He opened up a handful of locations that he passes through more or less directly to the 16550-compatible UART on board. I'm pretty sure this feature made it into the final firmware revision, since it works on the two CC3s I've tried it on. I had planned to quickly write up a demo then and get the driver and demo software out there. I got it about 90% completed and then shelved it when life got too hectic. (Specifically, I had to wrap up Space Patrol.) Well, because I want to use the code for something else, I decided to dust off the 90% complete code and make it more like 99% complete. :-) The result is visible in this YouTube video: That's me hunting and pecking on an ECS Keyboard while logged into my Linux box over a serial cable that stretches from the CC3's serial port to my PC's serial port. The terminal emulation is roughly VT-100 + ANSI color support. In the video, I'm using the Linux-based editor "vim" over the serial link. My code doesn't support all the escape sequences, but it supports enough of them to be usable. My serial terminal is able to keep up with 9600 baud ok. With more optimization effort, 19200 ought to be doable. In fact, I had 19200 working OK until I added the keyboard scanning, so it's on the cusp. I just can't be bothered. I need to clean up the code a bit, sure, but rather than wait for me to get around to that, I figure I should publish what I've got. I've put the code here: http://spatula-city.org/%7Eim14u2c/intv/dl/terminal.zip The serial driver code is very, very simple. It sets up 8-N-1, 19200 baud by default. There are two main APIs, "CC3_XMIT" and "CC3_RECV", and currently they're both "blocking" APIs. The Terminal application gets around this by scanning the keyboard in the interrupt routine, calling CC3_XMIT from there, so that CC3_XMITs can happen while CC3_RECV is waiting for data. Not the cleanest way to do it, but it worked. I ought to add non-blocking variants of XMIT and RECV. There are two other functions: CC3_SERINIT for initialization, and CC3_SETBAUD for picking one of several baud rates. The VT-100/ANSI emulation is a hoot. Feel free to poke your head in there if you're feeling crazy. It works, but I've made no attempt to optimize for anything other than the amount of time I was spending writing it. The keyboard scanning code is simple to call. Just call "SCAN_KBD" and it will return KEY.NONE if no new key is pressed, or the ASCII code of the key pressed. For the arrow keys, I've adopted some control-key values. KEY.UP, KEY.DOWN, KEY.LEFT and KEY.RIGHT have the values I chose for these keystrokes. (One shortcoming of the Terminal program is that it doesn't convert the arrows into proper VT-100 arrow sequences. To do that, it'd have to look for these codes and send ESC [ A, ESC [ B, etc...) I've mapped a number of punctuation keys via the CTRL key. Basically, CTRL + a number, or CTRL + an existing punctuation key will give you a new, sometimes related character. For example, curly braces are on CTRL+9 and CTRL+0, to pair up with the parentheses there. Square brackets are on CTRL+comma and CTRL+period to pair up with the angle brackets. Others were a bit more arbitrary. I'll have to sit down and write up the keymap. Enjoy, --Joe

Awesome! Chad does still have CC3s in stock. I suggest building a serial cable for it if your machine has a serial port, since that's faster than updating the MicroSD card every time. It's not terribly difficult. For mine, I bought a standard 9-pin serial extension cable, chopped off the male end, and used an ohmmeter to figure out the pin-to-wire mapping. From there, it's a simple job to solder it to a stereo jack. The schematic is in the documentation. I actually use an emulator (jzIntv, specifically, seeing as I wrote it for the purpose )for most of my development work, and then test on real hardware when things are pretty stable. I find jzIntv's debugger to be pretty helpful for sorting out tough issues.

David, that reminds me... I noticed that you have a lot of service manuals in the Library, but none for the ECS. Do you suppose there's one out there? Also, somewhere in my archives I managed to get a scan of an Intellivision 2 service manual, which doesn't seem to be in the Library. I've put a copy here.

Nothing to do with Internet connections, but everything to do with cell phones. I know if my cell phone is anywhere near certain mice, they go haywire, scrolling and moving about, but only when the GSM decides it's time to resync. Same with certain monitors, causing the image to jump and shift. Even if your phone isn't the issue, it could be a generic problem with interference, or with bad grounding/voltage regulation causing spurious readings from the optocouplers. That's probably what the mod you posted the link to is about--it stabilizes the voltage so you don't get spurious readings from the optical sensors. The way the old optically-encoded mice work (the ones with the rollers and the disc with slots in it) is that the slotted disc moves past a pair of optical sensors. The optical sensors are built out of an LED and a phototransistor. The light from the LED turns the transistor on. The solid parts of the disc block this light and turn the phototransistor off. Each axis has two of these. When the disc rotates one way, the first sensor shuts off, followed by the second as the first starts to turn back on. In terms of 1s and 0s, the motion sequence looks a bit like: "11", "01", "00", "10", "11". Or, at least, something to that effect. You can tell from those two bits that the obstruction is moving from left-to-right in this example. When the disc moves the other direction, the pattern reverses: "11", "10", "00", "01", "11". That's how you can sense bidirectional movement. That's also why, if you move your mouse too fast, the pointer goes in the wrong direction. Anyway, for the phototransistor to work, it needs to be biased appropriately, so that light hitting it turns it on, and light not hitting it turns it off. If there's excessive noise on the line so that it looks like the transistor is flickering on/off without the mouse actually moving, that'd give you spurious "inputs" that would look like the mouse is wandering everywhere. The LM339N is a quad comparitor. I'd imagine it's tasked with comparing the outputs of the phototransistors with a reference voltage. All the suggested hack does is add a high quality tantalum capacitor between power and ground on this comparitor chip. Steadying its supply inputs should help it make steady decisions about the voltages it compares. In other words, this modification makes total sense to me. Just make sure you get the polarity of the tantalum cap right. Failure to do so can lead to some spectacular fireworks.... (Yes, that was something that happened to me senior year of college.)

Oh wow, so someone DID produce a GIC-based system! I actually scanned a bunch of GI TV Games stuff in awhile back, and it included this system. Take a look at all the scans. Also, someone else passed along this scan of the GI Games 1978 catalog. I apologize my scans aren't in PDF form. The second link is.

Learn! . ... and don't say "I can't"! The tools that are available now for the Intellivision make it easier than ever. I'm not going to get to the Intellivision myself for a while, but from what little I've seen of the sdk1600 project, I'm very impressed. *blush* Thanks. :-) That reminds me, I need to update that website. There's lots of new goodies in the version of the SDK that comes with jzIntv. Hell, I need to get the latest jzIntv out there. So much to do.... FWIW, I hang out on the INTVPROG mailing list on Yahoo Groups. I'm always glad to answer programming questions. Arnauld also pops in from time to time too. Activity goes in bursts. Everyone's friendly. There's also a Wiki (IntelliWiki) with tons of programming details, although it seems to be down at the moment. I'm not sure why, and I haven't been able to get ahold of the guy who owns the site. Hopefully we can get that back in action soon. It's another useful resource. I've written a number of tutorials on assembly programming there. As far as BASIC goes, I think it'd be cool if someone did something like bAtari BASIC for the Intellivision. I don't really have the time to pursue such an endeavor, but it could open programming up to a wider audience. If one of you (or even bAtari!) wants to give it a whirl, I'd be happy to provide support.

Well, I can tell you for sure, Rick Dangerous is making progress. If y'all want more Intellivision homebrews, you could, you know, write some. So far, there's really only Arnauld and I writing games regularly for this and we do both have day jobs too. And David, I didn't mean to leave you out. You've been instrumental to releases from both Arnauld and I.

Well, I can tell you for sure, Rick Dangerous is making progress. If y'all want more Intellivision homebrews, you could, you know, write some. So far, there's really only Arnauld and I writing games regularly for this and we do both have day jobs too.

It could be the STIC or the GROM. It's not likely to be the EXEC. Is it always just the right-hand side of the screen?

I was actually there when Keith made that remark after someone else asked about Space Patrol. It was kinda surreal, I must say. :-) I will say this: Game design is hard. I have a lot of skills as a programmer and an engineer, but not so many as a game designer. This is why I value having David on my team so much, since it he's got a much better eye for it than I. Plus, there are some really good games I wanted to see on this system. Some of them are here now. :-) I'm starting to work on some new game concepts myself. I'm hoping that making my cart design accessible to a larger audience will inspire others to bring their game concepts to Intellivision, including even ports of unique homebrews from other systems. Someone else commented that Intellivision is harder to program than Atari. I forcefully disagree. The programming model for the Intellivision is closer to the Colecovision, since you need not write a "kernel" or time all your code tightly to display refresh. The STIC handles display refresh for you much as the VDP does in the CV. You also have a more powerful CPU (16 bits with 6 general purpose 16-bit registers) that, while not popular in its own right, has about as generic and approachable an instruction set as you could hope for. Here's a 100% complete "Hello World!" that doesn't rely on any EXEC functions for anything other than ISR dispatch (which is hardwired and unavoidable): ORG $7000 START: PROC MVII #$2F0, R6 ; Set stack pointer DIS CLRR R4 ; MVII #$360, R1 ; \_ Clear memory, STIC, PSG CALL FILLZERO ; / CALL PRINT ; Print Hello World! DECLE $7 ; white DECLE $200 + 6*20 + 4 STRING "Hello World!", 0 MVII #ISR, R0 ; \ MVO R0, $100 ; |_ Enable display SWAP R0 ; | MVO R0, $101 ; / EIS DECR PC ; Done! ENDP ISR PROC CLRR R0 MVO R0, $20 ; Enable display MVO R0, $28 ; Black background MVO R0, $2C ; Black border MVI $21, R0 ; Color-stack mode JR R5 ENDP FILLZERO PROC CLRR R0 ; Start out with R0 zeroed for FILLZERO FILLMEM [email protected] R0, R4 ; Store R0 out at R4, and move along DECR R1 ; Keep going until our count runs out BNEQ FILLMEM JR R5 ; Return to the caller. ENDP PRINT PROC @@FLS: [email protected] R5, R1 ; Load format word from invoc. record @@LS: [email protected] R5, R4 ; Load ptr to display loc from invoc record @@S B @@1st ; Get first char of string @@tloop: SUBI #32, R0 ; Shift ASCII range to charset SLL R0, 2 ; Move it to position for BTAB word SLL R0, 1 ADDR R1, R0 ; Merge with color info [email protected] R0, R4 ; Write to display @@1st: [email protected] R5, R0 ; Get next character TSTR R0 ; Is it NUL? BNEQ @@tloop ; --> No, keep copying then JR R5 ENDP That said, if bAtari wants to bring something like bAtari BASIC to Intellivision to simplify things further, I'm all ears. :-) We do lack those sorts of toolkits, and I think having them would add to the number of homebrews.

This is Joe Z. I have a cartridge design I'm putting into production. I am actively working on making it available to a wide audience so that anyone can self-publish with ease. I don't have the bandwidth to sell these personally as "Left Turn Only", so I'm researching other options. I'll still publish my own games under that banner. As with so many things in this arena, it's a labor of love. I was hoping to be at this point over a year and a half ago, but the economy tanked, work went absolutely nuts, and I had to shelve things. The economy's back now, and there are a bunch of exciting, material developments the last few months. (Not just talk... I've got beaucoup $$$ out there in active production.) Like David mentioned, we're not in a position to announce dates. But, I've moved forward with hardware production, so the rest is just a matter of time. If I can open up the capability to a wider audience, even better. I'm actively pursuing options there so that I'm not the bottleneck. My new design is flash based and in-circuit programmable, which makes it easier to fan out to a large audience. It also supports unimaginably large games (at least in terms of ROM size), so I doubt hardware should be much of a limitation ever again. If it is, I can make a better design. 16K bytes RAM, 240K bytes ROM though should be enough to hold people for a few years.... :-) BTW, I did actually receive a couple entries to my programming contest. Not as many as I hoped, but a couple. Now that I'm moving to hardware production, I can make good on the prizes I wanted to offer. I had wanted to move to production in 2007 originally, slipped to 2008, and then had to totally can things until 2010 due to the economy (all my savings "disappeared") and an oppressive work situation. I'm back now. :-)

I apologize I've been silent on this thread. Work swamped me. I'm catching back up though. Thanks for looking into this. The 8914 and 8917 looked the same to me, too, which is why I was surprised that I couldn't substitute one for the other. Another member pointed out that some models have different memory maps for the registers, so perhaps this accounts for the incompatibility. I did indeed notice those resistors; in fact, on some Intellivision II consoles, I've seen a similar array of resistors added to the 8914's controller port input pins. My first guess in troubleshooting my Computer Adaptor was to test these resistors with my ohmmeter, and they all checked out (1.5K, I think they are). Perhaps I should describe the problem I'm seeing in more detail. In ECS BASIC or the music player, some keys on the keyboard work normally, some do not work at all, and some are "sticky" (they register about ten keystrokes at a time). Sometimes, a keystroke--usually the ENTER key--will cause the entire system to freeze. When this happens, a slight "hum" is sometimes audible through the speakers, and I'm certain it's coming from the Computer Adaptor because I can turn it down with the Adaptor's volume control (a similar hum appears if I try to use the 8914 in place of the 8917). It also happens with my Music Synthesizer keyboard, and during ECS games which use either input device. The extra sound channels and RAM seem to work normally. At first I thought it was just a bad keyboard, but this keyboard tests fine with my second Computer Adaptor, and another known-good keyboard failed in the same way with this Adaptor. I haven't found any visibly bad components or traces, so my best guess at this point is that the 8917 itself is bad. Unfortunately, I haven't yet found a source for a replacement 8917, or a set of pinouts which might allow me to adapt the board for an 8914. Does anyone happen to know if J.H.C. Electronics (the "official" Intellivision repair service) still works on Computer Adaptors? I might have to give them a call if I can't figure this out on my own. FWIW, I collected up and scanned some ancient data sheets I had that predate the final release of the AY-3-8910. This data sheet says it is for the AY-3-8910, but it seems to offer a more complete pinout, and its register map actually matches the AY-3-8914. I'm guessing that this is probably the most "honest" AY-3-8914 datasheet that I've seen. It even explains what the two envelope select bits in the volume register actually do. (All the other references have only one bit for envelope select, or just say "Put 1 in both these bits.") The scans are here: http://spatula-city.org/~im14u2c/intv/gi_micro_programmable_tv_games/ The PSG stuff starts at page 7-100. The rest of it is interesting as an archaeological find, showing how GI conceived the Intellivision system before Mattel bought into it. I guess you've socketed your AY-3-8917? What sort of behavior do you get when you plug in an AY-3-8914? Can you see what, if anything, is hooked to pins 24, 25, 26 and 39? We may be able to make an AY-3-8914 work if it's just a matter of changing the chip selects. The memory map issues are, in some sense, a red herring. Both the ECS and Master Component PSGs are mapped at xxF0 through xxFF, and the address bits above that are managed by chip selects (pins 24, 25 and 26), not address lines. Within the xxF0 - xxFF range, both ECS and Master Component PSGs have the same register layout. I should know: My sound effect code treats both identically, just with different base addresses. :-)

I just took my ECS apart in an attempt to see what might be different about the pinout, and I must admit I'm stumped. The AY-3-8914 pinout appears to differ from an AY-3-8910 only slightly. Pin 26 is marked as "TEST2" on the AY-3-8910, but is an active-low enable input on the AY-3-8914. Likewise, pins 24 and 25 are enable inputs for the AY-3-8910 and unconnected on the AY-3-8914. I don't know why the AY-3-8917 would need a different pinout than the AY-3-8914. The only thing I can think of is that they needed to do something different with the I/O drivers to support the ECS keyboard or something. (There's a nice array of resistors between the PSG and the controller ports, I'm sure you've noticed.) All the pins I could easily verify (A, B, C analog outputs, the A/B I/O ports, etc.) seem to match what I'd expect from the AY-3-8914 pinout, looking at the AY-3-8917 on my ECS board.

Schematic for that switch It looks like the main transformer provides three lower voltages to the main power supply board, and that switch is switching all three together. Take a look a the link above so you can follow along. The main on/off switch is SW501, and that's the one that's kinda shown in the middle left part of the schematic in the bottom-left part of the page. If you really, really want to simplify things, you could short out the corresponding wires (uh... Light green to dark green; Dark green to the other dark green; and blue to blue??? Who came up with this coloring!?!?) and then just use a switched outlet strip to turn the unit on/off. (Or, break the 120v before the transformer and install a switch on that.) Alternately, you could look for a three-pole-single (or dual)-throw switch out there. It appears that Digikey stocks one that would be appropriate. (That's Digikey part number SW121-ND, just in case that link stops working.) Otherwise, if you really want an official Mattel replacement switch, perhaps I could be talked into parting with one from my Intellivision graveyard. If you're interested in that, give me a holler at intvnut AT gmail dot com. One further edit: You can download the entire Intellivision service manual scan here.

There's apparently at least two different such monitors, the 13" PHA4000 (the Zenith-manufactured one) and the 10" PHA4100 (manufactured by Matushita, aka Panasonic). I actually have the latter. I've also seen references to the PHA4100A. Wonderful monitor, except that the vertical hold went out on it. :-( On my PHA4100, I don't recall the image looking substantially different from my TV, just a little clearer since it skipped the RF modulation.

I was thinking of replacing the AY-3-8915 with alternate circuitry, to provide component, and possibly S-video and composite. According the the datasheet, the "transfer function" of the AY-3-8915 isn't that complicated. Do you have any details or links with AY-3-8915 information (besides the two page datasheet)? The beautiful thing about the Intellivision is that the digital video signals are readily accessible, so digital solutions such as DVI are also conceivable (as opposed to the A2600 and CV, where the digital signals are locked inside fairly complicated video ICs - to get DVI out of an A2600 or CV would require either replacing the complicated video IC or converting the analog signals to digital). Thanks, 5-11under What I meant about the "transfer function" being a bit weird is that there seems to be some non-linear transistor effects that shift the values around from what the data sheet describes. I've tried converting the values in the data sheet into RGB with all manner of YIQ transformations, and failed dramatically. For one, brown actually came out brown, not olive-drab, and blue wasn't as saturated as it is on a real Intellivision. Now, if you just want to make up your own "close enough" color palette, then it's pretty simple to make a decoder for the pixel codes and just do whatever you like for S-video or DVI. My "transfer function" comment mainly applies to getting the exact Intellivision colors. If you are OK with, say, grabbing the palette from one of the emulators out there, then there's nothing more to do. Build a couple D/As for S-video output or three for RGB output. If I ever get time, I still want to do that Intellivision-to-VGA scan doubler. Some day, in my copious free time.

Yes. Or, if you just want to multiplex up to 4 controllers on one port, you could use some 4-to-1 muxes (3 separate 74LS153s). I guess that's why if you want to go for a 4 controller game, it really seems like your best bet is to use one controller port as an output and the other as an input. All digital is nice and speedy. I'm guessing that the reason you have to wait two WSYNCs for the paddle inputs is because you're waiting for an RC circuit to charge, correct?

I'm not an Atari expert, but glancing at the VCS documentation, it appears the port responsible for reading the joysticks has a data direction register. Couldn't you simply set one controller to output and the other to input and matrix scan? This is how the Intellivision ECS keyboard works to allow a 49-key keyboard to hook up to two 8-bit I/O ports. Judging from the RIOT data sheet, you write to the data direction register to configure 4 controller pins as outputs, leaving the remaining 4 as inputs. Then, connect those 4 outputs to a 4-to-16 decoder for your row-select into your keyboard matrix. You could then have a 16x4 = 64 key keyboard scanned this way. Scanning wouldn't be particularly fast, though, with 16 rows + debounce time. Alternately, if you just want to allow for four standard joysticks to multiplex into one game, set one controller port to output, the other to input, and "matrix scan" the four controllers by pulsing one line at a time high from the output side to sense one of the four controllers from the input side. There are cheap ways to do this.