| |
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?
|
... 20 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
