intvnut

I left the Termux Makefiles as-is for now. If you're up for an experiment, I'd like you to try the following experiment: In jzintv/src/buildcfg/: ln -s 00-compiler-termux-clang.mak.txt 00-compiler.mak ln -s 10-opt-for-native.mak.txt 10-opt.mak Then try building with the Linux default Makefiles in jzintv/src: SDL1: make -f Makefile.linux_sdl1 clean ; make -f Makefile.linux_sdl1 SDL2: make -f Makefile.linux_sdl2 clean ; make -f Makefile.linux_sdl2 If those work, then we can retire the Makefile.termux* files.

I've finally uploaded an updated version here. Release notes: Release notes for 2020-07-12. (SVN r2110) Updates since 2020-06-07. See ReleaseNotes_20200607.txt for earlier updates. --------------- New features: --------------- * jzIntv * Debugger improvements: * GNU Readline support! * Available on Windows, Linux, Mac by default. * Readline-enabled builds pump event-loop in background, improving window behavior / interaction w/ the OS. * New commands: * rs now resets the Intellivision. * va now toggles AVI generation. * vm now toggles movie (MVI) generation. * vs now takes a screen shot. * Ctrl-C at console halts the game and drops to debugger when the debugger is enabled, rather than killing jzIntv. * Treat "off-in-the-weeds" and HLT cleanly. * Improved history logging around reset, in-the-weeds, and HLT. * Emulator now starts before the first command, not after. * Debugger requests clean exit from main loop, rather than just exiting the emulator entirely. * Added documentation on the Cheat facility. * You may provide up to 8 cheats (CHEAT0 through CHEAT7). * See doc/jzintv/cheat.txt for more details. ---------- Changes: ---------- * jzIntv * Batch mode: * Defaults to rate-control off. * AVI recording defaults to 1x time scale when in batch mode with rate control disabled. * Improved reset emulation: * --rand-mem now randomizes CPU registers at reset. * CPU registers and flags no longer reset when resetting mid-game. * Documentation: * Documented how to manipulate CPU flags with the 'g' debugger command. * Documented the (already present) 'v' debugger command. ------------------------- Cleanups and bug fixes: ------------------------- * Improvements: * Removed various unused/defunct files from source tree. * Lazier controller pad / ECS keyboard updates. * Allow quoted strings in CFG file macros that take string arguments. * Optimized transposed-keyboard code in ECS keyboard scanner. * Scale audio buffer depth based on SDL's reported buffer size. * Flush and close CSAV, CLOD when returning to ECS BASIC prompt, rather than the next ECS BASIC command. * Cleaner handling of momentary pause when toggling full-screen, as well as the initial pause at emulator startup. * Retire -Dlinux, -DPLAT_MACOS from Makefiles. Set PLAT_LINUX, PLAT_MACOS in config.h. * Add new buildcfg/ directory to clean up how Makefiles are configured: * MacOS X and Linux Makefiles now have sane out-of-the-box defaults that don't tie to a specific compiler version. More to come. * SVN version detection fails cleanly when not in an SVN working directory. Also fully avoids network access. * R-Pi builds now use the main Linux Makefile. * Move OS/X SDLmain.* to plat/SDL_osx_main.*. * Add new POP_UP action that pops the keyboard map stack on key release. * Use POP_UP when releasing WIN/CMD/META to leave Map 3. Avoids edge conditions where we sometimes get stuck in Map 3. * Add Clang pragmas to not complain about unreachable code in generated Bison and Flex output. Allows enabling -Werror for Clang builds. * Slightly more conservative CPU instruction cache invalidation. * Add additional error checking to cart.mac ROMSETUP. * Begin refactoring GFX module so less code is in SDL backends. This is just the tip of the iceberg. * Use -flto=auto w/ GCC to scale to the actual number of cores. * Print messages from JLP savegame emulation for read, write, and erase commands, rather than just read. * Spelling and typo fixes in intro_to_cp1600.txt. * Remove -Dtermux, relying on __TERMUX__ instead. * Prep work to decommission Makefile.termux_* in favor of just using the main Makefile.linux_*; however, it's not removed yet. * Updated the FSF's address in files under src/., and in the various license files. * Convert some source files to DOS text format rather than UNIX. * Fixed bugs: * Intellivoice min tick too high; deadlocks with small audio buffers. * PREVMAP accidentally did NEXTMAP, not PREVMAP. * Restore console output on Windows. * Restore window decorations when toggling fullscreen back to windowed on Windows. * Use C99-friendly forward declarations for palette_t in avi.h. * Missing top-level const on prototypes causes warnings in MSVC. * Crash when using --rand-mem and .ROM files. * Explicitly mute audio when there's no sound (e.g. when stopped at a breakpoint). Fixes looping noise in SDL2 builds. * Pause when auto-toggling to full screen when resuming in debugger. * Explicitly set sRGB colorspace on Mac w/ SDL2 to get correctly managed color on multi-monitor systems. * Add missing periph_reset() call in one of the reset paths. * Update comment in mapping.c to correctly describe what the four default maps are. * Fix examples/kbd_test so it assembles properly.

Yes it is. One version of the source code (the "teaser edition") is up here: http://spacepatrol.info/src/ jzIntv's examples folder has the full edition now. I started developing it before AS1600 even had macro support! I'm not sure if jzIntv even had full MOB support yet. I still used Carl's emulator for some testing, and the Intellicart for other test. I wrote the first code for it approximately 20 years ago, sometime in late 2000 or early 2001, IIRC. The oldest documentation I have was the initial engine brainstorm from Aug 6, 2000. I know I showed the first tech demo at PhillyClassic 2001, and it was already a few months old by then. There's a lot of code in it that's older now than many (most?) of the original 125 were at the time I first wrote it.

Unfortunately, few if any of the chips in most Inty 2s are socketed. And yes, the 2114s are pretty much always soldered in.

BTW, I'm the one making hardware, not @intvsteve. Steve did the incredible GUI that makes it actually usable. 🙂 The last year has been a bit of a rollercoaster for me. I won't go into my personal life, but I will say I'm through most of it, but I'm getting back to all of the stuff that's built up that I'm behind on. I have a large quantity of LTO Flash PCBs sitting unprogrammed in my living room, a large quantity of shells w/ USB notches in them, manuals, boxes, etc. I have all the hardware. I thought I was going to have time over the winter to get the Special Edition out because I'd gotten everything sorted, but, to horribly abuse the quote: I currently have over six weeks of vacation time built up, as a consequence of working long hours and no breaks. The last major "vacations" I had were: Driving up to PRGE, and flying out to see folks at Xmas. I did take the last week off, but spent half of it sleeping. I was that burnt out. I informed my boss that I need to find a 2-3 week block that I can take off because my effectiveness at work is waning and my personal life stinks at the moment. This goes hand-in-hand with some other fairly large personal-life changes I've made over the last few months. (A couple folks here are aware of them, but otherwise, I'd rather keep my personal life personal.) I have kept every email and AtariAge PM I've received inquiring about LTO Flash (around 90 or so) and will contact everyone as soon as I can get things shipping. As far as I'm concerned, you're all on the waiting list and will have a cart ready and waiting for you. I'm working on arrangements to offload some of the production work and sales fulfillment, so we can get these shipping again. I appreciate everyones' patience.

There are two 2114 SRAMs that form the GRAM. Sometimes, they use 9114s, such as the photo below. There's a pair of them, and each provides 4 bits of the graphics output. It looks like from your photo that the left four pixels of each tile is garbaged up. If the ordinary built-in text font looks OK (e.g. the title screen to Auto Racing looks OK), then it's probably the GRAM chip that provides the "upper half" of the graphics data. I think that's the one on the left in the photo, but I'm really not sure. The schematic in the Intellivision II service manual here is a terrible scan. But, if I read that correctly, U6 has data bits 4 through 7 (SD4, SD5, SD6, SD7 in the schematic). According to the board layout in that same scan, that's the one on the left in the photo above. If you have a better scan of the service manual (or a paper copy!), double check that I'm pointing you at the right chip.

I'd be lying if I said I didn't have you in mind when I mentioned: 🙂 I mean it in the nicest way. Only very few people have asked me about ECS 4-controller support in jzIntv, and you're one of them. A couple others have been interested in enabling the 4-controller support in World Cup Soccer, and someone actually got it working on the Ultimate Flashback. As far as we know, WC Soccer is the only original game that supported 4 controllers. Didn't you also once mention to me an idea for an 8-player game concept to me (perhaps at PhillyClassic 2001), where each person puts a finger on one keypad button, with a different keypad row assigned to each person?

As others have noted, IntyBASIC has support for 6-voice music when it detects the ECS. IIRC, IntyBASIC detects the ECS by reading/writing a couple bytes of ECS RAM. I don't think it actually makes use of any of that RAM on its own, though, other than to detect the ECS's presence. Also, IntyBASIC doesn't have native support for the ECS keyboard, unless it's been added since I last paid attention. For most bang-for-the-buck supporting the homebrews, all you need is the second PSG, and maybe the RAM. Controllers would be a nice-to-have, IMHO, but I honestly doubt there's that many folks who actually would make use of that. I'm not saying it's zero, but the number's small. The original Mattel ECS games need the ECS ROM and keyboard support. Thanks to Mattel marketing trying to push the ECS, many (or all?) of the ECS games require trivial keyboard inputs to become playable. For example, you can't leave the Mind Strike title screen without pressing a key on the keyboard. Ridiculous. But for homebrews, the second PSG gives the most bang for the least buck. The RAM is a cheap and easy to add, and needed to satisfy IntyBASIC's auto-detect. And, you can leave both on all the time without confusing any other games, AFAICT. Side note: The real ECS has an interesting interaction with the Ms. Pac-Man homebrew. That homebrew uses GRAM aliases at $7800 - $7FFF, $B800 - $BFFF, and $F800 - $FFFF to update GRAM. The real ECS disables those aliases, to enable page-flipped ROMs in those segments. If you implement that aspect of the ECS, you will break Ms. Pac-Man. If you want to do something safer to enable Ms. Pac-Man, but to prevent games that page-flip ROM in those ranges from corrupting GRAM, just filter out writes to $xFFF that match the pattern $xA5y at the GRAM. (e.g. $FA51 written to location $FFFF should flip a page, but not update the GRAM at $39FF via the write-only alias at $FFFF.)

The EXEC's sound routines can really only play one sound effect at a time. That's the most likely reason why.

There was, for a few versions, the ability to save/reload the emulator state. It was broken, so I've disabled it again. The feature was an outside contribution. At some point, I need to rewrite it and get it working again.

I did a search for "Flight of the Valkyries vs. Ride of the Valkyries" or something to that effect in order to satisfy my curiosity. That's where that link came from. "Ride" seems to be the overwhelming favorite, in any case. Or, is it possible there's multiple Reversi versions out there? The CRC32 on the copy I have is C7BB1B0E. I'll have to try the script later. Can't really try it while on the clock. @decle : Can you post the CRC32s for your copy of Reversi, and the resulting reversib.bin? jzIntv helpfully comes with a crc32 tool. 🙂

Apparently the original German name given by Wagner (Walkürenritt) can be translated as either Ride of the Valkyries or Flight of the Valkyries. For whatever reason, I tend to remember the "Flight" variation, but "Ride" is more common. They're on horses in the air, so it's kinda both.

For whatever reason, there's two copies of the tune—one in Checkers starting at $9D2C, and one in Backgammon starting at $AF44. But it's the same code, word for word.

All three standalone versions. Only Triple Challenge is different. To hear it, you either need to beat the computer, or complete the game in two-player mode. I've tried patching the game to jump directly to the code, but the song doesn't play correctly and it crashes partway through. I think I need to get through more of the initialization before the three-part harmony will play correctly.

There are three versions of Checkers outside of Triple Challenge. From what I recall, the original version has a min-max stack overflow bug, and the higher-pitched sound effects. It also has a longer "RAZZ." The revised versions, IIRC, have the short RAZZ, and lower "think" sounds, and the fix for the min-max stack overflow. The third version is the same as the second, but with the title string in lower case. If I'm not mistaken, this is the min-max stack overflow check/fix that was added. (At least, I assume Checkers uses min-max, since that was the state of the art and should be very effective. In any case, it uses a recursive descent that scores potential moves.) Before: L_548F: MVO R0, G_01D6 ; 548F 0240 01D6 CMPI #$000C, R0 ; 5491 0378 000C BGE L_54C3 ; 5493 020D 002E MOVR R0, R1 ; 5495 0081 ADDI #$033D, R1 ; 5496 02F9 033D SUBR R2, R2 ; 5498 0112 RRC R2, 1 ; 5499 0072 SARC R0, 1 ; 549A 0078 BNC L_549E ; 549B 0209 0001 After: L_548F: MVO R0, G_01D6 ; 548F 0240 01D6 CMPI #$000C, R0 ; 5491 0378 000C BGE L_54CC ; 5493 020D 0037 MOVR R0, R1 ; 5495 0081 << starting here ADDI #$0331, R1 ; 5496 02F9 0331 [email protected] R1, R2 ; 5498 028A CMPI #$01CF, R2 ; 5499 037A 01CF BGT L_54CC ; 549B 020E 002F << ending here SDBD ; 549D 0001 ADDI #$000D, R1 ; 549E 02F9 000D 0000 SUBR R2, R2 ; 54A1 0112 RRC R2, 1 ; 54A2 0072 SARC R0, 1 ; 54A3 0078 BNC L_54A7 ; 54A4 0209 0001

You might recognize a few of them as suggested by you. I have a couple more goodies are bubbling. And I need to make a minor fix to make to 'rs'. It currently doesn't do a good job of resetting after "CPU off in the weeds," and that's actually a rather important use case for the feature! In fact, jzIntv's debugger generally doesn't handle that state well.

Also, I believe the UDB for Reversi was modified to point its title string at location $9E1B, as the ROM contains: DECLE 86, "Reversi", 0 B INTV_TITLE_SCREEN at that location. Backgammon has a similar modification. Its UDB pointer is $A014 (meaning that the UDB starts at $A000), and its title string pointer points to $9E0D, where you find: DECLE 86, "Backgammon", 0 B INTV_TITLE_SCREEN In both cases, INTV_TITLE_SCREEN is $9E38. So, actually, the inserted title screen /menu code starts at more like $9E0D. Quickly scanning through the Checkers disassembly, comparing against the "newest" version (the 1979 copyright version with lowercase text), it appears the only modifications are: Relocate to $9xxx Set the "run titlescreen code" and ECS copyright bypass bits Change the copyright year to 86 Insert a J INTV_TITLE_SCREEN at $9026 Rewrite the music at the end Inserting the jump shifts the whole ROM down by 3 words. At $5D24 (original) / $9D27 (Triple Challenge), the real differences kick in. It looks like they took out Flight of the Valkyries with three part harmony, and replaced it with a couple bars of the 1812 Overture and a single "cannon" blast.

Yes. .START: PSHR R5 ; 9E88 0275 SDBD ; 9E89 0001 MVII #$B000, R1 ; 9E8A 02B9 0000 00B0 [email protected] R1, R1 ; 9E8D 0289 COMR R1 ; 9E8E 0019 RLC R1, 1 ; 9E8F 0051 CLRR R1 ; 9E90 01C9 RLC R1, 1 ; 9E91 0051 MVO R1, G_0160 ; 9E92 0241 0160 ;... MVI G_0160, R0 ; 9EE3 0280 0160 TSTR R0 ; 9EE5 0080 BEQ L_9EFA ; 9EE6 0204 0012 MVII #$0007, R3 ; 9EE8 02BB 0007 MVII #$027A, R4 ; 9EEA 02BC 027A JSR R5, X_PRINT_R5 ; 9EEC 0004 0118 007B STRING "4. Reversi" ; 9EEF DECLE $0000 ; 9EF9 0000 L_9EFA: There's a corresponding bit of code in the keypad dispatch to change the bounds check as well. From what I recall, it's very full, especially the later version that includes the overflow bugfix. (One decle free at the end.) A lot of space is taken up near the end for Flight of the Valkyries, so perhaps that was optimized down somewhat to make room. A cursory inspection suggests the music was encoded differently, but I spent less than 30 seconds looking at it. More likely cost vs. benefit. Reference: https://history.blueskyrangers.com/intvcorp/triplechallenge.html The test and jump allowed for a late-binding decision whether to add the last 4K ROM, I suppose. As it stood, it was already almost too expensive: Not without some additional work. Go For The Gold uses paged ROMs and runs the games at their original addresses. You would need to relocate the ROM from $5xxx to $Bxxx (that is, change JSRs, EXEC dispatches, etc.... anything that has an absolute address) to make it work. It's not impossible, but it's not automatically a walk in the park. Some of the addresses are tricky to find. There's a couple EXEC dispatch structures that store an address in DBD format (lower 8 bits across two words) and use the upper two bits in those words for flags.

I believe pins 14, 12, 10, 8, 6, and 4 are the upper 6 bits of the address bus. Decoding up through A10 would be necessary if the external RAM area is decoded at 2K granularity like the ROM itself. That seems like the most likely explanation. Even the RO-3-9502 description in the CPS (CCF10232011_00012.pdf from PapaIntellivision) lists those pins as NC. However, it also says it latches as 16 bit address for the external memory. Direct quote: "16 bit static address outputs for external memory." The section on "Operation with External Memory" in the CPS doesn't list any decode sizes below 2K. The 240 byte scratchpad RAM was a last-minute addition to the "GIMINI Deluxe 8900" architecture. If you find older sales pitch documents, it's not shown. This earlier data sheet describes the RO-3-9501 (ever hear of that one?) and RO-3-9502, indicating the latter latches all 16 lines, and it shows all 16 lines documented properly. I've seen multiple versions of the data sheet for both the AY-3-8910 and AY-3-8914, including a very early datasheet for AY-3-8910 that actually has the AY-3-8914 address map and 2-bit shift on the envelope volume. I've seen die photos of both, and can see where they removed that 2-bit shifter. At least one of the data-sheets (I think the one I got for the AY-3-8910 from Jameco back in the '80s) listed all three pins as a 3-bit address input that could be mask programmed to whatever address you prefer to map it in a 256-address range. I vaguely remember that data sheet also mentioned that the pins had internal pull-ups/pull-downs to act as "default selected" if left unconnected. The CPS's description of pins 24, 25, and 26 is funny: If you read starting at page 100 here, you'll see those three pins are listed as chip selects. Note, this is the AY-3-8910 preliminary data sheet with the AY-3-8914 address map and two-bit envelope volume shift (see page 101). I suspect GI wanted to change the address map to the more familiar AY-3-8910 production address map, but had to preserve the original for Mattel. Hence the AY-3-8914 was born. The follow-ons (AY-3-8914A, AY-3-8916, AY-3-8917) apparently came from Mattel. Mattel requested the I/O direction control be removed from the PSG so it was always input, and a change so that the counters counted up and compared, rather than counting down and reloading at 0. This is the source of the most commonly noticed sound effects bugs on the Intellivision II, BTW. It's weird, but sometimes the earlier data sheets are more accurate than what came later. Ah, so it does respond to $360 - $3FF? That's good to know. I won't ever put anything there unless it's write-only.

The Chess ROM inside Triple Challenge is identical to the original Chess, with two alterations: The cartridge header (UDB in EXEC parlance) was replaced with one that launches the Triple Challenge menu. The menu then switches the EXEC to point to the (now-relocated) UDB before reinitializing the EXEC to start Chess. The title string "CHESS" in the original ROM is rewritten as "Chess". Other than that, there are no other differences between the 8K of ROM in the front part of Triple Challenge and the original Chess ROM image. It's decle-for-decle identical. Are there any Chess cartridges that say "Chess" at the title screen instead of "CHESS"? Other details: The menu was crammed at the end of Checkers, it appears. This suggests Checkers may have been tweaked slightly to share code with one of the other games. ROM layout, roughly: $5000 - $5015: UDB that points to menu. $5016 - $6FFF: Chess, identical to the original. $9000 - $9E25: Checkers $9E26 - $9F45: Menu $9F46 - $9FFF: Empty $A000 - $AFFF: Backgammon $B000 - $BFFF: Reversi That's right... if you install a properly prepared Reversi ROM at $B000 - $BFFF, a menu item will appear for Reversi, and it will let you play it. Note I didn't dig into Checkers or Backgammon, nor do I intend to.

I don't know all the wild and wooly ways of IntyBASIC, but my first guess would be: if n=0 then DEFINE 0,6,myshipexp_3x2(0) + (6*4*(3 - (mytimer/16))) elseif n=2 then DEFINE 0,6,myshipexp_3x2(1) + (6*4*(3 - (mytimer/16))) elseif n=4 then DEFINE 0,6,myshipexp_3x2(2) + (6*4*(3 - (mytimer/16))) elseif n=6 then DEFINE 0,6,myshipexp_3x2(3) + (6*4*(3 - (mytimer/16))) end if '... myshipexp_3x2: DATA varptr myshipexp_3x2_00_bitmaps(0) DATA varptr myshipexp_3x2_02_bitmaps(0) DATA varptr myshipexp_3x2_04_bitmaps(0) DATA varptr myshipexp_3x2_06_bitmaps(0) Seems like you only need one level of VARPTR. I'm assuming, of course VARPTR array(x) is equivalent to x + VARPTR array(0). If the code above is correct, you can shrink it further: if (n AND 2)=0 then DEFINE 0,6,myshipexp_3x2(n/2) + (6*4*(3 - (mytimer/16))) end if

Yes indeed. SDL1 only supports a single window. SDL2 supports multiple windows, and that's definitely something I am interested in myself.

I haven't uploaded the sources for that version yet. I'd hoped to get to this sooner than I have, since there were some other changes I wanted to make. I have a new release brewing w/ other fixes and enhancements that hopefully I'll get out later today. A preview: Bugfixes: Scale number of audio buffers based on buffer size if smaller than expected. Fixed: PREVMAP accidentally did NEXTMAP, not PREVMAP. Fixed: Intellivoice min tick too high; deadlocks with small audio buffers. Fixed: Restore console output on Windows. Fixed: Restore window decorations when toggling fullscreen back to windowed on Windows. Fixed: Use C99-friendly forward decl for palette_t in avi.h. Fixed: Missing top-level const on prototypes causes warnings w/ MSVC. Fixed: Crash when using --rand-mem and .ROM files. Improvements: Flush and close CSAV, CLOD when returning to prompt, rather than after next command. Lazier controller pad / ECS keyboard updates (performance). No longer require -D_GNU_SOURCE on SDL2 builds. Retire -Dlinux from Makefiles; use PLAT_LINUX, set by config.h Improved "momentary pause" behavior when toggling full-screen / windowed, especially automatic toggles from debugger. Document the (already present) 'v' command to show source code in vicinity of an address. Move OS/X specific SDLmain.* files to plat/SDL1_osx_main.*. Features: New debugger commands: rs now resets the Intellivision. va now toggles AVI generation. vm now toggles movie (MVI) generation. vs now takes a screen shot. Ctrl-C at console halts the game and drops to debugger (if debugger's enabled) rather than killing jzIntv. Batch mode: Defaults to rate-control off. AVI defaults to 1⨉ scaling in batch mode when rate-control off. Better reset emulation: --rand-mem now randomizes CPU registers at reset. CPU registers and flags no longer zeroed when resetting mid-game. I haven't tried building on Windows in a few days, and I still have changes pending to merge for Termux. But, if you want to see the work-in-progress above, I've snapshot the source here: http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200621-src-pre.zip

ADAR does two things: Whatever memory is currently addressed should put its data on the bus, like DTB. Every address latch should latch this value as the new address, like BAR. What I've observed with RA-3-9600 is that it does the BAR part, but not the DTB part. I know I can read and write System RAM with direct-mode instructions. For example, MVI $200, R0 works, when executing from a game ROM. But, if I put a MVI $200, R0 instruction in System RAM and try to execute it from there, that doesn't work. It behaves more like MVI $FFFF, R0, although I'm not even 100% sure of that. What I expect, given that: If you assert BAR with an address outside $0200 - $035F, followed by ADAR with an address within $0200 - $035F, followed by DTB, you read the corresponding contents of System RAM. This would match what we see from the CPU. If you assert BAR with an address within $0200 - $035F, followed by ADAR, the System RAM will not drive any data out. An alternate possibility is that it copies SD to DB, which honestly seems unlikely. So, what I'm more interested in is bullet #2.

I've updated the waveform spreadsheet with the "minimum ø2 cycles" detail on BUSAK*.