SpritesMind.Net

King Of Chaos wrote:Make sure it's Mac OSX hacked for PCs (OSX86) or else it won't work, as Macs have special hardware needed to run OSX.

Well, it's not really needed as OSX86 shows. Apple just puts it there to try to force people to buy their Macs instead of an inexpensive generic PC.

Hi,

It Kalyway 10.5.2. It was recommended to me.

EDIT:
Hi Chilly Willy! Just wanted to let you know that linux port of Regen with Windows-like GUI and every feature of windows version will be available hopefully in three weeks.

stay safe,

AamirM

AamirM wrote: Hi Chilly Willy! Just wanted to let you know that linux port of Regen with Windows-like GUI and every feature of windows version will be available hopefully in three weeks.

Great news! Looking forward to it. I love playing these old SEGA games, but the linux emus tend to lag the Windows ones a bit. Oh well. I mainly use PicoDrive on my PSP.

AamirM wrote:It Kalyway 10.5.2. It was recommended to me.

Excellent choice. Should have a working OSx86 install soon.

Chilly Willy wrote: I mainly use PicoDrive on my PSP.

Nice to hear that I've succeeded improving performance ~5-10% for all games, just need to do some more polishing before release.

notaz wrote:

Chilly Willy wrote: I mainly use PicoDrive on my PSP.

Nice to hear that I've succeeded improving performance ~5-10% for all games, just need to do some more polishing before release.

Even better news!

I think my favorites on PicoDrive on the PSP are Earthworm Jim: Special Edition (the CD), and Sonic & Knuckles + Sonic 3. Those are really great on the PSP, and rather long fun for those times you're stuck at some relative's house and they'd rather watch something you don't care for.

Regen 0.85 in PAL mode (Europe) sound repeats. It's like broken CD. In NTSC mode all OK.

Hi,

Linux port has been uploaded. I don't even have enough time to to write some important stuff about it and respond to other posts . Hopefully I will get some free time soon. Comments on port are welcomed.

stay safe,

AamirM

Linux version works well.

I don't notice much difference with vsync. I'll have to try a few more settings to see how it goes.

Nice work!

Hi,

Good to hear that it is working fine. Vsync support is not very good that is why I listed it experimental. I need to find some other way for vsync to work.

@HardWareMan

Tell me the game you are running, your hardware specs and the settings of regen.

stay safe,

AamirM

Hi,

Is the speed of linux port ok? I think its a bit slow. But that may just be SDL.

stay safe,

AamirM

AamirM wrote:@HardWareMan
Tell me the game you are running, your hardware specs and the settings of regen.

The game is does not matter. Sample sound can take here. Before silence NTSC, after - PAL. P3 and P4 versions make same result. My hardware see below.


* * *

Right now I completed the update drivers for soundcard from soundblaster.com and motherboard chipset from intel.com. My videocard are already have latest drivers. This glitch is still present.

Hi,

You need to reload (not reset) the game after you change the region to europe (PAL). Then it will run fine.

stay safe,

AamirM

Stef wrote:

AamirM wrote:

notaz wrote: I can confirm original Musashi handles all 3 cases correctly (i.e. the way docs say).
Don't know how you got this idea, but I've looked at this too, and it surely doesn't do trace. In fact, I haven't encountered any game which would do that.

Hi,

Yes, no trace. I was going in the wrong direction. Still haven't figured out the correct solution. I have very less time these days.

stay safe,

AamirM

Don't search on 68000 core, problem is timing and specially interrupts timings. I spent *many* time with them on Gens. I adjusted them probably more than hundred time, a single cycle can fix more 1 or 2 games but break 3 others :-/ Today i know my timings are almost completly wrong, i had just luck with all my adjustements and fudges...

I think I figured out this one (Pacman 2's pause bug):

it is indeed a timing issue, more precisely a VINT timing issue:

when you hit START button, the following subroutine ($50158 if you want to look in the disassembled code) will execute, approx. at the middle of line 237.
This routine does the followiing:

1/ request Z80 bus and cancel Z80 reset
2/ fill up ZRAM from $A01000 to $A01FFF
3/ modify Z80 data from $A00000 to $A04AC (Z80 program ?)
4/ reset Z80, release Z80 BUS then cancel Z80 reset (Z80 restarts)
5/ reset $FFC000-$FFC4AA WRAM area (datas used later)
6/ once it is done, set $FFC016-$FFC018 with a particular ROM address (used later in the program)

This routines takes quite a long time (quite a whole frame) and will obviously be interrupted by VINT on line 224 of the next frame.

When this happens, 2 issues could occurs:

(a) if VINT triggers between part 5) and part 6), sound issues happens: indeed, the ROM address stored in $FFC016-$FFC018 is read by VINT for later use. If this address is still 0, bad data wil be read later, this will end up in messing some other flags, and finally shut off sound output (one of the messed flag is polled by the z80 in his sound routine)

(b) if VINT triggers between part 1) and part 4), another problem occurs. Indeed, VINT also want to access Z80 bus to write into ZRAM and so, will request access to the bus. Once it's done, it will (as usual) release the bus ... but when the main routine returns to his execution, all further Z80 RAM writes will failed since the bus has been released by the VINT callback.
This issue is described in one of the Sega Tech Bulletins, where they advised to disabled interrupts before accessing Z80 from the main loop, which this game obviously does not. Strangely, this ends up in a corrupted Z80 RAM but did NOT shut of sound output as above.

Now:

. issue (a) is what happen in all emulators when using common timings.

. if, like AamirM originally did, you increase the number of cycles used by the dbf instruction , the several write loops inside the subroutine will be delayed , VINT will be triggered sooner during the execution and issue (b) will occur. However, as explained, this does not shut off sound output as in issue (a), giving the impression you fixed the problem, which you haven't. Anyway, the dbf instruction timing are correctly handled by the 68000 core so this is not the correct solution.

. modifying the timing occurence of VINT on line 224 by some cycles does not work though, because VINT will still trigger during WRAM initialization (the loop takes approx. 0x4AA / 4 * 22 cycles = 6556 cyles = 13 lines to fully initialize the $FFC000-$FFC4AA area)

.a viable solution would be that the subroutine started a few lines earlier but I didn't find any way to do that. It starts at line 237 whatever you do with instruction timings.



The solution that I found is to add one cycle delay each time the 68000 access the Z80 RAM.

Indeed, I imagined that there could be some kind of bus latency in this case since this is not a "direct" access (z80 bus data is "copied" somehow on 68k data bus through the IO chip)...

I don't know if it is correct from a hardware point of view (please tell me if i'm wrong) but this makes the timings perfecly fit together, Z80 ram is not corrupted and sound output does not stop after pause.


quite a long post for a small problem but this bugged me for some time and found better to write everything down here

All emulators play samples a little bit faster than real hardware so there are some Z80 to 68K access limitations... I have no idea if there's any the other way. I imagine there are.