too close for comfort - black label

[Bananamatic]

didn't mean it that way, it's just that...cv1k is really only useable as a demo right now

it's cool otherwise

[Xyga]

Mame is not like the PCBs

Except when it' so close (in a 15KHz emu setup) you have to be a big connoisseur of a particular game/hardware to tell the differences.

[monouchi]

I am still waiting for someone to show me a mame setup that is exactly like the pcb.
There is always something, RGB levels, input lag etc etc.

[trap15]

Lacking the original hardware glitches/limitations is extremely common as well. Sprite flicker, sprite limits-per-line, PGM spazzing, etc.

[rtw]

Lacking the original hardware glitches/limitations is extremely common as well. Sprite flicker, sprite limits-per-line, PGM spazzing, etc.

@trap15, I saw you post about wait states.

Could you please explain why wait-states would help ?

Which device(s) on the CV1K board would you add wait-states to ?

[trap15]

The SH3 CPU doesn't actually have a wait pin iirc, so the memory controller in the CPU itself has registers for setting the wait states for each region. Simply using those is all that's necessary for proper wait states on CV1000. The blitter delay still needs obvious work after that, but games like Ibara are mostly CPU constrained.

[rtw]

The SH3 CPU doesn't actually have a wait pin iirc, so the memory controller in the CPU itself has registers for setting the wait states for each region. Simply using those is all that's necessary for proper wait states on CV1000. The blitter delay still needs obvious work after that, but games like Ibara are mostly CPU constrained.

But why would they use different access speeds for different regions ?

U4 is copied to RAM and executed from RAM. After it is copied to RAM U4 is not touched again. U2 is copied in a cache-wise fashion to RAM on demand.

The only device which would actually implement some kind of wait mechanism would be the blitter / FPGA.

Has anyone here analyzed the code to determine if there is any logic which checks a "wait" pin from the FPGA ?

[trap15]

The RAM waitstate setting is not "zero waits", and I believe the blitter space is different from that setting as well.

The games do indeed wait for the blitter to say it's ready for another frame, which is how the blitter delay works.

[Xyga]

About emulating stuff in a '15KHz' environment; from my experience even with a live demonstration and direct comparison of the best a properly set up and tuned 15KHz build can do, there will always be 'that guy' here to drop the "it's not the same" sentence because his cyborg-expert senses have detected that 0.08% deviation on one particular color tone, 0.02% wrong refresh speed, 10ms lag, and one particular sprite that's not clipping at the right moment in that particular scene.
(yeah he will anyway even though he barely gazed at the thing nor touched the controls)

What can a lowly emulation peasant reply to that except... "cool story bro!"

[Muchi Muchi Spork]

About emulating stuff in a '15KHz' environment; from my experience even with a live demonstration and direct comparison of the best a properly set up and tuned 15KHz build can do, there will always be 'that guy' here to drop the "it's not the same" sentence because his cyborg-expert senses have detected that 0.08% deviation on one particular color tone, 0.02% wrong refresh speed, 10ms lag, and one particular sprite that's not clipping at the right moment in that particular scene.
(yeah he will anyway even though he barely gazed at the thing nor touched the controls)

What can a lowly emulation peasant reply to that except... "cool story bro!"

No you might be describing most games in mame but Cave ones are often radically different by comparison and said differences make huge differences as far as the experience.

[Xyga]

Yup not denying that of course, especially when it's quite perceptible like in the case of the cv1k.
I'm just pointing at the exaggeration of the recurrent "it's not/will never be the same" statement.

I wouldn't be against a kind of "quality/accuracy of emulation" ranking system based on several criteria, applied to drivers or even games individually. Maintained and updated by proper experts who would be judges of course.
(you know there are those .dat files in MAME, well something like that much like the history.dat etc)

In my case, say such a system would exist, I'd probably be of the 'satisfied with even just 90% accuracy' crowd.

[Muchi Muchi Spork]

mametesters takes care of that if you don't mind reading a paragraph for a report, which is a lot more useful than a percentage. Your idea would also be impossible to maintain as new mames come out. Anyway I hear you about not caring about accuracy, I'm sure there is a large crowd that don't.

[Xyga]

It's not that I'm not caring, I would prefer 100%, most people would I'm sure, but I am personally satisfied when it's 'close-enough' that I can hardly tell the difference.

[Muchi Muchi Spork]

With Cave it kinda depends on the game I guess. Everything before CV1000 would fall into that category but often Cave got hardware limitations to work in their favor in more ways than slowdown. Not always like the glitch explosion in PGM (I wouldn't miss that) but limits like in ESP Ra.De. where you sometimes disappear into just a shadow trail, trust me, you are missing out on some of the magic. Ignorance is bliss, well maybe not.

[Xyga]

Depends on what you value, minor differences don't decrease the fun for me, only big ones that break the game.

People who don't like emulation will tell you to play the ports, and when you play the ports they will tell you those aren't good enough anyway.
If the status of the emulation of a game reaches a point it becomes better than the ports or close to 100%, they will find a way to tell you it's still no good, or that you're a pirate, or whatever. *yawn*

[trap15]

[Xyga]

[BIL]

[BareKnuckleRoo]

wait what was this thread again

where you sometimes disappear into just a shadow trail, trust me, you are missing out on some of the magic. Ignorance is bliss, well maybe not.

Or Espgaluda, when you get a massive cancel and the screen absolutely FREAKS OUT with green lines and stuff. It looks awesome, but it's caused by the PCB hardware's limitations so not in MAME (or PS2 port).

[pestro87]

^That sounds pretty awesome! I haven't seen that one.

I absolutely love when the sprites glitch out on big cancels in Futari God Mode and in DFK BL or the stream of glitchy pixels that appears on the very left of the screen on the first boss in Futari when he stomps, it feels like the boss is going to break the screen.

Other than that though, I find that the "small" differences between MAME, the ports and the PCB becomes more and more apparent the more time that you spend with the games. With Futari God Mode, I actually have to alter my routes and strategies on the port vs. the PCB because the slowdown behaves quite different. The Stage 5 midboss is also totally wack on the port vs. on the PCB. I've heard that his movements depend on various RNG elements including the player's position so not sure if those mess up the formula or whatnot on the port. Anyway, I digress... I haven't played any of the BLs in MAME so I don't have much to add here. These are just my opinions. If you're fine with how close the MAME emulation is then good for you, it will save you a bunch of money. As for piracy, these games are for Japan only as the boot screen clearly states and operation outside of this country is illegal so I suppose that owning the PCB is still not good enough from a legal perspective

[BareKnuckleRoo]

^That sounds pretty awesome! I haven't seen that one.

Has Moh ever come out to one of your meets? I'm pretty sure he still owns an Espgaluda board.

[pestro87]

^That sounds pretty awesome! I haven't seen that one.

Has Moh ever come out to one of your meets? I'm pretty sure he still owns an Espgaluda board.

Oh nice! Nope, would be awesome if he could make it sometime! I've met him a few times at Cody's meets when he brought Batsugun and TGM. I've played the PCB for Galuda at SuperMotaro (you may recognize me in the video playing Garegga next to Eaglet who's playing DOJ, lol) but I sucked at the game back then so I don't recall seeing that glitch. Would be awesome to give it another go now!

[IseeThings]

The SH3 CPU doesn't actually have a wait pin iirc, so the memory controller in the CPU itself has registers for setting the wait states for each region. Simply using those is all that's necessary for proper wait states on CV1000. The blitter delay still needs obvious work after that, but games like Ibara are mostly CPU constrained.

It's generally a bit more complex with modern CPUs tho, especially if you're running from instruction/data cache and therefore not touching the RAM (the waitstates don't apply unless the external RAM access actually happens)

Using the waitstates *always* will actually make the CPU too slow in such instances, because it's the very reason they have cache, so you'd need to fully implement the caching algorithms too.

Once you start emulating things like that everything gets very complex very quickly, although it is needed, there are known cases (not on the Cave games specifically) where something will wipe the very ram it's running code from, but not fail because the code is actually all contained within the instruction cache etc.

[Strikers1945guy]

It's not that I'm not caring, I would prefer 100%, most people would I'm sure, but I am personally satisfied when it's 'close-enough' that I can hardly tell the difference.

If all the things such as difference in slowdown from the pcbs, input lag, glitchyness, etc. are "small differences" that don't disrupt you from enjoying the games then that's all well and fine. if you're playing for score and are half way serious then these things come into play massively imo. Some older games no but stuff like Ibara & DFK BL are good for demoing the game right now... that's about it. Saying they are close enough is pretty LOL tastic.

[Xyga]

but stuff like Ibara & DFK BL are good for demoing the game right now... that's about it. Saying they are close enough is pretty LOL tastic.

I didn't. You missed my point. Read again.

[captpain]

Can a nice man or woman who does not care about esoteric Emulation Just Practices like some kind of Martian please fix the emulation speed issues so I can play the fun time shooty game on my computer please. I love you.

[xMetalliCx]

speaking of waitsates...
SH3 have such pin, but afair last time I checked how games works - SH3 RAM area configured as SDRAM and this pin is ignored. having such settings SH3 acts with it as memory controller, this means normally only SH3 can access it. normally, if other devices needed to do access to this RAM must be used SH On-Demand-DMA (DDT) so CPU's DMA controller read data from RAM and transfer it to external device, like in HOLLY-based systems (Dreamcast, Naomi, etc). BUT as I see no DDT is enabled in CV1K.

so the question of the day - how the hell blitter accesses SH3 RAM to fetch its blit-lists (with optional sprite data too) ?
the only thing wich comes to my mind - at blit start SH3 must be completelly stopped, and must be stopped until whole blit will be finished, during this time blitter will access to SH3 RAM directly. this can be made for example by blocking clock input (unlikely, because this breaks timers), or by not asserting acknoledge pin after blit start register (0x04) write or status register read (0x10, wich can be not blit status/buzy at all, but for example VBLANK), so the CPU will be stopped and wait until ACK arrives (ie external device put needed data on the bus).
this can also explain why current MAME's dirty speedhacks works without consequences - because the real hardware works this way too. and why this silly 100Mhz SH3 usually used only for 25-30% of its power.

[rtw]

speaking of waitsates...
SH3 have such pin, but afair last time I checked how games works - SH3 RAM area configured as SDRAM and this pin is ignored. having such settings SH3 acts with it as memory controller, this means normally only SH3 can access it. normally, if other devices needed to do access to this RAM must be used SH On-Demand-DMA (DDT) so CPU's DMA controller read data from RAM and transfer it to external device, like in HOLLY-based systems (Dreamcast, Naomi, etc). BUT as I see no DDT is enabled in CV1K.

so the question of the day - how the hell blitter accesses SH3 RAM to fetch its blit-lists (with optional sprite data too) ?
the only thing wich comes to my mind - at blit start SH3 must be completelly stopped, and must be stopped until whole blit will be finished, during this time blitter will access to SH3 RAM directly. this can be made for example by blocking clock input (unlikely, because this breaks timers), or by not asserting acknoledge pin after blit start register (0x04) write or status register read (0x10, wich can be not blit status/buzy at all, but for example VBLANK), so the CPU will be stopped and wait until ACK arrives (ie external device put needed data on the bus).
this can also explain why current MAME's dirty speedhacks works without consequences - because the real hardware works this way too. and why this silly 100Mhz SH3 usually used only for 25-30% of its power.

xMetalliCx thanks for the detailed explanation. So you are basically saying that the blitter pulls it's lists off the bus from SDRAM without any DMA thus halting the SH3 ? If that it true it is indeed silly.

Wouldn't it have made more sense for a thread in the SH3 to push to the blitter ?

Any way to verify this on real hardware ?

To add to the confusion, CAVE went through several revisions of the FPGA. For example the Mushihimesama versions contain different FPGA versions.

[xMetalliCx]

xMetalliCx thanks for the detailed explanation. So you are basically saying that the blitter pulls it's lists off the bus from SDRAM without any DMA thus halting the SH3 ? If that it true it is indeed silly.

Wouldn't it have made more sense for a thread in the SH3 to push to the blitter ?

well yes. it makes sense. but instead SH3 writes to one blitter register address in RAM there blit-list is, and then writes to another register blit-start signal.
no DMA enabled in this time. so blitter must somehow read data from SH3 RAM on its own.

Any way to verify this on real hardware ?

don't know yet. maybe xray PCB photos will give us some more info, so we know how components of this system connected to each other.

To add to the confusion, CAVE went through several revisions of the FPGA. For example the Mushihimesama versions contain different FPGA versions.

you mean firmware revisions ? as for me it looks like appeared first 2 versions have some bugs, it was fixed and from that time all games uses the same firmware.

[rtw]

To add to the confusion, CAVE went through several revisions of the FPGA. For example the Mushihimesama versions contain different FPGA versions.

you mean firmware revisions ? as for me it looks like appeared first 2 versions have some bugs, it was fixed and from that time all games uses the same firmware.

From my list I have:

Code: Select all

crc32: 0x9ba48061, len:   290416, file: espgal2.bit
crc32: 0x9ba48061, len:   290416, file: mushisama no dot
crc32: 0x460723c7, len:   290416, file: mushisama one dot
crc32: 0x92a74d06, len:   290416, file: mushisama two dot 
crc32: 0x460723c7, len:   290416, file: ibara
crc32: 0x92a74d06, len:   290416, file: ibara black 
crc32: 0x9ba48061, len:   290416, file: mushitama 
crc32: 0x92a74d06, len:   290416, file: mushitama one dot

In total 3 different versions.

0x92a74d06 is the latest version of the FPGA used on all the later games.