intvnut

I'm glad you got decent output! That's the biggest prize of all, IMHO. :-) I'm glad I could be of help, however indirectly.

I'm not sure how helpful this is, but here's how TI told people to do it back in the day: http://spatula-city.org/~im14u2c/vdp-99xx/e3/SPPA004A_9928-29_9118-28_Interface_to_Monitors.pdf Includes schematics. It even mentions the correct scaling to apply to the R-Y and B-Y signals, and that the components in the circuit were selected to ensure that various colors (including yellow) are fully saturated. Enjoy!

Oops, I didn't see you'd replied when I posted. I haven't given it a particular version number. It reports itself as 1.0. I don't anticipate many changes between this and 1.0. Then again, I didn't anticipate many changes between Beta 3 and 1.0. And in case you missed the link, here it is. Edit: And right after I post that I notice a minor bug in jzIntv's usage info. It says the -d and --debugger flags take an argument. I've fixed that, but it's not fixed in the binary I linked above. I just mention it so that you know you don't need to report it.

Anticipating a "yes", I've put it here: jzIntv for MacOS X, built Sep 13, 2009 from the latest and greatest source. I actually built this on my old OS X 10.4 machine (an old B&W G3 box), rather than my wife's shiny MacBook Pro. For one thing, she doesn't have Xcode on there, and for another, I'm not sure if 10.5.8 will still build binaries that run on G4s, and I wasn't gonna find out the hard way. Apple's been pushing toward Intel only for awhile, and with Snow Leopard, not so subtly pushing toward 64-bit only.

I have some MASSIVE egg to wipe off my face. I just looked at the source archive I have on my webserver for the 1.0 beta 3. Apparently I had fixed this bug after Beta 3 went out, because when I look in the mapping file, what do I see? /* ------------------------------------------------------------------------ */ /* Action buttons. */ /* ------------------------------------------------------------------------ */ { "RSHIFT", { "PD0L_A_T", "PD0L_A_T", "KEYB_SHIFT", "NA" }}, { "RALT", { "PD0L_A_L", "PD0L_A_L", "NA", "NA" }}, { "RCTRL", { "PD0L_A_R", "PD0L_A_R", "KEYB_CTRL", "NA" }}, { "LSHIFT", { "PD0R_A_T", "PD0R_A_T", "KEYB_SHIFT", "NA" }}, { "LALT", { "PD0R_A_L", "PD0R_A_L", "NA", "NA" }}, { "LCTRL", { "PD0R_A_R", "PD0R_A_R", "KEYB_CTRL", "NA" }}, *facepalms* I'll go make a new build with these fixes (and all the other new goodies). Wanna try it?

ok, I'm going to more thoroughly answer your post now. :-) I should kick myself for just quickly scanning. Oy. Yes indeed, all I get is: $ /Applications/jzintv-1.0-beta/bin/jzintv Could not find any of these candidate files: game.rom Search path: . /Applications/jzintv-1.0-beta/bin/../rom ERROR: Failed to initialize game Well, that should be fixed now. Can I talk you into trying the latest and greatest build? I'd be embarrassed (but not entirely surprised) if the issue you're seeing is fixed. I'll go grab my wife's MacBook and make a build. Very interesting -- I'd imagine those things could be exceedingly helpful! I'm a neophyte programmer but an experienced musician, and have written some music for the 2600's TIA. I may try my hand at some INTV sound programming, which will no doubt lead me to spend more time in debug world. Out of curiosity -- and forgive me if I overlooked something that should be clear -- is there a command in the debugger that translates to "Run this game normally until I call the debugger again via Command-C (or the equivalent)"? I tried "run until JSR/run for x cycles", but I'm guessing they're not intended for quite that purpose. You should be able to do "r" with no argument to "run forever." I do it all the time. It will stop only at the next breakpoint, or when you hit F4 (the break key). Why F4? Because that's what the TI-99/4A used. (The TI-99/4A was my first computer of my own, and so FCTN-4 holds a special place in my nostalgia banks.) Hey, that's very cool! It confirms that my LShift, LCtrl, and LAlt buttons are doing what they should be, but interestingly, my right-hand shift button is being recognized as LShift. I did some investigating, and it appears that both shift keys on the PowerBook G4 are equivalent to LShift. (There is no right-hand Option or Control key.) And that was an important part of your comment that I missed when I posted my hasty reply a moment ago. My apologies. It's not too surprising that the laptop doesn't distinguish the two sides. If we can't get to the bottom of why F6 doesn't work (ie. is MacOS grabbing it from me?) then we may have to solve this with a kbdhackfile in the short run. I may have to add an additional Mac-specific binding too. That sounds really weird. The current code in jzIntv is very clear: /* ------------------------------------------------------------------------ */ /* Action buttons. */ /* ------------------------------------------------------------------------ */ { "RSHIFT", { "PD0L_A_T", "PD0L_A_T", "KEYB_SHIFT", "NA" }}, { "RALT", { "PD0L_A_L", "PD0L_A_L", "NA", "NA" }}, { "RCTRL", { "PD0L_A_R", "PD0L_A_R", "KEYB_CTRL", "NA" }}, { "LSHIFT", { "PD0R_A_T", "PD0L_A_T", "KEYB_SHIFT", "NA" }}, { "LALT", { "PD0R_A_L", "PD0L_A_L", "NA", "NA" }}, { "LCTRL", { "PD0R_A_R", "PD0L_A_R", "KEYB_CTRL", "NA" }}, The PD0R_xxx are right controller and PD0L_xxx are left controller. The first column is the Map 0 binding (right modifier keys go to left controller, left modifier keys go to right controller), and the second column is the Map 1 binding (both left and right modifier keys go to left controller). Oh, and I had goofed something in my previous post. The corrected text in jzintv.txt says: Left Shift Right controller top action buttons Left Alt Right controller lower left action button Left Control Right controller lower right action button Right Shift Left controller top action buttons Right Alt Left controller lower left action button Right Control Left controller lower right action button I had somehow swizzled the left/right association for the right controller. I forgot that Alt/Ctrl are swapped between the left and right sides of my keyboard. Certainly! And my apologies for not getting back to you sooner on this. I was traveling on a (much needed) vacation the week you posted that, and I never remembered to come back here and reply.

Well... not 80 hour weeks any longer, but still a rather draining schedule. And yes, that's an error in jzintv.txt. I'll fix it now. It now reads: Also, don't be fooled by the IMI or MTE-201 test cart. It displays the left controller on the right, and the right controller on the left. My own hand-controller demo (attached) doesn't suffer this fault. On my machine, F6 does seem to push everything to the left controller--a single player mode, as the documentation suggests. That is, when I hit F6, after that point, both left and right modifier keys control the left controller. When I push F5 it goes back to the default map. Have you tried running the "event_diag.rom" to see what keyboard events are getting sent for your modifier keys? I've attached a copy. One should also have come with jzIntv. Edit: I should've read your lined-through text more completely. :-) The output from event_diag.rom will be useful for figuring out what rows of jzIntv's event mapping table it's hitting, and perhaps allow you to hack around it with a "kbdhackfile". The Hand Demo should help you figure out which hand controller events the game sees. handdemo.zip event_diag.zip

Cool...never knew about that game. I don't have an Intellivision but I'll look into this more, especially if there was an actual keyboard peripheral made. Here's a picture of someone's system that I found with some quick googling. I also have the "synthesizer keyboard." I should try playing it some time. I'm not much of a pianist. (As in, I can maybe play Chop Sticks, and can stumble through a little of Heart and Soul.)

How about the Intellivision's Melody Blaster? The Intellivision had a 4-octave piano keyboard attachment, and Melody Blaster was an attempt to put a game around it. It wasn't head-to-head like the game you mentioned, but it sounds somewhat similar in concept.

I haven't gotten a hold of Karl, but I can't see why he wouldn't want me to release all this stuff. As for releasing details of other TI products (as someone had asked), sorry... I am only 34, having joined TI fresh out of college in the mid 90s. While I do get to talk to some of the folks that were around at TI during my formative years, that doesn't mean I regularly get access to the related documentation. Enjoy.

And here's part 3: http://retrobits.libsyn.com/index.php?post_id=517736

I like those carts you have about 0:40 in... They look strangely familiar. :-)

Well, jzIntv's output for --help is rather verbose. What I currently have it do is output the following if given no flags: jzIntv v1.0 Copyright 2007, Joseph Zbiciak Portions copyright 2007: Tim Lindner, John Tanner, Rick Reynolds Pedro Giffuni, Joe Fisher, Frank Palazzolo This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Run "jzintv --help" for usage information. Legal note: Intellivision(TM) is a trademark of Intellivision Productions. Joe Zbiciak and jzIntv are not affiliated with Intellivision Productions. So, while it doesn't give the --help info directly, it does tell you how to get it. Were you getting a different message? It means that the Intellivision's CPU is executing nonsense code. A real Intellivision would just flash colors after awhile and maybe make the occasional weird noises in this situation. In jzIntv, I detect it and exit out. For games that otherwise should work (ie. all of the classic games and debugged homebrew games), this usually means that the config file is missing or incorrect or the binary is otherwise corrupted. The .ROM format files have internal checksums, so such errors are rare with that format. Sometimes it means you have incompatible peripherals enabled. For example, Pac-Man and a couple other games are incompatible with the ECS. All of them worked just fine, though the debugger was a little tricky to figure out. Is the correct flag for that -d, rather than -d1? I wasn't able to get -d1 to work. You would be correct. At one time, -d did allow an argument, and the nonsense -d0 did what you might expect: it disabled the debugger (which is its default state anyway). I guess I cleaned that up at some point. :-) That reminds me, I've beefed up the debugger in the development version. I'm going to have to publish something on this at some point. My 80+hr weeks at work are dying down, thankfully. As a teaser, this is what the online help from the development version of jzIntv: > ? jzIntv Debugger Commands Running the game: r<#> 'R'un <#> cycles. <#> defaults to "infinity" s<#> 'S'tep <#> cycles showing disassembly as it runs. <#> defaults to 1 cycle. -1 means "forever." t<#> 'T'race-over a JSR. Similar to "step" except it attempts to step over functions called by JSR. [enter] [enter] with no command is the same as "s1" or "t1", depending on whether "s" or "t" was used most recently f<#> 'F'ast forward to <#>. When running in fast-forward mode, the debugger skips all breakpoints and will only stop at the target address or when the user pushes the BREAK key. <#> defaults to the current program counter z Toggle showing timestamps during 'step' x Toggle showing CPU reads and writes during 'step' b<#> Set a 'B'reakpoint at <#>. <#> defaults to the current PC. n<#> u'N'set a breakpoint at <#>. <#> defaults to the current PC >> Note: Pressing the BREAK key while running or stepping will drop jzIntv >> back to the debugger prompt. BREAK is usually bound to F4. Viewing / changing state: u<#1> <#2> 'U'nassemble <#2> instructions starting at <#1>. <#2> defaults to 10. <#1> defaults to the current PC after 'r'un or 's'tep, or to the next address after 'u'nassemble. m<#1> <#2> Show <#2> 'm'emory locations starting at <#1>. <#2> defaults to 40 (hex). <#1> defaults to the first undisplayed location after the last 'm' command. g<#1> <#2> Write the value <#2> to re'G'ister <#1>. e<#1> <#2> 'E'nter the value <#2> to memory location <#1>. p<#1> <#2> 'P'oke the value <#2> to memory location <#1>. 'P'oke can always write to GRAM and STIC registers whereas 'E'nter has the same restrictions as the CPU. w<#1> <#2> Toggle write 'w'atching on range from <#1> through <#2>, inclusive. If <#2> is omitted, it toggles the watch flag for a single location @<#1> <#2> Toggle read watching on range from <#1> through <#2>, inclusive. If <#2> is omitted, it toggles the watch flag for a single location Statistics / History tracking: d Dump CPU and memory state to a series of files. Requires history or attribute logging to be enabled. h Toggle history logging. Use "d" to dump to "dump.hst" and "dump.cpu" a Toggle memory attribute logging. Use "d" to dump to "dump.atr" Miscellaneous commands: l<path> Load symbol table from <path>. Format must be same as that output by as1600's -s flag /<string> Look for symbols containing <string>. If <string> is also a valid hex number, look for symbols at that address. To only look for symbols at an address use /$<addr> q Quit jzIntv ? Print this usage information >> Most commands that take an address can also take a symbol defined by a >> symbol table file. These are output by as1600's -s flag. You can load a >> symbol table into jzIntv with the --sym-file=<path> command line flag or >> with the 'L'oad command shown above I know I went back and added a bunch of Mac-specific bindings at one point, including bindings on the Cmd key. If you had tried an earlier version before I had added these, you may have run into that. You know what, I wrote a program just for this purpose. If you look in jzintv-1.0-beta3/rom directory, there should be an "event_diag.rom" program. When you press keys on your keyboard, jzIntv will print out the name of the event it received. The program is actually an Intellivision program that uses a special hook in jzIntv to get raw events. :-) This way you know you're running in the exact environment a game would see. Here's what it looks like in action: You can then see precisely what event names are getting sent to jzIntv on your laptop. I wrote this specifically for working with oddball keyboards that take unexpected short cuts, as well as unusual input devices such as Saitek's gaming keyboards, and new platforms such as the GP2X and Pandora. The D and U before each event name mean "down" and "up," to distinguish key-down vs. key-up events. Once you know the names of the various input events, you can write a "keyboard hack file". I call it a hack file, because I literally hacked the facility in there. Someday I want something more elegant. Anyway, the documentation in jzintv-1.0-beta3/doc/jzintv/kbdhackfile.txt should explain how to configure your keyboard however you like. The --kbdhackfile command line flag lets you pick which file to load, so you can customize your keyboard however you like for each game. Enjoy!

Thank you for the excellent summary! BTW, additional flags you may want to use: -z1 will bump the resolution up to 640x480. This will make the "full screen" mode more useful for most people. -s1 will enable ECS support for games that use the ECS. Some home-brew games (such as Space Patrol) will use it for extra sound channels. -x1 will tell it to start in full-screen mode --help will list all the other flags jzIntv supports. An occasionally fun flag is --macho=N where N is a number greater than 1. (Decimals supported.) What this does is speed up emulation by a factor of N. Try Astrosmash on --macho=5 for a laugh. And as for that bus error you got... oops, my bad! It should have given a proper error message, not a bus error. I hope I've fixed that in my development version. (Yes, I still use it, find bugs and fix them as I go.) I don't remember what I bound the Apple key to. It looks like I have it set to push into keymap 3 while pushed, and back to keymap 0 when released. In keymap 3, most keys are unbound, but a few have bindings. Could you try these? Apple-R Reset emulator Apple-W Toggle windowed / full-screen Apple-S Take a screen shot Apple-M Record a movie (use imvtogif to convert to animated GIF) Apple-C Break out to debugger (only if debugger enabled with -d1 on command line) Apple-P Pause/unpause the emulator Apple-Q Quit Thanks! --Joe

I stand behind those words. If I were better at analog I'd make my composite mod more bullet proof. Part of me still wants to take a stab at a VGA scan doubler. Dunno if I'll ever get to it. Work has had me tied up non-stop the last month or two and I'm over a month behind I think. Gah.

In my case, when I had to replace a coin cell in a Zelda cartridge, I just wired in a battery socket so I'd never have to deal with soldering again on that cart. Since the socket didn't line up with the holes in the PCB, I used hookup wire, and then just used a couple cotton balls above/below the socket to pressure fit it into the large air-gap area in the NES cart so it wouldn't rattle around. Very effective, if a shade hackish.

I think I failed reading comprehension one day. Or, I clicked back to the wrong tab to see who I was quoting (more likely). I'll fix. (Durrh... I looked at the "level" not the "name", that's what it was. It's called "Multitasking at work == FAIL.")

I guess it depends on the output impedance of the TMS9928A's video mixing circuitry as compared to the AY-3-8915's external resistor ladder.

I'll add a note about the 2000uF cap to the Wiki page. I think I've seen a similar streaking problem on one machine. As for the color shifting blue, that's weird. That implies something is weird with the color phase information. The thing is that it ought to be that way for the whole screen, unless there's something about the voltage levels during vertical sync that cause the signal to be overmodulated in some way just after vertical retrace. I'll have to cogitate on this a little bit. Increasing the 22 ohm resistor will decrease the overall gain. Having a pot there is actually not a bad idea. When Tim and I iterated on this circuit, I was actually surprised how high the gain needed to be end-to-end, and it could be that it's a little on the hot side. If the problem is a short-term "DC" bias problem, then maybe the right answer is to add some clamping diode(s) in. I'll do some research.

I'd be happy to improve the design, seeing as I was the primary designer. I know it's far from perfect. What sorts of alteration have your installs needed?

So? The 8088 has an 8-bit bus, but everyone still thinks of it as a 16-bit CPU. The CP1610 will happily execute from 16-bit wide ROM and make use of 16-bit wide immediates and 16-bit displacements on branch instructions and read/write 16-bit data in 16-bit wide RAM. The 10-bit opcodes are a clever hack though to save cost on mass produced ROMs. Space Patrol actually uses a 16-bit wide ROM and makes use of the handful of extra cycles it gives you by not having to read 16-bit data from two consecutive ROM locations. (I needed every cycle I could get.) Arnauld Chevallier's games also use 16-bit wide ROM. There's no advantage to restricting ourselves to 10 bits anyway. The Atari 2600, though, is thoroughly 8 bit, as is the NES. The faster instruction rate of the 6502 / 6507 for register-register ops makes up for the narrower ALU width much of the time. The dearth of registers (ie. relying heavily on the zero page in lieu of actual registers) brings the instruction rate back down though for complex code. *shrug*

I've received quite the treasure trove from Karl. I just emailed him to confirm that I can post all this. If so, then I'll post the link to everything. I'm pretty certain I can share this immediately: SPPA004A 9928-29 Interface to Monitors It even includes the formulas for mixing Y, R-Y and B-Y to get RGB.

Actually, Karl invented that mode. He gave me a photocopy of his proposal to add it to the TMS9918A. I'll have to ask him if I can scan that and post it. (I'll also have to find where I put it. I think it's in a folder at work.) As for the data manual--I will get to it someday (that book lives sitting on my scanner), but it is a huge time sink and I haven't had that block of time yet. Also, I can't get the scanner to work on my computer, so I have to use my wife's. That's another hiccup. I just spoke w/ Karl on the phone. He said he has a bunch of VDP stuff that he's going to email me. This should be fun. :-)

Actually, Karl invented that mode. He gave me a photocopy of his proposal to add it to the TMS9918A. I'll have to ask him if I can scan that and post it. (I'll also have to find where I put it. I think it's in a folder at work.) As for the data manual--I will get to it someday (that book lives sitting on my scanner), but it is a huge time sink and I haven't had that block of time yet. Also, I can't get the scanner to work on my computer, so I have to use my wife's. That's another hiccup.

More fun facts on the TMS9918A VDP. I spoke tonight with one of the VDP designers, Karl Guttag. (He and I are friends. He's also the one that hired me at Texas Instruments, where I currently work. Go figure.) He mentioned that chroma magnitude and phase angles and levels for the luma were actually a bit of a hack, but the basic circuitry is all documented in a patent. If you look up patent 4,243,984 and look at figures 9 through 11, you can see just how the VDP does its magic. 4,262,302 seems to cover the composite signal generator more specifically.