| |
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? |
|
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
To work around the FLI bug, which get its colors from $ff as screen-ram and the opcode after the $d011 write as color-ram, one may use a bunch of different (il)legal opcodes. That way, it's possible to get one freely selectable color (any of the 16 available) + the light gray one and background in the first three columns.
The question is why your C64s don't handle it. What version of VIC-II and 6510 do you have? |
| |
Clarence
Registered: Mar 2004
Posts: 120 |
@Gryf,
as AmiDog pointed out, the displayer routine Mirage uses (or Timanthes generates?) uses illegal opcodes too, to color the fli bug area (left 3 chars) with desired values every pixel line. The problem with this, not all illegal opcodes are stable, and some colors you can't have without them. In fact "Oh Noes, They Be Stealing My Bench", uses opcode like lax #immediate in some rasterlines, which is known to be *highly unstable*, no wonder some of your hardware will produce weird results (ofcourse software emulators won't fail in it).
To sum it up, your hardware is fine, the code is faulty. ;)
|
| |
Cresh
Registered: Jan 2004
Posts: 354 |
Gergő, thank you for supporting my point of view (no hw problem, just Tiamanthes display routine) with some decent knoweledge. :)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11293 |
conclusion: noone actually bothers to look at these pictures on the real thing =P |
| |
Cresh
Registered: Jan 2004
Posts: 354 |
Word.
Where is scene police? |
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
@AmiDog
Mobo 252311 rev.B:
Vic II: 8565R2/3090 22
CPU: 8500/3190 24
Mobo 252311 rev.4:
Vic II: 8565R2/2888 22
CPU: 8500/4388 24
|
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
@Clarence
Oh great. That's a relief. However it's really pity, that i am unable to run it with real thing :/
Is there anyone else (besides a friend of mine) who was able to run "oh noesÂ…" successfully on C64C?
And, let's put the question in opposite way: On which *real* hardware it would be possible to delight all (or most) new productions on the real c64? Is it random because of illegal opcodes? |
| |
enthusi
Registered: May 2004
Posts: 675 |
UBER 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. |
| |
FATFrost
Account closed
Registered: Sep 2003
Posts: 211 |
If 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. |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quoting Clarence@Gryf,
as AmiDog pointed out, the displayer routine Mirage uses (or Timanthes generates?) uses illegal opcodes too, to color the fli bug area (left 3 chars) with desired values every pixel line. The problem with this, not all illegal opcodes are stable, and some colors you can't have without them. In fact "Oh Noes, They Be Stealing My Bench", uses opcode like lax #immediate in some rasterlines, which is known to be *highly unstable*, no wonder some of your hardware will produce weird results (ofcourse software emulators won't fail in it).
To sum it up, your hardware is fine, the code is faulty. ;)
LAX #<imm> shouldn't crash the machine, only produce the wrong results in Acc and X. At least that is what my tests on several machines show.
In Fundamentals of Icosahedral Symmetry only LAX <abs> and SAX <abs> illegals are used for instance, which should be stable.
Remember that many (most) demo effects rely on undefined machine behaviour so we can't really complain if it fails on part of the machine population. ;)
Q: Do these particular machines work with other D011 badline distorting effects like line crunch and VSP?
|
| |
MagerValp
Registered: Dec 2001
Posts: 1065 |
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: 4702 |
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: 4702 |
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: 1762 |
@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: 120 |
@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: 4702 |
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: 11293 |
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 :/ |
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
Quote: @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?
They look the same (excluding subtle differences between machines colors):
 
  |
| |
Clarence
Registered: Mar 2004
Posts: 120 |
They indeed seem identical.
I've tested on 2 machines and all pics are ok here, apart from the right border color split.
Are you quite sure the file itself you are running on c64 is not corrupted data? Can you plz transfer the file back to pc and binary compare/verify it with the original file from csdb?
|
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
Quote: They indeed seem identical.
I've tested on 2 machines and all pics are ok here, apart from the right border color split.
Are you quite sure the file itself you are running on c64 is not corrupted data? Can you plz transfer the file back to pc and binary compare/verify it with the original file from csdb?
I've done several approaches for converting this picture using tap2wav program. Always with the same effect. Note, that I was able to display this picture using different FLI routine (without right colors on first three columns). There is no way to transfer this picture back using datasette, since I'm using mp3 player and tape adapter, which is able to play wav files, but not record them by using mini jack connector. |
| |
enthusi
Registered: May 2004
Posts: 675 |
Even though I like the tape part, wav-mp3-c64 is like the worst method to transfer files actually.
Though it probably works (for you) maybe you can hack up a BASIC oneliner to make some RAM checksum-test after loading?
Well, the otherwise working alternative fli-player acts as a data-test somehow but a couple of flipped bits would not show up if they are in the data area... |
| |
MagerValp
Registered: Dec 2001
Posts: 1065 |
With the generic FLI displayer there's some garbage in the first 3 columns that shouldn't be there, indicating some sort of problem related to RAM access. I'd check the machines RAM chips, the VIC, the PLA, try a different PSU, and so on. |
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
@All,
It is partially solved:
Until I get some reliable way to transfer things back and forth to/from c64 (1541u) I'll have to do several loadings of the problematic things via datasette. One on three-five times I am able to load picture and display it correctly, and only on Rev.B board. On Rev.4 the result is the same as with BB. I'm going to clean up connectors for cartridge and datasette port to see if it help.
Faulty was most probably Black Box cartridge, which I was using to transfer things in turbo mode. Now I have Final III cart, which remembers some old days back in 97 ;P, but it works (sometimes it has problems with reset/freeze buttons/functionality, but it is another story)
Faulty it may be also transfer itself, which I was doing with prg2wav/wav player/datasette, like enthusi pointed out, but I can live with that for couple of weeks.
Thanks everyone for your comments :) |
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
Yet another remark. I found out, that this is NOT BlackBox fault, but something else. Because, after loading and running any of that pictures, i have it shredded as described earlier, however, if i reset c64 and run it again via sys 2064 than it works! That scenario is always reproducible.
Can anyone explains what could it be? Datasette? |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quote: Yet another remark. I found out, that this is NOT BlackBox fault, but something else. Because, after loading and running any of that pictures, i have it shredded as described earlier, however, if i reset c64 and run it again via sys 2064 than it works! That scenario is always reproducible.
Can anyone explains what could it be? Datasette?
The cassette loading routines could leave CIA's in a different state than after a clean reset.
If the displayer has an unclean init that might affect it.
To determine if it's the CIA's try this:
1. load from tape
2. SYS64931
3. RUN
This code in the displayer of Oh Noes, They Be Stealing My Bench is really strange though it looks to me it will do nothing:
.C:0965 A9 30 LDA #$30
.C:0967 8D 12 D0 STA $D012
.C:096a 8D 0F DD STA $DD0F
.C:096d A9 82 LDA #$82
.C:096f 8D 0D DD STA $DD0D
It force loads Timer B on CIA2, enables counting on CNT pin (but does not start) and enables Timer B NMIs. Note that $fffa/$fffb contains garbage.
It might generate an NMI if Timer B count registers are exactly $00,$00 but I don't remember.
To determine if it's CIA2 timer B try this:
1. load from tape
2. POKE56582,255
3. RUN
|
| |
gryf
Account closed
Registered: Aug 2006
Posts: 14 |
Quote: The cassette loading routines could leave CIA's in a different state than after a clean reset.
If the displayer has an unclean init that might affect it.
To determine if it's the CIA's try this:
1. load from tape
2. SYS64931
3. RUN
This code in the displayer of Oh Noes, They Be Stealing My Bench is really strange though it looks to me it will do nothing:
.C:0965 A9 30 LDA #$30
.C:0967 8D 12 D0 STA $D012
.C:096a 8D 0F DD STA $DD0F
.C:096d A9 82 LDA #$82
.C:096f 8D 0D DD STA $DD0D
It force loads Timer B on CIA2, enables counting on CNT pin (but does not start) and enables Timer B NMIs. Note that $fffa/$fffb contains garbage.
It might generate an NMI if Timer B count registers are exactly $00,$00 but I don't remember.
To determine if it's CIA2 timer B try this:
1. load from tape
2. POKE56582,255
3. RUN
Neither of those works (always the same result - garbage on the screen), however, entire fli is packed. So I've unpack the file and tried to run it this way with poking around CIA, but with no luck. |
| |
tlr
Registered: Sep 2003
Posts: 1762 |
Quoting gryfNeither of those works (always the same result - garbage on the screen), however, entire fli is packed. So I've unpack the file and tried to run it this way with poking around CIA, but with no luck.
I'm out of ideas.
If the cart is plugged in all the time, chances are it isn't correctly uninitialized after loading but is uninitialized correctly after reset...
|
