N64 Glide Plugin
- Thread starter Dave2001
- Start date
- Status
LoneRaven
Glide64 Website Guy
Great job dave. Now I have a question and a suggestion. Instead of having the user choose the ucode, why not use rom detection to select the corret ucode accordingly. You could probably leach code off of the PJ detection if needed. My suggestion also ties in to my question. Instead of using huge switch statements, can you not use rom detection. That way, you can have rom specific code without continually testing what the rom is. Correct me if I am wrong, but wouldn't this add a bit more speed and cleaner code?
LoneRaven
Glide64 Website Guy
To flow:
No, the CRC detection is not part of Jabo's D3D video plugin. It is part of the main program. Regardless of the used plugin, the list of Roms names and info is generated using the core of the emulator. I am not trying to belittle Dave, but save him time. Why not just (leech = site and use) leech it and move on without spending a great deal of time finding out how the CRC codes work. Anyway, where is there a ucode list of all the games. I looked everywhere to compile a ucode list for Dave and ended up using the Daedelus findings. According to Dave not all of them are correct either.
Smiff
Emutalk Member
LoneRaven said:
Er.. no, the uCode detection is definately part of the plugin, I know from working with Jabo and supplying him CRC->uCode references... it is not real 'autodetection' at all, his video plugin contains a huge table, each CRC has one corresponding uCode but one uCode can have many CRCs, it has to be checked on state loads also because they can change during execution.. simple to understand but not as easy a thing as it first appears to make reliable... still better than a simple ROM header CRC lookup though, but if you have relatively low compatibility i don't see that being a problem... I'm not sure of the formulae Jabo is using to derive his CRC, maybe he'd tell you, maybe he wouldn't
flow``
flow``
heh i have no idea what you think i meant and how you stated that paragraph.. but anyway
the CRC detection is a simple calculation of the first 8 bits of the rom header, then the seconds crc is a calc of the last 8 bits
is it bytes or bits? i can't remember
i doubt the crc has much to do with the roms corresponding ucodes since some games for instance; yoshi's story; relies on 2 ucodes doesn't it? one for the 2d gfx/sprites and another for the 3d animation and stuff
correct me if im' wrong..
the CRC detection is a simple calculation of the first 8 bits of the rom header, then the seconds crc is a calc of the last 8 bits
is it bytes or bits? i can't remember
i doubt the crc has much to do with the roms corresponding ucodes since some games for instance; yoshi's story; relies on 2 ucodes doesn't it? one for the 2d gfx/sprites and another for the 3d animation and stuff
correct me if im' wrong..
I think you are speaking about 2 totally different things. There's a CRC code in the header of each rom : this is used in emus to identify a rom. If the ucode is stored in an ini file, the emu can find it with the CRC that is in the header rom but this has nothing to do with autodetecting an ucode.
The other thing that can be checked by CRC is the RSP code that is simulated by the GFX plugin. This can be used to autodetect ucode. I have tried to implement it in the glide64 source code but i haven't get any result : i have many differents CRC on roms that are supposed to have the same ucode.
The other thing that can be checked by CRC is the RSP code that is simulated by the GFX plugin. This can be used to autodetect ucode. I have tried to implement it in the glide64 source code but i haven't get any result : i have many differents CRC on roms that are supposed to have the same ucode.
Hacktarux said:
Well acording to Smiff
That means that the CRC's are multitudinal for each uCode.
This seems like an inherently unreliable method really. I'm sure it works great for a specific few roms. I've no clue though what would be better.
CRC calculations very all over as well, they depend on the polynomial you are using and the Initial State of the CRC register you are storing the CRC in. Most CRC generators start with All ones to eliminate dead zones for CRC's. For each byte of the CRC value you need a 256 entry table to look up a new CRC value. Then on matching CRC's generated by various RSP code patterns being sent to the GPU. This costs time and is kind of challenging to implement. Is there a better way though? That's a tough question.
If one can use LLE for detecting the codes used then use HLE afterward for actually doing the emulation that might have promise. With LLE you will have a huge slow down but it could allow you to detect the uCode being used more acurately.
Cyb
You posted that just to complain about action?
The last post was by mean and it was about using CRC's for detecting what uCode is being used by the N64 program. My Last suggestion was using an LLE interpretor to determine what set of uCodes were being used (and use it to generate a real image as well) then switching to HLE for when the uCode is determined. Code that isn't compiled properly HLE wise would force another LLE pass and then redetct the uCode set being used.
Not simple but more likely to work than using CRCs
Cyb
The last post was by mean and it was about using CRC's for detecting what uCode is being used by the N64 program. My Last suggestion was using an LLE interpretor to determine what set of uCodes were being used (and use it to generate a real image as well) then switching to HLE for when the uCode is determined. Code that isn't compiled properly HLE wise would force another LLE pass and then redetct the uCode set being used.
Not simple but more likely to work than using CRCs
Cyb
Hmm, i can't understand exactly how you want to do it with a lle interpreter but when a task is started on the N64, the address and the length of the ucode is given to the rsp in order to allow it to load the code in its own memory. It's that code that we have to identify, and we have less than 10 possibilities. The CRC algorithm speed is not a problem because we only have to make it the first time a gfx task is launched (then to be sure that it is always the same ucode that is used, we can check if the address where the ucode start is always the same). And because of the few possibilities we have, the CRC algorithm doesn't need to be very accurate.
I think the problem i had is because the length that is indicated, is larger than the real one (or there is data that are not part of the ucode).
I think the problem i had is because the length that is indicated, is larger than the real one (or there is data that are not part of the ucode).
So you don't think that 32bit CRC's are necessary then? Possibly 24bit or 16 bit? Those use less space and are faster to calculate. (One less look up table entry to use to get the next byte basically).
It sounds to me that you might have to parse the data stream some to find out what is in it or find non RSP codes then filter them out. Not sure how to do that but hey.
The other problem is as someone stated early is some games switch code sets and use them for different things. Thus you might have to do your CRC check every frame in order to automatically adjust for new uCodes. And if you have combined uCode sets.. what then?
If as an example there are 8 uCode sets. From those uCode sets you can have potentially 2 Code sets used together that would give you the possibility of 56 combinations of CRCs. Plus you still need to throw out non RSP code (does the same chip handle sound data as well?).
Cyb
It sounds to me that you might have to parse the data stream some to find out what is in it or find non RSP codes then filter them out. Not sure how to do that but hey.
The other problem is as someone stated early is some games switch code sets and use them for different things. Thus you might have to do your CRC check every frame in order to automatically adjust for new uCodes. And if you have combined uCode sets.. what then?
If as an example there are 8 uCode sets. From those uCode sets you can have potentially 2 Code sets used together that would give you the possibility of 56 combinations of CRCs. Plus you still need to throw out non RSP code (does the same chip handle sound data as well?).
Cyb
I'm almost sure that it is impossible to have two ucodes for the same task. Each time a task is lauched the RSP load the ucode and execute the display (or audio) list. AFAIK, most roms use only one graphic ucode but maybe there are some that use one for 3d and one for 2d.
Audio tasks are handled by the same chip but not at the same time ! The emulator detect if it is a graphic task or an audio one before sending it to the plug-in.
For these reasons, i think that once we have identified the ucode, we only have to check at each frame if the ucode address is always the same => just one test. We are very unlucky if the rom put two different ucodes at exactly the same address.
Audio tasks are handled by the same chip but not at the same time ! The emulator detect if it is a graphic task or an audio one before sending it to the plug-in.
For these reasons, i think that once we have identified the ucode, we only have to check at each frame if the ucode address is always the same => just one test. We are very unlucky if the rom put two different ucodes at exactly the same address.
OP
Dave2001
Moderator
- Thread Starter
- #139
grr, it stopped emailing me about new posts, so I haven't checked this forum for about 5 days
Anyway, about the flipping problem on voodoo 1: Soon I'm going to implement something that should fix the texmirror problem, but about the full-screen flipping, do you think that setting the origin to upper-left instead of lower-left would fix it (maybe voodoo1 doesn't support lower-left origin?)
Thanks for trying to figure out how to autodetect ucodes!
Anyway, about the flipping problem on voodoo 1: Soon I'm going to implement something that should fix the texmirror problem, but about the full-screen flipping, do you think that setting the origin to upper-left instead of lower-left would fix it (maybe voodoo1 doesn't support lower-left origin?)
Thanks for trying to figure out how to autodetect ucodes!
Hacktarux said:
Hmmm.. So what you are saying for each task list the RSP code used is usually one ucode?
Then once you have identified each pointer to the task list you only need to check for the address for each uCode pass.
Might work.. assuming that uCodes sets are sent singularly to be processed that is. Might have a problem with getting CRC's to match ucodes though. Since CRC's are supposed to be unique as possible for a given data stream.
How are you matching uCode to CRC's?
Cyb
- Status