Restoring CPU card A3640

vibros

New member
Joined
Sep 28, 2009
Posts
2,067
Country
Italy
Region
Emilia-Romagna
Hello,

i have here an A3640, rev. 3.1; it is not mine, anyway, after a short test that has given green screen, i have tried to clean some pads and resistors from leakage of acid, without any result. After surfing the valuable site of the user from Sweden 'Chukky', i have watched for damaged vias, without any success!
Anyway, the last night, maybe i was dreaming, maybe not, i have chose to desolder all the GALs and put a socket on everyone and, in the meantime, look for something strange under the surface. So, after desoldering of U400 and U401, and looked at the schematics, referring to the material on the Haynie archive, i have discovered this: some pads on this PLDs are not connected, despite the logic equations of the contents of this GALs considers some of this unconnected pads into the equations (so, in other words, they are considered sometimes positive and sometimes negative!). But a not connected pad (nor to GND, neither to VCC) is floating or? And this is not the best situations or? Today, with a fresh mind, i will give a new watch to all of this, but i am sure that what i have wrote here is true!

Cheers
Stefano
 
Hello,

so, i was dreaming! Anyway it was not completely my fault, because the unconnected pins are reported on the schematics with their function's name: this function is used internally by the PLD and it, for my opinion, do not needs to stay on the schematics! This had confused me!
So, all is ok! I have followed the good tips has reported by user chukky on his Internet site, about the A3640.

The CPU card on my hands was a result of a patchwork: the true history of this card is unknow by me, anyway, the PLDs was detached and, later, resoldered; how programmed, was by me not know! The card looks a bit messy and not well managed.
Happily, this card is now fully working. What i have done is explained here...
First of all, the most important action is to look very close the board to discover issues like tracks interrupted by age, signs of leakage of acid (as result of, the pads look very dull, not more shiny and very hard to melt the tin!) and defective VIAs. This action does not need any instrument!
This card was affected by leakage of acid, in some pads of resistors and smd capacitors; cleaned the pads, i have desoldered all the PLD, to look under the surface for some signs of defect, but there all was ok. So, soldered the sockets, i have read all the contents of the PLD and compared this results against what is reported being the original content, found on some archive here and there around the NET. Compared that, result was that U208 and U401 was with wrong fuse map, and i have reprogrammed this two parts with original content. After that, returned the card to the original state, with new capacitors right positioned and new sockets, equipped the Master with a passive heatsink, i have inserted this baby on my A3000D and...Bang! A Workbench powered by a 68040...sadly not fast ram on the cpu board!

Here the pictures!

DCP_8996.JPG DCP_8997.JPG DCP_9001.JPG DCP_9002.JPG DCP_9003.JPG DCP_9004.JPG
sysspeed_040_system.jpg

Now a question: there is a MOD to eliminate wait states; this MOD requires new code for some PLD, and this is not a problem because the sockets.
The question is, if modifications on the motherboard (Amiga 3000) are required to do this MOD working!

Thanks!
 
Here's some links to ponder:

https://www.amibay.com/showthread.php?19993-A3640-50Mhz!&p=266058&viewfull=1#post266058

http://eab.abime.net/showthread.php?t=63160

I believe the -2 wait state part codes are in there, along with some POI2 motherboard part mods (A4000x, optional), and he hints at having a means to double-clock the A3640 with some additional modifications. YMMV applies.

I haven't seen any need for A3000 modifications with the updated A3640 GALs, but there are notes from Dave Haynie regarding the SuperDMAC -02/RAMSEY-04 timing being marginal on a certain signal that the v3.1 A3640 fixes make a bit less critical. I don't know how all that applies to Speedgeek's logic rework, or if it interacts with it (or avoids altogether).

On A3000's, it is suggested to get the replacement motherboard GALs (vs the original PALs) for heat reasons. I have a set for one of mine and there is no functional difference, but they do run cooler (than PALs).
 
Last edited:
Hello,

i have upgraded the A3640 and this are the some values compared to a basic A4000@030; sadly i have forgotten to do a module with the values reported by the A3640 in the original state. Compared the new one against the old values was better to show here, anyway...

before the MOD

sysspeed_040_wait.jpg

after the MOD

sysspeed_040_nowait.jpg

I would consider your request to upgrade your A3640, even if not in working order!

Cheers
 
Hello,

now some pictures of the game DOOM on my Amiga, with this A3640. The conversion used is 'ADoom'. The setup of the machine is: Amiga 3000 with OCS, 16mb ram (no burst mode, with my ZIP2SIMM adapter), and this baby, rev. 3.2 and MOD with no wait-state.
Now on Workbench...

doom_1.jpgdoom_3.jpgdoom_2.jpg

...and on custom screen (don't care about quality of the colors, because ExtraHalfBrite screens are managed not correctly on conversion on JPG pictures)

doom_5.jpgdoom_6.jpgdoom_7.jpg

Into window on workbench (OCS 640x512 16 colors) it gives about 5 frames/sec; on a own screen (ExtraHalfBrite 320x200) the frames rate can be vary from 7 to 16; it is very playable and smoothly on all situations (by the way, i have launched this game just to test this A3640, then i have played more then one hour!).
So now i wish just to add this: to load WAD files (Plutonia, in this case) takes minutes (more then ten) with the scsi disk on the on board scsi of A3000D (this disk is not old, old, old; because it is 2GB in size and SysInfo gives a transfer rate of about 2.3 Mb/sec) and, after that, during game play, every call to the Harddisk gives a break on the flow of the action, even with this A3640...now, with my IDE card and a 70GB disk (pictured on the thread of my IDE@ZII), the load takes few seconds (less then ten) and during action, the charge from the HardDisk is not noticeable! Believe in me!

Cheers
 
Last edited:
The native SCSI interface, if Sync is not supported by the drive (or the Sync bit is not enabled in CMOS - Aminet has a tool to tinker with it) then it will top off at ~2.3MB/sec - that's the SCSI spec for Async.

It could theoretically get close to 5MB/sec not including file fragmentation and seek/spindle access delay under optimal config with Synchronous enabled. Setting the bit has a pitfall that you must have proper/optimal termination of the bus, and if you ever change the drives on the bus, turn the bit off before you add/change anything, as it can be a pain to undo that bit if you get SCSI bus errors in less than ideal settings.
 
Hello,

i am now close to two minutes, on onboard scsi, to load the data from WAD file of the game DOOM...anyway against less then ten seconds...and this is not matter of 'buffers' or 'max transfer' for FileSystem!
Maybe the partition on my IDE card is PFS2; this is the only big difference that could be lead to this very good value. I repeat, during game play, the load of the game in progrees is unnoticiable on my card, but it stop the game play igf the game is launched from the SCSI disk.

Cheers
Stefano
 
Last edited:
Hello,

the card is now sold!
This week-end the system look like this

DCP_9103.jpg

For the purpose this computer usually does, there is a lack of a fast-ram controller suited for this type of cpu (despite the MOD, the local ram is not well served by this card), and, secondarily, a gfx card (or an AGA machine).

With this configuration and DPaint 4.5, sunday and yesterday i have drawn this thing...just to test the machine

DCP_9100.jpg

With or without A3640, DPaint 4 is almost the same ...different is during 3d calculation or game play with 'doom'.

Cheers
 
Hello,

know someone of you if there is differences between the A3000D motherboard and the A4000D motherboard, by the point of view of this MOD on this cpu card?

I have read that motherboards clocked twice need extra modifications about this mod, but i have no idea if this is the case about A3000D and A4000D motherboards.

The new owner of this card reach just a dark grey screen on his A4000D (where an A3630 work correctly), and obviously, i have not taken in consideration troubles, just because, as you can see on this thread, all was fine pratically at first shoot, on my A3000D.

Any help and advise is more then appreciated!

Thanks in advance
 
On the 3000 there are jumpers just like the 4000 so if he is using an accelerator card he will need to check these

Sent from my LM-G710 using Tapatalk
 
You have to set J100 and J104 to EXT when using A3640/3660 (INT setting is for A3630).
 
Great job Vibros,

The 3000D is such a beauty. Even with the slower ram access with the 040 to the mb, for it's day it was a real barnstormer.

The IDE@ZII looks interesting... I have toyed with the idea of picking up an IDE card for my 3000D, but with IDE hitting the cpu I was concerned that it would impact performance compared to a real controller.

Matt
Hello,

now some pictures of the game DOOM on my Amiga, with this A3640. The conversion used is 'ADoom'. The setup of the machine is: Amiga 3000 with OCS, 16mb ram (no burst mode, with my ZIP2SIMM adapter), and this baby, rev. 3.2 and MOD with no wait-state.
Look on Workbench...

View attachment 149313View attachment 149315View attachment 149314

...and on screen (don't careb about quality of the colors, because ExtraHalfBrite screens are managed not correctly on conversion on JPG pictures)

View attachment 149316View attachment 149317View attachment 149318

in window on workbench (OCS 640x512 16 colors) it gives about 5 frames/sec; on a own screen (ExtraHalfBrite 320x200) the frames rate can be varie from 7 to 16; it is very playable and smoothly on all situations (by the way, i have launched this game just to test this A3640, then i have played more then one hour!).
So now i wish just to add this: the charge of the WAD file (Plutonia, in this case) by the ADoom conversion, has taken many minutes (more then ten) with the scsi disk on the on board scsi chain (this disk is not old, old, old; because it is 2GB in size and SysInfo gives a transfer rate of about 2.3 Mb/sec) and, after that, during play, every call to the Harddisk gives a stop on the flow of the action, even with this A3640...now, with my IDE card and a 70GB disk (pictured on the thread of my IDE@ZII), the charge takes few seconds (less then ten) and during action, the charge from the HardDisk is not noticeable! Believe in me!

Cheers
 
Last edited:
Hello,

first of all sorry for my very bad english language!

About my IDE card, and the question of the cpu usage, look at the program diskspeed on AMINET; the IDE cards are not all the same and a good test, explained on this program, is about how much time, under WorkBench (= common usage) the system steals the cpu time; expecially then AmigaDOS scroll a list of files inside a directory. As already said on this thread, when scsi.device of Amiga3000D take about 2 minutes to load big files of this game, an IDE disk (even if it is old, like PIO 0), take a dozen of seconds to do the same job, on my IDE card.
So, in other words, just because the FastATA, that is very fast on Read/Write with modern disks, is not so fast during common usage (like as said, to list the content of a directory, with many files), my IDE card can be a good option for your need. Tell me. If you are not satisfied i will refund you...then, if you are tempted...

Great job Vibros,

The 3000D is such a beauty. Even with the slower ram access with the 040 to the mb, for it's day it was a real barnstormer.

The IDE@ZII looks interesting... I have toyed with the idea of picking up an IDE card for my 3000D, but with IDE hitting the cpu I was concerned that it would impact performance compared to a real controller.

Matt
 
Last edited:
Hello,

know someone of you if there is differences between the A3000D motherboard and the A4000D motherboard, by the point of view of this MOD on this cpu card?

I have read that motherboards clocked twice need extra modifications about this mod, but i have no idea if this is the case about A3000D and A4000D motherboards.

The new owner of this card reach just a dark grey screen on his A4000D (where an A3630 work correctly), and obviously, i have not taken in consideration troubles, just because, as you can see on this thread, all was fine pratically at first shoot, on my A3000D.

Any help and advise is more then appreciated!

Thanks in advance

Hello,

the question is still opened! Has someone, this card with this MOD (that involve the reprogramming of about four cpld), in working order on his A4000?

Thanks in advance
 
Bump...this card is sitting idle. Anyone know how to undo the A3000 specific fixes to make it work in an A4000 again?
 
What fixes were done to the card exactly?

I'm only aware of mods to upgrade the GALs to 3.2, and the mod to reduce the memory wait states (which can be done by changing a lot of GALs, and the other involves cutting tracks).

I haven't heard of any mods that are specific to A3000 that breaks usage on the A4000.

If the card works in a 3000, it should do so on a 4000 as long as the main board jumpers are set correctly.
 
I have absolutely no idea. I purchased the card as an "end-user" as it was working, assuming it was on an 4000. Now it's just a "20 year old PCB that doesn't work"...
 
Are You sure its the A3640? Maybe its Your A3k or cpu socket that isn't working, do you have any cance to test it?
 
It's my A4000/030EC....run's fine with the existing 68030 card.
No one available with another Amiga to test :(

I could buy another 040 CPU from eBay, but then that is expensive troubleshooting...
 
Hello,

BOOtBlOck, you can return the card to me, i will send a PM.
Anyway, the reason of this last posts was to collect more infos from users that have done this MOD (upgrade to rev 3.2 and no-wait-states, without any cut of track), to understand some things.

Regards
Stefano
 
Back
Top Bottom