Jump to content
Jagware

Zerosquare

Administrators
 View Profile  See their activity

  • Content count

    2,138

  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Zerosquare

  4. Posted · Report reply

    If you've ever looked at the netlists files for Tom and Jerry, you certainly noticed that they reference Toshiba ASIC cells for which there is no documentation, or even description.

     

    Fortunately, Torlus did find the documentation for the cells in a later, but seemingly similar, series of ASICs :

    http://www.engr.sjsu.edu/mjones/260c_pri_e.pdf

    Many thanks to him.

     

    It should make the netlists a little less cryptic :) (although it won't help with the bowl-of-spaghetti coding style :D)

  5. Posted · Report reply

    I think there's a possible read/write race collision too : when the OP starts rendering a line, it reads the value of this register, so if it happens while you're updating it, the OP can try to process an object list at a wrong address. Additionally, the documentation instructs you to set VDE to $FFFF so that the OP is always enabled, even outside the visible display area (that's why the two conditional branches at the start of the object list are needed).

     

    Nevertheless, the problem doesn't seem to happen in practice (if you access OLP at the start of the VBL, the timing is pretty much fixed anyways).

  8. Posted · Report reply

    Regarding the risk of writing the OPL from the 68k... I found the OP could lock up in some bad address cases, but I never had it happen just writing from the 68k, so I'm not sure if it only happens if it's allowed to scribble through memory for a longer time or if it's just really, really rare. ;)

    I just found something today while rereading the docs :

    Because the Object Processor could interrupt the 68000 in the middle of a write to this register, the 68000 should never be used to change OLP. Use the GPU instead.

    This part is in bold, and only appears in the scanned copy Tyrant uploaded some years ago, not in the "Technical Reference Revision 8" PDF file that was released by John Matthieson in 2001.

  10. Posted · Report reply

    Just did a quick test, and here's something that seems to match the original gradient:

    DEFDBL A-Z

R1 = 0: G1 = 39: B1 = 15
R2 = 0: G2 = 9: B2 = 1

FOR I = 0 TO 14
    R = FIX(R1 + (((R2 - R1) * I) / 14))
    G = FIX(G1 + (((G2 - G1) * I) / 14))
    B = FIX(B1 + (((B2 - B1) * I) / 14))
NEXT I

     

    And here are the RGB values it generates:

    0             39            15
0             36            14
0             34            13
0             32            12
0             30            11
0             28            10
0             26            9
0             24            8
0             21            7
0             19            6
0             17            5
0             15            4
0             13            3
0             11            2
0             9             1

     

    I don't have GFA32, so I tested it with gool old QBASIC. Note that FIX(x) always rounds down, not to the nearest integer (I tried adding .5 to round to the nearest integer, but it no longer matches the original gradient, though it's probably more accurate that way).

     

    EDIT: oops, looks like what I thought was the original gradient is actually your version. Back to square one then...

     

    EDIT 2 : If you look at the differences between successive colors, there's something strange in the original palette:

    0    -2    -1
0    -4    -2
0    -2    -1
0    -2    -2
0    -2    -1
0    -2    -1
0    -2    -1
0    -2    -1
0    -2    -1
0    -2    -1
0    -2    -1
0    -2    0
0    -2    -1
0    -2    0

    * the green channel uses -4 and -2, but not -3

     

    * the blue channel uses more than two values (-2, -1, 0) and it doesn't look like there's a recurring pattern

    IIRC that can't happen if the interpolation is linear, even with rounding. So either they were doing some really strange rounding, or they didn't use a linear interpolation (maybe it's gamma-corrected or picked manually?)

     

    Is it important to match the original palette exactly?

  11. Posted · Report reply

    There's something I don't understand with your code...

     

    The gradient list is 15 entries long, but your code seems to generate 16 (1 + 14 + 1) entries : 

     'write beginning gradient
...
For l = 1 To 14 
...
Next l
...
'write final gradient (15)

     

    If there are indeed 15 entries, then it needs a few patches :

    stepr = (r4 - r1) / 14 : stepg = (g4 - g1) / 14 : stepb = (b4 - b1) / 14
...
For l = 1 To 13

  15. Posted · Report reply

    Regarding the risk of writing the OPL from the 68k... I found the OP could lock up in some bad address cases, but I never had it happen just writing from the 68k, so I'm not sure if it only happens if it's allowed to scribble through memory for a longer time or if it's just really, really rare. ;)
    I suspect it can fail if the OP accesses the OPL register just between the two 16-bit parts of the 68k's 32-bit write access. That's the only reason I can think of that would explain why Atari's code example uses the GPU (which will write the 32 bits in a single bus cycle) to set OPL, while everything else is done with the 68k.

     

    Anyways, if it happens, it must be pretty rare. Or maybe the bus arbitration logic don't allow splitting 68k 32-bit accesses at all, and they were just paranoid. Who knows :D

  17. Posted · Report reply

    If I understand the Jaguar schematic correctly, solutions 1, 2 and 3 won't work as expected, because the reset chain is like this (arrows connect outputs to inputs, signals are not bidirectional) :

    +-------------+    +-------+      +-----+
|  Power-on   |    |       |      |     |
| reset pulse |--->| Jerry |--+-->| Tom |
|  generator  |    |       |  |   |     |
+-------------+    +-------+  |   +-----+
                              |    
                              |   +-----+
                              |   |     |
                              +-->| 68k |
                                  |     |
                                  +-----+

    So solutions 1 and 2 should only restart the 68k itself, and solution 3 should have no effect at all.

     

    As for solution 4... anything can happen :lol:

  18. Posted · Report reply

    SCPCD : remember, you're supposed not to stop the GPU and the DSP from 68k code, but only from GPU/DSP code :P

    Same thing for the object list pointer, I'm not sure it's safe to write it outside of the VBL (or even from 68k code at all, even if we all do this ;))

  19. Posted · Report reply

    Lazy guy :D

     

    I don't think there's a way to do a true hardware reset through software. It wouldn't look very good anyways, because it would rerun the whole boot sequence (logos and delays included).

     

    So I'll think you'll have to write your own "reset" code B)

  21. Posted · Report reply

    It looks like the download doesn't complete properly in some conditions (seems to happen with Firefox, but not Opera).

     

    Before burning, check the file size : it should be 269,056,893 bytes exactly.

    If it isn't, try downloading the file again using a different browser.

     

    Sorry, I've got no idea why this happens... <_<

×