|
Post by 3vix6 on Jun 4, 2010 23:01:44 GMT -5
What is a bank selection? I've heard of bank switching, but I've never heard of selection before.. Can you enlighten me? ;-)
|
|
|
Post by jlf65 on Jun 5, 2010 1:20:18 GMT -5
Same thing.
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 8, 2010 2:33:16 GMT -5
From the Quake DS webpage:
So you'd have to move it back to the original software renderer if porting it to the 32X. And I'm guessing that a large part of the software renderer was written in x86 assembly, so you'd have to manually translate all that code. Maybe there's a C version of the software renderer available somewhere, but then you'd likely end up wasting some precious cycles compared to what a competent SH2 coder could achieve.
|
|
|
Post by jlf65 on Jul 8, 2010 13:57:39 GMT -5
Yes, you'd want to write the renderer in decent SH2 assembly. Fortunately, the SH2 is fairly easy to do assembly on, being rather similar to the 68000, and having plenty of registers to work with.
I think that's part of why SEGA went with the SH2 for the Saturn and 32X - it is big-endian, and pretty similar to the 68000 assembly-wise. It doesn't take long for a competent 68000 programmer to become competent on the SH2 as well.
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 8, 2010 15:52:54 GMT -5
The fact that Hitachi is a large japanese company might also have had something to do with it
|
|
|
Post by Tom Maneiro on Jul 8, 2010 17:44:51 GMT -5
I've heard that Sega was in bed with Hitachi or something (aside of both being japanese, and you know, Japan still dislike foreigners in their business). This is also why the Dreamcast ended having a SH4 instead of a PowerPC CPU.
|
|
|
Post by Mairtrus on Jul 9, 2010 20:05:51 GMT -5
Today I saw this:
Just remember guys: Sega does what Nintendon't, no matter what happens...
|
|
|
Post by jlf65 on Jul 10, 2010 1:31:38 GMT -5
Today I saw this: Just remember guys: Sega does what Nintendon't, no matter what happens... That's not Quake, it's a ground-up tech-demo that walks through a few levels that look like Quake. There's no gameplay at all. Still, I'd have loved to see the code for that. The GBA is only a 16.8 MHz CPU, with no extra hardware for the video. It's probably all 100% assembly. The Yeti3D GBA demos are also very nifty... and GPLed! Maybe a 32X version could be made.
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 10, 2010 3:12:48 GMT -5
I'd say it's generally possible to write more efficient code for the ARM compared to the SH2. Of course the code will be bigger, but at least the most time-critical loops can be written in ARM assembly and executed from IWRAM. Hell, even Thumb code is probably more speed-efficient than SH2 code in many cases And the framebuffer is only 240x160 pixels on the GBA, compared the the 32X's 320x224, so on the GBA you only need to render about half of what you'd have to do on the 32X (assuming that you wanted to fill up the entire screen on both systems).
|
|
|
Post by jlf65 on Jul 10, 2010 14:53:28 GMT -5
The common practice on "lower-end" systems like the GBA or 32X is to double the pixels. For example, the Yeti3D GBA demos draw at 120x80, then double it.
I need to go through an ARM user manual and look at the timings - I'm not sure how efficient it is, but it's RISC, so it's probably like most other RISC processors. According to the wikipedia page, the ARM7TDMI version in the GBA has no cache, and gets 15 MIPS at 16.8 MHz. The SH2 has a 4KB unified cache (D&I), and gets 20 MIPS at 23 MHz. So it sounds like the ARM7 is slightly more efficient, but you have no cache (probably why it's important to put critical code in the IWRAM). The SH2 is clocked faster, and has a cache, so it should do better despite not being as efficient. Not to mention, you have TWO of them, as well as a 68000 and a Z80. Be careful about where you put your code and how you divide up the tasks and it should easily be better than the GBA.
|
|
|
Post by GiGaBiTe on Jul 10, 2010 18:20:43 GMT -5
If I were to make a Quake 32x port, I'd do a 32x CD game. Use both SH2s for rendering and both 68000s for game logic.
|
|
|
Post by jlf65 on Jul 10, 2010 18:37:39 GMT -5
If I were to make a Quake 32x port, I'd do a 32x CD game. Use both SH2s for rendering and both 68000s for game logic. Not enough ram. With a cart, you can at least stuff a lot of the data into the rom. With CD or CD32X, EVERYTHING has to go into the ram. You'd have to edit the levels to remove a lot of details and textures. Or make a version where it loads for every room. ;D Remember that the CD only has 768 KB of ram, and the 32X only 256KB. Trying to stuff a Quake level into that amount of ram would be a real trick. Now a "quake-like" game specifically written around the CD32X lack of ram could be done. Run the game logic on the CD 68000, the sound and glue logic on the MD 68000, and the rendering on the 32X.
|
|
|
Post by Tom Maneiro on Jul 10, 2010 22:16:05 GMT -5
CD-ROMs? ROM is cheap these days, so why not put a generously fat 32-64MB (NOR-Flash)ROM there with some custom mapper? How would you deal with bankswitching on a 32X? AFAIK no commercial game used bankswitching on that mushroom, and i've heard that SSFII (the rare 40Mbit cart) won't work there...
|
|
mic
Moldy Popcorn
Posts: 27
|
Post by mic on Jul 11, 2010 2:57:41 GMT -5
The GBA IWRAM has a 32-bit bus and can be accessed in a single clock cycle. So it's almost like having a 32 kB cache When I was talking about efficiency I wasn't talking about cycles/instruction, since most instructions take 1 cycle on both the ARM and the SH2 (plus whatever wait states apply for the memory you're accessing). I was talking about the fact that it's possible to implement the same algorithm with less instructions on the ARM since it has a much more powerful ISA; 3-operand instructions, arbitrary shifts, immediates > 255, no need to zero-extend after loading an immediate > 127, not being limited to the use of r0 for a lot of instructions, conditional execution, etc. The downside to this is of course that each instruction takes 4 bytes of memory, compared to 2 bytes on the SH2. But like I said before: write the most time-critical loops in ARM assembly and execute them from IWRAM. Write the rest of the code in Thumb assembly (or C compiled to Thumb code) and run it from ROM or the 256 kB "external" WRAM. Oh, and a small note about pixel-doubling: The GBA has hardware scaling, the 32X doesn't
|
|
|
Post by jlf65 on Jul 11, 2010 15:11:10 GMT -5
Here's a quick compile of yeti3d for the 32X: www.fileden.com/files/2009/2/3/2304902/yeti3d-32x-1.zipThis currently runs game ticks at 15 Hz (NTSC), and renders a 288x144 display window at 3 to 10 FPS (it's normally 8 to 9 FPS on Gens/GS). The rendering is BGR555 in straight C. Clearly you want to use an assembly replacement for the texture mapping code like they do for the GBA and the PS1. The controller mapping is: A = A (fire) B = B (jump) Start = Selection X = L (look up) Y = R (look down) Dpad = Dpad (turn/forward/back) mic - Yeah, sounds like the IWRAM is a cache, just external. And being able to scale half-width/height to full-screen cuts the drawing to one fourth! That's a fairly significant amount of the time on the 32X - 320x200 looks good, but takes a lot of time. Right now, the code just renders straight into the frame buffer. If I want to scale a smaller window, I would need to render to ram, then scale via software at the flip.
|
|