View Single Post
Old 13th Feb 2021, 12:57 am   #586
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,440
Default Re: Non-working Commodore PET 3016

[QUOTE=SiriusHardware

>>Results:
>>UD6 - matches "basic-2-c000.901465-01.bin", checksum = 3838
>>UD8 - matches "edit-2-n.901447-24.bin", checksum = FDBF *
>>UD9 - matches "kernal-2.901465-03.bin", checksum = 7C98

>>* although an 8K device this IC only contains 4K of code, the checksum is of the lower half (0000 - 07FF). Upper half contains all FF.


Information for Owen: The original Mask-Programmed PROMS used in the PET have -up to- three CS pins, named CS1, CS2, CS3. The exact function and 'sense' of these pins was programmed at the manufacturing stage, and the ones in the PET are set up like this:

CS1 (Pin 20) - Active low chip select
CS3 (Pin 21) - Active high chip select

CS2 (Pin 18) - programmed as address line A11. That is why, when you look at the PET circuit diagram, the PROMs all have a CS1 and CS3 but mysteriously, no CS2.

In the PET, pin 21 (active high chip select) is held at permanent +5V which is fortunate, as that pin coincides with VPP which also needs to be held at +5V for read mode on on 2532, etc EPROMs.[/QUOTE]

Thanks for the Info. Yes Commodore were often keen on having extra chip selects on the memories (I do recall them having 5 on one), to save a bit on external address-decoding logic.
Although if one active-high CS is permanently tied high, then that's one less that's really needed to have to emulate with an EPROM, and getting back to more like the usual 2 (or only 1 with 8K squeezed into 24pins)

I didn't think you could program as such where Address lines went. And maybe they dropped the 'CS2' to maintain naming on previous half-size devices but wanted Address-line compatibility with standards for 4KB? ones.

So with only 1 active-low CS required, then those MCM6876x ones should work with no extra logic required.


Re: UD8 being an 8KB device , with 'Upper' half reading all FF
Could it be that it was actually a 4KB device, with an active-low chip select connected to the 'A12' pin. As that may also result in FF being read if programmer has slight pull-ups on its data-lines, to prevent floating?
I do recall seeing some programmers read all FF's with no / faulty IC present.
ortek_service is offline