|
Post by pmjobin on Jul 28, 2005 8:59:17 GMT -5
paxl.org:2080/~avangion/TYRIS.ZIPYou will have to fix the checksum, that is because I don't know how to calculate it In fact, the whole MD header may be wrong... Thanks in advance!
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Jul 28, 2005 12:05:11 GMT -5
i can't get it to work on real hardware x.x
|
|
|
Post by pmjobin on Jul 28, 2005 22:27:49 GMT -5
Noooo! ... Thanks for testing this DevSter! Any idea of what I could have done wrong? I know your stuff work on a real 32X so I guess you have stumbled on some of the h/w pitfalls before. Also, could you explain me how you calculated the checksum? Thanks again!
|
|
|
Post by Fonzie123 on Jul 29, 2005 18:28:32 GMT -5
Great pic , too bad it's not a 32x babe I noticed several things to check when using the 32x: -Check if you have access to the FB before writting -Check if you are in Vblank before flipping FB -Add some nops before palette settings (and between those access : regs, palettes, fb's )... That was for the 68K... now, if you're using SH's I don't have any ideas of timings :/ See ya and good luck
|
|
|
Post by pmjobin on Jul 30, 2005 13:40:11 GMT -5
Then check this out! I love girls that have bad temper... ;D paxl.org:2080/~avangion/TYRIS2.ZIPThis one is displayed in VDP mode 1. The previous one was displayed in VDP mode 2. Thanks for your hints Fonzie, but I do check the VDP status register. As I told earlier, I think the main problem is in the header. paxl.org:2080/~avangion/CARTHEAD.68KUnfortunately, I still don't have a Tototek flash cart to test this.
|
|
|
Post by pmjobin on Jul 30, 2005 14:11:52 GMT -5
|
|
|
Post by Fonzie123 on Jul 31, 2005 5:38:22 GMT -5
;D Yeah, this one sounds exactly 32x's girlfriend... I have a tototek, i'll check your demo.
Btw, there is another thing that can make your demo fail, its the ntsc/pal problem... try to run your demo in a pal or ntsc emulator setting, if one of two fails, it means that your software do not wait for some important timings...
Also, i noticed you are using the sound (i can hear "poc poc") or it is gens that have problems?
btw: nice pics
See ya,
Fonzie
|
|
|
Post by RedAngel on Jul 31, 2005 6:16:21 GMT -5
Luis Royo draws comics but in the eighties he drew a lot of covers for Spanish videogames (Amstrad cpc, Spectrum, c64...). Alfonso Azpiri was also famous for the same thing. In Spain there were argues about who was the best of the two.
|
|
|
Post by pmjobin on Aug 3, 2005 14:24:46 GMT -5
Thanks! But I think I'll leave the 32X for now and get back into my DC project. The reason behind this choice is that sadly, the 32X is even less powerful than I thought... (bus latencies make it impossible to render something worthy at a decent framerate) My demo doesn't use sound and it seems that GenS (I'd rather say DirectSound ) has a problem. Thanks RedAngel, I didn't knew about him so you made me discover a new artist! I also like the work of Olivier Ledroit (Chroniques de la Lune Noire), Frank Frazetta (Death Dealer) & Simon Bisley among others.
|
|
oompa loompa
I AM THE GOVERNATOR
"Git 'Er Dun!"
Posts: 1,301
|
Post by oompa loompa on Aug 3, 2005 21:27:12 GMT -5
i can't get it to work on real hardware x.x my mistake, it does work on real hardware. i broke one of my wire wrapping wires when pulling out the flash on my homebrew cart =P the checksum is really simple: keep adding each 16-bit word after location 0x200 (in big endian of course =D). there doesn't have to be a checksum though, if a value of 0 is used for the checksum, the genesis and 32x will skip its checksum checks. the 32x actually doesn't compare the actual checksum versus the checksum presented in the header. the 32x master sh2 will calculate the checksum, and then send it over to the genesis side cpu to compare checksums (the poorman's 32x bios source codes show how the checksum is calculated) btw, i couldn't help myself but make another 32x pic demo, instead this time it's using RLE - video mode 3, and it was compiled using basiegaxorz. the newer release of imagenesis will convert pictures into RLE mode, and will export framebuffer picture data, scrolling data, and cram data. here it is - devster.retrodev.com/pub/basic2.zip
|
|
|
Post by pmjobin on Aug 4, 2005 12:24:36 GMT -5
Thanks Devster! If I get it correctly, the 32X checksum is calculated just like the usual MD cart checksum. Also, I'll look at your demo ASAP. My 32X project was to make a better port of DOOM. Unfortunately, as I told earlier, bus latencies are going to kill me. BTW, I just discovered that the guy who produced KOLIBRI is nobody else than Ed Ettore Annunziata. This guy is also behind Chakan, Ecco the dolphin & the first X-MEN.
|
|
|
Post by GiGaBiTe on Oct 30, 2005 1:09:11 GMT -5
i gave devster the idea of making a complex SLi (scan line interleaving) where each SH2 takes turns drawing even and odd lines on the screen, which would make the whole 32x your video card. then use the genesis 68000 for the game code.
and on top of that, the SH2's in the 32x are clocked at 23.5 MHz, but in reality the SH2's used in the 32x are the same SH2's in the sega saturn. so if you want, you can clock them to 28.7 MHz, which is the default clock for the SH2's
why sega made the SH2's slower, i have no idea. maybe they didnt want the 32x to compete with the saturn.
in normal 32x game, one cpu is designated as the graphics chip, while the other is the game code chip. if you have both of them doing rendering, and handing the game code of to the 68000, you can practically double the performance (and even more if you clock them at 28.7 MHz)
if your scared of running the game off the 68000, duke3D did it fine, although the graphic quality sucked ass because the genesis vdp was never designed to do 3d.
so you would have the 68k, z80, pwm, genny vdp and a few other things left to do your bidding.
|
|
|
Post by pmjobin on Oct 30, 2005 14:15:55 GMT -5
In fact, the dual SH-2s (even though they are down-clocked in comparison to the Saturn) have plenty of times the horsepower necessary to perform any type of rendering to the framebuffer. The real latency problem I was referring to in my previous post comes from the bus arbitrer & 4 word FIFO that lie in front of the SDRAM banks. Filling the FIFO with data is pretty fast, but once the FIFO is full, you have to wait for it to empty and as far as I know, it takes 5 cycles/16-bit writes (2x 8-bit pixel or 1x 16-bit pixel). So basically, even if you use a single SH-2 to perform all the rendering, it will wait against the FIFO most of the time... There isn't really a "good" way to handle rendering on the 32X. The design is flawed, mostly due the fact that the 32X and Genesis works in sync.
|
|
|
Post by Fonz on Oct 31, 2005 9:00:31 GMT -5
wow, doom port. Umm, I never heard you were forced to use the fifo (i thought you can write directly to fb)... Do you have official docs for 32x? Because, afaik, doom for 32x is a "direct" port of the computer code (just with lower rez tex). Splitting main SH for raycast and sub SH for drawing (running from a cached code) should be very okay... I also recommend to use genesis VDP to display weapon and status bar.
|
|
|
Post by Fonz on Oct 31, 2005 9:08:22 GMT -5
"but once the FIFO is full, you have to wait for it to empty and as far as I know" Yeah but, in doom, you have to do some calculations before drawing next pixel (especialy to calculate scalling of vertical lines), so it's not a real problem since you write a pixel, get/calculate next one, write it.... I'm not sure of that but I think that: If main SH runs from ram (raycast/game engine) and 68K runs from its ram (and a few cart access), you get full speed from cart>cache>fb with subSH and full speed ram>mainsh>ram . That can be a good thing if level is in ram and textures/monsters in cartridge.
|
|