New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The hack doesn't work on real hardware #1
Comments
From Luke Usher, emudev for (among other things), ares-
^ ~ 32X Technical Documentation
|
Hi @viciious, @HeroponRikiBestest I think we tried most of the options. Most of the testing was done by alacron_cinco and some by Mr_Boo_Berry using multiple mega drives/flashcards etc. I don't own a 32X myself unfortunately. Options already explored (still mistakes could have been made here too):
A big problem is ofc as mentioned if the 68000 crashes you cant make an exception handler to capture it due to the vector rom mapping as mention by Luke. It seems to work in MiSTer with some issues at the character profile screens and I guess the credits screen. |
As per Luke's suggestion the next logical step would be to permanently halt the Z80 and/or disable all sound subroutines. |
Sorry for the late reply. I already tried disabling the sound driver communication routines on the md side before. That did not work. I padded the output file to the next MB boundary. Then I tried everything mentioned below incrementally:
Seems that just having the 32X enabled causes a crash... |
For reference: Here is a comment from hangemhighhilton who claims it runs on their original hardware configuration.
|
The guy is yet to post a video though ;) |
True but I have seen reports with differences in stability. I have bought a PAL 32X since and mine crashes really fast. But for some people it only crashes when actually starting the game after character select (consistently). I tested with both ED Pro and x3 with the same results. I don't think I'm able to fix this. I lack the knowledge and frankly also time/motivation at this point. I still learned a lot of new things making this patch at least... so it was worth it to me. Maybe next year when I have some more time I will explore the 32X/SH2 properly and on real hardware for some new projects. Btw I actually got the idea for this hack after a comment by you about the RV bit that I got indirectly (i think from Relikk) when implementing the 32X+ patch for Mortal Kombat 2. |
Just an update for completeness sake. Took a brief look at the code again. And one of the problems on my 32X was this: https://github.com/viciious/32XDK/wiki/Bugs-and-quirks#about-rom-read-when-rv1. I made some changes to prevent crashes caused by that specific issue. But it still crashes on the 32X side with an illegal instruction at address 0 at random on the master cpu. No clue what causes this... If it was a coding error like a stackoverflow or whatever I would expect emulators to have this behavior as well but they seem to not have this issue. |
Ok it was partially a programming error lol (disclaimer: I'm not a C programmer in daily life). For some reason the value read from the COMM registers on the 32X side get corrupted in some cases. I'm not sure why but I just made a workaround for that. It seems to work well now on my PAL version at least. Did not do a full playthrough though. I need some help testing especially on the NTSC version as it has less cpu cycles per frame but also in general. Here is a patch: https://mega.nz/file/HTAEEJqI#Y_dolb-XficfAcnfxlhA0kMEzhP0pgZkK8DK_UONgEU |
Tested on an NTSC console and the game worked fine, at least the first level did. One thing I noticed is that the backgrounds don't scroll smoothly. I suppose you're not using the screen shift register so the backgrounds only scroll at 2px increments. |
Cool thanks for testing! I actually do set the shift register here: golden-axe-32x-edition/src/mars/command/map.c Line 298 in 067900f
The code uses a single framebuffer which is a bit unusual I think. It really depends on finishing the rendering in the vblank window. But it only renders a single 2 pixel column for horizontal scrolling and the actual lines scrolled for vertical scrolling per frame. It prepares the pixel data in a ram buffer during active display. The ram buffer is then transferred in the vblank period. If the vblank part of the routine runs out of time it would cause the wrong framebuffer to display so I don't think that is the issue. Maybe it drops frames due to the vsyncwait being too late on NTSC? I made the vsync wait routine to skip a full frame when it is called when in vblank period, Maybe just removing that part will fix it. But then I would expect the framerate of the genesis side to drop too (depending on if there was any scrolling). The code is not very readable I admit :/. I made a patch where the vsync wait routine does not wait for the next frame if called inside vblank period. Could be a bit flacky depending on the timing: https://mega.nz/file/jWY0lZAR#7wiRrlUzJcjfp6F1VKPxxj-glJW1e808KSxehKhZEpY I think this is also an issue but I really couldn't notice it on my screen: https://github.com/viciious/32XDK/wiki/Bugs-and-quirks#shift-bit-precaution. Really grateful for the 32xdk pages and wiki btw without those I would never have found these issues! But I actually only recently discovered the wiki part. Maybe it's useful to print a reference to it in the readme? |
Ah, if you do use the shift register, then what happens is indeed it occasionally misses a vblank and stutters as the result. But why did you choose the copy-from-SDRAM approach to begin with? It offers no timing advantage over writing directly to the VRAM. Also you don't need to tie your screen updates to vblanks at all since the hardware handles double-buffering for you. |
I think I was just experimenting at that point to find a solution that would be fast enough to keep in sync with the mega drive (I still use the md layers in limited ways) The md code sets the scroll values at the end of all processing iirc. So I have the remaining frame time (about half a frame on average iirc) to update the 32X display. I first just rendered brute force the whole screen but that was too slow even on emulators. Probably also because I used word writes to vram. I was not sure dword writes were possible on hardware. I think it is never explicitly mentioned in the manual. But you are right, I should use the double buffer. |
Dword writes are possible but they don't offer very little speed advantage over word writes, if any at all. Ah well, whatever works best in your case: if the copy-from-SDRAM works for you, that's fine :) |
Excellent work on ironing out the quirks of the 32X architecture, I tested on both PAL and NTSC Model 1 Megadrives and works 95% of the time. Oddly I found the initial boot would lock up with sound still playing, but 2nd/3rd boot works no issues. Possible a random seek/write on the spinning logo section. This was with Patch 2, but played to stage 5 no issues at all. I love to see these homebrew updates to show what the 32X Tower of Power combo could have achieved, superb. |
Thanks for testing. Maybe it's issues with the Z80 as described here: https://github.com/viciious/32XDK/wiki/Bugs-and-quirks#z80. These did not seem to manifest on my system though. The patch also works with the existing MD+ patch btw which is kinda cool. It could be that if you try the MD+ version you have less boot issues due to the Z80 not being used anymore for the music. That would verify if the Z80 is the issue. Although it's not perfect yet I made a new release. |
I suppose the original issue is now fixed. Thanks for your hard work! |
Oh sweet. Glad to see development has resumed on this. I'll have to flash me a repro cart and test it on my 32X with my Gen1,Gen2, CDX and heck even MegaSG & Polymega. Hope progress continues! Hope to see all the arcade stuff and hope exclusive 32X stuff like a new 3 player mode, SegaCD OST reading from the Sega Arcade Classics CD and more! |
Do you expect this to work with Pyron's color enhancement and/or the MSU-MD patches? |
Congrats with the first public release!
You mention that the hack doesn't work on real hw, so here's a few ideas as to what might be the culprit:
The text was updated successfully, but these errors were encountered: