E-Mail from ARNE about the Atari ST device As you can see the IDTs have /CS, /OE and /WE like any other SRAM. /CS is always (GND) active just to act faster with the expense of using a bit more current. But /OE is tied to Vcc i.e. in-active all the time! That means the "data" (addresses) on the IO[1..8] pins is never _read_! You can only write into the IDT in the way it is connected in the schematic! So a write-only device does not make sense at all. Well, yes. But there is one _output_ channel beside the IO pins: the MATCH pin (HIT signal in the schematic). On /RESET the GAL logic will assert (=GND) the /CLEAR pin of the IDTs. This will lead to the SRAM matrix to be set to '0' in some ten nanoseconds. Now the IDT-SRAMs are in their 'initial' state. Whenever a device (bus-master like CPU) accesses a memory location it puts the address on the address bus. The IO pins of the IDTs are connected to the upper part of the address bus while the lower part is connected to A0..A12 of the address pins of the IDTs. Cache is empty and needs to be filled. Whenever the GAL logic decides to store a 16bit word in the data SRAMs IC4/IC5 - only on writes to memory on the Mach16 - it needs to perform some red-tape action. At the same time when it writes the 16bit word into IC4/5 it needs to update the according entry in IC2/3. The upper part of the address visible on IO1..7 will be written into the location addressed by the address on A0..12 by asserting /WE. So, now we have stored a single data-word into the cache. The same data-word is written to the main-memory (write-through access). How to speed things up? Now comes the magic: every address on A0..A12 addresses an octet (byte) in the internal SRAM matrix. The IDT takes that byte and compares that bit-pattern with the bit-pattern currently on IO1..8. If the patterns match then we have a cache-hit. The GALs now forces the data SRAMs IC4/5 to output their stored data-word on D0..15 and an access to the (slow) main-memory is not even started by the GALs as they intercept /AS, /LDS and /UDS coming from the 68000. They "capture" these signals and start the faster SRAM access instead. That is the magic behind the MATCH pin. As DMA devices can alter main-memory contents without the GALs knowing anything about it we run into one problem: the updated data in main memory can differ from the cached values in IC4/5 which will certainly lead to problems (aka guru meditations). How to solve that? Simple: assert /CLEAR and invalidate the L1 content - like on /RESET - and start all over again. That said it is pretty obvious that constant DMA accesses will ruin cache performance. One more side note: as you can see IO1..6 on IC2 are pulled high. This is very important! At least one bit of all IO pins needs to be pulled high! Whenever the cache is in its initial state (matrix is erased via /CLEAR) every bit (especially on IO1..6 in case of Mach16) is set to '0'. Whenever you use /WE to write into the tag SRAMs IC2/3 the high-pattern on IO1..6 overwrites the '0' with a '1'. Next time the tag SRAM compares the internally stored pattern IO1..8 with the external pattern on IO1..8 it will check IO1..6 for a '1'-match, too. If the internal bits are still set to 0 then this indicates that the data at that address has not been stored in the data SRAMs IC4/5 yet. OTOH if the IO1..6 bits are set to '1' this will lead to a MATCH if the rest of the pattern matches, too. This way the bits at IO1..6 represent the Valid-bit. It would be enough to just use one of the six but as you shall not leave such inputs floating just connect them to high. The author may have grounded IO1..5 and just use IO6 as a valid it or any other combination as long a at least one unused IO is pulled high to counter the internal '0' set by the /CLEAR action. As the upper part of the address bus on all IO pins of IC2/3 goes up to and includes A23 this indicates that the whole 16Mbyte address space of the 68000 is cachable. The cache is implemented as a "direct-mapped" cache i.e. for every memory location (16 bit word in the case of the 68000) there is exactly one location in IC4/5 where the data can be stored/cached. In case of the Mach16 and your accelerator the cache size is 16KByte. So the locations at $000000, $004000, $008000, $00C000, $010000, $014000,... share the same offset-location in cache ($0000) and the same applies to $000002, $004002, $008002, $00C002, $010002, $014002,... share the word at offset $0002 in IC4/5. That is why you need to store the _upper_ part of the address in the tag SRAMs (the red-tape stuff) to distinguish between the possible main-memory loacions $000000, $004000, $008000, $00C000, $010000, $014000,... In case of the mach16 the cacheable area is 16MByte (more specific 8MWords) and the cache size is 16KByte (more specific 8KWords): So 8M / 8K = 1024 i.e. that 1024 main-memory locations have to share a single L1 location. Bigger cache = more cache hits as less main memory locations share the same cache location. Previous Comment from ClayCowGill Insider knowledge disclaimer-- I worked at Supra. So yeah, removing the part numbers (early on) was just to frustrate competitors trying to either reverse engineer (or simply figure out our costs). Early units had pretty much ALL the part numbers scrubbed by electric-erasers... I also remember a little discussion about the 68HC000 in particular in that the top speed grade from Motorola at the time was 16MHz (obviously we were overclocking) and we didn't want to have to have our (two) Amiga tech support people have to argue about 'out of spec' parts with nerds on the phone. ;-) Engineering also thought it was funny imagining GVP or some other competitor trying to figure out if we had a special deal with Motorola to get ~33MHz 68000's or something... We ran the accelerator in engineering up to 40MHz (it was originally going to be a 36MHz accelerator, but we got cold feet about compatibility/reliability and turned it down). Running slower also gave purchasing some elbow room in the speed grades of the SRAMs (and maybe PLDs?) which helped keep it cheaper and easier to source parts for.
In addition to making it smaller, the Intel PLDs also helped with the design obfuscation/protection -- at the time there wasn't any real fear of anyone being able to bypass the read back protection easily. (Back then there wasn't any Chinese outfits with a SEM and a FIB that'd crack programmable logic for a few hundred bucks!) Those parts are N85C090's -- kind of an early CPLD with ~24 macrocells (900 gates, hence the part number). They had a decent amount of IO though (more IO pins than macrocells). The 'clock' lines on those are just that-- a globally routed clock if the logic needed it. One of the PLDs acted as a state machine (so it used the clock pin as intended) and the other was just a bunch of combinatorial glue, so no clock edges needed. The benchmarks were indeed legit, but we would definitely pick the scenarios where we won! (e.g. things that fit in cache were very quick, so compare that to a slower clocker '030 upgrade over the 16-bit memory bus and the Turbo28 could outperform.) The Turbo28 cached and accelerated system ROM (0xF80000-FFFFFF), slow expansion RAM (0xC00000-D8FFFF), and fast expansion RAM (0x200000-9FFFFF). Removing the 'option' jumper punched a hole from 0x600000-0x9FFFFF for hardware that did DMA or otherwise messed with the cache. At boot time the cache is actually disabled-- there were timing loops in the boot ROMs that early acceleration messed with, so the cache only becomes functional (if it's enabled by switch/jumper) once autoconfig starts.
10:35 I don't recall having too much trouble soldering the J-leg chips when I was younger. But, about five years ago, I repaired an Atari Jaguar for somebody, and it took me forever to get the solder to wick onto the pads nicely, even with lots of flux. lol Some of the chips just have pins which are more heavily crimped, I guess. They can be a pain. I think you're using pretty much the best choice of soldering tip for the job, though.
I do think there's a chance one of the PLDs might have failed, tbh. And I could be wrong, but CPLDs around that time were based on EEPROM/Flash tech? So some might have a finite lifetime for storing the config? Most older PALs/GALs/PLDs were one-time-programmable, though, like a PIC 16C, I guess. Those probably last a lot longer without any worries of the config degrading. As I say, I could totally wrong about the EEPROM thing on some older CPLDs, but I know the 5-Volt Altera stuff often used that.
I just watched some of your previous vid, and saw that the PLDs are Intel iPLD910. Those do use "CHMOS EPROM" (floating gate) tech. So basically EPROM, not EEPROM. lol (ie. needs a higher voltage or whatever, to actually reprogram them.) So I think it is possible for those to degrade over the long time the accelerator has been around. Probably not half as much as older EEPROM tech would, but still possible. Unless somebody can find the PLD terms for this, or re-write them from scratch, it could be tricky to repair, as you say.
@@electronash Can't really explain why but I've always struggled with these types of packages, I can get them on eventually and it looks ok in the end but its always a fight 😅 I think you're probably right that the chips have failed or just degraded. Rewriting the equations from scratch is probably the only solution now but I'm afraid that one goes over my ability. It's still an interesting part of Amiga history, so makes a nice talking point to sit on a shelf somewhere. It a shame its dead but I'm not sure it's worth the effort it would now seemingly take to get it going.
Aww, no outro music this time 😅 You did your best, and I honestly think the outcome of the soldering was alright! PLDs and other one-time programmable logic devices are such a bear when they're broken. I know companies at the time liked them for preventing reverse-engineering, but that's a hindrance to hobbyists 30 years on!
Cut the outros to try and play to the RUclips gods algorithm, not so sure it working though 😅 But yeah those PLDs and other similar devices from the day are most certainly a pain for us these days and in terms of these cards it certainly seems as if there are plenty of examples of failed units.
@@CRG honestly I think they’ve just made significant changes. Everybody’s numbers seem to be down. I’ve certainly noticed far more recommendations from people I’ve never watched before, in stark contrast to the way it worked for a good 4 or 5 years. And even the subs box (not just the homescreen) isn’t showing me 100% anymore :/ I normally stick things into category playlists to watch later, and many more things are falling through the cracks now. I hope this isn’t the beginning of the end, but given the ways other social networks are becoming harder to gain traction on… this might be the start of a pay-to-play situation >.
I do have an old programmer that can read and write the programmable logic devices that you have. However any working devices you may find will probably be read protected which effectively stops any repairs of your board.
That's what I suspect so the only way would be to either get a copy of the original equations or brute force it and figure it out from scratch. It would take someone more knowledgeable than my to do that though.
Sorry if I missed it, but don't you need to remove the onboard CPU? I didn't think there was a way to disable the onboard 68K from the expansion slot on the 500 as it lacks the BOSS stuff that you get on the 2000? Looking at the manual, I don't see that - so maybe there is a way it disables the onboard 68K... Another point here - and again unlikely as I would expect some signs of life if this were the issue... It applies caching, probably on ranges except for chip RAM, does it work with the 8375 - ie. 2MB... I know that Tornado I worked on has similar lack of support for Agnus over 8372A.
Thanks for the suggestions. I've tried it without the cpu and it's the same story but I also found an article that said it needs the cpu installed, not sure why it would but either way it's just dead. I did try the accelerator on a rev6 A500 but it's just the same behaviour plus I've had some comments of other folk having it work on their 500+. I'm afraid it seems as if its just dead.
I think the normal way to disable the onboard CPU in the A500 is to simply assert BR and BGK all the time. Since there's no bus arbitration on those machines, this doesn't interfere with anything. I suspect they're just tied to GND as they come off the socket.
Which does make me wonder: since the external CPU isn't doing anything at all (although I don't think you checked AS?), is it possible BR and BGK on the extenal chip are being used in a similar way? Perhaps held low pending a startup signal from the cache controller that never comes?
Gents, the manual for this card states that it's just plug and play, so it must be capable of dealing with the original CPU in some manner. The owner of the card has said anyone who wants to have a further go is more than welcome to do so, if either of you to want the challenge then please let me know. It is now though beyond my ability. I'm convinced the fault is a failure in the plds and I have no means of correcting that.
I am afraid this is a harbinger of things to come for a lot of vintage hardware of that era. GAL and PLDs do have a limited shelf life and will eventually erase themselves. Depending on manufacturer published specs it’s about 20 years which we’ve already gone way past… Since the equation for most of these are closed source and/or the devices themselves are protected this will soon render a lot of these devices useless.
Thats why the PLDs in a working accelerator need to be read by someone with one of those expensive compatible programmers. They could then have new preprogrammed PLDs for sale.h
@@simontay4851 it’s not that easy unfortunately. The vast majority of PLDs used on commercial products of this era will have a protection bit set and cannot be read back. You’re left with reverse engineering the equations by reading the outputs by sending all possible signals combinations to the inputs. This is generally easy for simple PAL/GALs but far more complicated if the GAL/PLD is registered or uses a clock or has hidden intermediate states.
@@stbagnI've been doing the same with non registered GALs and PALs for time now using an arduino that dumps a pseudo truth table - for want of a better phrase - to the serial port. I've then manually worked out the equations. So far I've not tried this using registered devices, but it sounds like a nightmare. It would probably be possible if you know the internal setup of the chip ie the cell type and wiring etc, and had the schematics of the board to know what the inputs and outputs are, given GALs can change some of their pins pins from I to O etc. I guess the first step here is to work out if these two PLAs receive a clock signal or something similar from the layout of the board. If they don't then this may make it easier to understand the logic in them. On a slightly different note, I suspect the heating up of the cache RAM is probably more to do with a ongoing data bus crash between the two chips if both are constantly selected and one is (for example) trying to drive the bus high and the other low leading to a large constant current draw between the chips or the main data bus (example only!) It would be helpful to see what is controlling the read and write pins of the RAM chips (I suspect the PLA) and what state these signals are in. My suspension is that these chips map this in as cache memory as a write through sort of setup, or they cache the kick-start ROM, and redirect the new CPU to this. I'd also be interested to see if the Kick-start ROM is being selected during the attempt at startup from the accelerator.
@@jamescronin7742 unfortunately these PLCC 44 packages are far bigger than any simple PLA or GALs and are therefore far more complex CPLDs. Brute force truth table building is highly unlikely to work.
well glenn ya threw everything but the kitchen sink at this....and i dont think the sink would have helped.....good try glenn ! what a pain!!also please try not to wait so long to put on a video! i need my crg fix!😅
Sorry it's been so long, just had a lot on with work and family stuff. Back at it now though with 3 videos in the works and what I hope to be a big channel announcement coming soon. So as they say keep watching 😉
So, forgive any ignorance on my part, but why is the lack of a way to (gracefully) read one of these chips, if you got your hands on a working example, a dead stop? The thing must have a set of inputs, and provide outputs in a predetermined manner. There is a logic to the outputs, right? Why is it not possible, again providing a working example, to brute force it by giving it every possible input combination, and reading the outputs, and building a truth table from it then gleaning the equations from that? Might be a task to do manually for sure, but considering we've got devices like a pi or arduino, surely someone so inclined couldn't program one to do the inputs and outputs and automatically generate the equations from that.
It would be absolutely possible to brute force a working example and from that reproduce the equations for a new chip but I'm afraid doing that is outside of the scope of my knowledge. I'm not sure if there is an automated means of doing it with a Pi or Arduino but I suppose it would be possible to write some sort of program to achieve that. The issue with doing this though is capturing every state of every pin as they interact with each other. These ICs have multiple inputs and multiple input/outputs (apologies I can't remember the number off the top of my head) so you can appreciate there are probably hundreds of combinations for the logic.
@@CRG I thought so. Sadly, I neither have a working example, nor have I any experience with microcontrollers. I've just seen what others have done and figured someone out there could probably program one to do that. Maybe another one of your viewers. And maybe another will have a working sidecar, and willing to allow it yo be reverse engineered. Maybe even the same viewer. Lol. I've seen similar things before, a viewer have a working example of some obscure item that helps a creator unexpectedly out of a bind. And it'd have the potential of leading to reproduction if lucky.
Yeah that's a possibility, they do appear to be real and new old stock but it's impossible to say for sure. They do stay cool when the card is powered up now but that doesn't necessarily mean they are real.
@@cp256 Exactly. I've done videos on pistorm and other accelerators before, this though was something complete different and I thought an interesting device that deserved my best attempt to fix.
E-Mail from ARNE about the Atari ST device
As you can see the IDTs have /CS, /OE and /WE like any other SRAM. /CS is always (GND) active just to act faster with the expense of using a bit more current. But /OE is tied to Vcc i.e. in-active all the time! That means the "data" (addresses) on the IO[1..8] pins is never _read_! You can only write into the IDT in the way it is connected in the schematic! So a write-only device does not make sense at all. Well, yes. But there is one _output_ channel beside the IO pins: the MATCH pin (HIT signal in the schematic). On /RESET the GAL logic will assert (=GND) the /CLEAR pin of the IDTs. This will lead to the SRAM matrix to be set to '0' in some ten nanoseconds. Now the IDT-SRAMs are in their 'initial' state. Whenever a device (bus-master like CPU) accesses a memory location it puts the address on the address bus. The IO pins of the IDTs are connected to the upper part of the address bus while the lower part is connected to A0..A12 of the address pins of the IDTs. Cache is empty and needs to be filled. Whenever the GAL logic decides to store a 16bit word in the data SRAMs IC4/IC5 - only on writes to memory on the Mach16 - it needs to perform some red-tape action. At the same time when it writes the 16bit word into IC4/5 it needs to update the according entry in IC2/3. The upper part of the address visible on IO1..7 will be written into the location addressed by the address on A0..12 by asserting /WE. So, now we have stored a single data-word into the cache. The same data-word is written to the main-memory (write-through access). How to speed things up? Now comes the magic: every address on A0..A12 addresses an octet (byte) in the internal SRAM matrix. The IDT takes that byte and compares that bit-pattern with the bit-pattern currently on IO1..8. If the patterns match then we have a cache-hit. The GALs now forces the data SRAMs IC4/5 to output their stored data-word on D0..15 and an access to the (slow) main-memory is not even started by the GALs as they intercept /AS, /LDS and /UDS coming from the 68000. They "capture" these signals and start the faster SRAM access instead.
That is the magic behind the MATCH pin. As DMA devices can alter main-memory contents without the GALs knowing anything about it we run into one problem: the updated data in main memory can differ from the cached values in IC4/5 which will certainly lead to problems (aka guru meditations). How to solve that? Simple: assert /CLEAR and invalidate the L1 content - like on /RESET - and start all over again. That said it is pretty obvious that constant DMA accesses will ruin cache performance.
One more side note: as you can see IO1..6 on IC2 are pulled high. This is very important! At least one bit of all IO pins needs to be pulled high! Whenever the cache is in its initial state (matrix is erased via /CLEAR) every bit (especially on IO1..6 in case of Mach16) is set to '0'. Whenever you use /WE to write into the tag SRAMs IC2/3 the high-pattern on IO1..6 overwrites the '0' with a '1'. Next time the tag SRAM compares the internally stored pattern IO1..8 with the external pattern on IO1..8 it will check IO1..6 for a '1'-match, too. If the internal bits are still set to 0 then this indicates that the data at that address has not been stored in the data SRAMs IC4/5 yet. OTOH if the IO1..6 bits are set to '1' this will lead to a MATCH if the rest of the pattern matches, too.
This way the bits at IO1..6 represent the Valid-bit. It would be enough to just use one of the six but as you shall not leave such inputs floating just connect them to high. The author may have grounded IO1..5 and just use IO6 as a valid it or any other combination as long a at least one unused IO is pulled high to counter the internal '0' set by the /CLEAR action.
As the upper part of the address bus on all IO pins of IC2/3 goes up to and includes A23 this indicates that the whole 16Mbyte address space of the 68000 is cachable. The cache is implemented as a "direct-mapped" cache i.e. for every memory location (16 bit word in the case of the 68000) there is exactly one location in IC4/5 where the data can be stored/cached. In case of the Mach16 and your accelerator the cache size is 16KByte. So the locations at $000000, $004000, $008000, $00C000, $010000, $014000,... share the same offset-location in cache ($0000) and the same applies to $000002, $004002, $008002, $00C002, $010002, $014002,... share the word at offset $0002 in IC4/5. That is why you need to store the _upper_ part of the address in the tag SRAMs (the red-tape stuff) to distinguish between the possible main-memory loacions $000000, $004000, $008000, $00C000, $010000, $014000,...
In case of the mach16 the cacheable area is 16MByte (more specific 8MWords) and the cache size is 16KByte (more specific 8KWords): So 8M / 8K = 1024 i.e. that 1024 main-memory locations have to share a single L1 location. Bigger cache = more cache hits as less main memory locations share the same cache location.
Previous Comment from ClayCowGill
Insider knowledge disclaimer-- I worked at Supra. So yeah, removing the part numbers (early on) was just to frustrate competitors trying to either reverse engineer (or simply figure out our costs). Early units had pretty much ALL the part numbers scrubbed by electric-erasers... I also remember a little discussion about the 68HC000 in particular in that the top speed grade from Motorola at the time was 16MHz (obviously we were overclocking) and we didn't want to have to have our (two) Amiga tech support people have to argue about 'out of spec' parts with nerds on the phone. ;-) Engineering also thought it was funny imagining GVP or some other competitor trying to figure out if we had a special deal with Motorola to get ~33MHz 68000's or something... We ran the accelerator in engineering up to 40MHz (it was originally going to be a 36MHz accelerator, but we got cold feet about compatibility/reliability and turned it down). Running slower also gave purchasing some elbow room in the speed grades of the SRAMs (and maybe PLDs?) which helped keep it cheaper and easier to source parts for.
In addition to making it smaller, the Intel PLDs also helped with the design obfuscation/protection -- at the time there wasn't any real fear of anyone being able to bypass the read back protection easily. (Back then there wasn't any Chinese outfits with a SEM and a FIB that'd crack programmable logic for a few hundred bucks!) Those parts are N85C090's -- kind of an early CPLD with ~24 macrocells (900 gates, hence the part number). They had a decent amount of IO though (more IO pins than macrocells). The 'clock' lines on those are just that-- a globally routed clock if the logic needed it. One of the PLDs acted as a state machine (so it used the clock pin as intended) and the other was just a bunch of combinatorial glue, so no clock edges needed.
The benchmarks were indeed legit, but we would definitely pick the scenarios where we won! (e.g. things that fit in cache were very quick, so compare that to a slower clocker '030 upgrade over the 16-bit memory bus and the Turbo28 could outperform.)
The Turbo28 cached and accelerated system ROM (0xF80000-FFFFFF), slow expansion RAM (0xC00000-D8FFFF), and fast expansion RAM (0x200000-9FFFFF). Removing the 'option' jumper punched a hole from 0x600000-0x9FFFFF for hardware that did DMA or otherwise messed with the cache. At boot time the cache is actually disabled-- there were timing loops in the boot ROMs that early acceleration messed with, so the cache only becomes functional (if it's enabled by switch/jumper) once autoconfig starts.
Thanks for trying. Your excellent videos have far outstripped the entertainment value of the card! I hope the algorithm is kind and helps this fly. 👍🏻
Sorry I couldn't get it working as it would have been cool to test.
10:35
I don't recall having too much trouble soldering the J-leg chips when I was younger.
But, about five years ago, I repaired an Atari Jaguar for somebody, and it took me forever to get the solder to wick onto the pads nicely, even with lots of flux. lol
Some of the chips just have pins which are more heavily crimped, I guess. They can be a pain.
I think you're using pretty much the best choice of soldering tip for the job, though.
I do think there's a chance one of the PLDs might have failed, tbh.
And I could be wrong, but CPLDs around that time were based on EEPROM/Flash tech?
So some might have a finite lifetime for storing the config?
Most older PALs/GALs/PLDs were one-time-programmable, though, like a PIC 16C, I guess.
Those probably last a lot longer without any worries of the config degrading.
As I say, I could totally wrong about the EEPROM thing on some older CPLDs, but I know the 5-Volt Altera stuff often used that.
I just watched some of your previous vid, and saw that the PLDs are Intel iPLD910.
Those do use "CHMOS EPROM" (floating gate) tech.
So basically EPROM, not EEPROM. lol
(ie. needs a higher voltage or whatever, to actually reprogram them.)
So I think it is possible for those to degrade over the long time the accelerator has been around.
Probably not half as much as older EEPROM tech would, but still possible.
Unless somebody can find the PLD terms for this, or re-write them from scratch, it could be tricky to repair, as you say.
@@electronash Can't really explain why but I've always struggled with these types of packages, I can get them on eventually and it looks ok in the end but its always a fight 😅
I think you're probably right that the chips have failed or just degraded. Rewriting the equations from scratch is probably the only solution now but I'm afraid that one goes over my ability.
It's still an interesting part of Amiga history, so makes a nice talking point to sit on a shelf somewhere. It a shame its dead but I'm not sure it's worth the effort it would now seemingly take to get it going.
Being a big box Amiga man, this was one item that I was curious about to see it work. Well Glen as they say, you win some, you lose some. Unfortunate.
Absolutely as I wanted to test it out for myself but it's dead and there is nothing else I can do.
Aww, no outro music this time 😅
You did your best, and I honestly think the outcome of the soldering was alright! PLDs and other one-time programmable logic devices are such a bear when they're broken. I know companies at the time liked them for preventing reverse-engineering, but that's a hindrance to hobbyists 30 years on!
Cut the outros to try and play to the RUclips gods algorithm, not so sure it working though 😅
But yeah those PLDs and other similar devices from the day are most certainly a pain for us these days and in terms of these cards it certainly seems as if there are plenty of examples of failed units.
@@CRG honestly I think they’ve just made significant changes. Everybody’s numbers seem to be down. I’ve certainly noticed far more recommendations from people I’ve never watched before, in stark contrast to the way it worked for a good 4 or 5 years.
And even the subs box (not just the homescreen) isn’t showing me 100% anymore :/ I normally stick things into category playlists to watch later, and many more things are falling through the cracks now.
I hope this isn’t the beginning of the end, but given the ways other social networks are becoming harder to gain traction on… this might be the start of a pay-to-play situation >.
I do have an old programmer that can read and write the programmable logic devices that you have. However any working devices you may find will probably be read protected which effectively stops any repairs of your board.
That's what I suspect so the only way would be to either get a copy of the original equations or brute force it and figure it out from scratch. It would take someone more knowledgeable than my to do that though.
Sorry if I missed it, but don't you need to remove the onboard CPU? I didn't think there was a way to disable the onboard 68K from the expansion slot on the 500 as it lacks the BOSS stuff that you get on the 2000? Looking at the manual, I don't see that - so maybe there is a way it disables the onboard 68K... Another point here - and again unlikely as I would expect some signs of life if this were the issue... It applies caching, probably on ranges except for chip RAM, does it work with the 8375 - ie. 2MB... I know that Tornado I worked on has similar lack of support for Agnus over 8372A.
Thanks for the suggestions. I've tried it without the cpu and it's the same story but I also found an article that said it needs the cpu installed, not sure why it would but either way it's just dead. I did try the accelerator on a rev6 A500 but it's just the same behaviour plus I've had some comments of other folk having it work on their 500+. I'm afraid it seems as if its just dead.
I think the normal way to disable the onboard CPU in the A500 is to simply assert BR and BGK all the time. Since there's no bus arbitration on those machines, this doesn't interfere with anything. I suspect they're just tied to GND as they come off the socket.
Which does make me wonder: since the external CPU isn't doing anything at all (although I don't think you checked AS?), is it possible BR and BGK on the extenal chip are being used in a similar way? Perhaps held low pending a startup signal from the cache controller that never comes?
@@thetechnoshed Yes, certainly worth probing pins on the onboard CPU!
Gents, the manual for this card states that it's just plug and play, so it must be capable of dealing with the original CPU in some manner. The owner of the card has said anyone who wants to have a further go is more than welcome to do so, if either of you to want the challenge then please let me know. It is now though beyond my ability. I'm convinced the fault is a failure in the plds and I have no means of correcting that.
11:33 Why did you re-flow that other chip (IC10)? Now you will never know what really was the fault if it now works.
I was at the stage that I thought let's just throw everything at it.
Shot in the dark but would it work with a different type Agnus?
I tried it with a REV6 A500 so 8372A Agnus and it still doesn't work.
Shame its a dud but you did all you could dude :)...thanks for the update.
Thanks for watching, it's a shame I couldn't get it going but sometimes you just need to draw a line under something.
I am afraid this is a harbinger of things to come for a lot of vintage hardware of that era. GAL and PLDs do have a limited shelf life and will eventually erase themselves. Depending on manufacturer published specs it’s about 20 years which we’ve already gone way past… Since the equation for most of these are closed source and/or the devices themselves are protected this will soon render a lot of these devices useless.
Thats why the PLDs in a working accelerator need to be read by someone with one of those expensive compatible programmers. They could then have new preprogrammed PLDs for sale.h
@@simontay4851 it’s not that easy unfortunately. The vast majority of PLDs used on commercial products of this era will have a protection bit set and cannot be read back. You’re left with reverse engineering the equations by reading the outputs by sending all possible signals combinations to the inputs. This is generally easy for simple PAL/GALs but far more complicated if the GAL/PLD is registered or uses a clock or has hidden intermediate states.
True, the be a use pico pi or an esp32! But your point is validly
@@stbagnI've been doing the same with non registered GALs and PALs for time now using an arduino that dumps a pseudo truth table - for want of a better phrase - to the serial port. I've then manually worked out the equations. So far I've not tried this using registered devices, but it sounds like a nightmare. It would probably be possible if you know the internal setup of the chip ie the cell type and wiring etc, and had the schematics of the board to know what the inputs and outputs are, given GALs can change some of their pins pins from I to O etc.
I guess the first step here is to work out if these two PLAs receive a clock signal or something similar from the layout of the board. If they don't then this may make it easier to understand the logic in them.
On a slightly different note, I suspect the heating up of the cache RAM is probably more to do with a ongoing data bus crash between the two chips if both are constantly selected and one is (for example) trying to drive the bus high and the other low leading to a large constant current draw between the chips or the main data bus (example only!)
It would be helpful to see what is controlling the read and write pins of the RAM chips (I suspect the PLA) and what state these signals are in.
My suspension is that these chips map this in as cache memory as a write through sort of setup, or they cache the kick-start ROM, and redirect the new CPU to this.
I'd also be interested to see if the Kick-start ROM is being selected during the attempt at startup from the accelerator.
@@jamescronin7742 unfortunately these PLCC 44 packages are far bigger than any simple PLA or GALs and are therefore far more complex CPLDs. Brute force truth table building is highly unlikely to work.
well glenn ya threw everything but the kitchen sink at this....and i dont think the sink would have helped.....good try glenn ! what a pain!!also please try not to wait so long to put on a video! i need my crg fix!😅
Sorry it's been so long, just had a lot on with work and family stuff. Back at it now though with 3 videos in the works and what I hope to be a big channel announcement coming soon. So as they say keep watching 😉
any time you have more than one failed IC there is a chance that the board was damaged by over-voltage.
Very possible but I've no way to prove that other than the fact that its dead.
So, forgive any ignorance on my part, but why is the lack of a way to (gracefully) read one of these chips, if you got your hands on a working example, a dead stop? The thing must have a set of inputs, and provide outputs in a predetermined manner. There is a logic to the outputs, right? Why is it not possible, again providing a working example, to brute force it by giving it every possible input combination, and reading the outputs, and building a truth table from it then gleaning the equations from that? Might be a task to do manually for sure, but considering we've got devices like a pi or arduino, surely someone so inclined couldn't program one to do the inputs and outputs and automatically generate the equations from that.
It would be absolutely possible to brute force a working example and from that reproduce the equations for a new chip but I'm afraid doing that is outside of the scope of my knowledge. I'm not sure if there is an automated means of doing it with a Pi or Arduino but I suppose it would be possible to write some sort of program to achieve that.
The issue with doing this though is capturing every state of every pin as they interact with each other. These ICs have multiple inputs and multiple input/outputs (apologies I can't remember the number off the top of my head) so you can appreciate there are probably hundreds of combinations for the logic.
@@CRG I thought so. Sadly, I neither have a working example, nor have I any experience with microcontrollers. I've just seen what others have done and figured someone out there could probably program one to do that. Maybe another one of your viewers. And maybe another will have a working sidecar, and willing to allow it yo be reverse engineered. Maybe even the same viewer. Lol. I've seen similar things before, a viewer have a working example of some obscure item that helps a creator unexpectedly out of a bind. And it'd have the potential of leading to reproduction if lucky.
Frustrating but the journey was at least useful and entertaining!
hopefully those tag ram chips arent counterfeits from china.
Yeah that's a possibility, they do appear to be real and new old stock but it's impossible to say for sure. They do stay cool when the card is powered up now but that doesn't necessarily mean they are real.
Viper 2 fpga time
A lot of effort, time, and money when one could just buy/use a PiStorm or some Terrible Fire accelerator
It's not about the money, it's the challenge!
@@cp256 Exactly. I've done videos on pistorm and other accelerators before, this though was something complete different and I thought an interesting device that deserved my best attempt to fix.
Great idea, do another video about the TF and PS accelerators instead of exploring the more obscure stuff 🙄