Rot
Calvin & Hobbes, ,
- Joined
- Jul 8, 2003
- Posts
- 11,441
actually I was thinking more about this:
Touche Massi...
Touche...
xROTx
PS. For a Tech thread... sure is a lot of weird spammin' going on...
actually I was thinking more about this:
PS. For a Tech thread... sure is a lot of weird spammin' going on...
People soldering the crystal on the MVS is not the solution to this situation. What can happen now though is the neosd guys can try and put a 1fz in their pocession into that state and try and reproduce your situation directly. Then work a solution in the firmware while seeing the results instantly instead of relying on others to do the tests for them.
You are the only one with crc32 errors on the test firmware version you have afterall. No one else has had the issues in the way you have with it although problems are known in that test firmware.
Sorry but you are partly wrong! The crystal should be grounded! Do a little research on why this is done and why most of the boards have a grounding strap. In my case the jitter is more prevelant and clearly was causing a problem. That problem could be exacerbated on the 1FZ due to trace routing, component layout etc. But its good practise to ground the can of a crystal. I've removed the ground strap on my other 1FZ crystal and what do you know, CRC issues.
Sorry but you are partly wrong! The crystal should be grounded! Do a little research on why this is done and why most of the boards have a grounding strap. In my case the jitter is more prevelant and clearly was causing a problem. That problem could be exacerbated on the 1FZ due to trace routing, component layout etc. But its good practise to ground the can of a crystal. I've removed the ground strap on my other 1FZ crystal and what do you know, CRC issues.
EDIT: Also note - as I said in the post earlier, you may or may not be able to replicate the issue yourself. Part of the problem is noise, not just noise from the board but EMF noise in the area. My MVS sits 1 foot underneath a TV, we have communications masts nearby on industrial units etc, there are numerous factors to coupling on a crystal can.
GadgetUK,
I have no words to thank you for all the time you gave us on the last two weeks.
We had good, not so good and great moments, but at the end we have worked with the same goal, find what was happening at your end.
Lets keep improving NEOSD, with your help.
Big thanks for your patience
You did not understand what I have said.. I did not say you are wrong and I do not disagree that the crystal should be grounded. Clearly from your own comments you understand this is prob a manufactoring issue.
What I am saying is people with this issue (which was only you atm) should not be expected to ground the crystal to fix the issue when the MVS board in that state can play other MVS games without issue. The ideal solution will be to make sure the neosd is tuned to work in this situation.
Yes I undertstand.
In your case, are the other issues you have in kof2003 etc with the hair and such also fixed or improoved after you grounded the crystal?
Yes, noted =D It's just really minor speckles and things that he spotted and I think I've re-created but they might occur on originals - I need to test tomorrow, but they are so minor I don't care if they never get fixed tbh.Just remember you and Spectre have a differnet firmware so findings on one do not relate to the other until your both on the same one.
Yes, noted =D It's just really minor speckles and things that he spotted and I think I've re-created but they might occur on originals - I need to test tomorrow, but they are so minor I don't care if they never get fixed tbh.
I'm going to guess already and say the speckles are going to be the known snow that appears when writing to Palette RAM on NeoGeo hardware. If you can give an example of a place in question I can probably give a quick answer on that.
Magicial Lord etc.
This is the situation expected, those lines at top of screen when dying are from palette RAM access/update. If Metal slug looks like that then it will be the same thing, I suspect it is but a screen shot or small video of what you see would be helpful if it looks different. Could also be related to sprites update code falling out of vblank.
In general I would say 99% of glitches at the top of the screen in games will be normal. When there is a hortz line with broken colored pixels (like what you see in maglord) then its totally normal. If you see glitching durther down the screen then it could be either sprite clipping (normal) or something that needs to be looked at more. If you see a hortz line or lines that appear to be tracking sprite positions then that will need looking at.
Sound crackle.
I'll let gadget report back on that as he has original cart to compare against.
Unibios exceptions.
First think I need to say here is that just because the unibos exception screen shows up does not mean it is a unibios issue. I can see why one would think this however but in reality all you are seeing is a report created as the result of the 68000 cpu stopping (crashing). In a system without unibios the game would simply reset and the reason unknown/unnoticed.
This exception screen is very helpful however because it tells us where the cpu crashed and its state when it crashed. For that reason every crash seen should be treated as a potentiall different situation. What is needed for investigation however is 2 pictures of each crash, one with data registers showing and one with address registers. You swap between these pressing 'A' when the error message is showing. It is alsoimportant to know the game (and revision) being played.
Due to the above I cannot really give more info to you but I can make some theories.
1) Chashes happen alot because backupRAM storage for the game has corrupted and in many cases that will show itsself during hiscore entry or highscore displaying. Given you mentioned this I sugest resetting backupRAM and also disabling the neoSD backupRAM loading and saving option.
2) Try again while not using cheats (if you were) as this can also cause issues.
3) Confirm your PSU is good and that cart socket is clean. Make sure the neosd is correctly aligned with the pins. Given there is no shell at the moment it is possible to have a mis alignment.
With a little more information about crashes I can probably give more information but because you are on a beta firmware however its probably best to wait until you get an update one. You are not the only one to get crashes on that firmware.
Lastly (because I can't remember), did you get the unibios from me? If so can you private message me the version number and serial number so if you report exceptions in the future I can quickly reproduce the same setup here to investigate.
Raz,
Sceptre_JLRB is on beta firmware, different and older firmware version than the one we have sent to GadgetUK.
* Traces of horizontal-lines at upper screen: At concrete points in some games, maybe they are the same artifact typical on some games when the sprite number per scanline is overloaded. In particular, I've noticed them in these two cases:
- Magician Lord: When entering a door at 'loading' new stage, and sometimes upon dying. Almost always 1-2 horizontal lines misplace just next to score/other counters.
- Metal Slug 1: When facing a huge boss with quite elements on screen and your character is on the upper screen zone. The same, sometimes 1-2 horizontal lines misplace next or near to score/other counters.
Not sure if it's normal game or just a remnant of a 'timing' issue related with the already fixed horizontal-line glitch on NeoSD. GadgetUK has found both these artifacts on NeoSD, and he'll be testing them on original carts tomorrow.
* Sound crackle in Metal Slug 5: I get some 'crackle' sound glitches, similar to those that occur frequently on multicarts, but here only at few concrete points, like for instance at the final explosion of the 'red turtles' descending elevator at the 2nd mission, and also later (mission 4 or so) in tank explossions when much sounds join together. I don't have the original cart to compare, however, although it doesn't occur on MAME. I don't know if this could be due to some timing minor problem, together with the aforementioned line problem. Anyway, GadgetUK claims that he's heard such crackle at the very same points both in original and bootleg carts. So it's likely to be no issue at all.
However, maybe the sole real issue I'm having right now is the following:
* UniBIOS exceptions: I get some UniBIOS exception warning screens with low occurrence, with subsequent forced resetting. After rebooting, the problem disappears and the game goes on normally. I'm not sure whether this could be due to some kind of crosstalk with the UniBIOS itself. I've noticed that whenever exceptions occur, I had previously checked the UniBIOS options (softdip configuration, jukebox, CRC check) by soft-reset. This only occurs with a low frequency, about 5-10% of games whose UniBIOS/Service Menu options were previously accessed, and then the game plays normal until the exception pops up, sometimes at hi-score screen and others at first stage/fight or just starting the second one. Also, note that the same game under these conditions may give the exception or not, just in a seemingly random fashion. Yet I'd say I never got exceptions when UniBIOS/Service Menu options are not accessed.
Thankyou for testing too =D
On Magician Lord I see that same exact thing when going in and out of doors on the 2nd level - it's really minor but as Raz says its probably to do with Palette RAM access.
'Probaby' is not the right word to use here, it is 100% fact. The palette RAM access glitch/snow is a known situation in NeoGeo hardware and has nothing to do with the neosd or other faulty original game cart. All you are basically seeing is while the 68k is accessing the paletteRAM the display cannot lookup the correct color. This means in most cases when you write a color into PaletteRAM the currently drawn pixel on screen will be the color you are writing. This is why you see a hortz line made of different colored pixels like you do when palettes are updated outside of vblank.
This is another reason why you can instantly see what homebrew demos were never tested on real hardware because you will see this glitching all over the place and in some cases no correct display output at all while the same in emulation looks 100% fine. If you load up that Samsho5 xbox hack you'll see this situation in full effect.
I have a feeling this issue is going to be brought up many times in the future because it is not something you see in emulators. Probably people who come to NeoGeo hardware from emulators are going to question this but those you have played and programmed NeoGeo for years just take it for granted.
The kof2003 palette crash situation you bring up is something totally unrelated to the above glitch but you are right to say its tied in with other issues you have had.
You sure like to argue lol! I accept what your saying, what I am saying is the glitch doesn't appear on originals!
Im not argueing with you, Im just making sure its understoood correctly by other people reading the forum. I did understand what you mean but others may not.
For example, people reading what you have said now. In their minds they are thinking that you are saying this paletteRAM glitch I just mentioned does not happen on originals.. The thing is, it does happen on originals and has always happened on originals. I undstand your relating to the kof2003 crash situaion but others reading may read differently.
If you load up that Samsho5 xbox hack you'll see this situation in full effect.