Using 32x as a 3rd plane, possible?

Ask anything your want about the 32X Mushroom programming.

Moderator: BigEvilCorporation

Chilly Willy
Very interested
Posts: 2784
Joined: Fri Aug 17, 2007 9:33 pm

Re: Using 32x as a 3rd plane, possible?

Post by Chilly Willy » Wed May 01, 2019 3:10 pm

Ah, you're looking at the CD32X boot code. When there is no cart, the 32X BIOS waits for a special header to be copied into the frame buffer that gives it all the boot info it would have gotten from the rom. After the CD/MD sets the frame buffer, it flips it to the 32X side and sets COMM0 to _CD_ to tell the 32X to try the CD32X boot record, then looks for M_OK and S_OK. You might check out my CD32X MOD player code to see how CD32X is done.

Miquel
Very interested
Posts: 460
Joined: Sat Jul 30, 2016 12:33 am

Re: Using 32x as a 3rd plane, possible?

Post by Miquel » Thu May 02, 2019 5:27 am

Sorry, I haven’t explained myself properly. What I want is to use 32x hardware from the MD side only, optionally as a 3rd layer. Then what I need is to setup everything in that manner and shout down both SH2.

Right now I’m weighing options. A first idea was to ignore, as much as possible, the SH2 side and hope that it shouts down itself someway. The reason behind all this was to avoid set up a sh2 environment, which I’m nearly there, so it doesn’t matter anymore.

I’m using a “dual boot” cartridge, meaning it boots both on MD and on MD+32X.

And that’s the header you were talking about, as it is right now:

Code: Select all

.section .text.s32x
.align 4
s32xSource:
.align 4
s32xSourceEnd:

.section .text.boot
.org 0x3C0;	.ascii "Dream Engine 32X"		/* Module name */
.org 0x3D0;	.long 0x00000000			/* Version */
		.long s32xSource			/* Source */
		.long 0x00000000			/* Destination */
		.long s32xSourceEnd - s32xSource	/* Size */
		.long 0x06000240			/* Master SH2 Reset */
		.long 0x06000244			/* Slave SH2 Reset */
		.long 0x06000000			/* Master Vector Base Table */
		.long 0x06000120			/* Slave Vector Base Table */
As you can see “s32xSourceEnd - s32xSource”, or size in the header, is 0.

After reviewing again the boot code it turns out that with the mentioned size, a value of 0, only a long is copied to the 32x memory (don’t argue if it’s well done, just look at the code). What is that long? A random value depending on the compilation options, right now probably a padding 0.

That copied value is precisely the address were boot room jumps to at the end.

Conclusion, we need more control over the sh2 code, so installing a sh2 toolchain/environment is mandatory. I’m on it.
You can bring back that big cylinder now.

Miquel
Very interested
Posts: 460
Joined: Sat Jul 30, 2016 12:33 am

Re: Using 32x as a 3rd plane, possible?

Post by Miquel » Thu May 02, 2019 5:40 am

TmEE co.(TM) wrote:
Wed May 01, 2019 3:36 am
Motorola couldn't up the clocks and their chips started to lag behind others (intel, IBM etc.) who were getting faster and faster, their big flagship chips weren't competitive anymore and customers moved to new things. In the end they dropped 68k line and started doing PowerPC instead...
Well, for what I'm seeing now sh2 instructions is a subset of 68k instructions, I suppose this is why Sega choice this architecture. And Hitachi was not bigger than Motorola & friends back then, so the question remains.

Perhaps what kill the 68k series was a very few set of instructions that they weren't able to implement into a pipeline without increasing the die too much? (or the price) just asking.
You can bring back that big cylinder now.

TmEE co.(TM)
Very interested
Posts: 2373
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Using 32x as a 3rd plane, possible?

Post by TmEE co.(TM) » Thu May 02, 2019 6:21 am

68K can certainly draw into the framebuffers but it is probably tens of times slower that SH2 and you can probably forget about things like scrolling etc. since they'll use up a lot of 68K time, every single pixel needs to be manually written to the framebuffers by CPU, there's no hardware blitter. For effective use of 32X video hardware you'll definitely want SH2 to do the work for you and that comes with MD + 32X game in one cartridge...

As far as 68K and SH2 go, there's nothing shared or similar between them more than any general CPU (since they all do same sort of things). SH got used pretty much only because Hitachi rolled it onto Sega and tried really really hard to get Sega use the part. There's a whole article about it somewhere.

68K line getting dropped in favor of PPC was not at all about that sort of stuff. The 68040 and 68060 were both faster than their closest competitors (486 and Pentium) clock for clock but unlike Intel who has/had the best chip fabs in the world, Motorola didn't and they just couldn't keep up with the clocks. In mid 90's Pentiums were in 166MHz and faster range while 68060 was stuck at 75MHz and its superior performance clock for clock no longer mattered. If they could make 68060 at 166MHz (and faster) then the world we see today would be quite different most likely.
68K line still lived on, in embedded world using the low performance and cost parts such as 68EC020 and they were manufactured well into 2000's. There's also Dragonball and Coldfire line of 68K based MCUs though those are severely cut back versions missing most instructions.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Sik
Very interested
Posts: 890
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Using 32x as a 3rd plane, possible?

Post by Sik » Thu May 02, 2019 6:23 am

68k got stuck because the design they had as a whole simply couldn't scale much further, and any attempt at rearchitecting it would leave them in the dust, and everybody else was already switching to x86 anyway because PCs were already hogging the market (while the 68k machines were either all going away or seeing their market share plummet, and gaming hardware had all moved to RISC so there wasn't even that niche)… there really wasn't much more incentive to continue with 68k.

Anyway, I was reading the 32X docs further, and while RV=1 does indeed preserve the Mega Drive mapping for the most part… it also disables the mirror for some reason. Since the vector ROM remains in place even with RV=1 (why?!), that means interrupts won't work at all as they're hardcoded to point to the mirror (they'll hang up the 68000). So if you dare to do this you have to make a game that doesn't use interrupts at all (so no raster effects, and you have to poll vblank, which itself brings other issues due to only working when display is enabled).

For the record, it reminds me: it seems Z80 can access most of the MD-side 32X registers, even the PWM ones. Only reason we don't see games doing this is because while it seems to work on retail unit, this was broken in the devkit (which is likely why Chaotix has the Z80 tell the 68000 to pass the request to the 32X instead).
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 460
Joined: Sat Jul 30, 2016 12:33 am

Re: Using 32x as a 3rd plane, possible?

Post by Miquel » Thu May 02, 2019 6:39 am

Sik wrote:
Thu May 02, 2019 6:23 am
Anyway, I was reading the 32X docs further, and while RV=1 does indeed preserve the Mega Drive mapping for the most part… it also disables the mirror for some reason. Since the vector ROM remains in place even with RV=1 (why?!), that means interrupts won't work at all as they're hardcoded to point to the mirror (they'll hang up the 68000). So if you dare to do this you have to make a game that doesn't use interrupts at all (so no raster effects, and you have to poll vblank, which itself brings other issues due to only working when display is enabled).
I will look at it later and calmly, because this is really important for this to success. Right now I can tell you that the game works perfect on a 32x with the 32x side enabled.
Maybe are you forgetting that there is a substitute "vector" table at 0x200? It's basically jmp/bra instruction table.
You can bring back that big cylinder now.

Sik
Very interested
Posts: 890
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Using 32x as a 3rd plane, possible?

Post by Sik » Thu May 02, 2019 7:09 am

I'm not. The vector ROM points to that table… in the mirror space (i.e. $880200, $880206, $88020C, etc.). That means when an interrupt happens, the 68000 will fetch those addresses and jump to the mirror, which won't respond since the 32X disabled it, and hence the 68000 will be stuck forever waiting for a response.

It'd have been nice if the mirror stayed enabled even with RV=1 (in which case it'd be at worst a case of having two versions of the interrupts), but alas :​/
Sik is pronounced as "seek", not as "sick".

Chilly Willy
Very interested
Posts: 2784
Joined: Fri Aug 17, 2007 9:33 pm

Re: Using 32x as a 3rd plane, possible?

Post by Chilly Willy » Thu May 02, 2019 3:14 pm

Yes, when RV=1, the 68000 ints MUST be disabled! Period. If a 68000 int occurs while RV is set, it will crash due to the always-on int redirection table.

And quite a few things I do in my 32X demos aren't in the devkit because the developer hardware was an older rev of the chipset with bugs. I'm a bit shocked that Sega never updated the developer boards with fixed chips so that some of the real power could be used. Things like being free to use the FRT (Free Running Timers - they're reserved on the devkits to bumping the int system because ints were buggy on the developer hardware). Doing DMA PWM audio (every game I'm aware of uses an SH2 and PWM interrupts to set the PWM registers during the int). My port of Wolf3D did that before I got to using DMA PWM.

It's sad that they never completely worked out the bugs in the 68K->SH2 DMA channel. The current CPU driven mode can drop words, requiring a timeout routine, checksumming the data, and retries, but the VDP DMA driven mode meant for CD32X games doesn't work at all. :( The 32X has some bugs, but not nearly as serious as the ones in the Jaguar. Now THERE was a chipset that NEEDED another round of fixes before shipping! :lol:

Sik
Very interested
Posts: 890
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Using 32x as a 3rd plane, possible?

Post by Sik » Thu May 02, 2019 4:02 pm

We don't know if they ever got around to fixing the devkits actually, seeing as the docs we have predate the 32X's release. The scary part is that going by the tech bulletins (I was reading them the other day incidentally), they were still making revision changes to the hardware in September 1994. The 32X released on December 1994. That means that three months ahead of launch the hardware still wasn't ready, and technically less if you discount the time needed to mass-manufacture, package and ship.

That's all you should need to know about why some features are broken.

EDIT: actually seems to have released late November 1994 in the US, that makes the situation even worse.
Sik is pronounced as "seek", not as "sick".

Chilly Willy
Very interested
Posts: 2784
Joined: Fri Aug 17, 2007 9:33 pm

Re: Using 32x as a 3rd plane, possible?

Post by Chilly Willy » Thu May 02, 2019 8:03 pm

Even more worserer, the first games had to be ready months before launch to have enough lead time for carts to be made in time for launch. So all the launch titles were completed on devkits that were in the process of changing to fix bugs they found. I would sincerely hope that at least after launch, devs got new boards to match the commercial product. Not gonna hold my breath on that, given SOJ's insistence that all work shift to the Saturn. Perhaps the easiest way to tell would be to look at the vbr tables - if they all point to the same routine, we know they're still using the unified int handler required by the old devkits.

Miquel
Very interested
Posts: 460
Joined: Sat Jul 30, 2016 12:33 am

Re: Using 32x as a 3rd plane, possible?

Post by Miquel » Fri May 03, 2019 11:04 am

Sik wrote:
Thu May 02, 2019 7:09 am
I'm not. The vector ROM points to that table… in the mirror space (i.e. $880200, $880206, $88020C, etc.). That means when an interrupt happens, the 68000 will fetch those addresses and jump to the mirror, which won't respond since the 32X disabled it, and hence the 68000 will be stuck forever waiting for a response.
Chilly Willy wrote:
Thu May 02, 2019 3:14 pm
Yes, when RV=1, the 68000 ints MUST be disabled! Period. If a 68000 int occurs while RV is set, it will crash due to the always-on int redirection table.
It works on Kega Fusion, right now I'm trying to figure out what's going on. Maybe this program ignores RV, but is not that simple, I need more time.
TmEE co.(TM) wrote:
Thu May 02, 2019 6:21 am
68K can certainly draw into the framebuffers but it is probably tens of times slower that SH2 and you can probably forget about things like scrolling etc. since they'll use up a lot of 68K time, every single pixel needs to be manually written to the framebuffers by CPU, there's no hardware blitter. For effective use of 32X video hardware you'll definitely want SH2 to do the work for you and that comes with MD + 32X game in one cartridge...
There is no hardware scroll on the 32x? So it was just designed for brute force 3D then...
You can bring back that big cylinder now.

Sik
Very interested
Posts: 890
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Using 32x as a 3rd plane, possible?

Post by Sik » Fri May 03, 2019 11:50 am

Miquel wrote:
Fri May 03, 2019 11:04 am
It works on Kega Fusion, right now I'm trying to figure out what's going on. Maybe this program ignores RV, but is not that simple, I need more time.
Fusion is not accurate :​O)

Reminds me, Chaotix tries to show "DEVELOPED FOR USE ONLY WITH SUPER32X SYSTEMS." if you plug it into a MD directly without 32X… except it doesn't work in practice, because the security program directly attempts to poke the 32X without checking if it's there and hence it hangs up on a real Mega Drive as nothing is there to assert /DTACK in that area. Emulators don't handle this hang, so the message does indeed show up in them, but not on the real thing (which just stays blank).

Add that to the list of "32X was rushed as heck".
Miquel wrote:
Fri May 03, 2019 11:04 am
There is no hardware scroll on the 32x? So it was just designed for brute force 3D then...
There is! Although all it does is pan around the framebuffer. Also inevitably you'll run out of framebuffer RAM. It's not that terribly useful. I suppose you should look at panning techniques from the EGA and VGA era (especially anything to do with Commander Keen), you'd have to start doing something similar here to get some serious use out of this.
Sik is pronounced as "seek", not as "sick".

TmEE co.(TM)
Very interested
Posts: 2373
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Using 32x as a 3rd plane, possible?

Post by TmEE co.(TM) » Fri May 03, 2019 12:41 pm

Fusion definitely ignores RV bit and always keeps ROM areas same as in MD mode with the exception of vector stuff. For 32X dev you aboslutely need real hardware to do all testing on. When I did more 32X stuff I learned very early on that emulation is way too forgiving and it is super easy to get something that appears to be ok but won't function at all on the hardware.

As far as scrolling goes, you can indeed pan around the output in the framebuffer but there's very little offscreen area possible so you'll have to draw a significant amount of pixels every scroll step. You'll have to figure out how long it takes for your code and then design rest of the game with the remaining budget in mind. The double buffers of 32X will also get in the way, you will have to write two frames pixels to keep both buffers synchronized, it really is meant for brute 3D that overwrites framebuffers every frame not just adjusts its edges etc.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Chilly Willy
Very interested
Posts: 2784
Joined: Fri Aug 17, 2007 9:33 pm

Re: Using 32x as a 3rd plane, possible?

Post by Chilly Willy » Fri May 03, 2019 1:59 pm

What Tiido said. :D

Since the frame buffer fetching is in words, there is a "scroll" register in the 32X VDP for 8 bit pixel mode, but it only supports one pixel of scrolling. After that, you have to change the line table. So simple scrolling is a matter of changing the line table every frame. You use the amount of vertical scroll + the horizontal scroll & ~1 to set the line table entries, then set the horizontal scroll reg to horizontal scroll & 1. Since you're using a double-buffer, the next frame is formed from the one two frames back. Clearly, you'd only use 8 bit mode for scrolling since 16 bit mode doesn't have enough vram for a single frame, much less scrolling... unless you restrict the scroll region to only part of the total screen.

Post Reply