User talk:SMKDAN: Difference between revisions
No edit summary |
No edit summary |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 7: | Line 7: | ||
Okay, I see. Do you think it's possible to simulate other cuts such as on DOTA/DOTB... and on those in between lspc/B1 without too much effort ? I'll trace out the old chips pinouts from a dead board asap.--[[User:Furrtek|Furrtek]] 11:07, 18 June 2012 (CEST) | Okay, I see. Do you think it's possible to simulate other cuts such as on DOTA/DOTB... and on those in between lspc/B1 without too much effort ? I'll trace out the old chips pinouts from a dead board asap.--[[User:Furrtek|Furrtek]] 11:07, 18 June 2012 (CEST) | ||
I'd like to do something like that but I need low level info on how those work. I read DOTA/DOTB is output by ZMC2 or whatever when pixel is opaque and goes to LSPC2, so NEO-B1 does not automatically drop transparent pixels and requires LSPC to command it to draw every individual pixel? With xpos sent to it on P-bus etc.? That's my best guess for now. All the other LSPC<->B1 signals have really cryptic names but I have guesses as to what they are, but no easy way to confirm it. If the right info was posted I'd modify MAME's driver to create some realistic pics later on. | I'd like to do something like that but I need low level info on how those work. I read DOTA/DOTB is output by ZMC2 or whatever when pixel is opaque and goes to LSPC2, so NEO-B1 does not automatically drop transparent pixels and requires LSPC to command it to draw every individual pixel? With xpos sent to it on P-bus etc.? That's my best guess for now. All the other LSPC<->B1 signals have really cryptic names but I have guesses as to what they are, but no easy way to confirm it. If the right info was posted I'd modify MAME's driver to create some realistic pics later on.--[[User:SMKDAN|SMKDAN]] 09:48, 20 June 2012 (CEST) | ||
I really have no idea how both graphic chips work, I'm not even sure where are the line buffers (B1 from what you're saying ?). I don't have much equipment so all I'll be able to get is the pinouts. Signals between the chips will be hard to decrypt with what I have, curious to see what will go on if those lines are cut/pulled low/down. Kyuusaku said he had reversed some of the internal logic but don't know if he'll share. | |||
Weird they always had 2/3 chips for graphics instead of just 1, they never got to integrate everything in one even with NEO-GRZ...--[[User:Furrtek|Furrtek]] 11:13, 20 June 2012 (CEST) | |||
I only guessed that buffers are on B1 since that's where the GFX data and palette addresses come from. It just seemed odd to move it back and forth between LPSC/B1 like that and the B1 would otherwise have not much to do apart from watchdog and 68k palette access. It's still just a guess though, I have nothing 100% on it and I'm in a bad position to figure it out myself. It would be cool if you manage to figure anything out from those. It's already known what has to be sent to B1 based on how they're hooked up, just don't know how it's done exactly. --[[User:SMKDAN|SMKDAN]] 09:10, 23 June 2012 (CEST) |
Latest revision as of 07:10, 23 June 2012
Excellent page about the graphic glitches, will definitely take some time to get the pinout of lspc-a/pro chips next month. How did you emulate the glitches, is MAME low level enough to "cut the traces" in the code ? --Furrtek 09:02, 17 June 2012 (CEST)
Thanks, any extra info you have would be great. I didn't modify MAME. It's just some tiny C apps that read in the unmodified ROMs and output files with the glitches simulated and ran MAME with those. --SMKDAN 08:30, 18 June 2012 (CEST)
Okay, I see. Do you think it's possible to simulate other cuts such as on DOTA/DOTB... and on those in between lspc/B1 without too much effort ? I'll trace out the old chips pinouts from a dead board asap.--Furrtek 11:07, 18 June 2012 (CEST)
I'd like to do something like that but I need low level info on how those work. I read DOTA/DOTB is output by ZMC2 or whatever when pixel is opaque and goes to LSPC2, so NEO-B1 does not automatically drop transparent pixels and requires LSPC to command it to draw every individual pixel? With xpos sent to it on P-bus etc.? That's my best guess for now. All the other LSPC<->B1 signals have really cryptic names but I have guesses as to what they are, but no easy way to confirm it. If the right info was posted I'd modify MAME's driver to create some realistic pics later on.--SMKDAN 09:48, 20 June 2012 (CEST)
I really have no idea how both graphic chips work, I'm not even sure where are the line buffers (B1 from what you're saying ?). I don't have much equipment so all I'll be able to get is the pinouts. Signals between the chips will be hard to decrypt with what I have, curious to see what will go on if those lines are cut/pulled low/down. Kyuusaku said he had reversed some of the internal logic but don't know if he'll share. Weird they always had 2/3 chips for graphics instead of just 1, they never got to integrate everything in one even with NEO-GRZ...--Furrtek 11:13, 20 June 2012 (CEST)
I only guessed that buffers are on B1 since that's where the GFX data and palette addresses come from. It just seemed odd to move it back and forth between LPSC/B1 like that and the B1 would otherwise have not much to do apart from watchdog and 68k palette access. It's still just a guess though, I have nothing 100% on it and I'm in a bad position to figure it out myself. It would be cool if you manage to figure anything out from those. It's already known what has to be sent to B1 based on how they're hooked up, just don't know how it's done exactly. --SMKDAN 09:10, 23 June 2012 (CEST)