-// static uint16 onetime = 1;
-
- uint16 vmode = GET16(tom_ram_8, VMODE);
- uint16 hdb1 = GET16(tom_ram_8, HDB1);
-// uint16 hde = GET16(tom_ram_8, HDE);
-// uint16 hbb = GET16(tom_ram_8, HBB);
-// uint16 hbe = GET16(tom_ram_8, HBE);
-
- int clock_cycles_per_pixel = (vmode & PWIDTH) >> 9;
-
- uint32 width = 640;
- switch (clock_cycles_per_pixel)
- {
- case 0: width = 640; break;
- case 1: width = 640; break;
- case 2: width = 448; break;
- case 3: width = 320; break;
- case 4: width = 256; break;
- case 5: width = 256; break;
- case 6: width = 256; break;
- case 7: width = 320; break;
-// default: WriteLog("%i \n",clock_cycles_per_pixel);
- }
-
-/* if (jaguar_mainRom_crc32 == 0x3c7bfda8) // Kludge for what???
- {
- if (width == 320)
- width += 80;
- if (width == 448)
- width -= 16;
- }//*/
-
- if (hdb1 == 123)
- hblankWidthInPixels = 16;
- else
- hblankWidthInPixels = 0;
-
-// WriteLog("hdb1=%i hbe=%i\n",hdb1,hbe);
- return width;
+ //These widths are pretty bogus. Should use HDB1/2 & HDE/HBB & PWIDTH to calc the width...
+// uint32 width[8] = { 1330, 665, 443, 332, 266, 222, 190, 166 };
+//Temporary, for testing Doom...
+// uint32 width[8] = { 1330, 665, 443, 332, 266, 222, 190, 332 };
+
+ // Note that the following PWIDTH values have the following pixel aspect ratios:
+ // PWIDTH = 1 -> 0.25:1 (1:4) pixels (X:Y ratio)
+ // PWIDTH = 2 -> 0.50:1 (1:2) pixels
+ // PWIDTH = 3 -> 0.75:1 (3:4) pixels
+ // PWIDTH = 4 -> 1.00:1 (1:1) pixels
+ // PWIDTH = 5 -> 1.25:1 (5:4) pixels
+ // PWIDTH = 6 -> 1.50:1 (3:2) pixels
+ // PWIDTH = 7 -> 1.75:1 (7:4) pixels
+ // PWIDTH = 8 -> 2.00:1 (2:1) pixels
+
+ // Also note that the JTRM says that PWIDTH of 4 gives pixels that are "about" square--
+ // this implies that the other modes have pixels that are *not* square!
+ // Also, I seriously doubt that you will see any games that use PWIDTH = 1!
+
+ // NOTE: Even though the PWIDTH value is + 1, here we're using a zero-based index and
+ // so we don't bother to add one...
+// return width[(GET16(tom_ram_8, VMODE) & PWIDTH) >> 9];
+
+ // Now, we just calculate it...
+ uint16 hdb1 = GET16(tom_ram_8, HDB1), hde = GET16(tom_ram_8, HDE),
+ hbb = GET16(tom_ram_8, HBB), pwidth = ((GET16(tom_ram_8, VMODE) & PWIDTH) >> 9) + 1;
+// return ((hbb < hde ? hbb : hde) - hdb1) / pwidth;
+//Temporary, for testing Doom...
+ return ((hbb < hde ? hbb : hde) - hdb1) / (pwidth = 8 ? 4 : pwidth);
+
+// More speculating...
+// According to the JTRM, the number of potential pixels across is given by the
+// Horizontal Period (HP - in NTSC this is 845). The Horizontal Count counts from
+// zero to this value twice per scanline (the high bit is set on the second count).
+// HBE and HBB define the absolute "black" limits of the screen, while HDB1/2 and
+// HDE determine the extent of the OP "on" time. I.e., when the OP is turned on by
+// HDB1, it starts fetching the line from position 0 in LBUF.
+
+// The trick, it would seem, is to figure out how long the typical visible scanline
+// of a TV is in HP ticks and limit the visible area to that (divided by PWIDTH, of
+// course). Using that length, we can establish an "absolute left display limit" with
+// which to measure HBB & HDB1/2 against when rendering LBUF (i.e., if HDB1 is 20 ticks
+// to the right of the ALDL and PWIDTH is 4, then start writing the LBUF starting at
+// backbuffer + 5 pixels).