intvnut
-
Content Count
3,713 -
Joined
-
Last visited
-
Days Won
7
Posts posted by intvnut
-
-
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.-
4
-
-
1 hour ago, bhall408 said:Although I presume Space Patrol is assembler, and that is also a good test case/app for ECS PSG.
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.
5 minutes ago, Zendocon said:developed it several years before IntyBASIC came onto the scene.
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.
-
4
-
-
On 7/3/2020 at 9:53 PM, Humblejack said:Isn't that a solder in chip?
Unfortunately, few if any of the chips in most Inty 2s are socketed. And yes, the 2114s are pretty much always soldered in.
-
2 hours ago, Greg2600 said:Maybe Steve is willing to transfer the production to someone else?
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.
-
16
-
4
-
-
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.
-
1
-
-
3 minutes ago, Zendocon said:FUBAR uses the extra controller ports for 4 players, in addition to the extra sound channels. I didn't use the ECS RAM because the ECS is supposed to be optional.
Reading the extra controllers is a cinch. The state of the third and fourth controllers is at addresses $00ff and $00fe, whereas the state of the first and second controllers is at $01ff and $01fe.
I'd be lying if I said I didn't have you in mind when I mentioned:
7 hours ago, intvnut said: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.
🙂
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?
-
12 hours ago, bhall408 said:We started adding ECS support to Argon today, and it quickly was turning into a rabbit hole.
As in, needing keyboard support, support in our database to indicate when a keyboard would be needed in the UI, etc.
So taking a step back, we think it could be the most bang for the buck to take an "ECS Lite" approach, and wire up the extra RAM and 2nd PSG (sound chip), but nothing else.
Pretty sure Space Patrol would be happy with that (@intvnut) -- we'll know soon enough, but are there any other indy/homebrew games that would take advantage of those two features, while NOT requiring keyboard/etc?
And if the answer is no, then would there be interest from indy devs to change that to a yes if there were easy (we provide examples) and/or integrated support (we help @nanochess ?) in IntyBasic to take advantage of extra RAM/2nd sound chip (when it is detected/available?)
It is especially nice when games take advantage of these, especially the extra sound chip. For a nice comparison, there are the many Coleco games that detect/take advantage of SGM (Super Game Module), which is conceptually the same addition.
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.
-
1
-
-
21 hours ago, mr_me said:I don't think jzintv has any save game support unless it was implemented in the original cartridge. For example jzintv emulates the ecs cassette interface, so basic csav/clod should work and maybe world series baseball save game and save rosters should work. It also emulates the save game feature of homebrew jlp cartridges.
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.
-
2
-
-
2 hours ago, Zendocon said:I did look it up earlier, just to be sure I wasn't making a fool of myself once again. A literal search for "Flight of the Valkyries" kept pointing to "Ride of the Valkyries" with a couple of exceptions.
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.
6 minutes ago, Zendocon said:I've still got the disassembled/reassembled files. Perhaps the call to sed is different for me, and I ended up with a bad reassembled file. Or perhaps you were using a different version of jzintv than me. I'm running 20200607, though I doubt dis1600 and as1600 changed.
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. 🙂
-
4 hours ago, Zendocon said:Yep. I played a 2-player game last night and heard Ride of the Valkyries (not to be confused in name with Flight of the Bumblebee).
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.
-
1
-
-
On 6/23/2020 at 7:34 AM, mr_me said:My understanding was that the original cartridge release of checkers played ride of the valkyries and the original backgammon cartridge played the 1812 overture. So in triple challenge they axed the music from checkers and used the tune in backgammon in it's place. Is that correct?
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.
-
2 hours ago, Zendocon said:Interesting. The standalone ROM image I have draws the title in all-caps but has the lower-pitched sounds. My physical cart has the higher-pitched sounds I think. Which version(s) play Ride of the Valkyries?
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.
-
On 6/23/2020 at 10:14 AM, Zendocon said:The other difference between the old versions is that the sound effects are different. There's one where the sound effects when a move is made is the same as the dealer talking in Poker & Blackjack, and the AI "thinking" sound is the same as in Backgammon. The version on Triple Challenge has deeper sounds than that.
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 0001After:
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 -
8 minutes ago, Lathe26 said:That is an impressive list of improvements, thanks!
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.
-
1 hour ago, intvnut said: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.
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_SCREENat 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_SCREENIn 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.
-
1
-
10 hours ago, Zendocon said:Second, are you saying the menu checks for Reversi code to be present in $Bxxx and adds a menu item?
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.
10 hours ago, Zendocon said:I'll try reverse-engineering the original Checkers to see how much ROM space it really needs.
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.
10 hours ago, Zendocon said:Perhaps Reversi was taken out due to ROM space considerations, or perhaps the Stack Overflow issue manifested here as well.
More likely cost vs. benefit. Reference: https://history.blueskyrangers.com/intvcorp/triplechallenge.html
QuoteDEVELOPMENT HISTORY
Triple Challenge began as a quadruple challenge: the original concept was to put the four board games from the Mattel Electronics Strategy Network onto one cartridge. At the last minute, Reversi was cut to save money.
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:
QuoteFUN FACT: This idea almost died due to cost -- Chess requires 2K of RAM onboard the cartridge, which was found to be too expensive for INTV. Then INTV's executive in charge of procurement, Roger Rambeau, found a company that was stuck with thousands of defective 4K RAM chips. The chips did each have 2K of usable contiguous RAM. Roger bought them for a song, making the cartridge possible.
10 hours ago, Zendocon said:I should be able to concatenate Triple Challenge and Reversi, same as Go For The Gold, right? And then just modify the .cfg file to what you've got here?
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.
-
1
-
-
4 minutes ago, ChildOfCv said:Then on the RO-3-9502, it supposedly only has 10 address output lines for external memory. But pin 14 (NC on the datasheet) is labeled as A10 and connected to the OR gate. So, two WTFs.
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.
13 minutes ago, ChildOfCv said:Now looking closely at the schematic, I see that the ENABLE for the sound/peripheral chip is supposed to be pins 24 and 25. But the Inty leaves them disconnected and uses pin 26 (TEST 2, do not use!) as its enable.
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.
39 minutes ago, ChildOfCv said:I realized I forgot to answer this question. The RAM does respond even outside of the range of usable RAM, but I only got FFFF's for readback.
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.
-
11
-
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 -
Just now, Tarzilla said:So live GRAM and/or memory viewer windows that we've discussed before is now a eventual possibility with SDL2? I seem to recall you said SDL1 was the limiting factor.
Yes indeed. SDL1 only supports a single window. SDL2 supports multiple windows, and that's definitely something I am interested in myself.
-
2
-
-
3 minutes ago, jenergy said:Hi, do sources on jzIntv site contain finally these fixes?
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.
-
New debugger commands:
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
-
1
-
1
-
Bugfixes:
-
2 minutes ago, ChildOfCv said:So, from what I understand, ADAR should be equivalent to DTB for the source chip, but every other chip watches for an address in their range.
Are you asking me to check whether it latches an ADAR as an input address? Or that it outputs its data upon receipt of ADAR when it has latched an address in its range?
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*.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
jzintv Christmas update
in Intellivision / Aquarius
Posted
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:
If those work, then we can retire the Makefile.termux* files.