Page 12 of 68
Re: Icky - Progress
Posted: 21 Sep 2018 10:54
by exxos
It is something relating to the ACIA access I think.. Check E,VPA,VMA on the CPU, and 6850CS on the GLUE (I think 6850CS mimics VPA) I did write this down somewhere...
Re: Icky - Progress
Posted: 21 Sep 2018 10:55
by exxos
OK so this is what I wrote for those timings...
Code: Select all
8MHZ = 125NS
1X CLK8 = 125
2XCLK8 = 250
3X CLK8 = 375
4X CLK8 = 500
8X CLK8 = 1000
VPA GOES HI & LO WITH AS
VPA GOES LOW THEN VMA GOES LOW ~200NS LATER (BOTH HIGH ABOUT SAME TIME)
6850 CS GOES HI 1,000ns AFTER VPA, FOR ABOUT 600ns HI. (6850 CS GOES LOW (DISABLE) WHEN VPA GOES HI SAME TIME)
VPA GOES LO SAME TIME E GOES HIGH (2XE CLOCKS THEN VPA GOES HI) VPA GOES HIGH AS E GOES LOW
DTACK IS HI WHEN VPA IS LOW
VPA STAYS LOW ABOUT 1000NS
Re: Icky - Progress
Posted: 21 Sep 2018 11:13
by exxos
What you could try is lifting the 6850CS (pin 8 on both ACIA) and tie to 0v to disable them...
I say this as I had odd conflicts with the ACIA causing that error during booster work, and disabling the ACIA solved a odd bus conflict which seemed to be messing with the MFP..
I'm not sure if pulling the ACIA chips out of the sockets will work.. worth a try as its quick...
Re: Icky - Progress
Posted: 21 Sep 2018 11:39
by troed
Icky wrote: 21 Sep 2018 10:52
BlankVector wrote: 21 Sep 2018 10:48
BTW, that picture is really strange. The bombs are perfectly clean and stable, which means that the Shifter works well. But I can' figure where the strange background could come from...
Yes it is strange but actually quite pretty
I've pondered it for a while. Either the RAM contents* change from 0s to 1s, or the timing between MMU and Shifter is borderline. The latter has issues explaining the bombs being stable, while I _think_ the former would still allow it - depending on if the bombs are drawn from ROM memory (which I believe) over and over again (error loop).
*) actual contents, or just the timing between MMU/Shifter and RAM causing the read to become that
Re: Icky - Progress
Posted: 21 Sep 2018 11:45
by Icky
exxos wrote: 21 Sep 2018 11:13
What you could try is lifting the 6850CS (pin 8 on both ACIA) and tie to 0v to disable them...
I say this as I had odd conflicts with the ACIA causing that error during booster work, and disabling the ACIA solved a odd bus conflict which seemed to be messing with the MFP..
I'm not sure if pulling the ACIA chips out of the sockets will work.. worth a try as its quick...
Trying this first.
Re: Icky - Progress
Posted: 21 Sep 2018 12:01
by Icky
Pulling chips out does not work - board does not boot.
Lifting pin 8 on both and tying to 0V am still getting the same diagnostic error.
Will now start to measure the points as you mention to see what is going on. Need lunch first though :)
Re: Icky - Progress
Posted: 21 Sep 2018 12:09
by exxos
bummer :( Might not be ACIA related then.. but still worth checking those pins are all wired and switching..
Possible you could re-rest the MFP in a working ST ? The mono pin to it probably had Vsync being pushed into it for ages, might have damaged it, who knows...
Re: Icky - Progress
Posted: 21 Sep 2018 12:20
by Icky
exxos wrote: 21 Sep 2018 12:09
Possible you could re-rest the MFP in a working ST ? The mono pin to it probably had Vsync being pushed into it for ages, might have damaged it, who knows...
Good point - I must admit that the MFP was actually the warmest chip on the board.
Re: Icky - Progress
Posted: 21 Sep 2018 14:23
by Icky
Icky wrote: 21 Sep 2018 12:20
exxos wrote: 21 Sep 2018 12:09
Possible you could re-rest the MFP in a working ST ? The mono pin to it probably had Vsync being pushed into it for ages, might have damaged it, who knows...
Good point - I must admit that the MFP was actually the warmest chip on the board.
Discounted MFP being damaged - I was using a new one but put in another from my donor ST and board acts exactly the same. That was a fun (not) time desoldering.
Re: Icky - Progress
Posted: 21 Sep 2018 14:27
by troed
I think the MFP being warm is a bit strange. Not exactly the fastest chip on the board.