From: Shamus Hammons Date: Mon, 9 Mar 2015 12:07:33 +0000 (-0500) Subject: This time, for sure! X-Git-Url: http://shamusworld.gotdns.org/cgi-bin/gitweb.cgi?p=virtualjaguar;a=commitdiff_plain;h=0c0dea5b5411ef9be8c6d5159faf0d2226db4452 This time, for sure! Was a slight bug in the OP fix from last commit. :-P --- diff --git a/cross-compile b/cross-compile index f09a78e..285bb00 100755 --- a/cross-compile +++ b/cross-compile @@ -5,13 +5,18 @@ # by James Hammons # (C) 2012 Underground Software # -#PREFIX=i686-pc-mingw32.static -#echo "Cross compiling for Win32..." -echo "Cross compiling for Win64..." +#NOPE, doesn't work: PREFIX=i686-pc-mingw32.static +echo "Cross compiling for Win32..." +#echo "Cross compiling for Win64..." export PATH=/opt/mxe/usr/bin:$PATH #rm makefile-qt + +#/opt/mxe/usr/bin/i686-pc-mingw32.static-qmake -o makefile-qt #make CROSS=i686-pc-mingw32.static- + +/opt/mxe/usr/bin/x86_64-w64-mingw32.static-qmake-qt5 -o makefile-qt make CROSS=x86_64-w64-mingw32.static- + #rel=`svn info | grep Revision | cut -f 2 -d ' '` rel=`git log -1 --pretty=format:%ci | cut -d ' ' -f 1 | tr -d -` cd release && upx -9v virtualjaguar.exe && zip -9v vj-$rel.zip virtualjaguar.exe diff --git a/src/blitter.cpp b/src/blitter.cpp index c4975ab..588e6c2 100644 --- a/src/blitter.cpp +++ b/src/blitter.cpp @@ -17,7 +17,6 @@ // to Curt. ;-) Without that excellent documentation which shows *exactly* // what's going on inside the TOM chip, we'd all still be guessing as to how // the wily blitter and other pieces of the Jaguar puzzle actually work. -// Now how about those JERRY ASIC nets gentlemen...? [We have those now!] ;-) // #include "blitter.h" @@ -32,7 +31,7 @@ // Various conditional compilation goodies... -#define LOG_BLITS +//#define LOG_BLITS #define USE_ORIGINAL_BLITTER //#define USE_MIDSUMMER_BLITTER @@ -2774,7 +2773,7 @@ if ( #else logBlit = true; #endif -/*if (blit_start_log == 0) // Wait for the signal... +if (blit_start_log == 0) // Wait for the signal... logBlit = false;//*/ //temp, for testing... /*if (cmd != 0x49820609) diff --git a/src/op.cpp b/src/op.cpp index 85bbdf1..3cca7fa 100644 --- a/src/op.cpp +++ b/src/op.cpp @@ -9,7 +9,7 @@ // JLH = James Hammons // // Who When What -// --- ---------- ------------------------------------------------------------- +// --- ---------- ----------------------------------------------------------- // JLH 01/16/2010 Created this log ;-) // @@ -230,9 +230,12 @@ void OPDiscoverObjects(uint32_t address) if (objectType == 3) { - // Recursion needed to follow all links! This does depth-first recursion - // on the not-taken objects - OPDiscoverObjects(address + 8); + // Branch if YPOS < 2047 can be treated as a GOTO, so don't do any + // discovery in that case. Otherwise, have at it: + if ((lo & 0xFFFF) != 0x7FFB) + // Recursion needed to follow all links! This does depth-first + // recursion on the not-taken objects + OPDiscoverObjects(address + 8); } // Get the next object... @@ -252,7 +255,7 @@ void OPDumpObjectList(void) uint32_t lo = JaguarReadLong(address + 4, OP); uint8_t objectType = lo & 0x07; uint32_t link = ((hi << 11) | (lo >> 21)) & 0x3FFFF8; - WriteLog("%08X: %08X %08X %s -> $08X", address, hi, lo, opType[objectType], link); + WriteLog("%08X: %08X %08X %s -> $%08X", address, hi, lo, opType[objectType], link); if (objectType == 3) { @@ -263,12 +266,15 @@ void OPDumpObjectList(void) WriteLog("\n"); + // Yes, this is how the OP finds follow-on phrases for bitmap/scaled + // bitmap objects...! if (objectType == 0) - DumpFixedObject(OPLoadPhrase(address + 0), OPLoadPhrase(address + 8)); + DumpFixedObject(OPLoadPhrase(address + 0), + OPLoadPhrase(address | 0x08)); if (objectType == 1) - DumpScaledObject(OPLoadPhrase(address + 0), OPLoadPhrase(address + 8), - OPLoadPhrase(address + 16)); + DumpScaledObject(OPLoadPhrase(address + 0), + OPLoadPhrase(address | 0x08), OPLoadPhrase(address | 0x10)); if (address == link) // Ruh roh... { @@ -442,12 +448,16 @@ void DumpBitmapCore(uint64_t p0, uint64_t p1) void OPProcessList(int halfline, bool render) { #warning "!!! NEED TO HANDLE MULTIPLE FIELDS PROPERLY !!!" -// We ignore them, for now; not good +// We ignore them, for now; not good D-: +// N.B.: Half-lines are exactly that, half-lines. When in interlaced mode, it +// draws the screen exactly the same way as it does in non, one line at a +// time. The only way you know you're in field #2 is that the topmost bit +// of VC is set. Half-line mode is so you can draw higher horizontal +// resolutions than you normally could, as the line buffer is only 720 +// pixels wide... halfline &= 0x7FF; extern int op_start_log; -// char * condition_to_str[8] = -// { "==", "<", ">", "(opflag set)", "(second half line)", "?", "?", "?" }; op_pointer = OPGetListPointer(); @@ -562,8 +572,8 @@ WriteLog(" --> List end\n\n"); // This is only theory implied by Rayman...! // It seems that if the YPOS is zero, then bump the YPOS value so that it // coincides with the VDB value. With interlacing, this would be slightly more -// tricky. There's probably another bit somewhere that enables this mode--but so -// far, doesn't seem to affect any other game in a negative way (that I've +// tricky. There's probably another bit somewhere that enables this mode--but +// so far, doesn't seem to affect any other game in a negative way (that I've // seen). Either that, or it's an undocumented bug... //No, the reason this was needed is that the OP code before was wrong. Any value @@ -590,8 +600,8 @@ if (!inhibit) // For OP testing only! { // Believe it or not, this is what the OP actually does... // which is why they're required to be on a dphrase boundary! - uint64_t p1 = OPLoadPhrase(op_pointer | 0x08); - op_pointer += 8; + uint64_t p1 = OPLoadPhrase(oldOPP | 0x08); +//unneeded op_pointer += 8; //WriteLog("OP: Writing halfline %d with ypos == %d...\n", halfline, ypos); //WriteLog("--> Writing %u BPP bitmap...\n", op_bitmap_bit_depth[(p1 >> 12) & 0x07]); // OPProcessFixedBitmap(halfline, p0, p1, render); @@ -599,17 +609,6 @@ if (!inhibit) // For OP testing only! // OP write-backs -//???Does this really happen??? Doesn't seem to work if you do this...! -//Probably not. Must be a bug in the documentation...! -// uint32_t link = (p0 & 0x7FFFF000000) >> 21; -// SET16(tom_ram_8, 0x20, link & 0xFFFF); // OLP -// SET16(tom_ram_8, 0x22, link >> 16); -/* uint32_t height = (p0 & 0xFFC000) >> 14; - if (height - 1 > 0) - height--;*/ - // NOTE: Would subtract 2 if in interlaced mode...! -// uint64_t height = ((p0 & 0xFFC000) - 0x4000) & 0xFFC000; -// if (height) height--; uint64_t data = (p0 & 0xFFFFF80000000000LL) >> 40; @@ -621,15 +620,13 @@ if (!inhibit) // For OP testing only! p0 |= data << 40; OPStorePhrase(oldOPP, p0); } -//WriteLog("\t\tOld OP: %08X -> ", op_pointer); - // OP bottom 3 bits are hardwired to zero. The link address reflects - // this, so we only need the top 19 bits of the address (which is - // why we only shift 21, and not 24). + // OP bottom 3 bits are hardwired to zero. The link address + // reflects this, so we only need the top 19 bits of the address + // (which is why we only shift 21, and not 24). op_pointer = (p0 & 0x000007FFFF000000LL) >> 21; -//WriteLog("New OP: %08X\n", op_pointer); - //kludge: Seems that memory access is mirrored in the first 8MB of + // KLUDGE: Seems that memory access is mirrored in the first 8MB of // memory... if (op_pointer > 0x1FFFFF && op_pointer < 0x800000) op_pointer &= 0xFF1FFFFF; // Knock out bits 21-23 @@ -655,10 +652,10 @@ if (!inhibit) // For OP testing only! if (halfline >= ypos && height > 0) { // Believe it or not, this is what the OP actually does... - uint64_t p1 = OPLoadPhrase(op_pointer | 0x08); - uint64_t p2 = OPLoadPhrase(op_pointer | 0x10); - op_pointer += 16; -//WriteLog("OP: %08X (%d) %08X%08X %08X%08X %08X%08X\n", oldOPP, halfline, (uint32_t)(p0>>32), (uint32_t)(p0&0xFFFFFFFF), (uint32_t)(p1>>32), (uint32_t)(p1&0xFFFFFFFF), (uint32_t)(p2>>32), (uint32_t)(p2&0xFFFFFFFF)); + // which is why they're required to be on a qphrase boundary! + uint64_t p1 = OPLoadPhrase(oldOPP | 0x08); + uint64_t p2 = OPLoadPhrase(oldOPP | 0x10); +//unneeded op_pointer += 16; OPProcessScaledBitmap(p0, p1, p2, render); // OP write-backs @@ -711,9 +708,10 @@ OP: Scaled bitmap 4x? 4bpp at 34,? hscale=80 fpix=0 data=000756E8 pitch 1 hflipp */ //Here's another problem: // [hsc: 20, vsc: 20, rem: 00] -// Since we're not checking for $E0 (but that's what we get from the above), we end -// up repeating this halfline unnecessarily... !!! FIX !!! [DONE, but... still not quite -// right. Either that, or the Accolade team that wrote Bubsy screwed up royal.] +// Since we're not checking for $E0 (but that's what we get from the above), we +// end up repeating this halfline unnecessarily... !!! FIX !!! [DONE, but... +// still not quite right. Either that, or the Accolade team that wrote Bubsy +// screwed up royal.] //Also note: $E0 = 7.0 which IS a legal vscale value... // if (remainder & 0x80) // I.e., it's negative @@ -764,12 +762,12 @@ OP: Scaled bitmap 4x? 4bpp at 34,? hscale=80 fpix=0 data=000756E8 pitch 1 hflipp //WriteLog(" [after]: rem=%02X, vscale=%02X\n", remainder, vscale); } - // OP bottom 3 bits are hardwired to zero. The link address reflects - // this, so we only need the top 19 bits of the address (which is - // why we only shift 21, and not 24). + // OP bottom 3 bits are hardwired to zero. The link address + // reflects this, so we only need the top 19 bits of the address + // (which is why we only shift 21, and not 24). op_pointer = (p0 & 0x000007FFFF000000LL) >> 21; - //kludge: Seems that memory access is mirrored in the first 8MB of + // KLUDGE: Seems that memory access is mirrored in the first 8MB of // memory... if (op_pointer > 0x1FFFFF && op_pointer < 0x800000) op_pointer &= 0xFF1FFFFF; // Knock out bits 21-23 @@ -849,12 +847,12 @@ OP: Scaled bitmap 4x? 4bpp at 34,? hscale=80 fpix=0 data=000756E8 pitch 1 hflipp if (p0 & 0x08) { - // We need to check whether these interrupts are enabled or not, THEN - // set an IRQ + pending flag if necessary... + // We need to check whether these interrupts are enabled or + // not, THEN set an IRQ + pending flag if necessary... if (TOMIRQEnabled(IRQ_OPFLAG)) { TOMSetPendingObjectInt(); - m68k_set_irq(2); // Cause a 68K IPL 2 to occur... + m68k_set_irq(2); // Cause a 68K IPL 2 to occur... } } @@ -863,12 +861,14 @@ OP: Scaled bitmap 4x? 4bpp at 34,? hscale=80 fpix=0 data=000756E8 pitch 1 hflipp } default: // WriteLog("op: unknown object type %i\n", ((uint8_t)p0 & 0x07)); - return; +// return; + ; } - // Here is a little sanity check to keep the OP from locking up the machine - // when fed bad data. Better would be to count how many actual cycles it used - // and bail out/reenter to properly simulate an overloaded OP... !!! FIX !!! + // Here is a little sanity check to keep the OP from locking up the + // machine when fed bad data. Better would be to count how many actual + // cycles it used and bail out/reenter to properly simulate an + // overloaded OP... !!! FIX !!! #warning "Better would be to count how many actual cycles it used and bail out/reenter to properly simulate an overloaded OP... !!! FIX !!!" opCyclesToRun--; @@ -1374,13 +1374,15 @@ if (firstPix) uint8_t * tomRam8 = TOMGetRamPointer(); uint8_t * paletteRAM = &tomRam8[0x400]; - // This is OK as long as it's used correctly: For 16-bit RAM to RAM direct copies--NOT - // for use when using endian-corrected data (i.e., any of the *ReadWord functions!) + // This is OK as long as it's used correctly: For 16-bit RAM to RAM direct + // copies--NOT for use when using endian-corrected data (i.e., any of the + // *ReadWord functions!) uint16_t * paletteRAM16 = (uint16_t *)paletteRAM; uint16_t hscale = p2 & 0xFF; -// Hmm. It seems that fixing the horizontal scale necessitated re-fixing this. Not sure why, -// but seems to be consistent with the vertical scaling now (and it may turn out to be wrong!)... +// Hmm. It seems that fixing the horizontal scale necessitated re-fixing this. +// Not sure why, but seems to be consistent with the vertical scaling now (and +// it may turn out to be wrong!)... uint16_t horizontalRemainder = hscale; // Not sure if it starts full, but seems reasonable [It's not!] // uint8_t horizontalRemainder = 0; // Let's try zero! Seems to work! Yay! [No, it doesn't!] int32_t scaledWidthInPixels = (iwidth * phraseWidthToPixels[depth] * hscale) >> 5; @@ -1435,33 +1437,37 @@ if (start_logging) return; // Otherwise, find the clip limits and clip the phrase as well... - // NOTE: I'm fudging here by letting the actual blit overstep the bounds of the - // line buffer, but it shouldn't matter since there are two unused line - // buffers below and nothing above and I'll at most write 40 bytes outside - // the line buffer... I could use a fractional clip begin/end value, but - // this makes the blit a *lot* more hairy. I might fix this in the future - // if it becomes necessary. (JLH) - // Probably wouldn't be *that* hairy. Just use a delta that tells the inner loop - // which pixel in the phrase is being written, and quit when either end of phrases - // is reached or line buffer extents are surpassed. + // NOTE: I'm fudging here by letting the actual blit overstep the bounds of + // the line buffer, but it shouldn't matter since there are two + // unused line buffers below and nothing above and I'll at most write + // 40 bytes outside the line buffer... I could use a fractional clip + // begin/end value, but this makes the blit a *lot* more hairy. I + // might fix this in the future if it becomes necessary. (JLH) + // Probably wouldn't be *that* hairy. Just use a delta that tells the + // inner loop which pixel in the phrase is being written, and quit + // when either end of phrases is reached or line buffer extents are + // surpassed. //This stuff is probably wrong as well... !!! FIX !!! -//The strange thing is that it seems to work, but that's no guarantee that it's bulletproof! +//The strange thing is that it seems to work, but that's no guarantee that it's +//bulletproof! //Yup. Seems that JagMania doesn't work correctly with this... -//Dunno if this is the problem, but Atari Karts is showing *some* of the road now... -//Actually, it is! Or, it was. It doesn't seem to be clipping here, so the problem lies -//elsewhere! Hmm. Putting the scaling code into the 1/2/8 BPP cases seems to draw the ground -// a bit more accurately... Strange! -//It's probably a case of the REFLECT flag being set and the background being written -//from the right side of the screen... +//Dunno if this is the problem, but Atari Karts is showing *some* of the road +//now... +//Actually, it is! Or, it was. It doesn't seem to be clipping here, so the +//problem lies elsewhere! Hmm. Putting the scaling code into the 1/2/8 BPP cases +//seems to draw the ground a bit more accurately... Strange! +//It's probably a case of the REFLECT flag being set and the background being +//written from the right side of the screen... //But no, it isn't... At least if the diagnostics are telling the truth! // NOTE: We're just using endPos to figure out how much, if any, to clip by. - // ALSO: There may be another case where we start out of bounds and end out of bounds...! + // ALSO: There may be another case where we start out of bounds and end out + // of bounds...! // !!! FIX !!! -//There's a problem here with scaledPhrasePixels in that it can be forced to zero when -//the scaling factor is small. So fix it already! !!! FIX !!! +//There's a problem here with scaledPhrasePixels in that it can be forced to +//zero when the scaling factor is small. So fix it already! !!! FIX !!! /*if (scaledPhrasePixels == 0) { WriteLog("OP: [Scaled] We're about to encounter a divide by zero error!\n"); diff --git a/src/tom.cpp b/src/tom.cpp index 6ce648b..be4972a 100644 --- a/src/tom.cpp +++ b/src/tom.cpp @@ -788,8 +788,8 @@ void tom_render_24bpp_scanline(uint32_t * backbuffer) } -//Seems to me that this is NOT a valid mode--the JTRM seems to imply that you would need -//extra hardware outside of the Jaguar console to support this! +// Seems to me that this is NOT a valid mode--the JTRM seems to imply that you +// would need extra hardware outside of the Jaguar console to support this! // // 16 BPP direct mode rendering //