kludge’s TF534 build

TF534 - 68030 + More RAM Board (More compatible with amiga hardware)

Moderator: terriblefire

Post Reply
Justme14
Posts: 26
Joined: Tue Dec 18, 2018 9:28 pm
Location: Netherlands

Re: kludge’s TF534 build

Post by Justme14 » Thu Mar 28, 2019 7:15 am

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...

terriblefire
Moderator Team
Moderator Team
Posts: 1028
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: kludge’s TF534 build

Post by terriblefire » 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 get cranky when asked to repeat myself.

terriblefire
Moderator Team
Moderator Team
Posts: 1028
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: kludge’s TF534 build

Post by terriblefire » Thu Mar 28, 2019 8:03 am

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? :))
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.
It would be interesting to know what it is that DiagROM misses in this case.
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.
———
I get cranky when asked to repeat myself.

8 Bit Dreams
Posts: 283
Joined: Fri Nov 09, 2018 7:12 am

Re: kludge’s TF534 build

Post by 8 Bit Dreams » Thu Mar 28, 2019 8:04 am

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...
...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 fixed

User avatar
kludge
Posts: 270
Joined: Thu Nov 08, 2018 2:05 pm
Location: Sweden
Contact:

Re: kludge’s TF534 build

Post by kludge » Thu Mar 28, 2019 8:09 am

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 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 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.
I feel quite confident that the 7416AC245 is ok then. I'll try looking closer at my RAM CPLD. Again :D
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:
[ 3 * Amiga 500 ][ Amiga 500+ ][ Amiga 600HD ][ Amiga 2000 ][ Amiga 4000/030 w/ 64 MB RAM hack ][ CD32 (NTSC) ][ VIC-20 ][ 4 * C64 Breadbin ][ 2 * C64C ][ 2 * C128 ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]

terriblefire
Moderator Team
Moderator Team
Posts: 1028
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK
Contact:

Re: kludge’s TF534 build

Post by terriblefire » Thu Mar 28, 2019 8:35 am

kludge wrote:
Thu Mar 28, 2019 8:09 am
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.
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.
kludge wrote:
Thu Mar 28, 2019 8:09 am
I feel quite confident that the 7416AC245 is ok then. I'll try looking closer at my RAM CPLD. Again :D
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 get cranky when asked to repeat myself.

User avatar
kludge
Posts: 270
Joined: Thu Nov 08, 2018 2:05 pm
Location: Sweden
Contact:

Re: kludge’s TF534 build

Post by kludge » Thu Mar 28, 2019 8:45 am

terriblefire wrote:
Thu Mar 28, 2019 8:35 am
"The 8Mb Range" is a term we generally use to mean 0x200000 to 0x9FFFFF.
The terminology is hard sometimes for us n00bs :D
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.
Ok. I’ll try finding the time tonight to go over everything with the multimeter.
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:
[ 3 * Amiga 500 ][ Amiga 500+ ][ Amiga 600HD ][ Amiga 2000 ][ Amiga 4000/030 w/ 64 MB RAM hack ][ CD32 (NTSC) ][ VIC-20 ][ 4 * C64 Breadbin ][ 2 * C64C ][ 2 * C128 ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]

Justme14
Posts: 26
Joined: Tue Dec 18, 2018 9:28 pm
Location: Netherlands

Re: kludge’s TF534 build

Post by Justme14 » Thu Mar 28, 2019 9:21 am

terriblefire wrote:
Thu Mar 28, 2019 8:35 am
kludge wrote:
Thu Mar 28, 2019 8:09 am
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.
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.
kludge wrote:
Thu Mar 28, 2019 8:09 am
I feel quite confident that the 7416AC245 is ok then. I'll try looking closer at my RAM CPLD. Again :D
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.
Yes,Sorry I was maybe not clear on this :oops: .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 ...

User avatar
kludge
Posts: 270
Joined: Thu Nov 08, 2018 2:05 pm
Location: Sweden
Contact:

Re: kludge’s TF534 build

Post by kludge » Thu Mar 28, 2019 9:30 am

Justme14 wrote:
Thu Mar 28, 2019 9:21 am
Yes,Sorry I was maybe not clear on this :oops: .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 ...
Running from 0x40400000 to 0x40800000 will just test the 0x40000000 to 0x40400000 region once again :)

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:
[ 3 * Amiga 500 ][ Amiga 500+ ][ Amiga 600HD ][ Amiga 2000 ][ Amiga 4000/030 w/ 64 MB RAM hack ][ CD32 (NTSC) ][ VIC-20 ][ 4 * C64 Breadbin ][ 2 * C64C ][ 2 * C128 ][ Mac Classic ][ Mac Classic II ][ Mac Colour Classic ]

go0se
Posts: 62
Joined: Sun Nov 25, 2018 7:55 pm

Re: kludge’s TF534 build

Post by go0se » Thu Mar 28, 2019 9:33 am

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

Post Reply