Blitter and 68000

[WAVE 1 GAMES]

To the OP. Try testing whatever you are trying to run in the Phoenix emulator. I have had much more success using it vs Virtual Jaguar. It runs a little smoother than VJ and has a slightly better compatibility rate.

It is Russian but there are language patches available for it.

If you use this one and find the same bugs you saw with VJ than its probably not an emulation error and does have something to do with your code.

[jguff]

 

Writing to the blitter with the 68K is certainly possible and I and others have used that technique successfully. I would encourage you to get hold of the JTRM done by John Mathieson and read the section on the blitter, as the blitter is a very complex piece of hardware that most of the time will not do what you expect of it if you don't understand all the bits that go with it. If you can't find a copy, let me know and I'll post it here.

 

Which version of VJ are you using? Writing to B_CMD should not cause VJ to be unresponsive and if it is, that's a bug in VJ and not the Jaguar hardware. Have you tried the "Fast Blitter" option, to see if that works any better for you? Have you tried running it in Alpine mode to see what's happening with the emulated hardware?

 

Shamus,

 

Today I located Jaguar Technical Reference Manual Revision 8, dated 28 February, 2001. Past week i had been using one dated 1995. 15-20 years ago i used one purchased from B&C Computervisions.

 

Revision 8 has more information that i had ever prior seen (ie: pin descriptions).

 

Revision 8 also had this little tidbit, which i was unaware of:

The blitter pointer registers, which are written at addresses F0220C and F02230, appear for read at F02204 and F0222C. This error was also present on version 1 silicon.

Workaround:Read them at the incorrect addresses.

 

That presumably explains why Virtual Jaguar's, running in Alpine mode, Dissasembly Browser showed nothing written to F02204, when i wrote value1 to A1_FLAGs, but would show value2 at F02204 and F0220C when i wrote value2 to A1_PIXEL.

 

Will have to look at FLAGS and B_CMD register flags later and possibly older versions of Virtual Jaguar, to see why the blits are failing.

 

Bob

 

[jguff]

Have successfully blitted horizontal line. Thanks all,

 

Bob

[Zerosquare]

Today I located Jaguar Technical Reference Manual Revision 8, dated 28 February, 2001. Past week i had been using one dated 1995.

The one released in 2001 is useful because it's searchable, but it's not actually the most recent version. The latest I know of is dated June 7, 1995 (03 - Software Reference.pdf):

http://www.jagware.org/jag_uploads/dev/docs.zip

Edited November 17, 2017 by Zerosquare

[swapd0]

This is my code to clear the screen (8 bits bitmap) for the ST-NICCC.

 

Yesterday it didn't work, even today when I tried some hours ago, but after coding a bit in Classic Kong I've tried again and it works... WTF!?!? It looks that it doesn't work from a cold start, but I don't see if I'm missing something. If I turn the Jaguar off and turn it on again it doesn't work...

void clear_screen_blitter8(void)
{
#if LOG
	skunk_print("Clear screeen blitter 8 bits\n");
#endif

	wait_blitter();
	*A2_BASE = (uint32_t)current_frame;
	*A2_PIXEL = 0;//(1 << 16) | 0;
	*A2_STEP = (1 << 16) | (0xffff & -256);
	*A2_FLAGS = PIXEL32|XADDPHR|PITCH1|WID64;
	*B_PATD = 0;
	*(B_PATD + 1) = 0;
	*B_COUNT = ((_SCREEN_HEIGHT) << 16) | 64;
	*B_CMD = DSTA2 | PATDSEL;
}

[LinkoVitch]

Have you tried setting all the registers to 0 before attempting to configure the blitter? Might just need a tidy up before 1st use. Could have some random values in there from the power cycle

[swapd0]

Now it works.

 

I though that the unused registers in an operation won't affect the result...

[LinkoVitch]

Like with electronics, don't leave unused inputs to "float" (with unknown values) or you risk undefined or unknown results. Always try and work from a known state.. especially on the Jag

[swapd0]

I'm trying to pre-shift a 2bits bitmap with the blitter. The source bitmap it's 64x64 pixels, the destination it's 256x1024, it looks ok but some shifted values look wrong, with some columns in the wrong order. Any idea what I'm doing wrong? By the way, it's possible to read in phrase mode and write also in phrase mode but with the data shifted one pixel? I doubt.

 

Here it's the code.

 

    int16_t x, y;
    y = 0;
    for ( int16_t i = 0; i < 16; ++i )
    {
        x = 0;
        for ( int16_t j = 0; j < 4; ++j )
        {
            *A2_BASE = (uint32_t)src->data;
            *A2_FLAGS = PIXEL2|XADDPIX|WID64|PITCH1;
            *A2_PIXEL = 0;

            *A1_BASE = (uint32_t)dst->data;
            *A1_FLAGS = PIXEL2|XADDPIX|WID256|PITCH1;
            *A1_PIXEL = (y << 16) | x + i;
            *A1_STEP = 1 << 16 | (-64 & 0xffff);

            *B_COUNT = (64 << 16) | 64;
            *B_CMD = LFU_S|SRCEN|DSTEN|UPDA1;
            x += 64;
        }
        y += 64;
    }

 

Edited May 22, 2020 by swapd0

[Sporadic]

2 hours ago, swapd0 said:

I'm trying to pre-shift a 2bits bitmap with the blitter. The source bitmap it's 64x64 pixels, the destination it's 256x1024, it looks ok but some shifted values look wrong, with some columns in the wrong order. Any idea what I'm doing wrong? By the way, it's possible to read in phrase mode and write also in phrase mode but with the data shifted one pixel? I doubt.

 

Here it's the code.

 

    int16_t x, y;
    y = 0;
    for ( int16_t i = 0; i < 16; ++i )
    {
        x = 0;
        for ( int16_t j = 0; j < 4; ++j )
        {
            *A2_BASE = (uint32_t)src->data;
            *A2_FLAGS = PIXEL2|XADDPIX|WID64|PITCH1;
            *A2_PIXEL = 0;

            *A1_BASE = (uint32_t)dst->data;
            *A1_FLAGS = PIXEL2|XADDPIX|WID256|PITCH1;
            *A1_PIXEL = (y << 16) | x + i;
            *A1_STEP = 1 << 16 | (-64 & 0xffff);

            *B_COUNT = (64 << 16) | 64;
            *B_CMD = LFU_S|SRCEN|DSTEN|UPDA1;
            x += 64;
        }
        y += 64;
    }

 

You aren't waiting on the blitter in the loop - could it be corrupting/overwriting itself before it's finished?

 

It's hard to see exactly what's happened from the screenshot, are you able to post anything clearer?

Edited May 22, 2020 by Sporadic

[Sporadic]

I'm possibly not following what you are trying to accomplish, but do you need the + i ? 

 

*A1_PIXEL = (y << 16) | x + i;

[swapd0]

Sorry but it doesn't run in the emulator, but if you look at the lower part of the blue square you can see some vertical lines, that lines should be drawn about 8 pixels to the left. It's like instead of writing 0123456789 it writes 1234567890. 

Edited May 22, 2020 by swapd0

[swapd0]

29 minutes ago, Sporadic said:

I'm possibly not following what you are trying to accomplish, but do you need the + i ? 

 

*A1_PIXEL = (y << 16) | x + i;

it draws the bitmap at position 0, 64, 128 192, on the second iteration (I == 1) the bitmap will be drawn at 1, 65, 129, 193.. and so on.

 

I need to create a "matrix" 4x16 (256x1024 pixels) with the 64x64 bitmap, on each row the bitmap must be shifted one pixel to the right.

 

Edited May 22, 2020 by swapd0

[swapd0]

27 minutes ago, Sporadic said:

You aren't waiting on the blitter in the loop - could it be corrupting/overwriting itself before it's finished?

 

I never wait for the blittter because the code it's running into the 68000, and it has the lowest bus priority. I've used the blitter on several projects, never waited for it and they work.

[Sporadic]

13 minutes ago, swapd0 said:

it draws the bitmap at position 0, 64, 128 192, on the second iteration (I == 1) the bitmap will be drawn at 1, 65, 129, 193.. and so on.

 

I need to create a "matrix" 16x4 (256x1024 pixels) with the 64x64 bitmap, on each row the bitmap must be shifted one pixel to the right.

 

Sorry, I'm still not following why you need to shift it 1 pixel right per row. Why not have it 0,64,128,192 on every row? That'll create a grid.

 

By shifting right 1 pixel per row, the final iteration will draw between X = (192+15) and (192+15+64) - that'll overflow at the end of the destination bitmap.

[swapd0]

Yes, I know that I've a bit of overflow but I'll fix that later.

 

It's weird because I have the glitch on some positions, 0 it's ok, 1 wrong, 2 ok.

[+CyranoJ]

I don't understand why you are pre-shifting.  I'm guessing its for a h-scroll effect.

 

Pad the bitmap out wider, use g-width, adjust the x-position 15 times, then increment the base pointer.  There is no need for pre-shifting in most cases.

[swapd0]

You need pre-shifting if you are working with a 2bit per pixel bitmap and you want to do a distort.

Edited May 23, 2020 by swapd0

[+CyranoJ]

5 minutes ago, swapd0 said:

You need pre-shifting if you are working with a 2bit per pixel bitmap and you want to do a distort.

Use incrementing VIs, or a GPU interrupt, and change the object's X-Pos.

[swapd0]

Can't use the OP, I am doing alpha blending into the GPU with a 2bits bitmap and a 16bits bitmap, the idea of using a 2bits bitmap it's to save bandwidth on each memory access I got 16pixels. The OP RMW it's almost useless, at least in RGB mode.

[+CyranoJ]

4 minutes ago, swapd0 said:

Can't use the OP, I am doing alpha blending into the GPU with a 2bits bitmap and a 16bits bitmap, the idea of using a 2bits bitmap it's to save bandwidth on each memory access I got 16pixels. The OP RMW it's almost useless, at least in RGB mode.

Ah ok

 

RMW slows everything down a lot. The backdrops in Rebooteroids are 2-bit because of RMW

[swapd0]

Yeah... some times I would like to take a time machine and go to Atari or Flare in 1991 and tell them to include a cache in TOM, write buffer in the blitter, rearrange the blittter registers, more transparency modes, put a real sound chip, etc...

[Zerosquare]

And Atari would tell you "nah, that's too expensive".

 

When you look at the documentation for the Jaguar II, I think the designers themselves were well aware of what needed to be improved, and would have probably done it in the original Jaguar if they could.

 

Edited May 23, 2020 by Zerosquare

[ggn]

If you are preshifting, I assume you won't be using the results in real time. Why not just write a software preshifter and roxr.w the hell out of your buffers? You would have been done by now instead of fighting over blitter bugs

[jguff]

What is the blue screenshot trying to display?  I don't see a repeating tile, shifted by one pixel, for each row of tiles, in the screenshot.  Is the screenshot produced after blending with the repeated tiles?

 

Also, not the issue, but should UPDA2 be or'd into B_CMD?

 

Bob