| |
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....
|
| |
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...
|
| Previous - 1 | 2 | 3 - Next |
