Author Topic: Commodore 64 PLA chip 906114-01  (Read 3187 times)

0 Members and 1 Guest are viewing this topic.

Offline edyTopic starter

  • Super Contributor
  • ***
  • Posts: 2385
  • Country: ca
    • DevHackMod Channel
Commodore 64 PLA chip 906114-01
« on: September 03, 2018, 03:45:05 pm »
I'm trying to find a BIN dump of the 906114-01 ROM or at least put together one. I found some information on the PLA here but can't seem to find an already put together image and I'm not sure why.

http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/c64/

I also looked here, tried the BIN file, didn't work:

http://www.vic20.de/html/eprom_pla_8296_und_c64.html

Does anyone have any suggestions on how to make or get this ROM? Thanks. Seems I have all the other Firmware ROMS, and I was also able to successfully emulate PET 2001 using files from the zimmers site. But C64 is elusive. I wonder if it has to do with copyright issues. I was surprised the other files were available, and that the PET 2001 system seems to have everything needed to run (and get into a BASIC prompt).

[EDIT:  Although preferred not to, I managed to find the 906114-01.u17 file in here:   http://mess.oldos.net/c64.zip and managed to get to BASIC prompt]
« Last Edit: September 03, 2018, 04:29:17 pm by edy »
YouTube: www.devhackmod.com LBRY: https://lbry.tv/@winegaming:b Bandcamp Music Link
"Ye cannae change the laws of physics, captain" - Scotty
 

Offline Alex Eisenhut

  • Super Contributor
  • ***
  • Posts: 3338
  • Country: ca
  • Place text here.
Re: Commodore 64 PLA chip 906114-01
« Reply #1 on: September 04, 2018, 12:27:43 am »
It's not a ROM, it's a PLA. I'd guess it would need a .jed file. But do you have blank 82S100s to program?

Why not just buy a PLAnkton for a few bucks?
Hoarder of 8-bit Commodore relics and 1960s Tektronix 500-series stuff. Unconventional interior decorator.
 
The following users thanked this post: TK

Offline Peabody

  • Super Contributor
  • ***
  • Posts: 2005
  • Country: us
Re: Commodore 64 PLA chip 906114-01
« Reply #2 on: September 04, 2018, 01:56:17 am »
Back in the day I programmed a handful of 82S100's for this purpose, and they worked fine.  I believe I read the contents as a ROM, but had to build a special device to program them because of the voltage requirements.  But all my CBM stuff is long since gone.  It looks like that PLAnkton is the way to go.  Or maybe you could get the genuine CBM PLAs on Ebay or AliExpress.
 

Offline edyTopic starter

  • Super Contributor
  • ***
  • Posts: 2385
  • Country: ca
    • DevHackMod Channel
Re: Commodore 64 PLA chip 906114-01
« Reply #3 on: September 04, 2018, 02:41:08 am »
There is a PLA binary generator and source packaged on the zimmers.net site called "82S100+Jedec.zip" which does contain a JED file "C64APLA.jed" as shown below. The file is here: http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/c64/82S100%2bJedec.zip. Contents of that ZIP are shown:

-rw-rw-r-- 1 edy edy 10700 Mar  6  2015 82S100.cpp
-rw-rw-r-- 1 edy edy   624 Mar  6  2015 82S100.h
-rw-rw-r-- 1 edy edy   957 Mar  4  2015 82S100.sln
-rw-rw-r-- 1 edy edy  4439 Mar  5  2015 82S100.vcxproj
-rw-rw-r-- 1 edy edy  1358 Mar  5  2015 82S100.vcxproj.filters
-rw-rw-r-- 1 edy edy  2537 Mar  5  2015 C64APLA.jed
drwx------ 2 edy edy  4096 Mar  5  2015 Release
-rw-rw-r-- 1 edy edy   293 Mar  4  2015 stdafx.cpp
-rw-rw-r-- 1 edy edy   320 Mar  4  2015 stdafx.h
-rw-rw-r-- 1 edy edy   314 Mar  4  2015 targetver.h

The Release folder contains the file 82S100.exe (just the compiled 82S100.cpp). This is "82S100 JEDEC file to Eprom converter (c) 2015 by Frank 'androSID' Wolf, Contact: info@androSID.com. This is used to program an actual PAL, but I was looking for something to convert the JED to something the MAME/MESS emulator can use.... at least, that was the idea before I ran into that elusive 906114-01.u17 file (which for whatever reason was the only thing not included on zimmers.net that was required for the emulator to run). 

As it turns out, the JED *can* be used to fill in the missing blank for the emulator. It turns out that when analyzing the JED file and the 906114-01.u17 file I found from the C64 emulator (which does indeed work), they contain the same info just I didn't know what format was used. They are byte-for-byte matches but each has the binary in reverse. I will explain below... Here they are...

JED file from the ZIP file above used to write the 8S2100 lists the following table in text format (in between some formatting codes):

Code: [Select]
JEDEC file generated by Max Loader*
DM SIGNETICS(PHILIPS)*
DD PLS100*
QP28*
QF1928*
QV0*
G0*F0*
L00000 11101011 11100110 11110110 11101111 00111111*
L00040 11111011 11101010 11110110 11101111 01011111*
L00080 11111011 11101010 11110110 01011111 01011111*
L00120 11111001 11101001 10110110 11101111 01101111*
L00160 11101101 11101001 10110110 11101111 01101111*
L00200 11111001 11101001 10110110 01011111 01101111*
L00240 11111111 10111111 11111011 11100110 01101111*
L00280 11111111 10111111 11111011 01010110 01101111*
L00320 10111111 11101001 10110101 11111111 11111111*
L00360 11111010 11101001 10100110 11101111 01111011*
L00400 11111010 11101001 10110101 11101111 01111011*
L00440 11101110 11101001 10100110 11101111 01111011*
L00480 11101110 11101001 10110101 11101111 01111011*
L00520 11111010 11101001 10100110 01011111 01111011*
L00560 11111010 11101001 10110101 01011111 01111011*
L00600 11101110 11101001 10100110 01011111 01111011*
L00640 11101110 11101001 10110101 01011111 01111011*
L00680 11111111 11101001 10100110 10011111 01111011*
L00720 11111111 11101001 10110101 10011111 01111011*
L00760 11101011 11100101 11110110 01111111 01111101*
L00800 11111111 11100101 11110111 10011111 01111101*
L00840 11111011 11100110 11110110 01011111 01111110*
L00880 11111111 11101010 11110111 10011111 01111110*
L00920 11111111 11111111 11111011 10011010 01111110*
L00960 11111111 11010111 10111111 10011111 01111111*
L01000 11111111 11010110 11111111 10011111 01111111*
L01040 11111111 11011011 11111111 10011111 01111111*
L01080 11111111 11100110 11111111 10011111 01111111*
L01120 11111111 11101001 01111111 10011111 01111111*
L01160 01111111 11111111 11111111 11111111 11111111*
L01200 10111111 11111111 11111111 11111111 01111111*
L01240 01111111 11101001 10110101 11111111 11110111*
L01280 00000000 00000000 00000000 00000000 00000000*
L01320 00000000 00000000 00000000 00000000 00000000*
L01360 00000000 00000000 00000000 00000000 00000000*
L01400 00000000 00000000 00000000 00000000 00000000*
L01440 00000000 00000000 00000000 00000000 00000000*
L01480 00000000 00000000 00000000 00000000 00000000*
L01520 00000000 00000000 00000000 00000000 00000000*
L01560 00000000 00000000 00000000 00000000 00000000*
L01600 00000000 00000000 00000000 00000000 00000000*
L01640 00000000 00000000 00000000 00000000 00000000*
L01680 00000000 00000000 00000000 00000000 00000000*
L01720 00000000 00000000 00000000 00000000 00000000*
L01760 00000000 00000000 00000000 00000000 00000000*
L01800 00000000 00000000 00000000 00000000 00000000*
L01840 00000000 00000000 00000000 00000000 00000000*
L01880 00000000 00000000 00000000 00000000 00000000*
L01920 01111111* 
C7DEB*

And here is the data in the 906114-01.u17 binary file (as viewed through Jeex HEX/Binary viewer):

Code: [Select]
1: 00000000 00000000 00000111 10001000  11010111 01100111 01101111 11110111
 2: 11111100 11011111 01010111 01101111  11110111 11111010 11011111 01010111
 3: 01101111 11111010 11111010 10011111  10010111 01101101 11110111 11110110
 4: 10110111 10010111 01101101 11110111  11110110 10011111 10010111 01101101
 5: 11111010 11110110 11111111 11111101  11011111 01100111 11110110 11111111
 6: 11111101 11011111 01101010 11110110  11111101 10010111 10101101 11111111
 7: 11111111 01011111 10010111 01100101  11110111 11011110 01011111 10010111
 8: 10101101 11110111 11011110 01110111  10010111 01100101 11110111 11011110
 9: 01110111 10010111 10101101 11110111  11011110 01011111 10010111 01100101
10: 11111010 11011110 01011111 10010111  10101101 11111010 11011110 01110111
11: 10010111 01100101 11111010 11011110  01110111 10010111 10101101 11111010
12: 11011110 11111111 10010111 01100101  11111001 11011110 11111111 10010111
13: 10101101 11111001 11011110 11010111  10100111 01101111 11111110 10111110
14: 11111111 10100111 11101111 11111001  10111110 11011111 01100111 01101111
15: 11111010 01111110 11111111 01010111  11101111 11111001 01111110 11111111
16: 11111111 11011111 01011001 01111110  11111111 11101011 11111101 11111001
17: 11111110 11111111 01101011 11111111  11111001 11111110 11111111 11011011
18: 11111111 11111001 11111110 11111111  01100111 11111111 11111001 11111110
19: 11111111 10010111 11111110 11111001  11111110 11111110 11111111 11111111
20: 11111111 11111111 11111101 11111111  11111111 11111111 11111110 11111110
21: 10010111 10101101 11111111 11101111  00000000 00000000 00000000 00000000
22: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
23: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
24: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
25: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
26: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
27: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
28: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
29: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
30: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
31: 00000000 00000000 00000000 00000000  11111110

Notice that the data is identical, except that each byte in the JED file is written in "reverse binary" from that in the U17 file. That is, if you look at the last byte of each of these files (at the end).... one is 01111111 and the other is 11111110. Now if you work backwards... If you go through each byte from the tail end of the file and work your way back to the beginning..... each byte matches (except the JED binary digits written in reverse order to those in the U17). The JED file is 4 bytes SHORTER than U17.

The only difference is the JED file contains 241 bytes, whereas the U17 file contains 245. So if we start with byte #5 of the U17 file and match them up with the 1st byte of JED, now we look through the first few lines and compare, they match up exactly except bit values are simply reversed for every byte as shown here:

Code: [Select]
JED: 11101011 11100110 11110110 11101111 00111111 11111011 11101010 11110110
U17: 11010111 01100111 01101111 11110111 11111100 11011111 01010111 01101111

JED: 11101111 01011111 11111011 11101010 11110110 01011111 01011111 11111001
U17: 11110111 11111010 11011111 01010111 01101111 11111010 11111010 10011111

See.... the JED file table and the U17 match exactly byte for byte...  except U17 has an extra 4 bytes at the beginning (not sure why). Otherwise the binary is just reversed. This could be due to my "hex/binary" viewer which I used to view the U17 file. Or it could be a convention of the JED file format, or the way the PAL/EEPROM writer works. Or could it be the way the MAME/MESS emulator designers decided to format their files (that is, the U17 file format has each byte written in reverse digits)? Not sure, but either way it means that if I can find other JED files potentially using this pattern I may be able to convert to other PAL that can be used in the emulator, and vice-versa get emulator files and convert them back to JED?
« Last Edit: September 04, 2018, 02:57:39 am by edy »
YouTube: www.devhackmod.com LBRY: https://lbry.tv/@winegaming:b Bandcamp Music Link
"Ye cannae change the laws of physics, captain" - Scotty
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf