Chilly Willy

There you go.

But the moon landing WAS fake! It was CG generated at Area 51 on alien computers that all modern computers are (poorly) derived from!

Once in the vblank is fine. I wonder if that could be useful for something... use vdelay to hide half the lines...

All Y motion is done by actually moving the data for the players/missiles. The vdelay is to allow single line movement when using two-line resolution players/missiles. Set vdelay for one line, then move the data one line and reset vdelay, then set vdelay, then move the data one line and reset vdelay, etc. When in one-line resolution, you just always move the data one line.

Besides the educational value, it does indeed have real value for those of us still working on old consoles. For example, this would be awesome for Saturn homebrew as the hardware acceleration is of warped quads. The SH2 seems like a good target given the small tidbits tossed out in the thread at AF. You have a fast multiplier, and multiply and accumulate operations. You also have two SH2s, allowing some work to be offloaded - kinda like the DSP in the Falcon.

About 10 years. Yes, it's not like they keep a "stock" of old computers, it's just what's been donated that hasn't been sold or thrown away yet. The store I visited in Havasu was in the process of throwing out all the 8-bit computers and everything below a Pentium as far as PCs were concerned. So I also got an Apple IIc+ with 5.25" external drive and a 3.5" external drive and a B&W monitor and a color monitor for $10 total. I got a C64 for free. I got an SX-64 "portable" C64 for $5. I really should have picked up a IIgs, but wasn't much interested at the time. The most commonly donated computer will be systems that are almost worthless at the time of donation, but the person still spent a lot on. At the time, that was Pentium systems. They would clean them up, reinstall Windows 95 on them, pair them with a 15" VGA monitor, and sell them for $50. These days, it's probably P3 and K7 systems, along with any kind of CRT monitor.

I read through the thread over at A.F. - you are doing some awesome things. I was wondering if perhaps you could write up a little article on a modern approach to a software renderer... like that old Dr. Dobbs series Chris Hecker did so long ago showing the proper way to do an affine mapper, but now updated to pseudo-perspective correct. A whole new generation could use tips from the pro in a sadly neglected area of graphics.

The one in particular I was mentioning was in Lake Havasu City, Arizona. It was also a number of years ago... don't know if they have any left now.

http://www.svdpusa.net/find/find.thriftstoredt.php It's a US thing as far as I know. Won't help some folks... Goodwill is probably better for old consoles and computers than Salvation Army. I pick up keyboards and shit sometimes at Goodwill. What you'll find will vary wildly from one place to another, so all I can suggest is check and cross your fingers.

It's fine in the US, too. Just a minor outage... all sites have them now and then, some more than others.

Yeah, that was my main concern about blitter acceleration - the size of the blocks. Maybe for 8x8 blocks, but not smaller. I was going to get it going with just the GPU to start, then experiment with the blitter. Of course, the GPU has some provisions for moving phrases at a time. I'll have to see if that can be applied here as well. One issue about using 16-bit pixel (CRY or RGB565) is that motion compensated blocks can be on any word boundary, which on many processors means you have to move by words to avoid alignment restrictions. I used 32 bit RGB on the N64, so all moves are longs. If I optimize the N64 more, I'll probably take advantage of the 64 bit registers for moving when the alignment is right for that. I need to go back through the Jaguar hardware manual and review all the various rules on alignment for the GPU.

I never ask anyone to buy me stuff, but I gladly accept donations. I have bought most of my consoles off ebay for cheap... except the Dreamcast BBA, which is the most expensive thing I have (even more than my PS3), and the Atari Jaguar. I'm saving towards buying a JagCD from B&C, but it'll be a while... maybe next spring. And performance issues is what makes a task fun! If it's easy, it's not nearly as fun.

I've ported quite a few things that nobody ever wound up using... and some things a lot of people use. You never really know ahead of time, so yes, it's better if you port things for yourself and/or fun, and then if someone else uses it, all the better. The main purpose behind porting ROQ is actually to make a "universal" format for old consoles. 32X, Saturn, Dreamcast, Jaguar, PS1, PS2, PSP, N64, NGC... I encode whatever into a ROQ avi and I can then play it on any of my old consoles. Don't know if I'll use for anything more than a video player, but you never know. I've got a bunch of videos like Hellsing Ultimate Abridged I've been watching on my N64. It's pretty cool to see this stuff on these old consoles. I've encoded some music videos that I can leave running while I do other things... my player handles video files just like audio files - it plays the whole directory (in order or shuffled). I start it playing episode 1 of a series and it just keeps on playing until I stop it or it runs out of files.

Maybe that didn't come through well, but there aren't ANY docs. What you have are examples in the older archives, and a few threads on the forum. Those are your "docs".

I'm not COMPLETELY reinventing the wheel, I'm just trying to make it a little nicer which HOPEFULLY entices some folks into using it. We have a very recent thread in this forum from someone having real problems getting the current cinepak playing to work. Part of that was problems in even making a compliant video file. I already showed working C code for ROQ, and it's damn simple. Making a GPU assembly version, which might not even be needed, is straight-forward to anyone who has done any assembly. As for streaming CD code, yes, that is a difficult part of the task, but maybe that part I can reuse directly (provided non-conflicting licenses on the different code libraries). You did an excellent job on making alterations to the existing player code to allow ADPCM while still keeping the original cinepak decoder. I basically just want to make the video part a bit better just as you wanted to make the audio part a bit better. If we keep making little parts a little better, the whole becomes better and easier for folks. And yes, I've not written anything for the Jaguar before. I've only written stuff for the SNES, SMS, Genesis, Sega CD, 32X, Saturn, Dreamcast, N64, GameCube, PSX, PS2, PS3, PSP, Amiga, Mac (68K and PPC), PC (from 286 to modern), Atari 8-bit... yeah, I'll NEVER be able to make something for the Jaguar. My main limitation is available time for all the tasks I set myself. If anything, I try to do too much. Some things wind up on the back burner while I work on something else that has caught my fancy. Right, that something else that caught my fancy is ROQ video.

If you have a charitable organization in your town like St Vincent DePauls (Catholic version of Salvation Army), they often have donated computer equipment at ridiculously low prices. The last one I visited had Pentium PCs with a 15" monitor for $50. I got a complete Apple IIc+ with extra drive, two monitors (color & B&W), and some games for $10! They had an entire wall of Apple IIgs systems for $5 each.

I don't care if no ever uses it, I just want something other than the binary blob cinepak driver for folks. It's also something "fun" to work on. Also, the hoops you have to jump through to get a stream you can use with the binary blob driver is probably WHY no one uses your cinepak tools. It's a pain. I want a player that takes a plain avi with regular cinepak/roq. No conversions needed. Which answers TXG above - I COULD make a tool that goes through the ROQ stream converting YUV to CRY before hand, and it would make playback faster; however, it's one more thing that encourages people not to try it at all. We want support for PLAIN streams with no jumping through hoops.

Your setting the flags early doesn't crash because the int doesn't occur until much later. If other ints could occur, it could fail. What I think might be the problem with the correct order is this (from the doc):

Remember that decoding the frame IS just moving data. The GPU has a much better bus than the DSP. You could feed the compressed audio to the DSP for decompressing to take a little pressure off the GPU, but you really want the GPU (or GPU+BLITTER) handling the video. The code I posted above for decoding the frame moves 32-bit RGBA entries from the codebooks. You'll halve the bandwidth by using CRY mode instead. That was why I posted about converting RGB to CRY when decoding the codebooks. If that takes too long, maybe going with 16-bit RGB would be better. My point was you only need to convert the codebook entries to CRY, not every single pixel.

Actually, the code I posted is for each entry of the 2x2 codebook, making it a max of 1024 times per frame. Actually unpacking the frame is like this: static int roq_unpack_vq(unsigned char *buf, int size, unsigned int arg, quit_callback quit_cb) { int status = ROQ_SUCCESS; int mb_x, mb_y; int block; /* 8x8 blocks */ int subblock; /* 4x4 blocks */ int i; /* frame and pixel management */ unsigned int *this_frame; unsigned int *last_frame; int line_offset; int mb_offset; int block_offset; int subblock_offset; unsigned int *this_ptr; unsigned int *last_ptr; unsigned int *vector; /* bytestream management */ int index = 0; int mode_set = 0; int mode, mode_lo, mode_hi; int mode_count = 0; /* vectors */ int mx, my; int motion_x, motion_y; unsigned char data_byte; if (dc) { sync_audio(); display_show(dc); } while (!(dc = display_lock())); current_frame = (int)dc - 1; if (current_frame == 0) { this_frame = frame[0]; last_frame = frame[1]; } else { this_frame = frame[1]; last_frame = frame[0]; } mx = (arg >> & 0xFF; my = arg & 0xFF; for (mb_y = 0; mb_y < mb_height && status == ROQ_SUCCESS; mb_y++) { line_offset = mb_y * 16 * stride; for (mb_x = 0; mb_x < mb_width && status == ROQ_SUCCESS; mb_x++) { mb_offset = line_offset + mb_x * 16; /* macro blocks are 16x16 and are subdivided into four 8x8 blocks */ for (block = 0; block < 4 && status == ROQ_SUCCESS; block++) { block_offset = mb_offset + (block / 2 * 8 * stride) + (block % 2 * ; /* each 8x8 block gets a mode */ GET_MODE(); switch (mode) { case 0: /* MOT: skip */ break; case 1: /* FCC: motion compensation */ GET_BYTE(data_byte); motion_x = 8 - (data_byte >> 4) - mx; motion_y = 8 - (data_byte & 0xF) - my; last_ptr = last_frame + block_offset + (motion_y * stride) + motion_x; this_ptr = this_frame + block_offset; for (i = 0; i < 8; i++) { *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; last_ptr += stride - 8; this_ptr += stride - 8; } break; case 2: /* SLD: upsample 4x4 vector */ GET_BYTE(data_byte); vector = cb4x4[data_byte]; for (i = 0; i < 4*4; i++) { this_ptr = this_frame + block_offset + (i / 4 * 2 * stride) + (i % 4 * 2); this_ptr[0] = *vector; this_ptr[1] = *vector; this_ptr[stride+0] = *vector; this_ptr[stride+1] = *vector; vector++; } break; case 3: /* CCC: subdivide into four 4x4 subblocks */ for (subblock = 0; subblock < 4; subblock++) { subblock_offset = block_offset + (subblock / 2 * 4 * stride) + (subblock % 2 * 4); GET_MODE(); switch (mode) { case 0: /* MOT: skip */ break; case 1: /* FCC: motion compensation */ GET_BYTE(data_byte); motion_x = 8 - (data_byte >> 4) - mx; motion_y = 8 - (data_byte & 0xF) - my; last_ptr = last_frame + subblock_offset + (motion_y * stride) + motion_x; this_ptr = this_frame + subblock_offset; for (i = 0; i < 4; i++) { *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; *this_ptr++ = *last_ptr++; last_ptr += stride - 4; this_ptr += stride - 4; } break; case 2: /* SLD: use 4x4 vector from codebook */ GET_BYTE(data_byte); vector = cb4x4[data_byte]; this_ptr = this_frame + subblock_offset; for (i = 0; i < 4; i++) { *this_ptr++ = *vector++; *this_ptr++ = *vector++; *this_ptr++ = *vector++; *this_ptr++ = *vector++; this_ptr += stride - 4; } break; case 3: /* CCC: subdivide into four 2x2 subblocks */ GET_BYTE(data_byte); vector = cb2x2[data_byte]; this_ptr = this_frame + subblock_offset; this_ptr[0] = vector[0]; this_ptr[1] = vector[1]; this_ptr[stride+0] = vector[2]; this_ptr[stride+1] = vector[3]; GET_BYTE(data_byte); vector = cb2x2[data_byte]; this_ptr[2] = vector[0]; this_ptr[3] = vector[1]; this_ptr[stride+2] = vector[2]; this_ptr[stride+3] = vector[3]; this_ptr += stride * 2; GET_BYTE(data_byte); vector = cb2x2[data_byte]; this_ptr[0] = vector[0]; this_ptr[1] = vector[1]; this_ptr[stride+0] = vector[2]; this_ptr[stride+1] = vector[3]; GET_BYTE(data_byte); vector = cb2x2[data_byte]; this_ptr[2] = vector[0]; this_ptr[3] = vector[1]; this_ptr[stride+2] = vector[2]; this_ptr[stride+3] = vector[3]; break; } } break; } } } } /* if client program defined a quit callback, check if it's time to quit */ if (quit_cb && quit_cb()) return ROQ_USER_INTERRUPT; /* sanity check to see if the stream was fully consumed */ if (status == ROQ_SUCCESS && index < size-2) { status = ROQ_BAD_VQ_STREAM; } return status; } Notice that it's merely a bunch of moves. Should be pretty easy to convert to assembly and maybe use the blitter... if it's needed. I'll try it without the blitter to start and see what I can get away with.

After I posted, I wondered if you meant buy an X68000, and THEN add $500 to your budget for buying games (which all go for $100 to $300 each on ebay). I'd love to have an X68000 - they look super-cool and have great stats for when it was made, but they're just too damn expensive!

ROQ is YUV, so it can easily do 24-bit color. My N64 player runs in 32-bit output. The code book conversion looks like this: /* unpack the YUV components from the bytestream */ for (j = 0; j < 4; j++) y[j] = *buf++; u = *buf++; v = *buf++; u -= 128; v -= 128; /* CCIR 601 conversion */ u1 = (88 * u) >> 8; u2 = (453 * u) >> 8; v1 = (359 * v) >> 8; v2 = (183 * v) >> 8; /* convert to RGBA8888 */ for (j = 0; j < 4; j++) { /* CCIR 601 conversion */ r = y[j] + v1; g = y[j] - v2 - u1; b = y[j] + u2; if (r < 0) r = 0; else if (r > 255) r = 255; if (g < 0) g = 0; else if (g > 255) g = 255; if (b < 0) b = 0; else if (b > 255) b = 255; At that point, you can make the codebook entry 24 bit RGB, 16 bit RGB, 15 bit RGB, 16 bit CRY... RGB to CRY conversion is pretty fast: uint16_t rgb2cry(int32_t r, int32_t g, int32_t b) { uint16_t intensity; uint16_t color_index; intensity = r; /* start with red */ if(green > intensity) intensity = g; if(blue > intensity) intensity = b; /* get highest RGB value */ if(intensity != 0) { r = (uint32_t)r * 255 / intensity; g = (uint32_t)g * 255 / intensity; b = (uint32_t)b * 255 / intensity; } else r = g = b = 0; /* R, G, B, were all 0 (black) */ color_index = (r & 0xF8) << 7; color_index += (g & 0xF8) << 2; color_index += (b & 0xF8) >> 3; return (uint16_t)(((uint16_t)cry[color_index] << | (uint8_t)intensity); } We've already got R, G, and B as 8-bit ints, so then converting to CRY is simple. I'll probably replace that 255 / intensity calculation with a table lookup... use a small fixed point number so that you get a multiply and a shift instead of the divide.

All Atari code restores the flags AFTER the jump. In fact, it (correctly) points out that if you enable ints any other place but after the jump, another int can occur and corrupt the registers (in particular, r30 - the register you're getting ready to jump through), leading to a crash. For example, here's the int exit code for the Jerry CD audio: clean_up: ; do the housekeeping, per Leonard bclr #3,r29 ; clear IMASK bset #10,r29 ; set I2S interrupt clear bit load (r31),r28 ; get last instruction address addq #2,r28 ; point at next to be executed addq #4,r31 ; update the stack pointer jump (r28) ; and return store r29,(r30) ; restore flags Something else must be causing the crash, not the restore after jump.

Yes. The blitter has two pointers used as a source and destination for blit operations: A1 and A2. You can switch which is the source and which is the destination, depending on whether you're "just blitting" or if you're trying to do affine mapping. Note, the Jaguar has no rasterizing hardware - you use the GPU to do that, while the blitter draws the rasterized line in affine mode.

No problem. Like theloon said, the forum can be a little slow, and the program is kinda spread over a number of releases, so some folk need a little help getting going. There's no real docs on it, but the old release has examples. So don't skip downloading the old arcs or you'll miss the examples, which are about all the documentation you'll find. Also read threads where people ask about issues - you'll find good info in those threads. It could really do with a nice wiki page, though. That's one of the best things about Batari Basic - it has a REALLY great doc wiki.