Luigi301

It works! I've got a tilemapped background layer. (The sprite rendering and background rendering programs collide if there are too many sprites on screen but I can fix that another time.)

I don't know who maintains jaglib but I found an annoying bug - jag_gpu_load/jag_dsp_load apparently can't deal with copies over 400 bytes. Any more than that and I get corruption starting at $F00000. I switched to memcpy and my GPU program loads perfectly.

I can start with .gif, yeah. What converts a gif to Atari format?

I use Grafx2 for pixel art. I want to convert a 16-luma 80x40 grayscale .bmp into a format (either assembly or raw binary) I can include in my assembly program. What utility would serve me best?

I'm using a disk image, unless there's a way to run the cart image on a U1MB. I think it's a 16KB cart and the slots are only 8KB. (Or someone's still selling reproduction MAC/65 carts.)

So reset the bitmap structures with the GPU when we hit the VBL rather than the 68k? Okay, I'll give that a try.

Hmm, okay. I think I understand... The object list needs to start with branch objects that branch to the correct row for this scanline. The last tile in the row branches to whatever is after the tilemap (in my case, a font layer bitmap). So the object processor is only processing the bitmaps that make up a specific row rather than everything. I seem to be having a problem resetting the objects' pixel data pointer and height on each frame though. I tried putting it in my VBlank interrupt but it doesn't seem to be fast enough. I set it to 16x5 identical tiles and it seems to be running out of time. I'll look at the Project One code and see if I can figure out what's going on. I'm just doing mobj_background.graphic->p0.height = 200; mobj_sprites.graphic->p0.height = 200; mobj_font.graphic->p0.height = 200; for(uint8_t i=0; i<BACKGROUND_TILES_WIDE*BACKGROUND_TILES_TALL; i++){ mobj_bg_tiles[i].graphic->p0.height = 16; mobj_bg_tiles[i].graphic->p0.data = (uint32_t)shipsheet >> 3; } during VBlank.

Im writing a vertical shooter and I want to set up a scrolling tilemapped playfield with the object processor. I have a 320x200 window with a 272x200 area I want to scroll, so 17x13 = 221 8bpp tiles on screen, plus a 1bpp text layer. Can the object processor handle that? I dont really know how much DMA time is available on a scanline.

There were the laserdisc-based retail kiosks. And some companies made 2600 demo kiosks that let you select cartridges on a timer.

As mentioned it could be the GTIA going bad since it reads the console switches. The bad part is in XEGS units theyre generally not socketed or it would be a quick and cheap eBay fix.

I ended up getting it compiling in an Ubuntu VM. I was able to link against protobuf there.

I've gone every year and I'll be there this year. Hopefully that guy with all the boxed Jag games for sale is there this year

Are you sure this isn't referring to the Atari Z800 (then Sweet 16, then 1000, then 1200)? The Z800 processor was targeted for 1985 and never released. It also refers to the 800 as the Personal Computer System which would place it much earlier than the mid-80s.

I'm working on a little project and I need to link RespeQt with protobuf. I'm running Windows 10 and using Qt Creator. I installed Qt 5.8.0. I installed MSYS2 32-bit and set it up with Qt's mingw mounted and using its GCC. I compiled the protobuf library from source and installed it to mingw's /lib directory. I added it to the project in Qt Creator: LIBS += -L"C:\Qt\Qt5.8.0\Tools\mingw530_32\lib" -lprotobuf INCLUDEPATH += "C:\Qt\Qt5.8.0\Tools\mingw530_32\include" But it doesn't seem to be linking it. I get a million undefined reference errors when I try to use any of the protobuf functions. What do I need to do to get it to link properly with the Qt mingw environment?

MAMEDEV has experience with dumping laserdiscs in a format suitable for archiving. Its complicated since they contain analog video and sound. Maybe you can get in contact with someone from MAME to help archive the ERIC disc.

I was able to get it installed using vias that connect to the ANTIC but I haven't been able to fit it into the case as of yet. Right now it works but the wires and ribbon cables stick out of (and block) the cartridge port. The case is just too damn small. I'm thinking I can remove the PBI cover, put some insulation on the PBI edge connector, and just have it be a wart on the back.

I flashed the SpartaDOS 4.49 beta onto my U1MB. I want to put MAC/65 onto my data disk. I know SpartaDOS and MAC/65 used to not play well together. Is this still the case where I need to boot from the MAC/65 disk image (with DOS 2.5) instead of the built-in SpartaDOS cart?

Oh, I can look into that, thanks. Either way, I managed to get it working. The problem was that the pointer in my actual node structure that makes up the display list wasn't long-aligned. Now I've got the real hardware display working again.

I bought it modded from someone in the Marketplace. I dont know the specifics of the mod. Im also not sure where Im going to mount the U1MB inside the case - the keyboard ribbon is in the way of the two screw holes next to the joystick ports.

Nope, that wasn't it. The problem is that VBCC only word-aligns heap variables and the GPU's load instructions want them to be long-aligned. And VBCC doesn't support the GCC aligned attribute. I know some C compilers will long-align longs (or structs that begin with longs) implicitly but I haven't been able to massage VBCC into doing that. I'd need a GCC version of libc for Jaguar to recompile it in GCC.

Yeah, it's a sync problem with the CPU and GPU both trying to bait at the same time.

I'm the proud owner of a 600XL with 64KB of RAM and I'm installing a U1MB in it. I want to solder the four signal wires from the U1MB board in a way that it's not permanent, so I want to poke wires through vias on the board. I checked the schematics and traced the four signals over to easily-accessible vias over by the ANTIC. The vias closest to the CPU are under ICs. Is it safe to hook the U1MB up in this way? This is my first big console mod other than doing something similar to repair a blown diode on an Amiga.

Hmm. Well, I've also managed to break my GPU program in such a way that it works in Virtual Jaguar but doesn't blit anything on real hardware, too. That's... annoying to debug.

That doesn't clarify much. I'm still not sure why it doesn't actually clip to the destination bitmap dimensions I put down. I'm getting better at GPU programming though, I ported the Amiga's linked list library over to the Jaguar and rewrote the 68K list traversal macros in GPU code so I can have the GPU process sprite display lists now. Yay?

What is the proper usage of the A1_CLIP register? I have a 320x200 pixel buffer that I'm blitting my sprites to so I set A1_CLIP to 320x200 and enabled the CLIP_A1 flag in B_CMD. Now for some reason the blitter is only drawing the first line of each sprite? If I don't set CLIP_A1, the sprites are drawn correctly. I don't see anything about that in the manual or on the jagdox blitter page. My B_CMD value is (SRCEN | DSTEN | UPDA1 | UPDA2 | CLIP_A1 | DCOMPEN | LFU_REPLACE).