+5-11under #1 Posted August 13, 2014 Quick question... I'm firing up a game in jzintv, and the memory map that shows up the DOS window shows the following: ICart [R ] [0x5000...0x6FFF] ICart [R ] [0xD000...0xDFFF] ICart [R ] [0xF000...0xFFFF] Usually it says: "Legacy BIN+CFG" instead of "ICart [R ]". Does anyone know the CFG for this? The bytes in the words also seem to be swapped, but perhaps not every section. Any help would be appreciated. Otherwise I'll contact Good Deal Games... . There is also data at $4000 in memory, after the game code, if that helps: 0000 0000 0000 0000 0000 0000 6400 0030 0000 0000 1111 0000 0000 0000 0011 0711 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 BF07 FF94 Quote Share this post Link to post Share on other sites
+Lathe26 #2 Posted August 13, 2014 I'm not 100% sure, but it sounds like you are loading a ROM file into jzintv instead of BIN+CFG files. ROM files are a format created for the Intellicart and Cuttle Cart 3 that effectively combines the games BIN data and CFG data into a single file (no CFG file to lose or mangle, yay!). jzintv accepts both types game formats. This is likely why jzintv is printing "ICart". You don't need a CFG file for ROM files. If the ROM doesn't work, contact whoever you got it from. Quote Share this post Link to post Share on other sites
+BBWW #3 Posted August 14, 2014 I've never been able to the jzintv to work on my Macbook Pro… I think I just don't have the patience to troubleshoot. If I could get it to work I'd but the adaptors for the joysticks. Sigh Quote Share this post Link to post Share on other sites
nanochess #4 Posted August 14, 2014 I've never been able to the jzintv to work on my Macbook Pro… I think I just don't have the patience to troubleshoot. If I could get it to work I'd but the adaptors for the joysticks. Sigh The binary works just right away from the Terminal, but you need to install libsdl separately. Once you are in the right directory you only enter: ./jzintv game The point and slash is needed so the shell looks for the executable in the current directory. 1 Quote Share this post Link to post Share on other sites
+BBWW #5 Posted August 14, 2014 The binary works just right away from the Terminal, but you need to install libsdl separately. Once you are in the right directory you only enter: ./jzintv game The point and slash is needed so the shell looks for the executable in the current directory. Thanks, I'll give it a try. Next we need a multicast the you can plug into your laptop WITH a USB cord and play games from THAT! LTO needs a REV2 with the emulator built in the cart for computer play for morons like me. 1 Quote Share this post Link to post Share on other sites
nanochess #6 Posted August 14, 2014 Quick question... I'm firing up a game in jzintv, and the memory map that shows up the DOS window shows the following: ICart [R ] [0x5000...0x6FFF] ICart [R ] [0xD000...0xDFFF] ICart [R ] [0xF000...0xFFFF] Usually it says: "Legacy BIN+CFG" instead of "ICart [R ]". Does anyone know the CFG for this? The bytes in the words also seem to be swapped, but perhaps not every section. Any help would be appreciated. Otherwise I'll contact Good Deal Games... . There is also data at $4000 in memory, after the game code, if that helps: 0000 0000 0000 0000 0000 0000 6400 0030 0000 0000 1111 0000 0000 0000 0011 0711 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 BF07 FF94 The ROM file format added some bytes before each data segment to form the header. So if you have the original BIN+CFG files, you'll see the BIN total bytes doesn't match the ROM size. The ROM format probably is documented in the JZINTV sources. BTW, the assembler as1600 generates BIN+CFG files, and then the 'bin2rom' program generates the ROM file. Also exists the inverse, 'rom2bin' that takes a ROM file and generates BIN+CFG files. In another curious note if you use the --cc3 flag for bin2rom, Nostalgia 5.0 emulator cannot emulate the final ROM file. Quote Share this post Link to post Share on other sites
+intvnut #7 Posted August 16, 2014 (edited) Quick question... I'm firing up a game in jzintv, and the memory map that shows up the DOS window shows the following: ICart [R ] [0x5000...0x6FFF] ICart [R ] [0xD000...0xDFFF] ICart [R ] [0xF000...0xFFFF] Usually it says: "Legacy BIN+CFG" instead of "ICart [R ]". Does anyone know the CFG for this? The bytes in the words also seem to be swapped, but perhaps not every section. Any help would be appreciated. Otherwise I'll contact Good Deal Games... . There is also data at $4000 in memory, after the game code, if that helps: 0000 0000 0000 0000 0000 0000 6400 0030 0000 0000 1111 0000 0000 0000 0011 0711 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 0707 BF07 FF94 That table looks like it should be from a .ROM format file, not a .BIN format file. Rename it with the extension ".rom" and see if it loads. You don't say what game this is, so I assume it's one I haven't seen yet. Feel free to PM me or email me at [email protected] for technical support. Email is actually better; I tend to miss PMs as I often read email on my phone and forget to follow up on PMs when I'm at a real computer. Lately, work keeps slamming me, so I end up away from AA for extended periods of time. I promise to keep whatever details you share with me confidential if you prefer. .BIN format files hold raw game data with no metadata to say how it goes in memory. I followed the conventions Carl's INTVPC established, with an assumed memory map of $5000 - $6FFF, $D000 - $DFFF and $F000 - $FFFF for games up to 16K words. For .BIN files larger than that or a different memory map, you need a .CFG file to tell jzIntv (or INTVPC) how to put data from .BIN files into memory. Each word is stored in big-endian order in a .BIN. .ROM format files have an odd number of bytes because the first byte of the file is the "autobaud" byte. (0xA8 for Intellicart, 0x41 for CC3.) After that are chunks of ROM data prefixed with header information, followed finally by an attribute table. The header on each chunk says where to put the payload and how large it is. Each chunk has a checksum too. The attribute table at the end establishes the address map decoding. The actual ROM data in each chunk is still big-endian, and all the metadata is an even number of bytes. So, if you load a .ROM as a .BIN, it will look byte-swapped. Really, it's byte-shifted, with the lower byte of one word paired with the upper byte of the next, thanks to the single autobaud byte. It'll also be shifted down in memory because the various header metadata will look like program data. The file jzintv/doc/rom_fmt/IntellicartManual.booklet.pdf goes into way more detail than my high-level description above. Also, the comments jzintv/src/icart/icartrom.c may be helpful. This extract captures the basic gist of it. (Note that the CC3_ADV format doesn't exist. Chad and I reserved that autobaud byte for future expansion, but we haven't done anything with it.) /* -------------------------------------------------------------------- */ /* Next, calculate the size of the .ROM image. The .ROM format has */ /* the following fixed and variable costs: */ /* */ /* -- Header: 3 bytes (fixed) */ /* -- Attribute Table: 16 bytes (fixed) */ /* -- Fine Addr Table: 32 bytes (fixed) */ /* -- Table Checksum: 2 bytes (fixed) */ /* ------------------ */ /* 53 bytes total fixed overhead */ /* */ /* -- ROM segments: 4 + 2*num_words per segment. */ /* -------------------------------------------------------------------- */ size = 53; for (i = 0; i < num_seg; i++) size += 512 * (seg_hi[i] - seg_lo[i] + 1) + 4; *rom_size = size; /* Report the size to the caller. */ /* -------------------------------------------------------------------- */ /* Allocate a hunk of memory for the .ROM file. */ /* -------------------------------------------------------------------- */ if ((rom_img = CALLOC(uint_8, size)) == NULL) return NULL; /* fail if out-of-memory. */ /* -------------------------------------------------------------------- */ /* Now, construct the .ROM image. */ /* First: The header. */ /* -------------------------------------------------------------------- */ switch (type) { case ICART: rom_img[0] = 0xA8; /* Autobaud Rate-Detection Byte */ break; case CC3_STD: rom_img[0] = 0x41; /* Autobaud Rate-Detection Byte */ break; case CC3_ADV: rom_img[0] = 0x61; /* Autobaud Rate-Detection Byte */ break; default: free(rom_img); /* Fail on unknown type. */ return NULL; } rom_img[1] = num_seg; /* Number of ROM segments in image. */ rom_img[2] = num_seg ^ 0xFF; /* 1s Complement of # of segments. */ /* -------------------------------------------------------------------- */ /* Next: The ROM segments. */ /* -------------------------------------------------------------------- */ for (i = 0, ofs = 3; i < num_seg; i++) { int start_ofs, len; start_ofs = ofs; /* ---------------------------------------------------------------- */ /* Inclusive segment range. (upper 8 of addresses) */ /* ---------------------------------------------------------------- */ rom_img[ofs++] = seg_lo[i]; rom_img[ofs++] = seg_hi[i]; lo = seg_lo[i] << 8; hi = (seg_hi[i] << + 0x100; len = 2*(hi - lo) + 2; /* +2 to include header */ /* ---------------------------------------------------------------- */ /* Actual ROM image data in big-endian format. */ /* ---------------------------------------------------------------- */ for (j = lo; j < hi; j++) { rom_img[ofs++] = rom->image[j] >> 8; rom_img[ofs++] = rom->image[j] & 0xFF; } /* ---------------------------------------------------------------- */ /* ROM segment checksum (CRC-16), also big-endian. */ /* ---------------------------------------------------------------- */ crc = crc16_block(0xFFFF, rom_img + start_ofs, len); rom_img[ofs++] = crc >> 8; rom_img[ofs++] = crc & 0xFF; } /* -------------------------------------------------------------------- */ /* Last: The attribute and fine-address tables. */ /* -------------------------------------------------------------------- */ for (i = 0; i < 16; i++) rom_img[ofs++] = bank_attr[i*2 + 0] | (bank_attr[i*2 + 1] << 4); for (j = 0; j < 2; j++) for (i = 0; i < 16; i++) rom_img[ofs++] = fine_addr[i*2 + j]; crc = crc16_block(0xFFFF, rom_img + ofs - 48, 48); rom_img[ofs++] = crc >> 8; rom_img[ofs++] = crc & 0xFF; So, the tl;dr: It looks like you're trying to load a .ROM as a .BIN. Rename it to have the extension ".rom" and it will probably start working. If you are actually curious what's in a .ROM file, see the code above. :-) If you're wondering if I have any other documentation... it's all really in the jzIntv source tree. When I forget something, I go back and read the source. *shrug* Edited August 16, 2014 by intvnut 1 Quote Share this post Link to post Share on other sites
+Lathe26 #8 Posted August 17, 2014 Interestingly, the auto-baud baud values in the Cuttle Cart 3 manual were inconsistent. I asked Chad about it and he only said that "It should be 0x61, capital 'A'. The 0x41 is a typo." Quote Share this post Link to post Share on other sites
+intvnut #9 Posted August 18, 2014 Interestingly, the auto-baud baud values in the Cuttle Cart 3 manual were inconsistent. I asked Chad about it and he only said that "It should be 0x61, capital 'A'. The 0x41 is a typo." Other way around. 0x41 is capital A. 0x61 is lower-case A. The standard CC3 format uses 0x41, which is capital A. Quote Share this post Link to post Share on other sites
+Lathe26 #10 Posted August 18, 2014 Other way around. 0x41 is capital A. 0x61 is lower-case A. The standard CC3 format uses 0x41, which is capital A. That makes more sense given the hex values. Quote Share this post Link to post Share on other sites
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord