A3640 overclocking/upgrading

[jbenam]

@SpeedGeek

I have been attempting the A3640 state mod these last few days.

I've bought a bunch of ATF16V8C 5ns and ATF22V10C 7.5ns. My programmer (TL866II) supports them and I have been able to use them for the IDE PIO2 GALs and A3640 3.2 GAL without any issue.

When replacing the 5 GALs needed by the state mod, something goes wrong. The A4000D stops booting entirely and I only get a black screen.

I have tried replacing a few GALs at a time and I get the following screens if I do. Just U203, yellow screen. Just U208, red screen. U203, U208 and U205, red (or was it yellow? Can't remember) screen. Which means they are working, I guess? Otherwise I would be getting a black screen.

The trouble comes if I put in U207 or U204. I just get a black screen and that's it. Is there anything in the code of these two GALs that would make them stop working at 7.5ns?

I have seen a lot of people around use 10ns successfully, but nobody has posted anything about 7.5ns yet.

Since the PIO2 required slower GALs but worked anyway, I am hoping I won't have to purchase more GALs and that I can get the ones I have currently to work - otherwise I will have to order from the US again...

Any insight on what might be happening?

Thanks for your time and your excellent work.

[dalek]

When you are programming the Atmel GALs with the TL866, do you select the 'encrypt chip' option? Otherwise it programs garbage.

[jbenam]

Originally Posted by dalek

When you are programming the Atmel GALs with the TL866, do you select the 'encrypt chip' option? Otherwise it programs garbage.

Yep, luckily I had read about it beforehand, otherwise I would have wasted quite a bit of time wondering why it didn't work

[SpeedGeek]

Originally Posted by jbenam

@SpeedGeek

I have been attempting the A3640 state mod these last few days.

I've bought a bunch of ATF16V8C 5ns and ATF22V10C 7.5ns. My programmer (TL866II) supports them and I have been able to use them for the IDE PIO2 GALs and A3640 3.2 GAL without any issue.

When replacing the 5 GALs needed by the state mod, something goes wrong. The A4000D stops booting entirely and I only get a black screen.

I have tried replacing a few GALs at a time and I get the following screens if I do. Just U203, yellow screen. Just U208, red screen. U203, U208 and U205, red (or was it yellow? Can't remember) screen. Which means they are working, I guess? Otherwise I would be getting a black screen.

The trouble comes if I put in U207 or U204. I just get a black screen and that's it. Is there anything in the code of these two GALs that would make them stop working at 7.5ns?

I have seen a lot of people around use 10ns successfully, but nobody has posted anything about 7.5ns yet.

Since the PIO2 required slower GALs but worked anyway, I am hoping I won't have to purchase more GALs and that I can get the ones I have currently to work - otherwise I will have to order from the US again...

Any insight on what might be happening?

Thanks for your time and your excellent work.

The most common problems (reported by users) are GAL programming problems and pin contact problems. In particular, SMD PLCC sockets are known to have reliability problems. Not all of the new GALs are interchangeable with the original ones. U203 and U207 are the only ones which might work with the original ones. But there are different revisions of the originals and GAL speed differences which may affect compatibility.

You should use the default 25 MHz clock speed and 10 ns delay line configuration for testing. You should check the +5 Volt supply and make sure it's good and stable.

You did not mention A3640 revision, but some early revisions may have the STERM sampling bug or electrolytic cap problems which need to be fixed before you do the state machine mod.

Also, since you are using Atmel "C" PLDs you will need a pull up resistor on the U205 "Extra Wait State" jumper pin. GALs have internal pull up resistors but the Atmel "C" types use pin keepers.

The PIO2 mod reliability is also affected by GAL speed. Also, it's not a good idea to attempt to do 2 different mods at the same time.

[jbenam]

Originally Posted by SpeedGeek

The most common problems (reported by users) are GAL programming problems and pin contact problems. In particular, SMD PLCC sockets are known to have reliability problems. Not all of the new GALs are interchangeable with the original ones. U203 and U207 are the only ones which might work with the original ones. But there are different revisions of the originals and GAL speed differences which may affect compatibility.

You should use the default 25 MHz clock speed and 10 ns delay line configuration for testing. You should check the +5 Volt supply and make sure it's good and stable.

You did not mention A3640 revision, but some early revisions may have the STERM sampling bug or electrolytic cap problems which need to be fixed before you do the state machine mod.

Also, since you are using Atmel "C" PLDs you will need a pull up resistor on the U205 "Extra Wait State" jumper pin. GALs have internal pull up resistors but the Atmel "C" types use pin keepers.

The PIO2 mod reliability is also affected by GAL speed. Also, it's not a good idea to attempt to do 2 different mods at the same time.

Thanks for your reply.

I can't exclude programming problems at the moment - soldering issues I can safely exclude for now otherwise the original GALs wouldn't work either in the sockets.

U203 "works" with the older GALs. I can see the screen flickering once which means at least part of the startup works.

Putting U207 in doesn't let the first flicker happen, so it stops booting completely.

Right now it's a bog-standard 040@25MHz. I haven't attempted the delay line mod yet (and I will most certainly do it only after I can get this working). 5V is rock stable.

A3640 revision is a 3.1. I have upgraded U209 to -03, so it's now a 3.2. That one GAL works well with my original ones so it's definitely working.

Same goes for the PIO2 mod - it's working well with my stock GALs, so I don't think that's the issue.

I have tried with both a 4.7k and 1k resistor as a pull-up between Pin 17 and Pin 28 (VCC) on U205 with no success

[dalek]

Another thought - did you get your GALs from a known good supplier (mouser/rs etc) or a known bad supplier (ebay/aliexpress). In the second case you may have been sent remarked fakes that are much slower or a different part altogether.

[jbenam]

Originally Posted by dalek

Another thought - did you get your GALs from a known good supplier (mouser/rs etc) or a known bad supplier (ebay/aliexpress). In the second case you may have been sent remarked fakes that are much slower or a different part altogether.

Yep, bought them new from Digi-Key exactly to avoid these issues

[Mathesar]

Originally Posted by SpeedGeek

Also, since you are using Atmel "C" PLDs you will need a pull up resistor on the U205 "Extra Wait State" jumper pin. GALs have internal pull up resistors but the Atmel "C" types use pin keepers.

The PIO2 mod reliability is also affected by GAL speed. Also, it's not a good idea to attempt to do 2 different mods at the same time.

That is interesting! I have an A3660 with your GAL's on it. Atmel type C that is. I do not have a pull-up installed but does the A3660 (rev 1.1) need it as well????

[jbenam]

Originally Posted by Mathesar

That is interesting! I have an A3660 with your GAL's on it. Atmel type C that is. I do not have a pull-up installed but does the A3660 (rev 1.1) need it as well????

Follow-up to this - I have the ATF type Cs in my A3640 right now (there is another thread in the forum explaining the various issues I had, tl;dr: 22V10Cs had to be programmed in UES mode) and I do not have any pull-up resistor installed and everything works as expected.

@SpeedGeek
Is the resistor required or can I just keep it like this?

Thanks.

[SpeedGeek]

Originally Posted by jbenam

Follow-up to this - I have the ATF type Cs in my A3640 right now (there is another thread in the forum explaining the various issues I had, tl;dr: 22V10Cs had to be programmed in UES mode) and I do not have any pull-up resistor installed and everything works as expected.

@SpeedGeek
Is the resistor required or can I just keep it like this?

Thanks.

I thought this was already very well explained. Apparently, this was not the case.

The "Extra Wait State" feature was intended for A4000T users. Of course, all the other users could use it too, and why would they use it? Because it's there.

So, how many wait states do you really want to remove from your A3640 or A3660? One or two?... Because it's there!

[jbenam]

Originally Posted by SpeedGeek

I thought this was already very well explained. Apparently, this was not the case.

The "Extra Wait State" feature was intended for A4000T users. Of course, all the other users could use it too, and why would they use it? Because it's there.

So, how many wait states do you really want to remove from your A3640 or A3660? One or two?... Because it's there!

So it removes two without the resistor and just one with the resistor in it, right?

Just asking to be sure

[SpeedGeek]

Originally Posted by jbenam

So it removes two without the resistor and just one with the resistor in it, right?

Just asking to be sure

Did you not read post #64 or not understand post #64?

[jbenam]

Originally Posted by SpeedGeek

Did you not read post #64 or not understand post #64?

Latter case, that's why I am asking

[Mathesar]

As I understand, only A4000T owners would "want" an extra waitstate to prevent problems.
The rest of us do not want that extra waitstate and thus the pin should be high. Problem is, on the "C" type GAL's this pin has a keeper on it meaning the pin can start up either high or low depending on the phase of the moon or when jupiter and mars align. It will work but not at optimal speed if you're unlucky.
So, in order to force it high a pullup is needed.

EDIT: The A3660 does not have the pullup on the board so one would have to add it when using C GAL's

[Rustynutt]

My first post, thanks to the admins!

Owned since 1995 a 68040 accelerator card for an Atari Falcon, past month got back into the need for speed testing.
Basically a CPU daughter card sitting on and 24 bit expansion bus. Uses an 88915 1/2 clock bus design, 40 MHz from an old Apple Quad Doubler, properly cooled. Had 64mb of 32 bit RAM tied in with the same Amtel CPLD's seems the Amigas discussed here use, as well as surface mount, sure any programming is different, and long forgotten.

It's stable, with fast ram enabled at 40MHz. The O/S requires patching for the VDI to work over the 030 based designed speeds, in the form of disabling a hardware BLiTTER.
Talk between the expansion bus and card is solid. A known DMA issue with SCSI and floppy is worked around by switching via control panel soft the bus clock to 1/2 speed (10MHz in the 40MHz CPU case). IDE is unaffected by the 040 card at 40Mhz.

Sorry, figure I'd try to explain it best I could

Without fast ram installed (physically, just not set up with the 040 PMMU), the card can be over locked to 46-48MHz CPU/ 23-24MHz bus. The standard 030 setup can handle 55/23.5 MHz easily and is stable.
This lead me to the Amiga world, and found this thread. Most of this is soul specific (as in heart and soul ), but the "widening" of the TA/TS lines modification has my attention. I've looked in the zip archive and can't find how this is done.
Is it tied to a specific Amiga IC, or one that could be added over one of the Amtel CPLD? Best I can to is trace signals from the expansion bus, 040, and ram to see if it's something I could implement?
Really think this board would easily run at 50/25.

Sorry for the long read, just didn't want to get discarded asking an unknowledgeable question
68K forever!

[SpeedGeek]

Originally Posted by Rustynutt

Without fast ram installed (physically, just not set up with the 040 PMMU), the card can be over clocked to 46-48MHz CPU/ 23-24MHz bus. The standard 030 setup can handle 55/23.5 MHz easily and is stable.
This lead me to the Amiga world, and found this thread. Most of this is soul specific (as in heart and soul ), but the "widening" of the TA/TS lines modification has my attention. I've looked in the zip archive and can't find how this is done.
Is it tied to a specific Amiga IC, or one that could be added over one of the Amtel CPLD? Best I can to is trace signals from the expansion bus, 040, and ram to see if it's something I could implement?
Really think this board would easily run at 50/25.

Sorry for the long read, just didn't want to get discarded asking an unknowledgeable question
68K forever!

Sorry, but you probably won't find much info (or technical expertise) for over-clocking Atari 040 cards here. You are welcome to use anything you find here, but you will have to determine to what extent (if any) it can be used for your specific application.

There isn't anything that's 040 specific for Amiga ICs (Which are more commonly known as "Custom Chips" in the Amiga community). There isn't anything in the zip archive related to the widening of TA/TS lines that I'm aware of.

I would expect that the QuadDoubler is probably the easiest way to reach 50 MHz for Atari 040 owners, but it's also interesting to explore the more difficult ways too. Good Luck!

[Rustynutt]

Originally Posted by SpeedGeek

Sorry, but you probably won't find much info (or technical expertise) for over-clocking Atari 040 cards here. You are welcome to use anything you find here, but you will have to determine to what extent (if any) it can be used for your specific application.

There isn't anything that's 040 specific for Amiga ICs (Which are more commonly known as "Custom Chips" in the Amiga community). There isn't anything in the zip archive related to the widening of TA/TS lines that I'm aware of.

I would expect that the QuadDoubler is probably the easiest way to reach 50 MHz for Atari 040 owners, but it's also interesting to explore the more difficult ways too. Good Luck!

Appreciate the response.
Read back the entire thread, cross site post, it's all interesting and relative, if I can figure it all out!

I'd seen where the Quad Doubler worked in Amiga, and did try this maybe 10 years ago. Gave it another shot last night after reading back what it expects for a BCLK.
Falcon boots with 8MHz bus right after reset, then switches to 16MHz. I'd edited the binary to keep it in 8MHz until desktop (Workbench ).
Down clocking the bus to about 12MHz, the 040 88915 outputs a 24MHz BCLK, the Quad Doubler did indeed boot. Could manage 46 MHz and stable, but the 32 bit RAM still bites me when it's installed, so there's something. At least proves the 040 works at this speed, as does the host computer.
Have 3 of those left.
Also have a Mac card called a DiiMOCache 040/050. Has a selectable BCLK input of 25 or 33MHz. Also has 128K CPU cache. Made a Quadra 950 scream. Not any info on it, it plugs direct to the 040 socket. Imagine it would work as well, but until the 32 bit RAM issue is figured out, not much sense as that's where the huge speed comes from. Had to repair 2 CPU socket pins on it last night, then noticed 15 years ago pulled the 88915 for some dumb reason, need to order one of these before testing.
Again, appreciate the response.
Mike