intvnut

Actually, you're right, and I'm wrong. I had remembered what Frank told me, but I did not remember the correction Frank sent me when we were sharing notes with Decle while he was getting the KC tape up and running. From Frank in June 2018: And "biphase mark coding" is another name for Differential Manchester. It actually makes sense. True Manchester doesn't tolerate a signal inversion. As for "line" / "frame"... I don't think I've used the terms entirely consistently. I'd love to get whatever terms Mattel / APh were using and stick to those.

It would have been some other year. 2004 was in San Jose. I thought that wasn't quite true. IIRC, it's Manchester encoded, so you get a half-cycle of 1.5kHz if there's no bit-change, and full cycle of 3kHz if there is. (Differential Manchester has the property you described.) Or am I mis-remembering? There is a digital track recorded next to the prerecorded audio track that contains an odd, semi-repeating pattern. Frank and I hypothesize it's a time-code of sorts, used to keep animations in sync with pre-recorded audio. It does not fit the same encoding scheme as the 37 x 15 data chunks. I never quite isolated that part of the 6502 EXEC, but Frank might have. For everyone else's benefit: Digital data is encoded in chunks of 15 words holding 37 bits, with a small leader before each chunk. The header is four 32-bit words containing a cute V pattern in the bitmap: 00000000 00000000 00000000 01111110 00000000 00000000 00000000 10111101 00000000 00000000 00000000 11011011 00000000 00000000 00000000 11100111 Within the chunk itself, as @Lathe26 states, each 37 bit line consists of 5 framing bits and 32 payload bits. The 5 bits are framing bits have a fixed value (11101). The remaining 32 bits form one bit-plane of 15-bit data. That is, one word corresponds to "bit 14" for the 32 words, the next for "bit 13", etc. (I believe they're sent MSB first.) The 15-bit words contain 5 bits of SECDED code (not classic Hamming, but isomorphic to it), and 10 bits of data payload. The bit-plane encoding spreads dropout errors across multiple ECC words. (Side note: The SECDED code was apparently designed by Dean Inada. (I forget who told us that.) It uses three sets of rotated 5-bit values, each with 3 ones and 2 zeros, to represent the syndromes for each of the 15 bits. It's actually slightly better than SECDED, because the error-correct code will try to fix 2-bit errors by taking positions where we saw Manchester violations/carrier loss into account and trying again.) Here is an excerpt from some tape data Frank and I analyzed (mostly Frank): 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000001111110 00000000000000000000000010111101 00000000000000000000000011011011 00000000000000000000000011100111 ['1110100000000010000000000000000000000'] ['1110110000000100000000000000000000000'] ['1110110100000100000000000000000000001'] ['1110100000000110000000000000000000000'] ['1110110000000110000000000000000000001'] ['1110100000000000000000000000000000001'] ['1110100000000000000000000000000000000'] ['1110100000000100000000000000000000000'] ['1110100000000000000000000000000000000'] ['1110100000000100000000000000000000001'] ['1110100000000100000000000000000000000'] ['1110100100000110000000000000000000000'] ['1110100100000110000000000000000000001'] ['1110100100000100000000000000000000001'] ['1110110000000010000000000000000000000'] ['1110111110111111011111100100100111010'] ['1110101101110101110101011011000000101'] ['1110111101001110101010101101100111011'] ['1110101111110100111001010011000010100'] ['1110110111111001010000110111110011101'] ['1110100000000001001110001001001100010'] ['1110101100000110000000010010010000100'] ['1110100001010000111110001000001100000'] ['1110101000100100000100010011000000100'] ['1110101001100100001110011010000100100'] ['1110101101000110001110011010010100100'] ['1110100011000010001010001001010100000'] ['1110110111111010011000111110100001100'] ['1110100001100000001001000001001010000'] ['1110100010000000000110000000001110011'] ['1110111110111111011111100100100111010'] ['1110101101110101110101011011000000101'] ['1110111101001110101010101101100111011'] ['1110101111110100111001010011000010100'] ['1110110111111001010000110111110011101'] ['1110100000000001001110001001001100010'] ['1110101100000110000000010010010000100'] ['1110100001010000111110001000001100000'] ['1110101000100100000100010011000000100'] ['1110101001100100001110011010000100100'] ['1110101101000110001110011010010100100'] ['1110100011000010001010001001010100000'] ['1110110111111010011000111110100001100'] ['1110100001100000001001000001001010000'] ['1110100010000000000110000000001110011'] Data that's predominately 8 bits will have two 37-bit frames (or lines, as @Lathe26 calls them) that are all zeros except for the 5-bit sync. @Lathe26 hinted at this, but didn't draw the connection between bits 8/9 being zero and two whole frames/lines being zero. ASCII data will have three such lines, like this: ['1110101010101001000010010100100001000'] ['1110101000100000101011100110000100010'] ['1110110000100100010010010111000010001'] ['1110111000011101101011010110100101001'] ['1110101110110000000001010100101111010'] ['1110100000000000000000000000000000000'] ['1110100000000000000000000000000000000'] ['1110100000000000000000000000000000000'] ['1110111110111101111011110111001110011'] ['1110100000000000000000000000100001000'] ['1110110010000100010011010001000100011'] ['1110101100010000000000010010001000000'] ['1110100000011001010010100111000010010'] ['1110111000110100000011100010000110001'] ['1110111100000100101000010110001010011'] And, in fact, the block above contains ASCII: SKIP\0 BNDS\0 DATA\0 VRFY\0 EOT\0 IRG\0 US (The \0 are literal zero bytes, ASCII NUL.) There's also a different kind of block that appears during pre-recorded audio tracks: Timing code blocks. The timing-code data retains the 37-bit framing, but doesn't seem to encode the data the same. Instead, it has a repeating 8-record pattern that almost forms a sort of Gray code. Here are some notes I took many years ago, while Frank and I were actively picking apart one of his dumps: Timing blocks are repeating 8-record patterns involving the following 8 bit patterns: a. 11111011 b. 01111011 c. 10110101 d. 10110100 e. 01001010 f. 01001000 g. 00000100 Interestingly, each bit pattern has one more 0 in it than the previous pattern. The 32-bit word divides up into several fields: sync g e c a ? f d b ['11101, 000, 010, 000, 111, 101, 0, 1000000, 000, 111, 001'] ['11101, 000, 000, 110, 001, 111, 0, 0000000, 100, 001, 111'] ['11101, 000, 000, 001, 110, 111, 0, 1000000, 001, 100, 111'] ['11101, 000, 001, 000, 111, 110, 0, 1000000, 000, 111, 100'] ['11101, 000, 000, 111, 000, 111, 0, 1000000, 110, 000, 111'] ['11101, 000, 100, 000, 111, 011, 0, 1000000, 000, 110, 011'] ['11101, 000, 000, 100, 011, 111, 0, 1000000, 000, 011, 110'] ['11101, 000, 000, 011, 100, 111, 0, 1000000, 011, 000, 111'] In each column, the corresponding bit pattern appears, rotated through three different rotations: 0, +3, +6. The pattern starts out with 16 37 word records of all zeros (except the sync word). Then, bit pattern trio 'a' shows up. 16 records later, pattern 'b' gets added. 16 records after that, pattern 'c' gets added, and so on. Once pattern 'g' is added, there's no further changes. New patterns arriving correspond to the '0' in the column marked with a '?'. Rotations of the bit patterns, given in hex: a. 11111011 FB F7 EF DF BF 7F FE FD b. 01111011 7D F6 ED DB B7 6F DE BD c. 10110101 D5 6B D6 AD 5B B6 6D DA d. 10110100 B4 69 D2 A5 4B 96 2D 5A e. 01001010 4A 94 29 52 A4 49 92 25 f. 01001000 48 90 21 42 84 09 12 24 g. 00000100 04 08 10 20 40 80 01 02 Are the codes rotations of each other with just another bit removed? a. 11111011 b. 01111011 c. 01101011 d. 01101001 e. 00101001 f. 00001001 g. 00000001 I know Frank spent a lot more time on this after where my notes leave off, and he did share more of his progress with me. I haven't had the time to dig through and internalize it all yet.

Games that are timed based on the vertical retrace input run slower, unless they adjust for the different interrupt rate: 50 ticks/second vs. 60 ticks/second. Games that are timed based on how fast the CPU runs will run faster, unless they add more delay loops on PAL. Most games derive their sense of time from the vertical retrace interrupt. That's essentially all EXEC based games, but also most non-EXEC based games. Space Patrol slows down on PAL for this reason, for example. Kroz didn't base its execution speed on retrace interrupts. At least not entirely. I added some very carefully calibrated delay loops to slow PAL gameplay down to match NTSC. It was too fast otherwise, and that caused problems on some levels. If you're careful to detect PAL and adjust your game's sense of time accordingly—either through adjusting for the different interrupt rate, or calibrating delays differently—they can run the same speed on both.

Having a read through it now. Lots of good stuff in here. One thing I didn't see highlighted in the text (or if it was, I missed it): Keith's handwritten description of the downloaders/debuggers currently in use has the only contemporaneous confirmation of the code name Black Whale we've seen, as far as I know, and it was crammed in there as an edit: I chuckled at jzIntv showing up in the debugger comparison. FWIW, jzIntv doesn't have "run at address" as a separate command, but you can do "g7 addr" followed by "r" to get the same effect. Think of it as RISC vs. CISC. From your doc, it sounds like PX1600 Crosspatch allowed source-level debugging. That's probably worth a row in the debugger comparison table. Something that's probably worth adding to the "Y adaptor" section: There was an external power supply that goes with that to boost power to the unit when using the Y adaptor. I don't know that all Y adaptors had one, but the one I had the opportunity to document did: In case you're wondering about the Prio Mail box... I was using that as a "camera stand" for my phone in some of the shots. There's a relevant blurb about Imagic's development environment on Intellivision Rocks! that I discovered the other day, while researching Keith's photo of the "momentum" lucite block. (This hobby takes us strange directions sometimes, eh?) The "graphics editor" and "software that controlled the development hardware" caught my eye. Sounds like they did have some custom equipment of their own. (Not surprising, really.) And a side note: The EXEC routine names decle uses in his document are names I picked for the EXEC routines when I wrote dis1600. These are not the same as the names that appear in Your Friend The EXEC. I am happy to provide the official EXEC names to replace my made-up names in a future revision.

I converted it to C, as statically linked C++ binaries are ginormous, and put the new version here: http://spatula-city.org/~im14u2c/intv/dl/fsk2.zip BTW, one thing I noticed in my quick testing: In jzIntv, you do need to run one additional "immediate" command in ECS BASIC to get it to close a CSAV'd file. I have a fix for that, and it'll be in the next jzIntv release.

Not quite an Inverted Jenny...

I did some digging around, and it appears there's a Python evdev library that provides a UInput interface similar to what you're already unit for injecting events: https://python-evdev.readthedocs.io/en/latest/tutorial.html#injecting-input It looks like gpiozero can uses a variety of back-ends. I guess for now I won't worry about implementing raw support. A perhaps more interesting approach anyway would be to open a pipe to an external "event provider," although I don't think that works on Windows. That's what I was hoping to enable, even if it doesn't make sense for the "UFB" type builds. For example, a dedicated Intellivision-only build. Also, if Hafner can update his adaptor to provide raw controller bits (if it doesn't already), I can provide higher-fidelity input options that would allow, for example, triggering easter eggs with arbitrary controller patterns. I don't have support for GPIO input events, per se. But, if you can map GPIO events to keys, then you can bind those keys directly to controller pad bits. There are 8 input bits for each controller: PD0L_BIT_[0-7], PD0R_BIT_[0-7], PD1L_BIT_[0-7], and PD1R_BIT_[0-7]. That's enough to get you raw controller pad support. I have an example kbdhackfile that maps the upper buttons of a suitably-updated Retronic USB adaptor directly to the raw controller pad bits here (also under doc/jzintv/ in the downloads): http://spatula-city.org/~im14u2c/intv/jzintv/doc/jzintv/retronic-usb-raw.kbd It looks like, for example, the current Python uinput module supports F13 - F22 input keys, and I'm pretty sure nothing uses them. So, you could have your GPIO script output F13 - F20 events based on whether those bits read 1 or 0. "Press" the button for 1, and "Release" the button for 0. You might want a periodic refresh (e.g. send a redundant "press" or "release") if there's any chance an event could get dropped between your script and jzIntv. jzIntv's own internal tracking won't care if it gets redundant presses or releases. For raw GPIO connections, you'll need a pull-up on the 8 data pins, and to tie the 9th pin to ground. It looks like gpiozero supports configuring pins as pull-up. If I need a more flexible scheme for controlling the controller input raw bits, I can add it. (e.g. "BIT_x_SET" and "BIT_x_CLR" that ignore press/release might be useful in some scenarios.) Note: This doesn't get you raw ECS alphanumeric keyboard and music synth input. jzIntv needs to be able to drive values out to do that, and to switch ports between input and output.

Perhaps I could build a direct interface to GPIO so we can retire your Python scripts, at least for jzIntv? Do your GPIO scripts perform any translation / mapping, or do they mostly just detect GPIO changes and reinsert them as events picked up by SDL1? That is, what degree of matching and translation do you do? Do you know offhand how Python accesses the GPIO? Is it through pigpio, WiringPi, or something else? When I looked before, it looked like most documentation focused on using some high level libraries or Python. I have no problem directly mangling the GPIO myself, or consuming GPIO from a commonly-loaded daemon (as pigpio does), or opening a pipe to a Python script (so it can just print the events to me), or whatever. Biggest challenge: I'm not really set up to test this. Would you be willing to test what I build? I can easily add a bunch of general purpose GPIO events to the event table, and provide platform-specific modules where it makes sense. I also have corresponding "raw" actions now, so in theory you really could directly wire Intellivision controller bits to GPIOs. If the wiring is more complicated, that could get challenging. I don't think I used Xinerama when I was using multiple monitors on Linux. I believe I used RandR. Right now, I'm sadly in a zero-monitor state on Linux, but I hope to change that within the next month. At the moment, I'm only considering features that would directly connect to the core of jzIntv, such as debugger windows. I want to clean up the separation of core and GUI so that it's easier to write a front end and embed jzIntv within it, or move jzIntv to other graphics/sound/event backends. Organizing a library of manuals, overlays, box images, and so on seems like a task that belongs outside the core emulator. It would be both interesting and useful to the folks playing the games, and I want to enable that. I'm not the right person to write that, for the same reasons I wasn't the right person to write the LTO Flash GUI. 🙂

Unless I'm dreaming, Intellivision Productions actually did that one year at CGExpo, as I recall. I think that may have been the same CGExpo that they raffled off a Keyboard Component in its original box (or what was left of the box) for charity. ISTR that they didn't show the demo too many times as the cassette drive was being finnicky. IIRC you could hit space-bar to trigger some of the transitions.

I remember there was a hardware bug with the board design used for that release. The RAM didn't work properly on Intellivision I systems, but worked on Intellivision II, due to differences in bus skew on BC1, BC2, and BDIR. (The Intellivision 1 has some discrete logic to remap the INTAK bus cycle to BAR, consisting of some XOR gates fed by some NAND/NOR to flip BC1/BC2. On the Intellivision II this got absorbed into the Mattel LAD custom chip.) That causes BC1, BC2 to be unstable for about 3 74LS TTL gate delays (around 30-35ns, IIRC). I did provide a little help to 5-11under while he debugged his RAM logic design—I just pointed out where the glitches would come from, what was likely failing, and what to look for. He did all the work. The fix involved time-delaying some signals to create a glitch filter. Were there any software bugs as well?

It was a highly informed guess, thanks to all your reverse engineering efforts.

Fun fact: It appears Intellivision Rocks! was mastered on a Macintosh, on a hard disk (or the machine itself) named The Strand II. The Strand II:Desktop Folder:ROCKS CD STAGING:Intellivision Rocks I suppose that makes sense, given that Strand Cruisers was the parent of Making It. (Something I learned while digging for that quote.) And, FWIW, a hard disk (or machine) named The Strand was used for Intellivision Lives! along with some Iomega disks (Zip Disks or Jazz Drives, I imagine). So much interesting stuff hidden in metadata. 🙂 The Strand:Intellivision:Emulation:Mac Emulator:Volume2PPC1.0 Iomega Tools:Multimedia:Intellivision Movie

I found the quote!!! And yes, this is that block! It's on Intellivision Rocks! I ran 'strings' on all of the various multimedia files (because of course I did), and found this. And the answer of "who said it" is... I'll redact the name below so you can enjoy the text without revealing the spoiler. Hopefully it wasn't ruined for you already by an email notification. So now we know: These paperweights were souvenirs of a May 1983 party, and part of clapping futilely for tinkerbell!

SDL2 makes better use of modern video cards. On the Mac, for example, I was getting some dreadful frame rates with SDL1. I'm talking 10-15FPS when running in a window. jzIntv seemed to get slower with each new OS release, even though under the hood it was as fast as ever. It was doing 60Hz around 20 years ago on much slower hardware. I also saw some performance issues on Windows, although to a lesser degree. I haven't tried with anything newer than Windows 7, though. SDL2 uses modern APIs, and pulls 60Hz effortlessly on modern machines. It's buttery smooth and responsive on my laptop now. SDL2 also supports some other nice features, such as multiple monitors and multiple windows. I may make use of those at some point. But for now, I'll take the nice 60Hz display.

I've put a new test build up for Windows only. This just has the updated Windows executables, and is not a full release. It should restore console output, and should resolve the Intellivoice deadlock. It will hopefully resolve any problems with sound "popping" (reported against the SDL2 version) by increasing the buffer depth. Please let me know if it complains about missing DLLs or any other problems. If these builds for SDL1 and SDL2 are clean, I'll create full releases with all the updates. SDL1: http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl1-test.zip SDL2: http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200610-win32-sdl2-test.zip Thanks!

FWIW, you don't really need special software to download to an Intellicart. Anything that can send a binary file over the wire should do the trick. The bigger challenge is finding a serial port. You might need to buy a USB to serial converter. The floppy is only important for collector value. 🙂 And, knowing the crowd here, that means it's very important! 😃

Good point. As for wav2bin, I don't really have that yet. But, should be easy to modify bin2wav to output the right baud rate and FSK frequencies for a mismatched pair. (i.e. 50Hz Inty + 60Hz ECS and vice versa.) IIRC, the 2400Hz and 4800Hz tones were generated directly by ECS_COB_50 (aka. U41), weren't they? That would cause both baud rate and FSK to be wrong by the same ratio. If the tones come from something else, then the baud rate may shift independently of the FSK tones.

From what I recall, even the title screen change was very minimal. The Atari logo graphic is still loaded into GRAM, and the black "mask" that makes the Atari logo shape is still displayed. But the animated colored bars and the ATARI name aren't displayed and the code that updates the animation for the colored bars is disabled. Pressing 1+ Clear at the title screen crashes both versions. There are a few other bytes that are different between the two ROMs that I can't explain. I wonder if I have a clean ROM dump for the Atarisoft version. I have another Atarisoft ROM dump from Steve Orth, and those few bytes are the same between Atarisoft and INTV. That suggests my Atarisoft dump is flawed. CRC32s in case anyone is interested: A21C31C3 pacman_atarisoft_mine.bin 48D522AD pacman_atarisoft_steve.bin 6E4E8EB4 pacman_intv.bin I believe "pacman_atarisoft_steve.bin" is the "clean" cart dump. Punchline: The Atarisoft and INTV versions should play identically, and the only difference is in the titlescreen.

That was my guess too. The "vanishing point" effect and what not just amplify it. It fits well with the early Keyboard Component marketing video, back when Space Battle was still Battlestar Galactica.

Are you sure that wasn't on one of the CDs or maybe a video? I tried finding that anecdote looking at both the Intellivision Lives! Blue Sky section, and the much older Making It Blue Sky section, over at archive.org. I tried a few date ranges, but no luck. You might have better luck than I did.

An update: I've added the missing doc folder to both Windows downloads. However, the Windows SDL2 release is broken: it deadlocks when you enable voice. Also, both SDL2 and SDL1 don't display stdout when launched from CMD. This is unfortunate, as both do display stdout when you launch from an MinGW window. For the deadlock, I've figured out that the problem is SDL2 gives me very tiny audio buffers compared to SDL1 on Windows, and that causes my peripheral scheduler to deadlock when voice is enabled. I don't know the solution yet, but it has highlighted to me yet again that both my peripheral scheduling scheme and my audio buffering scheme have issues. I've actually known that for a while but have been able to mostly ignore it, since it worked well enough. In the short run, I'll probably tweak it so it "works" again, but I need to replace both longer term. I don't have an ETA just yet, but hope to get to it soon.

I've gotten a couple reports of issues with the new release. In particular, it appears I accidentally busted stdout output on SDL2 on Win32, and I forgot to include the doc directory on the Win32 downloads. (The latter part is fixed—the Win32 downloads include the doc directory). If you download and try any of these versions—Win, OS/X, x86-64 Linux, R-Pi—using either SDL1 or SDL2 and see an issue, please contact me. I'll do my best to address, and will release a followup version that hopefully addresses the issues soon.

jzIntv has support for defining up to 64 COMBO events involving 2 key presses, along with a configurable delay. See "Combo Events" in doc/jzintv/kbdhackfile.txt.

Nearly all of the Intellivision titles will work in the 50Hz systems (including SECAM). There were only a few titles that didn't work at all at 50Hz, such as Dreadnaught Factor, and I believe one version of Motocross. A couple other titles have minor glitches, but otherwise play fine. The rest work just fine. I've posted a patch for Dreadnaught Factor elsewhere. If you paste the patch into the CFG file for Dreadnaught Factor and load it onto LTO Flash!, it should apply the patch as part of the loading process. Just copy the code below to the end of Dreadnaught Factor's CFG file, and it'll patch it for PAL. If you have a .ROM rather than .BIN, use jzIntv's rom2bin utility to convert it to BIN+CFG. [memattr] $D000 - $D0FF = ROM 16 [macro] @p 5cb5 734a @p d000 02b8 @p d001 d009 @p d002 0240 @p d003 0100 @p d004 0040 @p d005 0240 @p d006 0101 @p d007 0220 @p d008 72c6 @p d009 02b8 @p d00a 5ca9 @p d00b 0240 @p d00c 0100 @p d00d 0040 @p d00e 0240 @p d00f 0101 @p d010 0220 @p d011 bffd Those should both work on LTO Flash!. Note that WSMLB needs a complete ROM image (24K words / 48K bytes) to function properly. The version that was on Intellivision Lives! is not complete. In the incomplete version, the voice playback will crash and play static/noise.