Today Ive released the file I created as a replacement for the HAL16L8 from an Amstrad 6128.
Its taken me quite a while and have had help along the way but now its here and tested as much as I can.
Hope this helps some people out.
Thanks to arnoldemu for his truth tables and to Charles MacDonald for once again showing me what the hell was going on when I couldn’t.
caius is back with a couple more PAL dumps. This time from the Japan version of Strikers 1945.
They are in GAL16V8 format already and are tested.
Thanks again to caius
caius has dumped and tested 2 PAL chips from a Super Pang bootleg.
He says this bootleg is a bit different to the one normally found so these files may not work for everyone.
Thanks to caius
Meet my new addition to my retro collection, the Amstrad 6128.
Ive never owned an Amstrad computer before and I absolutely love it.
I had to change the drive belt but other than that it works great and came with a few discs too.
Ive made a lot of progress since my plea for help regarding this chip.
To recap, this chip could not be dumped in a programmer as it was security locked and I could not recreate its logic by the usual automated method due to the fact that this chip used latches, something that I had not seen before in a combinatorial device.
Due to the fact that this chip operates in a not often seen way I thought it would be good to write a bit about what Ive found, mainly the latches.
If you look at the schematics for this system you can see the HAL/PAL chip in all its glory.
What I initially found was equations associated with the three X pins (pins 13, 14 and 15) but on the schematic they appear to be disconnected to which I assumed meant unused. You know what they say about assumptions right?
These three pins are where the latches come in. The Amstrad 6128 has 8 different memory selections from C0-C7. With these latches the system will always be in the same memory configuration until it is changed. Makes a lot of sense when you think about it or after every write to a specific memory location it would default back to C0. These configurations are derived from the D# pins but obviously those D# pins are used to send the actual data on too so without these latches the data bus would only be 5 bit.
Using a lot of logic analysis and a huge helping hand from Charles MacDonald I eventually got these latches working. All plain sailing from here I thought. No chance!
I was easily able to implement the A15OUT, A14OUT, CAS0 and CAS1 from truth tables found on CPCtech but this brought up another issue. When one of the CAS lines was LOW it would latch into this state until the NCAS line was toggled.
From my initial inspection of this behavior it seemed like they were switching on a low edge which meant a flip-flop needed to be used. Looking at what I already had I could see there wasn’t going to be enough product terms available to implement this flip-flop.
After sleeping on the problem it occurred to me that it was simply another latch that locked the other CAS line out until the NCAS line reset.
Im pleased to say that all my testing seems to be spot on so far but I could really do with testing some of the other modes to be completely sure. Ive been testing a GAL16V8 replacement out and there are no issues so far.
This thing has taken me a very long time to do and its been very satisfying to now be at (or near) the end.