Fixed DSP/audio options to be unambiguous and consistent.

[virtualjaguar] / src / op.cpp

diff --git a/src/op.cpp b/src/op.cpp
index 62be06681901ac49a6f311e5298a3cb20bcc7645..8708d9b34418c81a28ca6f279f5a81e65a51d953 100644 (file)
--- a/src/op.cpp
+++ b/src/op.cpp
@@ -3,10 +3,10 @@
 //
 // Original source by David Raingeard (Cal2)
 // GCC/SDL port by Niels Wagenaar (Linux/WIN32) and Caz (BeOS)
-// Extensive cleanups/fixes/rewrites by James L. Hammons
+// Extensive cleanups/fixes/rewrites by James Hammons
 // (C) 2010 Underground Software
 //
-// JLH = James L. Hammons <jlhamm@acm.org>
+// JLH = James Hammons <jlhamm@acm.org>
 //
 // Who  When        What
 // ---  ----------  -------------------------------------------------------------
@@ -20,7 +20,7 @@
 #include "gpu.h"
 #include "jaguar.h"
 #include "log.h"
-#include "m68k.h"
+#include "m68000/m68kinterface.h"
 #include "memory.h"
 #include "tom.h"
 
@@ -36,9 +36,9 @@
 #define OBJECT_TYPE_BRANCH     3                                       // 011
 #define OBJECT_TYPE_STOP       4                                       // 100
 
-#define CONDITION_EQUAL                                0
-#define CONDITION_LESS_THAN                    1
-#define CONDITION_GREATER_THAN         2
+#define CONDITION_EQUAL                                0                       // VC == YPOS
+#define CONDITION_LESS_THAN                    1                       // VC < YPOS
+#define CONDITION_GREATER_THAN         2                       // VC > YPOS
 #define CONDITION_OP_FLAG_SET          3
 #define CONDITION_SECOND_HALF_LINE     4
 
@@ -180,6 +180,10 @@ void OPDone(void)
 
        WriteLog("\n");
 #else
+#warning "!!! Fix lockup in OPDiscoverObjects() !!!"
+//temp, to keep the following function from locking up on bad/weird OLs
+return;
+
        numberOfObjects = 0;
        OPDiscoverObjects(olp);
        OPDumpObjectList();
@@ -429,6 +433,10 @@ void DumpBitmapCore(uint64 p0, uint64 p1)
 #warning "Need to fix this so that when an GPU object IRQ happens, we can pick up OP processing where we left off. !!! FIX !!!"
 void OPProcessList(int halfline, bool render)
 {
+#warning "!!! NEED TO HANDLE MULTIPLE FIELDS PROPERLY !!!
+// We ignore them, for now; not good
+       halfline &= 0x7FF;
+
 extern int op_start_log;
 //     char * condition_to_str[8] =
 //             { "==", "<", ">", "(opflag set)", "(second half line)", "?", "?", "?" };
@@ -612,8 +620,17 @@ if (!inhibit)      // For OP testing only!
 /*     if (op_pointer > ((p0 & 0x000007FFFF000000LL) >> 21))
                return;*/
 
-                       op_pointer = (p0 & 0x000007FFFF000000LL) >> 21;
+// NOTE: The link address only replaces bits 3-21 in the OLP, and this replaces
+//       EVERYTHING. !!! FIX !!! [DONE]
+#warning "!!! Link address is not linked properly for all object types !!!"
+#warning "!!! Only BITMAP is properly handled !!!"
+                       op_pointer &= 0xFFC00007;
+                       op_pointer |= (p0 & 0x000007FFFF000000LL) >> 21;
 //WriteLog("New OP: %08X\n", op_pointer);
+//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
+
                        break;
                }
                case OBJECT_TYPE_SCALE:
@@ -767,6 +784,7 @@ OP: Scaled bitmap 4x? 4bpp at 34,? hscale=80 fpix=0 data=000756E8 pitch 1 hflipp
                        uint16 ypos = (p0 >> 3) & 0x7FF;
 // NOTE: The JTRM sez there are only 2 bits used for the CC, but lists *five*
 //       conditions! Need at least one more bit for that! :-P
+// Also, the ASIC nets imply that it uses bits 14-16 (height in BM & SBM objects)
 #warning "!!! Possibly bad CC handling in OP (missing 1 bit) !!!"
                        uint8  cc   = (p0 >> 14) & 0x03;
                        uint32 link = (p0 >> 21) & 0x3FFFF8;
@@ -832,7 +850,7 @@ OP: Scaled bitmap 4x? 4bpp at 34,? hscale=80 fpix=0 data=000756E8 pitch 1 hflipp
 //                     break;
                }
                default:
-                       WriteLog("op: unknown object type %i\n", ((uint8)p0 & 0x07));
+//                     WriteLog("op: unknown object type %i\n", ((uint8)p0 & 0x07));
                        return;
                }
 
@@ -890,6 +908,13 @@ void OPProcessFixedBitmap(uint64 p0, uint64 p1, bool render)
 // Is it OK to have a 0 for the data width??? (i.e., undocumented?)
 // Seems to be... Seems that dwidth *can* be zero (i.e., reuse same line) as well.
 // Pitch == 0 is OK too...
+
+//kludge: Seems that the OP treats iwidth == 0 as iwidth == 1... Need to investigate
+//        on real hardware...
+#warning "!!! Need to investigate iwidth == 0 behavior on real hardware !!!"
+if (iwidth == 0)
+       iwidth = 1;
+
 //     if (!render || op_pointer == 0 || ptr == 0 || pitch == 0)
 //I'm not convinced that we need to concern ourselves with data & op_pointer here either!
        if (!render || iwidth == 0)