Hi All,
Just my findings, related to the similar issues seen with Kludge ...
My A 500+ boots with no issues on original 68000 with all KS except for KS 3.1.4 as i do not have this currently.
I still face the same issue as only KS 1.3 works on my second TF354 build , Even with a lower Frequency crystal (replaced with a 48Mhz), So the two boards TF534 I build are now both identical ,One boots with out issues and second build only for Diagrom & KS 1.3.
For the Second build TF534 with KS issues :
I think 8bit dream is right there most be still a short or a bad connection..
As I tried KS 2.04 (no Scsi) and this gave me as well a black screen,
Ks 2.05 (vs 37300) hangs with a Grey Screen ?not sure what this grey screen actually means ..
I suspect the Sram has issues as this not in KS 1.3 detected, where diagrom pass the ram detection but this not rellaible where if you test 8MB range it pass with no issues ......Or are there more possibility
Good to mention I use the last Firmware rev 2C -2019 on both boards...
kludge’s TF534 build
Moderators: terriblefire, Terriblefire Moderator
-
- Moderator Team
- Posts: 5368
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: kludge’s TF534 build
The RAM on the 534 isnt in the 8Mb range. Its in ZIII Space. 0x40000000 to 0x40400000... I'm now having to repeat myself!
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
-
- Moderator Team
- Posts: 5368
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: kludge’s TF534 build
The 7416AC245 is the data path between the Amiga and the CPU. If even one pin was soldered badly you've have a very unstable DiagROM.kludge wrote: ↑Wed Mar 27, 2019 10:15 pm The A500+ is a very recent acquisition
I have a USB microscope as well as other magnifying options. I have checked, but I will check again tomorrow. And tomorrow I will hopefully get my new soldering station with hot air and preheater, so I could go over it with that. Or even desolder the chips and put them back on. (Practicing on a TF534 is a great plan, right? )
It would be interesting to know what it is that DiagROM misses in this case.terriblefire wrote: ↑Wed Mar 27, 2019 10:12 pm If the 74AC16245 didnt work the CPU wouldnt boot diagrom. You can leave that alone i think.
The schematics are up on my github in pdf form.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
- 8 Bit Dreams
- Moderator Team
- Posts: 785
- Joined: Fri Nov 09, 2018 7:12 am
- Location: Germany
Re: kludge’s TF534 build
...and that's why it works under 1.3, Zorrolll is NOT detected. Have built 4 TF534 cards for now - all are working. There was one exception under 3.1.4 but it was my CIA related swapped it out and was fixedterriblefire wrote: ↑Thu Mar 28, 2019 7:59 am The RAM on the 534 isnt in the 8Mb range. Its in ZIII Space. 0x40000000 to 0x40400000...
Retro computer hardware & repair in Germany
Re: kludge’s TF534 build
I think what he means is that DiagROM detects multiple 4 MB memory regions on the TF534, and passes tests well beyond 0x40400000. But I guess that's more of a software (DiagROM) issue than a TF534 issue.terriblefire wrote: ↑Thu Mar 28, 2019 7:59 am The RAM on the 534 isnt in the 8Mb range. Its in ZIII Space. 0x40000000 to 0x40400000... I'm now having to repeat myself!
I feel quite confident that the 7416AC245 is ok then. I'll try looking closer at my RAM CPLD. Againterriblefire wrote: ↑Thu Mar 28, 2019 8:03 am The 7416AC245 is the data path between the Amiga and the CPU. If even one pin was soldered badly you've have a very unstable DiagROM.
The schematics are up on my github in pdf form.
A kludge is a workaround or quick-and-dirty solution that is clumsy, inelegant, inefficient, difficult to extend and hard to maintain.
My lack of focus:
[ 4 * Amiga 500 ][ Amiga 500+ ][ 2 * Amiga 600 ][ A1200 ][ Amiga 2000 w/ A2386 ][ Amiga 4000/030 w/ CyberVision 64 3D, FastLane SCSI Z3 ][ CD32 ][ VIC-20 ][ 4 * C64 Breadbin ][ 5 * C64C ][ 2 * C128 ][ C128D ][ C64 DTV ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]
My lack of focus:
[ 4 * Amiga 500 ][ Amiga 500+ ][ 2 * Amiga 600 ][ A1200 ][ Amiga 2000 w/ A2386 ][ Amiga 4000/030 w/ CyberVision 64 3D, FastLane SCSI Z3 ][ CD32 ][ VIC-20 ][ 4 * C64 Breadbin ][ 5 * C64C ][ 2 * C128 ][ C128D ][ C64 DTV ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]
-
- Moderator Team
- Posts: 5368
- Joined: Mon Aug 28, 2017 10:56 pm
- Location: Glasgow, UK
Re: kludge’s TF534 build
Ah ok. Yes it will repeat. Its the nature of the beast not to fully decode things because it wastes space in the CPLD. OS gets told its 4Mb it doesnt do detection. "The 8Mb Range" is a term we generally use to mean 0x200000 to 0x9FFFFF.
You need to get this ram tested in systest somehow. Diagrom doesnt find all the issues all the time. e.g. you might have a missing / shorted address pin. Systest will find this. Diagrom wont.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
Re: kludge’s TF534 build
The terminology is hard sometimes for us n00bsterriblefire wrote: ↑Thu Mar 28, 2019 8:35 am "The 8Mb Range" is a term we generally use to mean 0x200000 to 0x9FFFFF.
Ok. I’ll try finding the time tonight to go over everything with the multimeter.terriblefire wrote: ↑Thu Mar 28, 2019 8:35 am You need to get this ram tested in systest somehow. Diagrom doesnt find all the issues all the time. e.g. you might have a missing / shorted address pin. Systest will find this. Diagrom wont.
A kludge is a workaround or quick-and-dirty solution that is clumsy, inelegant, inefficient, difficult to extend and hard to maintain.
My lack of focus:
[ 4 * Amiga 500 ][ Amiga 500+ ][ 2 * Amiga 600 ][ A1200 ][ Amiga 2000 w/ A2386 ][ Amiga 4000/030 w/ CyberVision 64 3D, FastLane SCSI Z3 ][ CD32 ][ VIC-20 ][ 4 * C64 Breadbin ][ 5 * C64C ][ 2 * C128 ][ C128D ][ C64 DTV ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]
My lack of focus:
[ 4 * Amiga 500 ][ Amiga 500+ ][ 2 * Amiga 600 ][ A1200 ][ Amiga 2000 w/ A2386 ][ Amiga 4000/030 w/ CyberVision 64 3D, FastLane SCSI Z3 ][ CD32 ][ VIC-20 ][ 4 * C64 Breadbin ][ 5 * C64C ][ 2 * C128 ][ C128D ][ C64 DTV ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]
Re: kludge’s TF534 build
Yes,Sorry I was maybe not clear on this .still learing Sorry..terriblefire wrote: ↑Thu Mar 28, 2019 8:35 amAh ok. Yes it will repeat. Its the nature of the beast not to fully decode things because it wastes space in the CPLD. OS gets told its 4Mb it doesnt do detection. "The 8Mb Range" is a term we generally use to mean 0x200000 to 0x9FFFFF.
You need to get this ram tested in systest somehow. Diagrom doesnt find all the issues all the time. e.g. you might have a missing / shorted address pin. Systest will find this. Diagrom wont.
I tested a range of 0X040000000 to 0x40800000 in Diagrom ,where it do not detect any ram Issues, It always pass ...
I was just trying to help and pin point the issues as this is rather similar issue seen ...
Re: kludge’s TF534 build
Running from 0x40400000 to 0x40800000 will just test the 0x40000000 to 0x40400000 region once againJustme14 wrote: ↑Thu Mar 28, 2019 9:21 am Yes,Sorry I was maybe not clear on this .still learing Sorry..
I tested a range of 0X040000000 to 0x40800000 in Diagrom ,where it do not detect any ram Issues, It always pass ...
I was just trying to help and pin point the issues as this is rather similar issue seen ...
Yeah, it seems our issues are very similar.
A kludge is a workaround or quick-and-dirty solution that is clumsy, inelegant, inefficient, difficult to extend and hard to maintain.
My lack of focus:
[ 4 * Amiga 500 ][ Amiga 500+ ][ 2 * Amiga 600 ][ A1200 ][ Amiga 2000 w/ A2386 ][ Amiga 4000/030 w/ CyberVision 64 3D, FastLane SCSI Z3 ][ CD32 ][ VIC-20 ][ 4 * C64 Breadbin ][ 5 * C64C ][ 2 * C128 ][ C128D ][ C64 DTV ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]
My lack of focus:
[ 4 * Amiga 500 ][ Amiga 500+ ][ 2 * Amiga 600 ][ A1200 ][ Amiga 2000 w/ A2386 ][ Amiga 4000/030 w/ CyberVision 64 3D, FastLane SCSI Z3 ][ CD32 ][ VIC-20 ][ 4 * C64 Breadbin ][ 5 * C64C ][ 2 * C128 ][ C128D ][ C64 DTV ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]
Re: kludge’s TF534 build
Hi Kludge,
I don't want to further muddy the waters on your thread as it's likely that everyone's problems have subtly different symptoms and causes , however here's my plan of attack for dealing with similar issues that I'm currently having:
1. Check all soldering looks good under the scope & all ICs pass a tweezer leg pin wobble test.
2. Ensure all flux is removed from the board, I am using BGA rework flux and it tends to be stubborn to remove, especially once it has received a few heat cycles and hardens into a film. I've improved a previously non booting board by further/proper cleaning with IPA alone which makes me think that my residual flux is capable of causing electrical issues with the components. I intend to hit the boards with an ultrasonic cleaner as I suspect that there is still significant buildup behind the CPLDs that IPA can't easily reach. I will also consider switching to a more appropriate flux although I know TF appears to use thick BGA flux on his videos, seemingly without issue.
3. Use quality passives. Although for my 534 builds I got all ICs from Digikey, the passives were a mixed leftover bunch of generic no names from less complex builds. I actually suspect this might be my major issue with my two builds as the issues are similar, perhaps 8 Bit Dreams might share part #s for the passives he's using?
4. Continuity test all pins on your cpu re-locator (if using one) and the newly built board.
5. Continuity test the ground pins on your ram chips. There was a slight PCB mask overrun onto the ground pins on my boards which needed to be removed before tinning and installing the ram chips.
6. Be careful if you're 'cleaning up' the soldering using a hot air station. Cooking something inside the ram or CPLDs would ruin your day. I am pretty sure this wasn't an issue for me as temperature was sensible and application brief but I haven't ruled it out completely, I will shed a tear if this turns out to be the case!
Cheers.
go0se
I don't want to further muddy the waters on your thread as it's likely that everyone's problems have subtly different symptoms and causes , however here's my plan of attack for dealing with similar issues that I'm currently having:
1. Check all soldering looks good under the scope & all ICs pass a tweezer leg pin wobble test.
2. Ensure all flux is removed from the board, I am using BGA rework flux and it tends to be stubborn to remove, especially once it has received a few heat cycles and hardens into a film. I've improved a previously non booting board by further/proper cleaning with IPA alone which makes me think that my residual flux is capable of causing electrical issues with the components. I intend to hit the boards with an ultrasonic cleaner as I suspect that there is still significant buildup behind the CPLDs that IPA can't easily reach. I will also consider switching to a more appropriate flux although I know TF appears to use thick BGA flux on his videos, seemingly without issue.
3. Use quality passives. Although for my 534 builds I got all ICs from Digikey, the passives were a mixed leftover bunch of generic no names from less complex builds. I actually suspect this might be my major issue with my two builds as the issues are similar, perhaps 8 Bit Dreams might share part #s for the passives he's using?
4. Continuity test all pins on your cpu re-locator (if using one) and the newly built board.
5. Continuity test the ground pins on your ram chips. There was a slight PCB mask overrun onto the ground pins on my boards which needed to be removed before tinning and installing the ram chips.
6. Be careful if you're 'cleaning up' the soldering using a hot air station. Cooking something inside the ram or CPLDs would ruin your day. I am pretty sure this wasn't an issue for me as temperature was sensible and application brief but I haven't ruled it out completely, I will shed a tear if this turns out to be the case!
Cheers.
go0se