intvnut

First thing I thought: "We've got the momentum! Unfortunately, it's angular momentum." (Or worse, "downward momentum.") That does look like a neat lucite block. I wonder where in the timeline that was produced. If it was 1979, it's optimistic enthusiasm. Fall 1983? Futilely clapping for tinkerbell. Speaking of corporate goals that don't work well if taken literally: At my previous job, management set a goal for our business to grow at twice the rate of our competitors. I asked what I thought was an obvious question: "What they're declining?" I know I sure don't want 2⨉ a negative growth rate... Any more buzzwords like that, and I'll have to make you recite the mission statement!

Release notes: Release notes for 2020-06-07. (SVN r1996) Updates since 2018-12-25. --------------- New features: --------------- * SDL2 support! Thanks to Daniele Moglia for nudging me to get this done. * New SDL2-specific keyboard events. See doc/kbdhackfile.txt. * CHEAT support (thanks to Patrick Nadeau). These allow you to bind keys to trigger "pokes" that change values in memory. This is useful for, say, adding lives, becoming invincible, etc. (TODO: document in doc/jzintv/cheat.txt). * Other kbdhackfile updates: * Added new pause-related actions: * PAUSE_ON always pauses; PAUSE_OFF always unpauses. * PAUSE_HOLD pauses only while the input key is "down." Useful to tie to the HIDE event to auto-pause when minimized. * WINDOW / FULLSC actions: * WINDOW forces windowed mode. Useful with SDL2 FOCUS_LOST event. * FULLSC forces full-screen mode. * SETMAPx, NEXTMAP, PREVMAP as clearer-named aliases for KBDx/KBDN/KBDP * Added an example kbdhackfile with an alternate ECS keyboard map that's more useful on modern computer keyboards. * UTF-8 support in game metadata (ROM and BIN+CFG). * P macro in .CFG files can now poke paged ROM. * Added support for manipulating processor flags to 'g' debugger command. Registers numbers 8 - 13 manipulate the flags S, Z, O, C, I, D according to the LSB of value. * CP-1600X: * Added examples/macro/cp1600x.mac. * Added CP-1600X version of TagAlong Todd 2v. ---------- Changes: ---------- * AS1600 * Do not sign-extend characters >= 0x80 in STRING/DECLE declarations. * Raise macro expansion limits by 10x. * Windows * SDL1: The environment variable SDL_STDIO_REDIRECT controls whether jzIntv redirects stdout/stderr to files. Set it to 0 to send these to "stdout.txt", "stderr.txt". * Makefile.stdout is gone. Use Makefile.w32_sdl1 or Makefile.w32_sdl2 to build jzIntv. * MacOS: * Builds are now 64-bit. * Cmd-F toggles fullscreen/windowed mode. * Cmd-W now closes the program on SDL2. (Enforced by SDL2.) Still toggles windowed mode on SDL1. ------------------------- Cleanups and bug fixes: ------------------------- * ROM / BIN handling> * Better .ROM format detection in the presence of metadata tags. * Improved string-quoting rules when generating CFG files. * Use a common unquoter for CFG file parser and everywhere else. * Example/library code: * cart.mac: Use EQU, not ORG to declare BYTEVAR/BYTEARRAY. * Add missing library/jlp_accel.asm. * Add macro/cp1600x.mac. * jzIntv general: * You can power jzIntv off like an Intellivision II again. * Hack to allow jzIntv SDL1 port to work on OS X Mojave and newer. * Fix INTRQ regression (assert() failure). * Restore JLP accelerator enable state across reset. * Use <stdint.h> types rather than home-grown type aliases. * Lots of type / const / restrict cleanups. * Move color palettes out to their own file, and start to convert the rest of jzIntv to use the central infrastructure. * Remove some moribund ports, such as MacOS Classic. * Refactor event subsystem to have a common core, and an SDL-specific portion. EVENT_xx enumeration no longer depends on SDL keycode values. * Re-arm SIGWINCH signal handler in the right place. * Add missing entries to joystick button and hat event tables for joysticks 4 through 9. * Fixed some ECS key mappings for certain keys when shift is pressed. * More robust paged-ROM loader in bincfg/legacy.c to handle paged RAM, and paged ROM segments that are declared piecemeal. * Begin cleaning up all the global variables and narrowing module interfaces. * Clean up stray debug printfs in bincfg_lexer ("BAD2", "BAD3"). * More MSVC compatibility fixes. * Correctly map between voice/voice_compat in CFG metadata. * Remove unnecessary uses of 'volatile'. * JzIntv debugger: * Pokes to paged-ROMs now work correctly. * Fix cycle skid on reaching a HLT instruction. * jzIntv CPU instruction decode cache invalidation fixes: * Invalidate 2K of address space on Intellicart bankswitch. * Invalidate paged-ROM flips correctly. * Minor bugfix encoding LUIGI files with paged memory that overlaps JLP accelerator memory. ------- Misc: ------- * Updated Emscripten to build with either SDL1 or SDL2. Untested.

The bin2wav program I posted is just source code and a Linux executable. If you need an executable for another platform, either you'll need to compile it, or I could compile it for you. You'll need to type in a program in ECS BASIC within jzIntv and save it to simulated "cassette." If I understood your sentence correctly, we're on the same page here. But just to be sure everyone's clear: The bin2wav converter doesn't parse ECS BASIC program text. Rather, it needs the binary image that ECS BASIC writes to cassette. And the way to get that is to type it in to ECS BASIC in jzIntv and "save" it to "cassette." Other than the sample programs that were in the manual that came with it, and the enhanced programs in Mr. BASIC Meets Bits'n'Bytes, I haven't seen any ECS BASIC programs from Mattel. If you scout through this thread, you'll find some ECS BASIC programs others have posted, including the ones @Zendocon referred to above. Yep, that's my understanding. Some of the cartridge games, such as World Series Major League Baseball and Game Factory can save/load data from cassette.

OK... I finally have a new version of jzIntv up on the website. It took a few weekends' effort, but hopefully the result is worth it. http://spatula-city.org/~im14u2c/intv/ Since the Christmas 2018 release, SVN tells me: 303 files changed, 21191 insertions(+), 14237 deletions(-) About half of that was due to the SDL2 port: 121 files changed, 9264 insertions(+), 7954 deletions(-) I still need to write up some release notes to catalog everything that's gone into jzIntv in the last 18 months. In the meantime, download it and let me know if you run into issues. Linux users (including R-Pi): I haven't had a chance to test what I've built. Also, for Linux x86 users, you'll probably want to build the SDL2 port from source. For folks hacking on the source: Platforms that support both SDL1 and SDL2 have separate Makefiles for SDL1 and SDL2. This may change eventually, but for now it's true. Be sure to run make -f Makefile.foo clean if you switch between SDL1 and SDL2 in the same source tree. I don't have immediate plans to remove the SDL1 support from the code. But, at some point I'll stop releasing official SDL1 builds for platforms that support SDL2. Hopefully, I haven't broken your Wii port too badly. 🙂 You'll need to split Makefile.termux into Makefile.termux_sdl1 and Makefile.termux_sdl2 if you want to retain support for both. Or, if everything works great with SDL2 and you don't care to carry SDL1 forward, just update Makefile.termux. Hopefully it's as simple as: Change sdl-config to sdl2-config. Add -DUSE_SDL2 to the CFLAGS. If the SVN_xxx lines I added to the Makefile give you any issue, just comment them out. The rest of the Makefile will cope.

I believe the FSK encoder (bin2wav) I posted above will work with the ECS cassette save files that jzIntv now produces. So, you should have an easy path from jzIntv to ECS. The other direction, ECS => jzIntv, is trickier. I spent some time awhile back trying to recover some tapes that were in rough shape for a collector, and I was able to get some, but not all of the games to decode. A clean recording of a tape that isn't 30+ years old might go better, though. 🙂

Also, here's the corrected form of the BASIC-callable assembly function, in case folks want to see what it looks like w/out downloading the code. The documentation comment block comes from the cp1600x.mac file, and mentions another instruction, ATAN2FX, that works with IntyBASIC-style fixed point numbers. BTW, one thing to watch out for: ATAN2 and ATAN2FX are defined based on classical Cartesian coordinates, with +y going up, rather than down. This is the opposite of the screen coordinates. Be sure you use the correct sign on the delta-Y value you pass into ATAN2. ASM INCLUDE "cp1600x.mac" '' ------------------------------------------------------------------------ '' '' ATAN2 dst = direction_of(src1, src2) (signed) '' '' ATAN2FX dst = direction_of(src1, src2) (signed fx-pt) '' '' '' '' Returns the direction pointed by the vector <src1,src2>. This is '' '' approximately equivalent to the C library function atan2(); however, '' '' instead of returning a value in the range [0, 2*PI], this returns a '' '' value in the range 0..15, starting counter clockwise the origin as '' '' follows: '' '' '' '' 4 '' '' 5 ^ 3 '' '' |+y '' '' 6 | 2 '' '' \ | / '' '' 7 \ | / 1 '' '' \ | / '' '' \|/ '' '' 8 <------------+-----------> 0 '' '' -x /|\ +x '' '' / | \ '' '' 9 / | \ 15 '' '' / | \ '' '' 10 |-y 14 '' '' 11 V 13 '' '' 12 '' '' '' '' This can be useful for computing the direction something is from the '' '' one's current position. '' '' ------------------------------------------------------------------------ '' ASM X_ATAN2: PROC ASM MVO R1, X0 ASM ATAN2 R0, X0, X0 ASM MVI X0, R0 ASM JR R5 ASM ENDP

I'm catching up on my inbox. Sorry for the delay. Oops, yes it is. It was supposed to be checked in as jzintv/examples/library/jlp_accel.asm as part of jzIntv. It will be a part of the next jzIntv release. Until then, I've attached the file. You will need to add a line like this to your BASIC code somewhere: ASM INCLUDE "cp1600x.mac" Adjust the path if necessary. The cp1600x.mac file is the same file that's part of the TagAlong Todd release above. It adds the new instructions and addressing modes through some creative macros. I've written up a quick demo of using ATAN2 from IntyBASIC and attached it. It just prints the value returned by ATAN2 for points around the perimeter of a 100-unit square in hexadecimal. jlp_accel.asm atan2_intybasic.zip

The BACKGROUND in HIT_BACKGROUND refers to BACKTAB, aka. the grid of 20 × 12 tiles. (BACKTAB stands for background table. It's the name either GI, APh, or Mattel gave it.) It doesn't mean "pixels assigned a background color," but I can see how you might have thought it would. The hardware collision detection looks for on pixels (1 in the bitmap) in the BACKTAB. IntyBASIC just reports the hardware collision info. If you use any colored-squares pixels, colors 0 through 6 count as on, and 7 counts as off.

So, about 21 years and one month ago, I got jzIntv running with SDL 0.10. Yes, SDL wasn't even 1.0 yet when I moved to it from Allegro. revision 1.9 date: 1999-05-03 02:10:01 -0500; author: im14u2c; state: Exp; lines: +26 -24; ------------------------------------------------------------------------------ 05/03/1999 (jzbiciak) release_006 ------------------------------------------------------------------------------ -- Finally got it building and running with SDL. Suffered a minor setback in that I haven't integrated the horiz/vert delay and blanking bit support for the STIC yet, but that's only because I'm slowly redoing the STIC emulation the _right_ way. :-) (BTW, it took me this long only because I've only had about 8-9 hours to spend on that, over half of which were discarded as I toyed around with various ideas on how to structure my code. SDL isn't that difficult to use.) TODO: It appears that the Football demo in the demo-cart runs incorrectly. Must fix this!!! This weekend, I'll at least release the sources for the SDL 2 port. I haven't had time to do anything on Windows or Linux, so for now it's only available on Mac. I might find some time this weekend for that as well. If folks wanna help out, please do. I expect it will be pretty minor actually, once I have SDL2 installed in both places. And, of course, I've made a number of minor fixes to other things along the way. Hopefully I can have a nice official 4th of July release on Linux/Mac/Windows, with both SDL1 and SDL2 builds. I expect to retire the SDL1 builds at some point, though.

For what it's worth, an extra tile is only 4 words of ROM. So, unless you're actually inverting a ton of tiles, it's not terribly expensive. And as carlsson pointed out, depending on the graphics mode you could just swap FG/BG. But that's often harder than it seems. In the level select in Space Patrol, I had to invert some of the bitmaps to make the screen look the same as it does in the main game. (!) That's because one uses FGBG mode and the other uses CSTK. FGBG wouldn't let me select the foreground colors I needed, so I inverted the graphics so the color scheme would work.

I wish there was an SDBD [email protected], but there is no such thing. Very early versions of jzIntv supported it, but no real Intellivision does, sadly. It seems like such an obvious thing to have, but it's not there. This change went in before jzintv-009 was released a few months later, on my birthday. In fact, I committed this change 21 years ago tomorrow. Yikes. In a few more years, I will have been working on this for half my life. Double-yikes. revision 1.12 date: 1999-06-06 19:13:36 -0500; author: im14u2c; state: Exp; lines: +6 -2; -- Apparently, SDBD is not allowed w/ MVO. For now, I've modified the [email protected] instruction to issue a warning whenever this pairing is encountered. It'll act as though the SDBD were not there, though. I've also changed the "Intro.." doc accordingly. -- Added a rudimentary breakpoint command to the debugger. Still more work to do there. ... --- op_exec.c 6 Jun 1999 04:30:26 -0000 1.11 +++ op_exec.c 7 Jun 1999 00:13:36 -0000 1.12 @@ -4,7 +4,7 @@ * * Author: J. Zbiciak * - * $Id: op_exec.c,v 1.11 1999-06-06 04:30:26 im14u2c Exp $ + * $Id: op_exec.c,v 1.12 1999-06-07 00:13:36 im14u2c Exp $ * * ============================================================================ * fn_invalid -- Executed when a decoder failure happens @@ -29,7 +29,7 @@ #include "op_decode.h" #include "op_exec.h" -static const UNUSED char rcs_id[]="$Id: op_exec.c,v 1.11 1999-06-06 04:30:26 im14u2c Exp $"; +static const UNUSED char rcs_id[]="$Id: op_exec.c,v 1.12 1999-06-07 00:13:36 im14u2c Exp $"; int fn_invalid (const instr_t *instr, cp1600_t *cp1600) @@ -457,8 +457,12 @@ if (cp1600->D) { + fprintf(stderr,"WARNING: [email protected] w/ SDBD prefix @ %.4X\n", instr->address); + /* CP1600_WR(cp1600, instr->address+1, (r0 & 0xFF)); CP1600_WR(cp1600, instr->address+2, (r0 >> 8)); + */ + CP1600_WR(cp1600, instr->address+1, r0); } else { CP1600_WR(cp1600, instr->address+1, r0); (Note: diff times are in TZ -0000, as compared to the log message in -0500.)

If you mean just swapping all the 1s for 0s and vice versa, the following assembly snippet would do that from within an interrupt context (assuming R4 already points to the GRAM card): ; Invert GRAM card @R4. Trashes R0, R5 MOVR R4, R5 ; 6 Copy input ptr to output ptr REPEAT 4 SDBD ; 4 \_ Get 2 rows of GRAM [email protected] R4, R0 ; 10 / COMR R0 ; 6 Invert [email protected] R0, R5 ; 9 \ SWAP R0 ; 6 |- Write both rows back out [email protected] R0, R5 ; 9 / ENDR ;---- ; 44 ;* 4 ;---- ; 176 ;+ 6 (from above) ;---- ; 182 cycles If you only have a small number of graphics tiles you need to invert, it may actually be cheaper to store them already inverted in ROM and just load the inverted images. Also, if you're using IntyBASIC for this, that may be the preferred method generally. Does IntyBASIC even offer a facility for reading GRAM? Sure, there's PEEK, but you also have to sync with the vertical retrace. And WAIT : PEEK might not be the worst thing you can do, but I don't think it's a great idea.

Yeah, I've been at this awhile... I believe both have the same size active field—192 scanlines plus an additional scanline at top and bottom borders. Across two fields (one frame), that's 386 scanlines. That's why the PAL units only displayed in the middle 80% of the screen, apparently. The PAL units end up with more time to compute across the board, it turns out. The particular glitch in question happens when the STIC can't get the information from RAM in a timely fashion. The STIC gives the CPU approximately 1 scanline's heads up via ~BUSRQ: "I need to steal some cycles to fetch the next row of BACKTAB." The CPU has to to respond with ~BUSAK before the STIC starts fetching the data. If it doesn't, then the STIC can't actually fetch the data and will replay the previous row of BACKTAB. That causes the screen to jump downward by a row of characters starting at that point. This artifact can only happen 12 times per frame: once for each row of characters. There's an additional related artifact that can happen at the very top of the screen: The STIC also uses a very short ~BUSRQ before the active display to kick the System RAM into "isolation mode." If the CPU doesn't ~BUSAK that in a timely fashion, then the System RAM won't kick into isolation mode, and CPU writes could interfere with the first few scanlines of active display. (Don't do this: it forces a buffer fight between the STIC and the System RAM.) The point is, no matter whether you're on PAL or NTSC, the STIC only intrudes about a dozen times a frame to fetch characters, and you get this particular glitch when the CPU doesn't let the STIC intrude. Otherwise, the STIC is pretty well isolated from the CPU and they don't bother each other. The other main place the STIC bugs the CPU is the vertical retrace interrupt. At the end of active display, the STIC fires an interrupt toward the CPU, so the CPU knows it can go reprogram STIC registers and update GRAM. On NTSC, it has a very short time window to do this. On PAL, because it only fills 80% of the display, it has a much more generous time window to access STIC registers and GRAM. And, of course, NTSC gets interrupted 60 times a second, while PAL only gets interrupted 50. So, PAL steals fewer cycles due to interrupts. Now throw in the fact that the PAL systems run the CPU about 11% faster... PAL systems have it easier all around!

Seems unlikely to me. The US 60Hz version has a slower CPU than the PAL 50Hz version. (895kHz vs. 1MHz.) Also, the scanlines are longer on PAL (64µs) vs. NTSC (63.6µs). The time allotted for the CPU to halt is around one scanline, which is 57 cycles on NTSC, or 64 on PAL. So, a PAL machine has about 7 more CPU cycles to halt the machine than NTSC does.

Well, if you want to try to help me reheat Tim Lindner's port to MacOS Classic, I suppose I can dig those files back out. They're in the revision history. How many extensions are there out there now? I search for bin, int, itv, rom, and cc3 currently.

I'm not committing to libretro at this time, as I haven't really dug into what it will take. I will say, Intellivoice support should follow jzIntv wherever it goes, since it's baked into jzIntv. I don't use WAV samples. Frank Palazzolo and I reverse engineered the Intellivoice.

You didn't upgrade it to OS/X? We inherited one of the blue&white G3s when TCU dumped theirs, and I used that for OS/X builds for years. I think the last MacOS Classic machine we owned was my wife's clamshell iBook.

I was planning separate Makefiles, although it's possible I could merge them. How old are we talking? This line of code (the one that blows up with SDL2) was there in 2006, when I checked everything into Subversion: /* -------------------------------------------------------------------- */ /* Allocate the event lookup table (this will be huge!). */ /* -------------------------------------------------------------------- */ event->mask_tbl[0] = calloc (sizeof(event_mask_t), EVENT_LAST * 4); event->max_event = EVENT_LAST; And EVENT_LAST was tied to SDLK_LAST, which doesn't exist in SDL2. Is it possible you just set SDLK_LAST to a suitable value, since you didn't need the SDLK event numbers that correspond to scancodes for the Android and Switch ports? That seems quite likely. Ah, yeah. I haven't used that Makefile in a long time. I've been using the poorly named "Makefile.stdout" for Windows builds, as it preserves stdout/stderr, rather than redirecting them to files. I should just rename that to Makefile.w32 and delete the other one. Also, I doubt Makefile.w32x works at all. I haven't used it in ages. I should also delete some of the unmaintained ports. For example, my Nokia N900 is dead, and I imagine almost everyone else's is as well. I may as well delete N900 support. I should ping Rick Reynolds to see if he's still interested in the GP2X port. I also need to find a suitable Amiga fan (or fans) to see if the Amiga and MorphOS ports still work. I've already deleted the Metrowerks Codewarrior makefile for MacOS Classic. I don't think that one's worked in 15+ years.

Another quick update: I've got most things working now. I refactored the event subsystem and have both SDL1 and SDL2 working. There's at least one missing bit: I don't currently fill in the display borders (-bXX). That should be quick to add. I also need to try building on Windows and Linux. So far, I've only built this on my Mac. Lots of little (and a few big) changes... Still need to refactor gfx/ to move the common code to a common core.

Just a quick update: I have basic SDL2 support working, except for events of course. I didn't use jenergy's SDL2 code as-is, but I used it as a starting point. That was very helpful. Thanks! One piece of good news is that SDL2 performs way better on modern Macs than SDL1. Buttery smooth 60Hz on my Retina display. With SDL1, it was dropping a huge number of frames on the built-in Retina display, and only managed 60Hz in full screen, or on my secondary display. I have some ideas on how to handle SDL2 events. I won't get to it until tomorrow, though. I have other things going on today.

Some observations I've made over the years: Intellivision has different NTSC and PAL color sets. In particular, Mattel computed what the chroma values should be from what they thought the NTSC was doing, and sent that to Radofin for the PAL units. The videos I've seen of PAL systems match the colors I get when I use the numbers in that document, but they're different from what I see on NTSC. (I forget which scan it is, but it's in the huge archive at PapaIntellivision.com.) Intellivision NTSC "Red" has a lot of green in it. It's more "unripe tomato." I discovered it was more than I realized when working with the ChromaDepth 3-D glasses. The NTSC Magenta, Purple, and Yellow-Green seem to be "out of gamut" for RGB, so these will never look quite right on RGB. They just don't "pop" like they should. Congo Bongo's first level makes a great litmus test to determine if you balanced tan, "brown," orange, and yellow properly. Also, several folks have pointed out that 80s fully analog CRTs may have displayed Intellivision's colors a bit differently than modern TVs, so it's worth setting up an old TV if you have access to one. I ditched all of my CRTs a long time ago, unfortunately.

Hey, could you send me the SDL2 changes you made? I've had SDL2 in my "to-do" list for quite awhile, and perhaps this will get me off my butt to actually do it. I can merge your changes into my current tree, or tweak them as needed. For SDL2 event management, that really is the sticking point. I will need to create a sparse structure to decode SDL2 events, and do some work at runtime to create a hash or similar structure.

Herman's a cool guy. I worked with him up until he retired. Knowing TI, I wouldn't be surprised if Microsoft ended up working on a project adjacent to the one TI shipped. I also worked with Karl Guttag. He had indicated to me (back when we were both still at TI) that he thought Microsoft had actually done the BASIC for the Home Computer. I wonder if he'd conflated the 99/4 with the 99/7 as Herman suggests? Karl was on the VDP side of things (and later CPU, with the TMS9995), while Herman was right in the thick of things in Lubbock.

The unsigned vs. signed greater than flags (L> and A>) on TMS9900 family always throw me off when I return for a visit. On most other CPUs I've encountered, there isn't a separate unsigned greater-than flag. Rather, the carry bit serves that purpose. If you treat a 2's complement subtract as merely "invert and inject a carry," then the carry will be clear after A - B when A < B (unsigned), and set otherwise. That gives you "unsigned less than" and "unsigned greater than/equal" just looking at the carry bit. Add in the EQ bit and you'd have "unsigned less than/equal" and "unsigned greater than." You can get by with four flag bits rather than five. In general, the TMS9900 family is weird about their carry bit compared to other architectures I've worked with. You can set it or clear it, but it's difficult to consume it without a branch. You can't use it directly for extended precision adds, subtracts, or shifts. You gotta branch, or do a funky dance with STST. It makes sense that ABS always zeros it out given how it's implemented. Without the L> bit, I could see using the carry flag to indicate whether ABS had modified the number. Not in floating point or 1's complement! I'm pretty sure that includes the 99/4A's weird Radix-100 floating point.

I only got there with your help, naturally. You shaved more cycles off mine than I did off yours. For the R0 < 0 case, the JLT gets taken, so we never actually end up with 50 + 11*mem. That case ends up being 42 + 8*mem, since we skip the INCT, but the JLT becomes 10 cycles. So, the final cycle counts end up being: R0 > 0: 48 + 10*mem R0 = 0: 22 + 3*mem (ABS is 12+2*mem, JEQ is 10+1*mem) R0 < 0: 42 + 8*mem (ABS is 14+3*mem, JLT becomes 10+1*mem) To put it in perspective, a single SRA R0, 15 is 42 + 3*mem. In zero wait-state memory, this is only slightly slower than that shift in the worst case. Nice!