[Coco] [bruce#fanboy.net at 127.0.0.1: Re: Multi-Pak PAL equations for CoCo3?]

[Louis Ciotti]

Do bad you can’t really go backward to the actual logic diagram…  :-/


On Mar 14, 2014, at 3:53 PM, John W. Linville <linville at tuxdriver.com> wrote:

> Here is a message from the comp.sys.tandy newsgroup posted back in
> November of 2003 -- hth!
> 
> John
> 
> ----- Forwarded message from Bruce Tomlin <bruce#fanboy.net at 127.0.0.1> -----
> 
>> From: Bruce Tomlin <bruce#fanboy.net at 127.0.0.1>
>> Newsgroups: comp.sys.tandy
>> Subject: Re: Multi-Pak PAL equations for CoCo3?
>> Date: Wed, 12 Nov 2003 11:15:10 -0600
>> 
>> In article 
>> <bruceNS+usenet13-ABA3BC.20591415092003 at news-50.giganews.com>,
>> Bruce Tomlin <bruceNS+usenet13 at fanboy.net> wrote:
>> 
>>> Okay, I've got two multi-paks with the original PAL chip, and two 16V8 
>>> PAL chips that I can program.
>>> 
>>> Does anyone have either the equations or a JEDEC file (even a raw JEDEC 
>>> dump read from a chip would be great) for the updated PAL?
>>> 
>>> Unfortunately my programmer won't read any chip it can't program, and it 
>>> doesn't know how to program any of the pre-V era PAL chips.
>> 
>> I had heard Tandy never set the security fuse on their Multi-Pak PAL 
>> chips, but modern programmers won't even let you read fuse-PALs.  I 
>> guess that means they're yet another form of "dead media".  So I got me 
>> an ancient fuse-PAL programmer, installed it into an old ISA bus PC, and 
>> read the chip with it.  It worked.
>> 
>> Here's a raw JEDEC dump of it:
>> 
>> 14L4*
>> L0000
>> 0000000000000000000000000000
>> 0000000000000000000000000000
>> 0000000000000000000000000000
>> 0000000000000000000000000000
>> 0110101110110101011001010110
>> 1010011101110101011001010110
>> 0000000000000000000000000000
>> 0000000000000000000000000000
>> 0110101110110101011101010101
>> 1010011101110101011101010101
>> 0000000000000000000000000000
>> 0000000000000000000000000000
>> 1010011111111111111111111111
>> 1110101111111111111111111111
>> 1111111011111111111111111111
>> 1111111111101111111111111111
>> *
>> 
>> And the pinout:
>> 
>> 1 = !(A15 & A14 & A13 & A12 & A11 & A10 & A9 & A8)
>> 2 = A7
>> 3 = A6
>> 4 = A5
>> 5 = A4
>> 6 = A3
>> 7 = A2
>> 8 = A1
>> 9 = A0
>> 11 = R/!W
>> 12 = E clock
>> 13 = Q clock
>> 14 => !G for data bus
>> 15 => !I/O read
>> 16 => !I/O write
>> 17 => (unused output)
>> 18 = !CTS - cartridge ROM select
>> 19 = !SLENB - disable internal bus
>> 
>> The equations are:
>> 
>> pin 16 = (address = FF7F or FF9F) and write and E high and Q low
>> pin 15 = (address = FF7F or FF9F) and read and E high
>> pin 14 = address = FF40-FF7F or (address = FF00-FF3F or FF80-FFBF) or 
>> SLENB low or CTS low
>> 
>> It looks like someone couldn't make up their mind on what address to use 
>> for the cartridge select port.  It's also possible that the FF00-FF3F 
>> was a goof from not including the A7 line when looking for FF80-FFBF.
>> 
>> The new equations should probably be:
>> 
>> pin 16 = address = FF7F and write and E high and Q low
>> pin 15 = address = FF7F and read and E high
>> pin 14 = address = FF40-FF7F or SLENB low or CTS low
>> 
>> This is the equivalent of removing the first terms of pins 15 and 16, 
>> and the second term of pin 14.
>> 
>> I'll post a JEDEC file of this for the 16V8 later.
>> 
> 
> ----- End forwarded message -----
> 
> -- 
> John W. Linville		Someday the world will need a hero, and you
> linville at tuxdriver.com			might be all we have.  Be ready.
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco