 Previous Messages |
Posted By
MMS
on 2020-03-06
15:13:32
 |  Re: Problems loading Alpharay
Happy to hear that you could solve that issue.
|
|
Posted By
Mad
on 2020-03-06
01:33:18
| Re: Problems loading Alpharay
Great news Craftsman!
|
|
Posted By
crock
on 2020-03-05
15:08:05
 | Re: Problems loading Alpharay
@craftsman: Yes, if you're willing, I would love to add them to my collection of partial 264 chips. Happily pay you the postage costs. I'll PM you.
|
|
Posted By
craftsman
on 2020-03-05
00:20:13
| Re: Problems loading Alpharay
MMS, She ran for over 12 hours with several reboots and reloads. No crashes.
As to the 2nd 6529 and 8551 the P4 seems to run just fine without them, Probably just like a c16 does.
Mad, Yes you got us going in the right direction. I wonder what the bad 8551 is doing after it warms up. I'm guessing your modified version clears our the error just before the crash would happen each time.
Now I just need to put in the new chips when they arrive. I still need to build the cassette dongle for diag264. Parts are hard to find. Need to also replace a PLA. seem to have misplaced the one I had for this one...
Thanks to Mad, Doug and MMS for all the help!!
March 4th update
The forum would not let me post a new update.
The 8551 and 6529b arrived. Both work fine so my old ones got put back in the temp donor board.
I made a make shift cassette dongle to be able to test all the ports.
The P4 passes all tests with Diag264 and the game no longer crashes when the computer is warm.
Crock can you use the bad 8551 and 6529 for testing?
|
|
Posted By
Mad
on 2020-02-26
12:27:05
| Re: Problems loading Alpharay
Great news Craftsman. Perhaps it was good that Alpharay showed that bug so easily. Funny and good thing is, that it happened on a place where no "harder tricks" where used. Glad to hear, that you seem to be through with it! All the best! 
|
|
Posted By
MMS
on 2020-02-26
08:26:31
| Re: Problems loading Alpharay
Great news, that the rootcause seems to be identified!
I suppose the 8551 is not used at all intentionally by the Alpharay, so it should be as Crock said, the "noise intrerrups" kill the timings.
BTW if you do not use modem or User port (like a C16), does the 8551 has any use? Just curious if really required to put it back....
|
|
Posted By
craftsman
on 2020-02-25
23:57:39
| Re: Problems loading Alpharay
Rob, first tanks for all the work you have done with diag264. I am guessing this is what is occurring as well.
I decided not to wait for the 8551 and 6529b to arrive from Germany. I'm in Colorado USA so I pulled the 8551 and 6529b from one of my NTSC P4's it to test in the P4 that has been having the crash issues.
Both IC's work in the computer and it is now passing the diag264 Userport and RS232 tests that it was failing before.
I'm doing a long run test now with game to see if the crash re-occurs. So far not.
|
|
Posted By
crock
on 2020-02-25
07:29:04
| Re: Problems loading Alpharay
So I assume your 8551 is generating spurious interrupts. Diag264 has numerous tests to check that interrupts occur when they should, but none to check that they are not occurring when they shouldn't. I will add this to the to-do list.
Rob
|
|
Posted By
craftsman
on 2020-02-24
22:50:13
| Re: Problems loading Alpharay
Follow-up. With both the 8551 and 6529b removed the computer ran steady for over 12 hours with numerous loading of the program.
I have a cheap 30 dollar scope and checking this computer against a known working one several of the signals appeared different one with no signal on what is believed to be the bad 8551 pin 5 RXC. The working one has what appears to be a timing signal.
Hopefully the new chips will solve all of this.
|
|
Posted By
craftsman
on 2020-02-23
20:47:18
| Re: Problems loading Alpharay
Bit of an update.
I checked for solder joint and track issues on the board. Basically re-flowed the ram area. Put in new tested ram. After running all night I still had the crash issues.
Today I was able to do diag264 checks. I could use the serial tester from my 64. The serial port checked out ok.
I was able to make a userport connector. The computer fails with the bad 6529b as expected switching the 2 then the keyboard fails and the userport passes.
Now the 8551 is skipped which means it may be bad.
So as of now I am the waiting for the chips to arrive.
|
|
Posted By
craftsman
on 2020-02-22
20:05:05
| Re: Problems loading Alpharay
Mad, I have the eprom and cartage for the diag264 cart. I don't have the full harness to do a complete test.
What I can do it passes all ram and IRQ. It does not fail anything that can be tested without the harness. I've let it run for hours.
|
|
Posted By
Mad
on 2020-02-22
19:22:47
| Re: Problems loading Alpharay
Craftsman curious about that. The Diag264 Doug mentioned could be also some help if you can afford it.
|
|
Posted By
craftsman
on 2020-02-22
19:11:01
| Re: Problems loading Alpharay
Also I've ordered a 8551 and 2 6529b's. It will take a few weeks to get here.
I've been trying to understand the effect of having one that is tied into the 8551.
The bad one when switched to the controller for the keyboard had the issues that if you press the shift key it does a shift run stop loading the first program on the disk. As the rest if the keyboard functions I'm trying to understand just what pins would be bad. This is so I can see what it may do in the other spot.
|
|
Posted By
craftsman
on 2020-02-22
18:37:36
| Re: Problems loading Alpharay
When I get a chance I'll go back through the ram. Maybe a reflow of the pins.
I've checked this already but it can't hurt to do so again.
Also I've tested the ram, 2 different sets in my tester several times and all pass.
|
|
Posted By
Mad
on 2020-02-22
12:56:16
| Re: Problems loading Alpharay
MMS Thanx.. The bug seems to be no software failure. Could be that your hint is exactly pointing to the problem. At least Doug and me seem to be "out of the equation". I would point to faulty RAM (or sockets) now too.. Much thanks for the hint!! Curious, what craftsman will find out..
|
|
Posted By
MMS
on 2020-02-22
07:00:35
| Re: Problems loading Alpharay
Maybe off, maybe will be helpful
When I worked at a factory produced DVD players and LCD TVs (in fact some millions per year) such kind of random loads/hangups were typically due to RAM chip cold soldering on one of the legs (there were some PCB "craccked vias" and "delaminated/black pad BGA soldering" too, but in case of Plus/4 there are not so many, maybe zero).
We usually never see this sympthom with the sets running in the 500h long test hot chamber (preheated to 40°C), but typically on production lines at the longer EOL test. The deferct rate went up especially when the PCBs brough from the outer warehouse in wintertime.
(I spent some months analysing these random patterns due to a green belt quality improvement project made together with production team).
Most of these PCBs were returned (mixed back into the fresh good ones, after removing our defect sticker) by the PCB supplier due to "no fault found" at their side, as sometimes it required 2-5 minutes to reproduce the problem, and they never tested them so long, or just tested in a PCB jig, tested only 60-70% of ll functions (or the defect was so random, or the jig pressed the PCB in a was that the contact was OK in Jig, but Not OK in the finished product).
After my colleague idea to put a UV dot on the PCB edge, then it became evident, that out of those failing "fresh PCB", up to 30-40% were in fact alraedy returned by the PCB supplier 2-5 times (to these PCBs circulating between the two factories, rejected at out tests again and again ("defective"), and passing the supplier test again and again ("OK")!)
Only after doing a very detailed research on the boards with microscope, we found those almost not visible cold soldering on those RAM IC legs (or the sockets).
While these 200ns RAM chips are less sensitive to than those 80ns on DVDs (I mean the timings are expecting less proper timings), I suggest to check very thoroughly the soldering of the RAM chip socket, as I saw you swapped the RAM chips without success. So one explanation, that not the IC itself defective, but the socket.
The V4 may load better, if some timing could be less strict, so it may put less stress on the components. Also it gives an explanation, why the older games run fine on the machine, and the new continuoulsy "decompressing" and "trackloader" games are hanging up, due to strict timing on the stuff.
|
|
Posted By
Doug
on 2020-02-22
02:41:49
| Re: Problems loading Alpharay
Groan... 
That's so weird. Dead RAM? Next steps would be some deep deep debug with more custom code, or reach for Diag264 cartridge. The debug steps would involve putting a custom M/C monitor into the code (or paging in the kernel if that's possible) and getting to a prompt so the system can be examined. But if RAM is flaky that too could be dodgy.
Random thought... maybe on IRQ exit you could read the saved PC from the stack and render the 16 bit value on the screen in hex (say top left). Might yield some info when it goes bad. Bit of a stretch though.
Doug
|
|
Posted By
craftsman
on 2020-02-21
19:25:42
| Re: Problems loading Alpharay
Okay I spent about 4 hours testing this and am even more confused.
First run of test from a cold P4
V2 Crashed 5 times
V3 Crashed 5 times
V4 Loaded
I went round ad round with this for hours after the P4 was warmed up.
Numerous boots after that where all worked,
last test I left the P4 on for over an hour running Adventure Time. Powered it off for over 30 sec. once back on loaded Alpharay.
Apharay failed V2 V3 but would load v4..
I kept doing these tests and would have issues sometimes loading with V2 and 3 not all the time. Seemed random.
Ended up not seeing any pattern except FF09 never failed.
|
|
Posted By
Mad
on 2020-02-21
10:20:52
| Re: Problems loading Alpharay
Thanx Doug!
Interessting that your yape showed the bug. It never (not once) happened here (at least 1 year). I check now the code for this kind of stuff..
craftsman here are three versions after that it should be clear if it's a TED / IRQ line problem.
https://www.dropbox.com/s/w22igvwob5ljawn/AlpharayTestsV2.zip?dl=0
Can you report how these d64s behaved (v2,v3,v4).
v2_alpharay_wibble.d64 = Dougs FF09 WIBBLE (should work normal without problems)
v3_alpharay_justwibblevar.d64 = only the WIBBLE var at the end of the code (should crash at least on the third run)
v4_alpharay_original = the version I have here, should be the same as your crashing one (should crash at least on the third run)
if v2 is working normal and v3 is crashing then it's clearly a TED / IRQline problem (or some packing got wrong)..
I am "offline" (not posting) from around 17 o'clock GMT today till tomorrow evening. Hope that is no problem.
edit: just checked all pha/pla instructions.. Nothing problematic. perhaps somewhere is a write to $100,x or something..Btw.. Thanx Doug for helping with this!
|
|
Posted By
Doug
on 2020-02-21
06:19:10
| Re: Problems loading Alpharay
Lots of interesting stuff here! (BTW, what was the expected behaviour of your initial test program? - When I fired it up on my Yape it did exactly what Craftsman said - which is how I spotted that it was returning from the IRQ to execute the same corrupt instruction which the 6502 interprets as a BRK. Hence the 'interrupt storm', welll, BRK storm I suppose you'd call it).
So, how to tell if it's a BRK (or BRK type) instruction causing it, or a rogue TED/IRQ line? I would add the following to the every IRQ entry sequence once you've saved registers:
[PUSH A, X, Y]
TSX
LDA $104,X
AND #$10
BEQ SKIP
LDA #some signature value
HANG: STA $FF19
JMP HANG
SKIP:
Thus if a BRK is ever encountered the border will change colour and it will all freeze up. I've done this before. I've also used a modifiied version of Yape that dumped a histor of the last few 1000 instructions executed when I got in such a pickle. That was really useful!
The observation that LDA $FF09/STA $FF09 has issues, but LDA #$FF/STA $FF09 'fixes it' is very interesting. Given that the game is basically working, I've kind of discounted the idea that its a TED bug. I can't believe that reading $FF09, under some special circumstances doesn't return the asserted interrupts. Its too specific to that code, at that time. For me the interesting thing here is timing and/or code layout. The new sequence is both shorter and faster that the old one. Could you change the code to be:
LDA WIBBLE
STA $FF09
PLA
RTI
WIBBLE: .DB $FF
This will take the same time as the original, but eliminates the TED read. It would be ideal if you could use some pre-existing valiue in memory that is guaranteed to be $FF rather than creating WIBBLE - that way the code size would also remain the same as the original. If this too works, then OK, its a TED bug. Otherwise we're looking at some timing thing / memory corruption.
I hope craftsman is up for running lots of tests and reporting back!!
(EDIT - actually tried the code above and it should be 104, not 103,x. Doh!)
Doug
|
|
Posted By
craftsman
on 2020-02-21
01:10:17
| Re: Problems loading Alpharay
I waited 10 minutes and nothing changed.
I am no hardware expert. Looking at the schematics there are two IRQ sections on the motherboard. One goes from the processor to the cart-port with a 3k resister in the path. The resister checks out ok.
The other goes from the ACIA 8551 to the TED's IRQ pin. There is nothing else connected between these.
I do not know if the 8551 is working correctly the sister chip 6529 is not. I wonder if they could be causing a problem.
but maybe the IRQ's are not connected to the software FF09.
Just guessing
I need to find a way to test the ACIA.
|
|
Posted By
Mad
on 2020-02-20
23:57:48
| Re: Problems loading Alpharay
-> Using the FF09 version of the program I can not reproduce the crash. Even when the P4 is warmed up: Does this mean the bug is gone with this version?
-> I'm not sure what you mean by "bug stays the same for a longer period time" : Just wait like 10 minutes with the screen flickering and see if the bug changes in appearance..
If the bug is gone already that means, that my lda $ff09/sta $ff09 is the problem. Not sure what causes this behaviour but $ff09 clearly is a TED register.
|
|
Posted By
craftsman
on 2020-02-20
19:40:53
| Re: Problems loading Alpharay
Sorry for the delay power outage this morning.
Using the FF09 version of the program I can not reproduce the crash. Even when the P4 is warmed up.
I'm not sure what you mean by "bug stays the same for a longer period time". Do you mean when you power off. I've left the computer off for over a minute when it's warmed up to have the same issue occur. Or do you mean leaving it in a crashed state?
I'm still wondering if there is a bad cap or something on the board causing this mess.
|
|
Posted By
Mad
on 2020-02-20
19:21:21
| Re: Problems loading Alpharay
Hi Doug,
Thanks for the clarification! I did notice that a brk ($00) instruction did the same corruption, too. Perhaps emulators behave differently because the brk instruction in yape and plus4emu didn't halt the processor. After $1000 units of "brk" it turned again to normal processing, that's why I was asking up there if the bug stays the same for a longer period time. I am just guessing, no deep processor knowledge here  .. Dunno I think it is as you said that memory or the stack is corrupt. Lets see then, strangely it happens only on this device.. Thanx!
Btw.. Do you have any approach to hunt this down on a "remote" real iron device?
cheers,
Stefan
|
|
Posted By
Doug
on 2020-02-20
18:09:33
| Re: Problems loading Alpharay
Hi Mad,
If I may chip in on this thread - I think I know what's going on, maybe. Sounds like some memory corruption or stack corruption to me. Don't forget that BRK is vectored through the *same* vector as interrupts. So your interrupt fires and does its stuff, but when it returns, it hits a BRK, or some garbage that has the same effect as a BRK as far as the poor old 6502 is concerned, and it calls the IRQ handler again. If you examine the saved processor flags on the stack when you enter the handler you'll see the magic bit set that identifies this as a BRK rather than an interrupt - if I'm right. And yes, I've been bitten by a bug like this too!!
Cheers,
Doug
|
|
Posted By
Mad
on 2020-02-20
12:10:55
| Re: Problems loading Alpharay
https://www.dropbox.com/s/itwh2ovu5mzy2r1/checkff07_sound.prg?dl=0 this one has also the ingame sound.. (rastertime stuff)
Ok, if I remove all lda $ff09 / sta $ff09 I get "your" behaviour. It could be that the interrupts cannot be acknowledged whyever and the interrupt keeps beeing firering.. That produces at least the error you describe and your video is showing. Perhaps some hardware guy here may help..
One interessting thing I noticed, was that if it's corrupt memory whats the problem, you may give waiting a longer time a try and look if the bug changes or switches off again..
Since the sound keeps playing I think it has something to do with this $ff09 interrupt acknowledging mechanics, hardware or software..
edit: https://www.dropbox.com/s/u0wymwjyquqmh4f/alpharay_ff09.d64?dl=0 (this is an Alpharay version with an lda #$ff sta $ff09 instead of lda $ff09/sta $ff09 on this screen..) you may give this d64 a try..
If it is the $ff09 stuff it seems to be Ted related.. We can do some further tests, if not.. I hope the forum guys don't mind this thread here?
|
|
Posted By
craftsman
on 2020-02-19
19:21:40
| Re: Problems loading Alpharay
I really appreciate all your questions. I've been dealing with this for a month now. Your little demo that you had me try just as the bars when you press space to like exit. On the full game when you get to that screen it has the bars already. I'll be away from the computer for a little bits you won't get a reply for several hours from me.
|
|
Posted By
Mad
on 2020-02-19
19:19:23
| Re: Problems loading Alpharay
Did you have to press space / button to get to the result in the video in the original? Or does it mean, that behaviour of the sourcecode.zip and original alpharay.d64 somehow already differ?
p.s.: Some time ago there was something suggested to be an hardware error with Alpharay already. Turned out it was the sourcecode writing to random memory (and only on this device). So perhaps again it's the sourcecode and not the hardware again. Let me know if I can help even if I sound stupid with the questions I ask.. And thanks for the appreciation of the game :)..
|
|
Posted By
craftsman
on 2020-02-19
19:07:43
| Re: Problems loading Alpharay
I've tested it with multiple pi1541s. Different cables as well and on each computer. It only occurs on this P4.
|
|
Posted By
Mad
on 2020-02-19
19:08:25
| Re: Problems loading Alpharay
What do you suggest then? I just try to encapsulate the bug.. That's why I am asking these stupid questions.
|
|
Posted By
craftsman
on 2020-02-19
19:04:57
| Re: Problems loading Alpharay
Like I said though I don't think it's a software issue as it runs just fine on all my other computers.
|
|
Posted By
Mad
on 2020-02-19
19:04:16
| Re: Problems loading Alpharay
Do you have to press space in the very first case, too? In order to get the bars? Currently I have no clue, perhaps the loading system or some ram is wrong.. Did you use the same disc + drive for your other C16, too (of course)?
|
|
Posted By
craftsman
on 2020-02-19
18:54:13
| Re: Problems loading Alpharay
For the Peek command it results in 8.
The program seems to load and run fine. But if I press space to continue I get the bars. I know there is nothing to continue to.
|
|
Posted By
Mad
on 2020-02-19
18:39:17
| Re: Problems loading Alpharay
print peek(65287) would give you the content of ff07, would be interessting whats in there..
and checkff07.prg from sourcode.zip should also fail on your setup.. And sorry, it would most probably have nothing to do with $ff07, I was just thinking that I perhaps checked already somewhere for this bits value in the code..
|
|
Posted By
craftsman
on 2020-02-19
18:27:33
| Re: Problems loading Alpharay
https://youtu.be/J1knHaZEUX4
|
|
Posted By
Mad
on 2020-02-19
18:32:08
| Re: Problems loading Alpharay
Here you have some stuff to play with..
https://www.dropbox.com/s/3aq39cmnayb6kw2/sourcecode.zip?dl=0
I looked it's bit 6 of $ff07.. I didn't took care of preserving this bit since the game was PAL anyways, shame on me.. Sorry.. Could you look if this bit is set at your setup (that would be wrong)? The above .zip contains exactly the screen you mentioned. Would be interessting if this works.. The "_yape.bat" builds and executes all.. And gives a checkff07.prg
|
|
Posted By
craftsman
on 2020-02-19
17:59:11
| Re: Problems loading Alpharay
It is strange as all my P4s and c16s are converted.
Amazing game.
|
|
Posted By
Mad
on 2020-02-19
17:59:45
| Re: Problems loading Alpharay
Hello Craftsman,
The screen you mention (in Alpharay) does nothing fancy. That it fails is strange. You said, you converted it to PAL, i suspect a timing issue for that currently. I will upload some tests for you later on. Perhaps other people have an idea about that already? I hope we get that fixed.. I will upload some stuff here within the next hours..
Is the NTSC/PAL bit right, I suppose yes.. :) (upperst bit of ff07 if I remember right)..
|
|
Posted By
craftsman
on 2020-02-19
17:47:00
| Problems loading Alpharay
First I want to say that Alpharay is a great game on the Plus/4 and C16 expanded.
The game runs fine on my c16s and other Plus/4s.
I have a Plus/4 that I had gotten several years ago for the keyboard to repair another one. The computer had sat on the shelf for several years as a spare parts board but I got tired of seeing it not running so I went to the task of repairing it. The computer had originally been covered in some type of goop that had gotten into the area of the userport and keyboard. Probably water as well.
The repair process went well and I ended up replacing all the ram (all mt's tested bad) as well as the 7406. Once these were replaced the P4 booted right up. I could load programs from a pi1541 and play any of the newer PAL games including Adventure Park and Alpharay.
One catch with Alpharay once the computer warmed up the game would load but once you get to the screen that showed the controls it would lock up on that screen and you could go no further. On that screen there is a multi-colored band going across the screen below the ship. This band is duplicated 3 times. The music keeps playing but is choppy and appears sped up. The ship moves as the games shows all the keys that are used to control the game. You can not press fire to go on.
The P4 has been converted to PAL.
I am at a loss as to what causes the problem. So far I have done the following.
All chips have been socketed. The TED and CPU have been tested in other computers a C16 and P4 and all play the game fine even if the computer is warmed up. Sockets for the TED, CPU were replaced. Should note the known working TED and CPU's were switched from several fully working P4's and C16s and the same problem happens.
The new ram was pulled and different RAM was installed. Same problem.
All Dielectric Capacitors were replaced.
In the process of adding sockets every logic IC was tested in my eprom programmer. All passed except the noted 7406.
Tested different PLA's no change.
PAL eproms, 2 different ones used.
Removed the PAL timing crystal. Replaced with one from different company.
Diode at cp2 was replaced (hopefully with the correct version 6.8)
Power supply is the original but been tested for hours under a homemade load tester and does not go over 5.1 volts.
It does have a bad 6529 as I has switched them once both were socketed. The bad was used for the user port. The keyboard one appears fine. The bad one has a strange problem as the keyboard works but if you press shift it does an automatic shift /run stop and tries to load a program. The problem still occurs even if the bad one is removed.
I'm at a loss as where to go next. Noting on the board get unusually hot. Even when this error occurs once the computer is reset I can load up and play any other game I have tried. It does not need to cool down.
Any ideas and if the programmers are out there what could be happening at that very point in the game.
Thanks
|
|
