Getting started with the 32X

[Charles MacDonald]

I'm using DevSter's startup code which is the 2K block where 68000 execution starts at $800. I can control the Genesis VDP like normal, but I can't display anything on the 32X layer, or get the PEN/FEN bits to be '0' to indicate I can write to the framebuffer or palette.

I can write data to 780000+ without freezing ($800000+ freezes) so it seems the first frame buffer is mapped to the 68K side and the second one is being displayed. I made sure to set the 15-bit RGB direct mode as the default 32X display is blanked.

I don't suppose anyone can explain what registers need to be set up so I can see something?

[Chilly Willy]

The frame buffer is at 0x840000, and the overwrite area is 0x860000. You should be able to read/write those areas when the 32X is enabled and b15 at 0xA15100 is cleared. You need to be able to write the frame buffer at any time because until you write the line table at the start of the frame buffer, you will NEVER see anything (but maybe a little garbage).

The first 256 words of the frame buffer hold the offset (in words) to the start of the data for that particular line. The word at offset 0 holds the offset to the start of line 0, and so on. In 224 line mode, you need 224 offsets, and in 240 line mode, you need 240 offsets. The offsets can point to any word in the frame buffer allowing for many interesting effects, or just simple scrolling. You usually start with 0x100 as the first offset so that the frame buffer you draw to starts just after the line table. Then increment the offset by 160 for each line. That gives a plain bitmap you draw to. When you flip the frame buffer, the second frame also needs the line table written - each frame is independent of the other.

Once you have written the line table, you set the display mode by writing a word to 0xA15180. b7 = 1 sets the priority to the 32X graphics, b6 = 1 sets 240 line mode (PAL only), and b1-0 sets the mode: 00 = off, 01 = 256 color mode, 10 = direct color mode, and 11 = RLE mode. Note that the mode can be changed during the horizontal blank to change the mode of the screen from then on. HINTs can therefore be used to make more complex displays. For a simple 320x224 256 color bitmap with the MD having priority, just set the register to 0x0001.

The color palette is at 0xA15200 and can be written at any time, but if you write it during the active display, the CPU waits until it gets time... up to possibly one full scanline (~65 usec). You also don't need to worry about FEN - that's a DMA busy flag when you are using the VDP to fill the frame buffer line. If you don't use the fill function, you never have to check FEN. You only check it while waiting for the fill to finish.

I should also mention that when you change the frame buffer select bit, it doesn't actually change until the next vblank. To be sure the frame has actually flipped, read the bit back and wait for it to be the same value as you just set it to be. For example, if it's currently 0, set it to a 1, then read it back and loop until you read back 1.

[Charles MacDonald]

The color palette is at 0xA15200 and can be written at any time, but if you write it during the active display, the CPU waits until it gets time... up to possibly one full scanline (~65 usec).

I can write to $A1518A, but reading it freezes the system (I was trying to poll PEN). Reading or writing the palette at $A15200+ also freezes. I have verified the status bits FM=0, ADEN=1, and loaded up the line table, frame buffer, and set up $A15180 to $0001. Is there anything else I need to do?

Also at this point even with the line table set up and graphics data written to $840000+ I still can't see anything on the screen regardless of the display mode (I tried direct color and packed pixel).

[Chilly Willy]

Ah yes, forgot something else... you not only need the IP block mentioned in the other thread, you also need a valid MARS rom header at 0x3C0, which will tell the 32X where to find data to copy into SDRAM. Said data must contain an SH2 exception table for the Master and Slave SH2s as well as exception handling code and startup code, even if said code does nothing but loop.

Code: Select all

! Standard Mars Header at 0x3C0



        .ascii  "Yeti3D Demo     "              /* module name */

        .long   0x00000000                      /* version */

        .long   _etext-0x02000000               /* Source (in ROM) */

        .long   0x00000000                      /* Destination (in SDRAM) */

        .long   _sdata                          /* Size */

        .long   0x06000240                      /* Master SH2 Jump */

        .long   0x06000244                      /* Slave SH2 Jump */

        .long   0x06000000                      /* Master SH2 VBR */

        .long   0x06000120                      /* Slave SH2 VBR */

For everything, you could probably look at my yeti3d port:
Yeti3D-20100730.zip

For testing from the MD side, it might be easier to simply shut down the SH2s. Enable the 32X and assert the reset. Set the RV bit: set b0 of the word in 0xA15106. Then deassert the SH2 reset. The first time either SH2 tries to access the rom, they will halt until the RV bit is cleared. So the SH2s will be in effect halted while the 68000 is free to mess with the rest of the 32X hardware. This will also keep the MD mapping in place in the rom space. You should probably put the code to do this in ram.

RV was made so that the MD VDP could DMA like normal, but I think that this should give us free reign on the 32X without needing all the other junk... you just don't get the SH2s.

[TmEE co.(TM)]

That demo of yours is very impressive

[Chilly Willy]

That demo of yours is very impressive

You should see it set for a 144x72 frame - get a nice smooth 15 FPS with no optimizations. I'm making an update using the Yeti3D Pro version of the code, and adding the ability to change the display to do half the res horz or vert. That should be really nifty.

You change the viewport size in viewport.h.

Code: Select all

// 144x72 display

#define YETI_VIEWPORT_X1 88

#define YETI_VIEWPORT_Y1 64

#define YETI_VIEWPORT_X2 232

#define YETI_VIEWPORT_Y2 136

That just draws it smaller in a centered position. What I really need is to make it store a long per pixel and double the lines using the line table for a full size display.