Zerosquare

Added

For those that would like to enter the speed-coding contest, the rules are there : http://www.yaronet.com/posts.php?sl=&s=155018

Go ahead Thanks

Hi Matthias, No need for excuses, it wasn't aimed at anybody

It's just a company that prints Wikipedia pages. There are thousands of "books" like these that are printed on-demand.

I don't think anybody ever tried to modify the Doom serial code.

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 )

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).

Yes, I think we've been all guilty of this

Happy birthday

I just found something today while rereading the docs : 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.

Tursi has just announced that no new Skunkboards will be manufactured, and that the "official" support is going to be discontinued. But the good news is that he and Tursi kindly released the full sources, hardware design files and documentation to the public domain For more details, see here.

Not at the moment.

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?

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

Soon... oh wait, that's what I said last time already The technical details have been sorted out, so as soon as the money is collected, we're good to go with mass production of the first Jagtopus-based games. When this will happen is up to game developers to tell me

True enough

Bon courage pour les prochains mois

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

Merry christmas everybody

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

SCPCD : remember, you're supposed not to stop the GPU and the DSP from 68k code, but only from GPU/DSP code 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 )

Lazy guy 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

Do you still have the file you downloaded? What is its size?