| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
A way to track down hardware malfunction
Hi there.
I've already wrote about the problem in http://noname.c64.org/csdb/forums/?roomid=12&topicid=92251, however I've got no response.
The problem is more generic than this single FLI routine used in Mirage (wonderful BTW :) picture.
So here we go again: I have two C64C with mobos:
- Assy No. 250469/252311 Rev.4
- Assy No. 250469/252311 Rev.B
Mirage picture display routine doesn't work:
http://c64scene.pl/files/noes_101.jpg
however, when I've used generic FLI displayer, it works (besides first 3 columns, which most probably that routine doesn't support at all):
http://c64scene.pl/files/test2_126.jpg
As far as I can tell those pictures have similar (or even worse - including hangs) effects on mine machines:
* Fundamentals of Icosahedral Symmetry
* Retired Clown
* Sanxion Replugged 2009
* Sthaeirwayll
* The Mob
* Vampires? Oh I bake them in the oven!
Those, for example, works just fine:
* Landing in the Village
* Silphur Surphur
* Mamba #10
And btw, for now I cannot use any other way to transfer data to C64 than a datasette with turbo cartridge (BlackBox v2) - can't wait for my 1541ultimate.
Has anyone have similar effect on those boards? Is there any way to check/repair my hardware? |
|
... 20 posts hidden. Click here to view all posts....
|
| |
MagerValp
Registered: Dec 2001
Posts: 1074 |
Quoting ClarenceThe problem with this, not all illegal opcodes are stable, and some colors you can't have without them.
The opcode itself generates the color, the result (which is unpredictable on unstable opcodes) is discarded. Or does LAX #imm randomly crash on some machines? |
| |
hedning
Registered: Mar 2009
Posts: 4720 |
All the pics above works fine on my C64G, except "noes", but it bugs just a little on the right side of the pic. Will check ASSY and VIC, and two more c64:s. |
| |
Sander
Registered: Jan 2002
Posts: 493 |
Quoting EnthusiUBER fail,
have we become emu-scene?
I vote for no more screenshots of gfx releases.
Usually there are like 20 votes and 10 downloads.
Shame on us/them/everyone.
Butbut.. The quality of the pixels remains, don't forget :)
I'd like to see someone else do a (x)fli display routine generated straight from a pixel editor. Groepaz pointed out yesterday it seemed impossible. Lars' work deserves nothing but praise.
Quoting FatfrostIf it doesnt work on the real machine then what's the point of releasing it? You may as well just release it on Pouet as a c64 inspired piece. I mean we all come together because we love the real c64 right, not an emulated piece of software from 1982?! Peace.
Isn't it true you have used the Timanthes prg-export yourself? ;) Additonally, your logic outrules the usage of VSP and probably more things too. |
| |
hedning
Registered: Mar 2009
Posts: 4720 |
My C64G, where all pictures mentioned above works fine, except "noes" (bugs a little in the right border - two stripes):
Mobo: 250469/252311 rev.4:
VIC-II: 8565R2/0888 22
CPU: 8500/0988 24
I also tested them all on a C64C, and got the EXACT same result as above: all pics mentioned above works fine, except "noes" that have the exact same bug in the right border (I add a pic of the bug below).
Mobo: 250469/252311 rev.A:
VIC-II: 8565R2/3789 22
CPU: 8500/3289 24
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
@hedning: you see the exact same "bugs" (grey dot in the border) in vice using x64sc set to C64C and "full border" enabled.
This is due to updating $d020 (to $00) in the border area. |
| |
Clarence
Registered: Mar 2004
Posts: 121 |
@Tlr + Magervalp, yeah my bad, I didn't examine the code much last time, just had a quick look, and didn't notice the unpredictable lax #imm result was not written to d011/18, so that should not confuse the display routine.
Then my guess is, high instability/sensitivity to d011 trickery. Does the corrupted picture look every time the same or random, Gryf?
|
| |
hedning
Registered: Mar 2009
Posts: 4720 |
Quote: @hedning: you see the exact same "bugs" (grey dot in the border) in vice using x64sc set to C64C and "full border" enabled.
This is due to updating $d020 (to $00) in the border area.
Ah. Thanx for explaining that. :) Then all pics work on the two C64:s i tested. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11350 |
Quote:Then my guess is, high instability/sensitivity to d011 trickery. Does the corrupted picture look every time the same or random, Gryf?
it would be interesting to patch the illegal opcodes out of the displayer one by one and then check if the behaviour changes :) |
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
@clarence
Probably. I'll make some more screenshots from my tv card to find out. |
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
Quote: Quoting ClarenceThe problem with this, not all illegal opcodes are stable, and some colors you can't have without them.
The opcode itself generates the color, the result (which is unpredictable on unstable opcodes) is discarded. Or does LAX #imm randomly crash on some machines?
If you point me to some one file only progs, that contains such routines (since i don't own disc drive), i can check them out.
Oww.. That should quote tlr :/ |
| Previous - 1 | 2 | 3 - Next |
