Aiuto - Cerca - Utenti - Calendario
Versione completa: CPS1.C - All'attenzione di Robiza....
MAME Ö Italian Forum > MAME > WIP / Drivers / Bugs
Mamesick
GiÓ sai.... ecco lo snapshot che ti serviva. Non ho avuto ancora modo di compilare un MAME con la tua modifica perchŔ sar˛ via da casa per 15 giorni e quindi senza il mio fidato PC e costretto a vagare per internet point....

Dacci dentro! wink.gif

robiza
CITAZIONE(Mamesick @ Sep 6 2006, 06:20 PM) *
GiÓ sai.... ecco lo snapshot che ti serviva. Non ho avuto ancora modo di compilare un MAME con la tua modifica perchŔ sar˛ via da casa per 15 giorni e quindi senza il mio fidato PC e costretto a vagare per internet point....

Dacci dentro! wink.gif



la diff sarebbe pronta ma voglio fare altri test
Mamesick
Ho chiesto ad un amico di compilare, ecco il risultato:



Mi sembra ok.... cmq aumentando la luminositÓ ci sono chiazze grigie casuali, comuni in moltissimi giochi capcom e il "carattere" che adesso Ŕ uno spazio ha in effetti sfondo grigio. Urge una tile trasparente....
Haze
CITAZIONE(Mamesick @ Sep 6 2006, 09:09 PM) *
Ho chiesto ad un amico di compilare, ecco il risultato:



Mi sembra ok.... cmq aumentando la luminositÓ ci sono chiazze grigie casuali, comuni in moltissimi giochi capcom e il "carattere" che adesso Ŕ uno spazio ha in effetti sfondo grigio. Urge una tile trasparente....


see this thread
http://www.mameworld.info/ubbthreads/showt...part=1&vc=1

the change needed to correctly reproduce a bug in final fight breaks carrier airwing.

the driver is full of per game hacks anyway.

As you can see fro the PCB shots posted there neither 'emulated' screenshot is right, where the corrupt tile is in MAME there should be a completely black tile, with the grey around them. In your 'fixed' shot it's replaced with another solid grey tile. It looks UGLY on the real hardware too.

I can only conclude that your fix is just another hack, or removing the fix I made for final fight. (which was tfor http://haze.mameworld.info/2006/04/05/cps1...er-final-fight/ this problem if you use mixed roms)
Mamesick
CITAZIONE(Haze @ Sep 7 2006, 01:07 PM) *
see this thread
http://www.mameworld.info/ubbthreads/showt...part=1&vc=1

the change needed to correctly reproduce a bug in final fight breaks carrier airwing.

the driver is full of per game hacks anyway.

As you can see fro the PCB shots posted there neither 'emulated' screenshot is right, where the corrupt tile is in MAME there should be a completely black tile, with the grey around them. In your 'fixed' shot it's replaced with another solid grey tile. It looks UGLY on the real hardware too.

I can only conclude that your fix is just another hack, or removing the fix I made for final fight. (which was tfor http://haze.mameworld.info/2006/04/05/cps1...er-final-fight/ this problem if you use mixed roms)


I remember perfectly the thread you linked and why cawing is broken now.

Yes, it's another kludge in the driver and it's not mine but robiza's work. I know he also fixed tile bugs in 3wonders using the same method (change to transparent or ignore some tiles) is already applied to mercs, mtwins, msword, etc.

So what could be the choice?

1) Rewrite of the driver
2) Remove all hacks in the driver - this will produce new bugs
3) Add other kludges - at least for games that exhibit display bugs

I can always apply robiza's code to my personal build... so I couldn't care... but hey, MAME is a community.
robiza
CITAZIONE(Mamesick @ Sep 6 2006, 10:09 PM) *
Ho chiesto ad un amico di compilare, ecco il risultato:



Mi sembra ok.... cmq aumentando la luminositÓ ci sono chiazze grigie casuali, comuni in moltissimi giochi capcom e il "carattere" che adesso Ŕ uno spazio ha in effetti sfondo grigio. Urge una tile trasparente....


finalmente ho visto una foto di una vera pcb (grazie al link di haze su mametesters); la tile da sostituire Ŕ una tile completamente trasparente; va bene la 0x0000 del gfxset=4
poi ti mando la fix per quando torni



l'hardware cps1 non disegna delle tile in base al codice della tile stessa; nel caso di cawing le tile 8x8 iniziano da 0x5000 e quindi tutte le tile con codice inferiore non vengono disegnate; sfortunatamente non Ŕ chiaro come viene segnalato all'hardware il range delle tile esistenti

problema analogo vale per 3wonders; anche in questo caso all'hardware arrivano dei codici tile fuori dal range ammesso e non vengono disegnate (mi riferisco, per esempio, ai puntini di chariots a fianco all'indicatore delle vite rimanenti o ad esempio al punto che compare quando si inserisce un high score dopo aver cliccato end)
sempre per 3 wonders la tile bianca alla fine del primo livello e le due tile marroni durante il terzo sono dovute ad un problema diverso: Ŕ una tile 16x16 che dovrebbe essere disegnata trasparente; il suo codice Ŕ 0x0000 che Ŕ un valore ammesso per le tile 16x16 nel caso di three wonders; certo Ŕ che l'hardware non la disegna comunque

Mamesick
Benissimo. Complimentoni. w00t.gif

Se vuoi mandami pure la diff giÓ adesso, tanto rimane nella mia casella di posta. wink.gif
Haze
CITAZIONE(Mamesick @ Sep 7 2006, 01:11 PM) *
So what could be the choice?

1) Rewrite of the driver


This basically, although the fact is that some of these things don't make sense. The hardware needs to be studied, and we need to figure out why the broken tiles don't get drawn on the original hardware in the first place. Maybe it really is a per game protection, or maybe it's something to do with the memory access, eg. if one layer is using gfx from a certain part of the rom then the other layer can't use them at the same time.

The only way you're going to know for sure is by getting the real boards and running lots of test code on them.
robiza
CITAZIONE(Haze @ Sep 7 2006, 05:42 PM) *
This basically, although the fact is that some of these things don't make sense. The hardware needs to be studied, and we need to figure out why the broken tiles don't get drawn on the original hardware in the first place. Maybe it really is a per game protection, or maybe it's something to do with the memory access, eg. if one layer is using gfx from a certain part of the rom then the other layer can't use them at the same time.

The only way you're going to know for sure is by getting the real boards and running lots of test code on them.


a point to start maybe can be 3 wonders: at the reset of the machine in mame are visible four strange tile;
three of them have this code: 0x0000, 0xaaaa, 0xffff, three value out of range of the normal 8x8 tile (from 0x5400 to 0x7000); if in a real PCB are visible all the four tiles probably it is in the software the tile 0x0000 are disabled in the game (0x0000 must be not draw; it's sure; 0x0000 is the tile of the chariots bug: strange points in the game)
Kold666
all'accensione la scheda di 3wonders jap fa delle righe verticali bianche mentre testa ram etc.

avevo visto anche una pcb di 3wonders world ma non compaiono quelle righe verticali...

I puntini in chariots non ci sono sulla pcb naturalmente...
robiza
CITAZIONE(Kold666 @ Sep 7 2006, 09:21 PM) *
all'accensione la scheda di 3wonders jap fa delle righe verticali bianche mentre testa ram etc.

avevo visto anche una pcb di 3wonders world ma non compaiono quelle righe verticali...

I puntini in chariots non ci sono sulla pcb naturalmente...


riesci a fare una foto? un video forse sarebbe troppo laugh.gif

se qualche volenteroso del forum vuol dare una mano per raccogliere informazioni potreste fare un lavoretto; fate partire un gioco cps1, una volta che si vede l'attract mode:
1) premete F4 (trovate la palette)
2) premete INVIO (trovate la GFX 0/4 8x8)
3) premendo continuamente PAG DOWN (a fianco del tastierino numerico) fino a che trovate grafica comprensibile (ci vuole un po' di sensibilitÓ) - segnate il numero di partenza (prima quello di sinistra poi quello in alto) e scorrendo ancora il numero finale
4) premete ý (la i accentata) (trovate la GFX 1/4 8x8)
5) premete ancora ý (trovate la GFX 2/4 16x16)
6) come punto 3 e segnatevi il numero di partenza e finale
7) premete ancora INVIO (gfx 3/4 32x32) (attenzione se premete ancora ý il gioco va in crash)
8) come punto 3 e segnatevi il numero di partenza e finale
9) mandatemi i valori raccolti

se provate a farlo con 3wonders dovreste trovara:

GFX 0: 5400-6fff
GFX 2: 0000-29ff ma anche 5400-7fff
GFX 3: 0E00-1500

per chi Ŕ interessato tradotto in byte:
0000-53ff GFX 2
5400-6fff GFX 0
7000-a7ff GFX 3
a800-ffff GFX 2
robiza
CITAZIONE(Haze @ Sep 7 2006, 05:42 PM) *
This basically, although the fact is that some of these things don't make sense. The hardware needs to be studied, and we need to figure out why the broken tiles don't get drawn on the original hardware in the first place. Maybe it really is a per game protection, or maybe it's something to do with the memory access, eg. if one layer is using gfx from a certain part of the rom then the other layer can't use them at the same time.

The only way you're going to know for sure is by getting the real boards and running lots of test code on them.


maybe if sprite is using gfx from a certain part of the rom then the layers can't use them at the same time

for example for three wonders the 0x0000 tile is a sprite tile 16x16 and it is the source of the bug in mametesters (a strange tile at the end of level one)
is there a easy way to discover (in runtime of course) what part of the rom is used by sprite?
emuLOAD
no real idea, but it would only make sense that a runtime debugger would give information regarding the data reads, including the offset adress being read wouldn't it?

Sorry if its profainly stupid....
robiza
CITAZIONE(emuLOAD @ Sep 8 2006, 05:41 PM) *
no real idea, but it would only make sense that a runtime debugger would give information regarding the data reads, including the offset adress being read wouldn't it?

Sorry if its profainly stupid....


manualmente so trovare i range degli sprite, delle layer tile 8x8, 16x16, 32x32 ma poi diventa un kludge per ogni gioco; comunque secondo me ognuna delle 4 zone non puo' sovrapporsi ed Ŕ cosi' che l'hardware "decide" di non disegnare una tile che non appartiene al proprio range; per capirci se Ŕ sprite non puo' essere sfondo anche se entrambi 16x16 (come succede in three wonders) o se Ŕ tile 32x32 non puo' essere tile 8x8 (come succede in strider)
Haze
please do not submit obvious hacks.
Mamesick
CITAZIONE(Haze @ Sep 9 2006, 05:49 PM) *
please do not submit obvious hacks.


Please remove all existing hacks from all MAME drivers at this point. I'm not joking, really. Please start from stvhacks.c....
Haze
CITAZIONE(Mamesick @ Sep 9 2006, 04:52 PM) *
Please remove all existing hacks from all MAME drivers at this point. I'm not joking, really. Please start from stvhacks.c....


Most of stvhacks.c is speedups, and protection workarounds rather than video hacks, speedups are accepted as standard until processors are fast enough, at which point they will be removed. Protection workarounds (which may not even really be hacks) are accepted as they allow other elements of the emulation to be fixed. How many hacks do you see in vidhrdw/stvvdp1 and stvvdp2 ?

These hacks that are being submitted are just stupid. They don't allow progress to be made on other areas of the emulation, they're just crappy hacks to make things look nicer, and there are already enough of them without adding more. The sprite centering on ssv was ok, everything else is garbage.
robiza
CITAZIONE(Haze @ Sep 9 2006, 05:49 PM) *
please do not submit obvious hacks.


you are joking! laugh.gif laugh.gif laugh.gif laugh.gif

and mercs? and msword? and knights? and ssf2t? and xmcota?
and all games with famous tile 0x0020 8x8?

/* 0x0020 appears to never be drawn for CPS1 games (it is drawn for CPS2 games though, see gigawing '0' in score for example) */

for the same cause 0x0020 8x8 appears to never be drawn for CPS1 games , 0x0000 16x16 in three wonders appears to never be drawn!

sprite 16x16 ------- 0000 ----- 53ff
tile 8x8 ------------- 5400 ----- 6fff
tile 32x32 ---------- 7000 ----- a7ff
tile 16x16 ---------- a800 ----- ffff

i understand! the kludge is only for mamedev component! it was enough to say it !
i don't continue this discussion for avoid the possibility you delete other kludge in mame source!
Haze
we want to find ways to *remove* hacks / kludges, not just add more. Once it reaches a certain point it's clear that there is something very *wrong* or not understood. Papering over the cracks again and again only leads to an ugly mess like the old System 16 and System 32 drivers.

A study of the hardware is needed, somebody needs to figure out how these things really worked. At this stage there is no point at all in adding more and more hacks to the CPS1 driver because it tells us _nothing_, and yes, I am tempted to remove the existing hacks.
Mamesick
CITAZIONE(robiza @ Sep 9 2006, 07:02 PM) *
i understand! the kludge is only for mamedev component! it was enough to say it !


How true is this sentence.....sad but true.
emuLOAD
lol, kk ppl, cool down now (referred to everybody wink.gif)

I do see David's point here. simply adding extra hacks brings the core further and further away from its purpose. I wouldn't agree, however, that these things are to be binned mercylesly. While i perfectly agree with removing hacks from mame (I for one am not overly concerned about a game's working status as I seldomly play anyways), I also understand why many people do like them, as they enable playing and allow for testing other areas of the system. My personal opinion is that all non-dev critical (i.e. not neccessary to allow developement of the systems emulation) hacks should be "removed" from the main core, while implemented in one or more of the several custom builds out there. This way we'd have a double win, while we keep mame as clean as possible, we also allow other people to do what they want...

ciao smile.gif

Trad:

ok, gente, ora rinfrescate i bollenti spiriti (tutti)

Capisco il punto di vista di David. Aggiungere hacks allontana sempre piu il core dall'obiettivo che si prefissa. Non sarei pero d'accordo con l'eliminarle ed ignorarle a priori. Mentre sono perfettamente d'accordo con la rimozionedi tutti gli hacks dal MAME (Tanto io per primo non gioco) capsico anche le argomentazioni a favore, visto che molta gente prova piaacere proprio nel giocare o magari addirittura servono ai dev per p'oter usare il gioco capendo quindi come emularne altre componenti. A mio parere tutti gli hack non neccessari allo sviluppo sarebbero da togliere dal codice ufficiale, per essere invecie inclusi nelle miriadi di versioni personalizzate a disposizione. Questo porterebbe tutti alla vittoria, visto che il MAME continuerebbe la sua ascesa verso l'emulazione "perfetta", e coloro che vogliono solo giocare ne avrebbero la possibilitÓ.

ciao smile.gif
Mamesick
CITAZIONE(Haze @ Sep 9 2006, 06:51 PM) *
Most of stvhacks.c is speedups, and protection workarounds rather than video hacks, speedups are accepted as standard until processors are fast enough, at which point they will be removed.


Speedups are accepted to make the games playable with current CPUs.... But this rule is not applied to every driver. Who follows MAME *knows* that Radical Bikers and other very slow games could be at least playable with some speedups here and there. This is a fact.

-- Gli speedups sono accettati per rendere i giochi "giocabili" con le attuali CPU.... Ma questa regola non Ŕ applicata ad ogni driver. Chi segue il MAME *sa* che Radical Biker e altri giochi molto lenti potrebbero essere almeno giocabili con qualche speedups qua e lÓ. Questo Ŕ un dato di fatto.--

CITAZIONE(Haze @ Sep 9 2006, 07:09 PM) *
I am tempted to remove the existing hacks.


So do it.

--E allora fallo.--
emuLOAD
If this turns into a flame all participants will receave a warning, so keep it constructive....
Swos
Piccole note: pregherei chi scrive in inglese, di tradurre poi in italiano per dar modo a tutti di seguire la discussione
Mamesick
CITAZIONE(emuLOAD @ Sep 9 2006, 09:06 PM) *
lol, kk ppl, cool down now (referred to everybody wink.gif)

I do see David's point here. simply adding extra hacks brings the core further and further away from its purpose. I wouldn't agree, however, that these things are to be binned mercylesly. While i perfectly agree with removing hacks from mame (I for one am not overly concerned about a game's working status as I seldomly play anyways), I also understand why many people do like them, as they enable playing and allow for testing other areas of the system. My personal opinion is that all non-dev critical (i.e. not neccessary to allow developement of the systems emulation) hacks should be "removed" from the main core, while implemented in one or more of the several custom builds out there. This way we'd have a double win, while we keep mame as clean as possible, we also allow other people to do what they want...

ciao smile.gif


I disagree. Or better, I could agree with you just only if the "no hacks in source!!" rule will be applied to Developers too. It's a known fact (and not only my personal opinion) that every hack submitted to MAMEDev is rejected or very hardly accepted... but if is a Dev that write a driver and use some hacks (including VIDEO KLUDGES) generally his work is accepted without problems.

-- Non sono d'accordo. O meglio, potrei esserlo solo se la regola dei "no hacks in source!!" fosse applicata anche agli sviluppatori. E' un dato di fatto (e non solo opinione mia personale) che ogni hack inviato ai MAMEDev Ŕ rifiutato o accettato con molta difficoltÓ... ma se Ŕ un Dev a scrivere un driver e usa degli hacks (inclusi quelli per l'emulazione video) generalmente il suo lavoro Ŕ accettato senza problemi. --
robiza
CITAZIONE(emuLOAD @ Sep 9 2006, 09:06 PM) *
lol, kk ppl, cool down now (referred to everybody wink.gif)

I do see David's point here. simply adding extra hacks brings the core further and further away from its purpose. I wouldn't agree, however, that these things are to be binned mercylesly. While i perfectly agree with removing hacks from mame (I for one am not overly concerned about a game's working status as I seldomly play anyways), I also understand why many people do like them, as they enable playing and allow for testing other areas of the system. My personal opinion is that all non-dev critical (i.e. not neccessary to allow developement of the systems emulation) hacks should be "removed" from the main core, while implemented in one or more of the several custom builds out there. This way we'd have a double win, while we keep mame as clean as possible, we also allow other people to do what they want...

ciao smile.gif

Trad:

ok, gente, ora rinfrescate i bollenti spiriti (tutti)

Capisco il punto di vista di David. Aggiungere hacks allontana sempre piu il core dall'obiettivo che si prefissa. Non sarei pero d'accordo con l'eliminarle ed ignorarle a priori. Mentre sono perfettamente d'accordo con la rimozionedi tutti gli hacks dal MAME (Tanto io per primo non gioco) capsico anche le argomentazioni a favore, visto che molta gente prova piaacere proprio nel giocare o magari addirittura servono ai dev per p'oter usare il gioco capendo quindi come emularne altre componenti. A mio parere tutti gli hack non neccessari allo sviluppo sarebbero da togliere dal codice ufficiale, per essere invecie inclusi nelle miriadi di versioni personalizzate a disposizione. Questo porterebbe tutti alla vittoria, visto che il MAME continuerebbe la sua ascesa verso l'emulazione "perfetta", e coloro che vogliono solo giocare ne avrebbero la possibilitÓ.

ciao smile.gif


anch'io comprendo il punto di vista ma non sono d'accordo e spiego perche'; si sostiene che i kludge fanno diminuire l'incentivo a trovare una soluzione "corretta" e quindi sono dannosi; io dico che partendo dai kludge invece si puo' tentare di estrapolare una regolaritÓ che puo' diventare fonte per scoprire cosa c'e' che non va! provo a spiegarmi con un esempio:
attualmente Ŕ regola condivisa da tutti gli emulatori compreso il mame che una certa tile (la 0x0020 di dimensioni 8x8) non debba essere disegnata dall'hardware cps1 (il cps2 invece la disegna ma solo nel gioco Gigawing); secondo la mia opinione invece Ŕ un effetto collaterale non una regola; inizialmente mi sono dedicato a trovare altre tile che non vanno disegnate solo per eliminare il difetto grafico in 3 wonders; da questa ricerca ho scoperto alcune regolaritÓ che avrei scoperto prima se fossero stati presenti i relativi kludge (piu' o meno ho perso una decina di ore di test che avrei potuto risparmiarmi); probabilmente altri avevano fatto gli stessi test ma l'unica fonte realmente pubblica di conoscenza Ŕ il source del mame e li' non c'e' traccia di ipotesi di comportamento dell'hardware
questo vuol dire che ogni volta si perde un sacco di tempo per scoprire l'acqua calda;

la mia ipotesi ovviamente smentibile sulla gestione delle tile da non disegnare: la memoria Ŕ suddivisa a salti di 0x0400 byte; ogni zona puo' essere o sprite 16x16, o tile 8x8, o tile 16x16 o tile 32x32; la zona Ŕ mappata a livello software; come? avendo tutti i kludge si puo' andare avanti sulle ipotesi

la mia conclusione: inserite i kludge nei driver! al limite lasciandoli commentati!
emuLOAD
d'accordo con tutto quello che dici, che fondamentalmente Ŕ quello che intendevo io, tenere, in un modo o nell'altro, cio che puo servire per lo sviluppo... ciao smile.gif
Haze
Hacks are generally accepted when they benefit the driver *development* in other ways. If they do not, and simply patch over problems with the driver then they are not.

Further CPS1 patches won't help the driver develop further, they just cover up the fact that there is something *wrong* with the driver. This is not a good thing.

There is a limit to how many hacks are acceptable in a driver, beyond that it becomes quite clear that the driver simply needs rewriting with additional information from the hardware. That is the case with the CPS1 driver. Adding extra hacks is a waste of time, and leaves less reason to find a real fix.

It is true that dev submissions are generally accepted, but in most cases devs are *trusted*. It is assumed that any hacks in a development driver are for the benefit of development, eg. to allow the game to progress further and for other bugs to be fixed. If you're annoyed about submissions not being accepted then get an eeprom programmer, get a board, write some trojan code, find out how things work and submit real fixes. This is the only way things will move forwards, further hacks are a step backwards.
robiza
CITAZIONE(Haze @ Sep 10 2006, 04:38 AM) *
Hacks are generally accepted when they benefit the driver *development* in other ways. If they do not, and simply patch over problems with the driver then they are not.

Further CPS1 patches won't help the driver develop further, they just cover up the fact that there is something *wrong* with the driver. This is not a good thing.

There is a limit to how many hacks are acceptable in a driver, beyond that it becomes quite clear that the driver simply needs rewriting with additional information from the hardware. That is the case with the CPS1 driver. Adding extra hacks is a waste of time, and leaves less reason to find a real fix.

It is true that dev submissions are generally accepted, but in most cases devs are *trusted*. It is assumed that any hacks in a development driver are for the benefit of development, eg. to allow the game to progress further and for other bugs to be fixed. If you're annoyed about submissions not being accepted then get an eeprom programmer, get a board, write some trojan code, find out how things work and submit real fixes. This is the only way things will move forwards, further hacks are a step backwards.


i understand your postion or the position of mamedev but i don't agree!
for example ssv is all kludged but with kludged correct values maybe i can understand how crt works; for example this are values of crt register 6a/6b and 6c/6d and the values of height of visible area for some games:

ultrax:
6a/6b : 00 12
6c/6d : 01 02
height of visible area = f0
6c/6d - 6a/6b = f0

eaglshot:
6a/6b : 00 16
6c/6d : 00 f6
height of visible area = e0
6c/6d - 6a/6b = e0

maybe 6a/6b is the start y of visible area and 6c/6d is the end y.
i don't know if it is the right interpretation of the register 6a,6b,6c,6d but only with the values kludged i have get an ipothesis
ok! with kludges the source is full of garbage, i agree; where i can find the kludges not included in the source for all games cps1 ?
i have an ipothesis about how works cps1 hardware! with kludges i can know if my ipothesis is wrong or if can be right (obviously with other test, in real hardware too)

traduzione: premetto che il mio inglese fa schifo; ho studiato tedesco

io capisco la tua posizione e la posizione dei mamedev ma non la condivido!
per esempio ssv Ŕ tutto "kludgiato" ma con i valori corretti "kludgiati" forse posso capire come il crt lavora (crt pilota la grafica dell'hardware ssv); per esempio questi sono i valori dei registri crt 6a/6b e 6c/6d e il valore dell'altezza dell'area visbile per alcuni giochi:

ultrax:
6a/6b : 00 12
6c/6d : 01 02
altezza dell'area visibile = f0
6c/6d - 6a/6b = f0

eaglshot:
6a/6b : 00 16
6c/6d : 00 f6
altezza dell'area visibile = e0
6c/6d - 6a/6b = e0

notare l'uguaglianza fra l'altezza e la differenza dei valori dei registri
forse 6a/6b Ŕ l'inizio dell'area visibile e 6c/6d la fine
non so se Ŕ l'interpretazione corretta dei registri 6a,6b,6c,6d ma solo con i valuri "kludgiati" sono riuscito a formulare un'ipotesi;
ok con i kludge il codice Ŕ pieno di spazzatura! sono d'accordo! dove posso trovare i kludge non inclusi nel codice sorgente per tutti i giochi cps1?
io ho un'ipotesi su come lavora l'hardware cps1! con i kludge posso confutare l'ipotesi o vedere se puo' essere vera (dopo altri test , anche su pcb reali)
Haze
Yes, sometimes the kludges can hint towards a real solution, other times they don't. There are enough 'odd' cases to test in CPS1 already, and as I've said, I think the only way to know anything for sure with that system is to run code on the real board. Once you get to a certain level of hacks, with hacks all over the place it stops helping as much. Nobody is stopping you looking for test cases when trying to find a real fix for the bug, but I regard a real fix as unlikely without extensive tests on the hardware, I tried many things, each of which introduced new bugs in other games. Source *comments* about bugs (set, tilenumers, situation, other details explaining the problem, what has been tried etc.) and reports on Mametesters are more useful than kludges and hacks. Once a bug is kludged Mametesters will usually remove a report, people forget it exists.

We want at least some of the errors to be visible, by having errors visible it screams 'fix me'. 'fix me' does not mean 'hack me'

Jan Klaas (Final Burn Alpha) did work out all the CRT registers on SSV.c about a year ago, but never got around to submitting his code. Nobody appears to have seen or heard from him in about 4 months tho, it's a bit of a concern, but people do end up busy with other things. Either way that says to me there is plenty enough information aoubt the crt registers to figure those out. Apparently Twin Eagle 2 does some strange tricks with the register (reduces screen height to 1 at times IIRC, he wanted to see how it looks on real hardware)

Again a problem here is if you introduce hacks to the crt size / screen offset, and hacks to the sprite offset then you might be fixing bugs in the crt / sceen offset by modifying the sprite offsets a bit, and the screen offsets another bit, at which point it isn't clear if the bug in the code is in the crt register emulation, or the sprite emulation. Given this scenario you might fix the display area code but think it's wrong because some games are broken due to hacks in the sprite code.

The Eagle Shot Sammy Logo needs raster interrupt effects, it should be something like the Sammy logo on Viewpoint (neogeo)
Layne
CITAZIONE(Kold666 @ 07 September 2006, 20:21) *
all'accensione la scheda di 3wonders jap fa delle righe verticali bianche mentre testa ram etc.

avevo visto anche una pcb di 3wonders world ma non compaiono quelle righe verticali...

Kold mi serve una foto da postare su MT delle righe verticali della tua pcb jap please wink.gif
Kold666
guarda, e' inutile perche' credo che ci sia un rewrite nell'aria smile.gif
cacis
sarebbe ora
Layne
Nicola vuole una verifica su una scheda di Mega Twins, chi ce l'ha? MKL help please! smile.gif
Kold666
ce l'ha stefan lindberg
Layne
Lo contatto subito wink.gif
Questa è la versione 'lo-fi' del forum. Per visualizzare la versione completa con molte più informazioni, formattazione ed immagini, per favore clicca qui.