5 Apr
2010
5 Apr
'10
12:08 p.m.
----------------Original Message:
Date: Mon, 5 Apr 2010 02:13:20 -0400
From: Ethan Dicks <ethan.dicks at gmail.com>
Subject: Anyone have an image of a Japanese PET chrgen ROM 901447-12?
Hi, All,
This has all been discussed over on the cbm-hackers list over the past
several months, but I've been fixing a couple of Static PET boards for
someone in Japan. The only thing that appears to be unique to one of
the boards is a 2316B in a Commodore-built 6540 adapter board (P/N
320076) and the 901447-12 ROM that's in it. There is no corresponding
ROM image on Zimmers.net (where the old funet archive lives), and this
ROM reads all zeros.
I have a photo of the keyboard layout for a Japanese chicklet PET, and
it doesn't happen to match the map of the Japanese C-64. One
interesting feature is a few Kanji characters mixed in with the
Katana, specifically, "4" maps to the Kanji for "year", "5"
has
"month", and "6" has "day" - obviously for rendering dates
easily.
There looks to be 51 Japanese glyphs total (all the Katakana
characters, the three Kanji, and a couple of other characters needed
to write sentences in Japanese). Given that the editor ROM is
identical to a standard European/US BASIC 1.0 PET, it seems likely
that the character drawn on the key would be the replacement in
"upper/lower case mode" for that particular symbol.
It seems likely I could reproduce the general contents of the ROM
following the keyboard map, but it would be great it someone out there
happened to have the real thing. I already know that nobody on the
cbm-hackers list has come forward with a copy, but I'm pretty sure
there are PET owners on this list who are not on cbm-hackers.
If anyone happens to have this ROM or ROM image, please share it with
the great repository at Zimmers.net.
Thank you,
-ethan
--------------------------------Reply:
----------------------------------------------------------
It would certainly be nice to find the 'official' ROM, but I thought that
the ROM that Philip (the owner of that PET on your bench) created
was pretty well complete and correct; it seems to match my Japanese
keyboard perfectly except for one character, and I suspect it's the key
that's wrong and not the CG.
Did you try that image and match it up to your Japanese chiclet
keyboard?
I've been playing with the idea of having all three (four?) character sets
available on screen at the same time, using the reverse video signal.
mike
5 Apr
5 Apr
3:18 p.m.
On 4/5/10, M H Stein <dm561 at torfree.net> wrote:
----------------Original Message:
Date: Mon, 5 Apr 2010 02:13:20 -0400
From: Ethan Dicks <ethan.dicks at gmail.com>
Subject: Anyone have an image of a Japanese PET chrgen ROM 901447-12?
It would certainly be nice to find the
'official' ROM, but I thought that
the ROM that Philip (the owner of that PET on your bench) created
was pretty well complete and correct; it seems to match my Japanese
keyboard perfectly except for one character, and I suspect it's the key
that's wrong and not the CG.
Why would the key be wrong?
Did you try that image and match it up to your
Japanese chiclet
keyboard?
I have not. If you could send me a copy of it off-list, that would be
appreciated. I don't seem to have it in the place I store such things
(though I do remember the conversation).
I've been playing with the idea of having all
three (four?) character sets
available on screen at the same time, using the reverse video signal.
How would that work? Obviously, you'd use some new means of toggling
upper bits on the CHRGEN ROM, but I don't get how the reverse video
signal would be the trigger... the upper bit on a PET character cell
inverts the data out of the bit shifter (unlike the C-64 where it's
just another address bit). I can see how you could steal that upper
bit and pipe it into A11 on a larger CHRGEN ROM, but how do you get 3
or 4 sets from one bit?
-ethan
4:28 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an image of a Japanese PET chrgen ROM 901447-12?
Speaking of early Commodore PETs, I have here a 4032 on which some of the keys
do not work. Some time ago I took a brief look at it and, as I recall,
concluded the problem was not the keyboard but rather something was messed up
with the scanning, something like not all columns/rows being scanned. I think
it was a 6821 or 6822 or some such doing the I/O, but the diagnosis was perhaps
more suggestive of something like a PROM bit failure causing the firmware
program to foreshorten the scan sequence.
Anyone have knowledge of a known failure mode of this sort with these machines?
6 Apr
6 Apr
12:03 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an image of
Speaking of early Commodore PETs, I have here a 4032 on which some of the keys
do not work. Some time ago I took a brief look at it and, as I recall,
concluded the problem was not the keyboard but rather something was messed up
with the scanning, something like not all columns/rows being scanned. I think
it was a 6821 or 6822 or some such doing the I/O, but the diagnosis was perhaps
more suggestive of something like a PROM bit failure causing the firmware
program to foreshorten the scan sequence.
Possible, I suppose, but unlikely. My first test would be to bridge the
suspect row/column pin to all the column/row pins (one at a time) with a
bit of wire at the keyboard connector to ensure the problem is on the
logic board.
I seem to rememebr (and it's been years since I've been inside a PET)
that the scanning is doen by an output port on a PIA chip, decoded with a
TTL decoder. And that the inmputs from the keybaord go to the other port
of that PIA/VIA. I would then check that all the outputs of the decoder
are active
Anyone have knowledge of a known failure mode of this sort with these machines?
Many faults on PETs are caused by the very poor IC sockets used.
Replacing them all with turned pin ones will cure said faults, and even
if it doens't help now, (a) it will prevent such faults in th future and
(b) it will tell you that you have a real fault to find.
-tony
12:59 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an image of
On Tue, Apr 6, 2010 at 3:03 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
Agreed. I have a 2001N/3032 board that mostly works, except for the
IEEE port. It's not the drivers - I'm reasonably certain that it's a
PIA or VIA socket. I have recently secured a stack of 40-pin sockets
and replace them when I have the time. I've had this machine since it
was new, so I'm not unhappy to have to do so. I've gotten a lot of
milage out of it.
-ethan
I seem to rememebr (and it's been years since
I've been inside a PET)
that the scanning is doen by an output port on a PIA chip, decoded with a
TTL decoder.
Yes. A 74LS145.
Anyone have
knowledge of a known failure mode of this sort with these machines?
Many faults on PETs are caused by the very poor IC sockets used.
Replacing them all with turned pin ones will cure said faults, and even
if it doens't help now, (a) it will prevent such faults in th future and
(b) it will tell you that you have a real fault to find.
1:39 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an imageof
Tony Duell wrote:
The unlikely does occur on occasion.
Only a couple of chips are in sockets in this model/unit, not the problem.
Speaking of early Commodore PETs, I have here a
4032 on which some of the keys
do not work. Some time ago I took a brief look at it and, as I recall,
concluded the problem was not the keyboard but rather something was messed up
with the scanning, something like not all columns/rows being scanned. I think
it was a 6821 or 6822 or some such doing the I/O, but the diagnosis was perhaps
more suggestive of something like a PROM bit failure causing the firmware
program to foreshorten the scan sequence.
Possible, I suppose, but unlikely. My first test would be to bridge the
suspect row/column pin to all the column/row pins (one at a time) with a
bit of wire at the keyboard connector to ensure the problem is on the
logic board.
I seem to rememebr (and it's been years since I've been inside a PET)
that the scanning is doen by an output port on a PIA chip, decoded with a
TTL decoder. And that the inmputs from the keybaord go to the other port
of that PIA/VIA. I would then check that all the outputs of the decoder
are active
As I implied, I already checked all this. As stated in my 1st message and in
more depth in my 2nd message the diagnosis shows a problem with the scan
sequence, not the keyboard.
Anyone have
knowledge of a known failure mode of this sort with these machines?
Many faults on PETs are caused by the very poor IC sockets used.
Replacing them all with turned pin ones will cure said faults, and even
if it doens't help now, (a) it will prevent such faults in th future and
(b) it will tell you that you have a real fault to find.
7 Apr
7 Apr
12:05 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
Tony Duell wrote:
The unlikely does occur on occasion.
Of course...
However, assuming the firmware does the obvious thing (load a register
with 0, write it to the output port, increement it, go round again), I am
wondering just what sort of firmware failure could cause this. If the
counter was stored in RAM, it could be a RAM problem, I suppose.
Do you have a logic analyser? If so, try triggering it on a write to the
apporpriate PIA register, and look at machine cycles arround that. See if
you can figure otu what hte frmware is really doing.
Speaking of early Commodore PETs, I have here a
4032 on which some of the keys
do not work. Some time ago I took a brief look at it and, as I recall,
concluded the problem was not the keyboard but rather something was messed up
with the scanning, something like not all columns/rows being scanned. I think
it was a 6821 or 6822 or some such doing the I/O, but the diagnosis was perhaps
more suggestive of something like a PROM bit failure causing the firmware
program to foreshorten the scan sequence.
Possible, I suppose, but unlikely. Only a couple of chips are in sockets in this
model/unit, not the problem.
Far too many times i've thoguht 'Oh, that's certainly not the problem'
and then spent hours/days looking elsewhere only to find in the end that
that it _was_ the problem :-)
I can't rememebr who first said 'In any system that which is most
obviosulty correct, beyond all need of checking, is the problem.'
-tony
3:25 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
Tony Duell wrote:
It is poor policy to not give consideration to a potential source of a
problem on the basis of an assumption.
A more typical way of programming this would be to load a register with the
loop count and decrement till zero or negative. 9 is the first value to be
output both in that scenario (the '145 is a decade decoder) as well as the
observed sequence, the observed sequence being one which increments.
I don't have the 6502 instruction encoding at hand, but I'll hazard a guess
there is only a 1-bit difference between a decrement instruction and an
increment instruction, said instruction coming out of ROM. A sequence which
was supposed to go from 9 down to 0 would hence go from 9 up to F and then 0,
within 4 bits.
Note also the intended sequence is a cycle-of-10, the observed sequence is a
cycle-of-8, there are 2 values (0,9) in common to the sequences, and 10+8-2=16=2^4.
That would seem to be in contradiction to your earlier suggestion of the
unlikely not likely being the problem.
The sockets are not a problem as they have been checked already.
The power supply levels have also been checked.
Tony Duell wrote:
The unlikely does occur on occasion.
Of course...
However, assuming the firmware does the obvious thing (load a register
with 0, write it to the output port, increement it, go round again), I am
wondering just what sort of firmware failure could cause this. If the
counter was stored in RAM, it could be a RAM problem, I suppose. Speaking of early Commodore PETs, I have here a
4032 on which some of the keys
do not work. Some time ago I took a brief look at it and, as I recall,
concluded the problem was not the keyboard but rather something was messed up
with the scanning, something like not all columns/rows being scanned. I think
it was a 6821 or 6822 or some such doing the I/O, but the diagnosis was perhaps
more suggestive of something like a PROM bit failure causing the firmware
program to foreshorten the scan sequence.
Possible, I suppose, but unlikely. Do you have a logic analyser? If so, try triggering it
on a write to the
apporpriate PIA register, and look at machine cycles arround that. See if
you can figure otu what hte frmware is really doing.
If I had a logic analyser it would have been applied already.
Only a couple
of chips are in sockets in this model/unit, not the problem.
Far too many times i've thoguht 'Oh, that's certainly not the problem'
and then spent hours/days looking elsewhere only to find in the end that
that it _was_ the problem :-)
I can't rememebr who first said 'In any system that which is most
obviosulty correct, beyond all need of checking, is the problem.'
8 Apr
8 Apr
11:29 a.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
It is poor policy to not give consideration to a
potential source of a
problem on the basis of an assumption.
Of course. That is the quickest way not to find a problem :-)
A more typical way of programming this would be to load a register with the
loop count and decrement till zero or negative. 9 is the first value to be
output both in that scenario (the '145 is a decade decoder) as well as the
observed sequence, the observed sequence being one which increments.
Now that's an interesting suggestion, I'd not thought of that, and it
makes a lot of sense.
It would be interesting to look at the key scanning lines of a working PET
(either at the input of the '145 or the outputs, suitable pulled up) to
see which direction it counts in.
I don't have the 6502 instruction encoding at
hand, but I'll hazard a guess
there is only a 1-bit difference between a decrement instruction and an
There is in most cases (assuming thr Apple ][ referecne manual is
correct), but it's not as obvious as you might think. It's not always the
same bit that changes.
DEC M (memory revference) are C6, D6, CE, DE depending on the addressing
mode. THey become E6, F6, EE, FE respecively (so it's the 32's bit that
changes)
DEX is CA, INX is E8,. So here he 32s an d the 2s bits both change
DEY is 88, INY is C8, so it's the 64s bit here.
The difference between ADC and SBC (add and subtract) seems to be the
128s bit in all cases.
Are the ROMs socketed? If so, it would be sensible to compare them with
ROM dumps fro ma working machine.
-tony
9 Apr
9 Apr
11:04 a.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
Tony Duell wrote:
That a different bit changes for the different forms of inc/dec instructions
is irrelevent to the conjecture. The primary candidates see only a 1-bit change.
The conjecture doesn't strictly hinge on the 1-bit aspect, regardless, just
makes it more likely.
It is poor policy to not give consideration to a
potential source of a
problem on the basis of an assumption.
Of course. That is the quickest way not to find a problem :-)
A more typical way of programming this would be to load a register with the
loop count and decrement till zero or negative. 9 is the first value to be
output both in that scenario (the '145 is a decade decoder) as well as the
observed sequence, the observed sequence being one which increments.
Now that's an interesting suggestion, I'd not thought of that, and it
makes a lot of sense.
It would be interesting to look at the key scanning lines of a working PET
(either at the input of the '145 or the outputs, suitable pulled up) to
see which direction it counts in.
I don't have the 6502 instruction encoding at
hand, but I'll hazard a guess
there is only a 1-bit difference between a decrement instruction and an
There is in most cases (assuming thr Apple ][ referecne manual is
correct), but it's not as obvious as you might think. It's not always the
same bit that changes. DEC M (memory revference) are C6, D6, CE, DE depending
on the addressing
mode. THey become E6, F6, EE, FE respecively (so it's the 32's bit that
changes)
DEX is CA, INX is E8,. So here he 32s an d the 2s bits both change
DEY is 88, INY is C8, so it's the 64s bit here.
The difference between ADC and SBC (add and subtract) seems to be the
128s bit in all cases.
Are the ROMs socketed?
IIRC, only one of several is.
If so, it would be sensible to compare them with
ROM dumps fro ma working machine.
Glad you see it my way.
Someday I might get back to working on it. Getting ROM dumps from a working
machine shouldn't be difficult even for the soldered-in ROMs (a little PEEKing
program or such), they may be out on the web already. Unfortunately, in the
broken machine the socketed ROM - if it is something optional - is not likely
to contain the pertinent code.
12:29 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
There is in
most cases (assuming thr Apple ][ referecne manual is
correct), but it's not as obvious as you might think. It's not always the
same bit that changes.
That a different bit changes for the different forms of inc/dec instructions
is irrelevent to the conjecture. The primary candidates see only a 1-bit change. The conjecture doesn't strictly hinge on the 1-bit
aspect, regardless, just
makes it more likely.
Sure. A single-bit failure is more likely than a 2-bit failure, etc. I
wonder if one direction of failure is more likely than another (in the
case of most EPROMs, as they contaiin FFs when erased, bit rot gerneally
causes 0's to become 1's, for example)
If so, it
would be sensible to compare them with
ROM dumps fro ma working machine.
Glad you see it my way.
Someday I might get back to working on it. Getting ROM dumps from a working
machine shouldn't be difficult even for the soldered-in ROMs (a little PEEKing
program or such), they may be out on the web already. Unfortunately, in the broken machine the socketed ROM - if it is something
optional - is not likely
to contain the pertinent code.
Ithink we can disocunt the possibllity of a bad socket too ;-)
It might be easiest to desolder the 6502 processor and find some way to
drive the address connections on its PCB position and monitor the data
lines. Compters with what I grew up calling 'user ports' are not common
these days [1] althoguh it shouldn't be hard to make somthing (I hate to
say this, but I would guess a microcontroller with a USB slave interface
could do this very easily on a modern PC.
[1] I personalluy like the HP98622 card in an HP9000/200 machine.
-tony
12:50 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
On 4/9/10, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
> Someday I might get back to working on it. Getting
ROM dumps from a
> working
> machine shouldn't be difficult even for the soldered-in ROMs (a little
> PEEKing
> program or such), they may be out on the web already.
They are...
http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/index.html
It might be easiest to desolder the 6502 processor and
find some way to
drive the address connections on its PCB position and monitor the data
lines.
An 80C52 or ATmega8515 (depending on what your preferred architecture
is) has at least 24 I/O lines and can be easily interfaced to via
serial port. A slightly more complex way of doing it might be to gang
a pair of '595s together for a 16-bit SPI-interfaced port (3 wires for
clock, data, and latch) to drive the address bus off the 6502 socket
then generate _R/W, Phi2, etc, and read or write what's at that
address from some 8-bit bidirectional port your tester happens to have
(doing read-only tests could result in a simpler tester). I myself
have been doing exactly these sorts of tests recently on a pile of
1977-1978-era Static PET boards with a Fluke 9010A and 6502 pod. I've
even identified three bad 6540 ROM chips (out of 16 or so tested) and
one bad 2316. The 2316 was 100% bad (all reads were zero), but the
6540s were about 1% bad - I was surprised at that.
Of course with a tester that's as sophisticated as a Fluke 9010A, you
could probably write a Fluke program to set up the PIA to scan the
keyboard matrix and test that aspect of the circuit independently of
any ROM tests.
If you don't already have a Fluke + 6502 pod lying around and don't
have enough 6502 machines to repair to justify the investment, it
shouldn't be too hard to make a microcontroller-based 6502 memory map
tester, even from something like an Arduino (for those that don't want
to roll their own stuff 100% from scratch).
-ethan
1:50 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
Ethan Dicks wrote:
Interesting, I'm not familiar with the 6540, not sure if there would be
any in this 4032.
On 4/9/10, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
Great, I'll have to cross-check part numbers sometime to see if there are
matches for the ones in the 4032 here.
> Someday I might get back to working on it.
Getting ROM dumps from a
> working
> machine shouldn't be difficult even for the soldered-in ROMs (a little
> PEEKing
> program or such), they may be out on the web already.
They are...
http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/index.html It might be
easiest to desolder the 6502 processor and find some way to
drive the address connections on its PCB position and monitor the data
lines.
An 80C52 or ATmega8515 (depending on what your preferred architecture
is) has at least 24 I/O lines and can be easily interfaced to via
serial port. A slightly more complex way of doing it might be to gang
a pair of '595s together for a 16-bit SPI-interfaced port (3 wires for
clock, data, and latch) to drive the address bus off the 6502 socket
then generate _R/W, Phi2, etc, and read or write what's at that
address from some 8-bit bidirectional port your tester happens to have
(doing read-only tests could result in a simpler tester). I myself
have been doing exactly these sorts of tests recently on a pile of
1977-1978-era Static PET boards with a Fluke 9010A and 6502 pod. I've
even identified three bad 6540 ROM chips (out of 16 or so tested) and
one bad 2316. The 2316 was 100% bad (all reads were zero), but the
6540s were about 1% bad - I was surprised at that. Of course with a tester that's as sophisticated as
a Fluke 9010A, you
could probably write a Fluke program to set up the PIA to scan the
keyboard matrix and test that aspect of the circuit independently of
any ROM tests.
If you don't already have a Fluke + 6502 pod lying around and don't
have enough 6502 machines to repair to justify the investment, it
shouldn't be too hard to make a microcontroller-based 6502 memory map
tester, even from something like an Arduino (for those that don't want
to roll their own stuff 100% from scratch).
I actually use a SWTPC 6800 for this sort of thing on occasion: RS232 serial to
console computer, 6820 PIA lines to DUT, perhaps some intervening hardware
between the PIA lines and DUT. Write a little 6800 assembler program on the
console computer, download it to the 6800 to do DUT control and data capture
and send the data back to the console computer.
It would be nice to build up something a little less cumbersome, however. I
have yet to get around to setting up here for programming modern
microcontrollers. I'll take note of the ATmega8515, I was looking at PICs a
while ago but just wasn't getting enthused about the instruction set.
2:15 p.m.
New subject: PET 4032 keyboard scanning problem / was Re: Anyone have an
On 4/9/10, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
There would not be. The 6540 is an oddball MOS ROM with a lot of
select lines and a non-JEDEC pinout.
You will have 2332s in your machine. They will have a pinout
compatible with a TI2532. If you do have a bad ROM, you could track
down a TI2532 to replace it, or make an in-socket pin-swabber to
relocate a couple of pins and burn a bog-standard 2732. I've done
both.
Great, I'll have to cross-check part numbers sometime to see if there are
matches for the ones in the 4032 here.
IIRC, your 4032 might or might not have a 6545 CRTC chip. That's the
critical difference to determine what ROM set you might have - The 12"
PETs all had CRTCs I'm pretty sure, but I'm a bit fuzzy about the
transition between 9" and 12" models.
The ROMs are all uniquely numbered - just check your parts against the
list on zimmers.net. I would be shocked if yours weren't there or at
least mentioned as exact copies of some older part.
... I've
even identified three bad 6540 ROM chips...
Interesting, I'm not familiar with the 6540, not sure if there would be
any in this 4032. I actually use a SWTPC 6800 for this sort of thing on
occasion: RS232 serial
to console computer, 6820 PIA lines to DUT, perhaps some intervening hardware
between the PIA lines and DUT. Write a little 6800 assembler program on the
console computer, download it to the 6800 to do DUT control and data capture
and send the data back to the console computer.
Sure. I did something like that years ago with a 6821 PIA hanging off
of a self-built VIC-20 cartridge (since the protoboards were $3 at
Radio Shack and the VIC-20 was about the cheapest platform I could lay
hands on at the time - $20 or less at hamfests). What you pick is
largely influenced by when you pick it.
It would be nice to build up something a little less
cumbersome, however. I
have yet to get around to setting up here for programming modern
microcontrollers. I'll take note of the ATmega8515, I was looking at PICs a
while ago but just wasn't getting enthused about the instruction set.
I am working on an ATmega8515-based clock board with a local friend of
mine (we punted when the 89C52 was giving us some fits, and the 8515
has a compatible pinout, so there were no hardware changes to the
target). I have a lot of Arduino (ATmega8/168/328) experience, and
I'm a crack C programmer, so I've had zero problems with the 8515 so
far (I'm using a USBtinyISP to program it, in case anyone is curious -
$20 kit from a couple of places) - but you can make non-USB
programmers from scratch less expensively).
I'm really happy with the 8515 - it's powerful enough for what I'm
doing, plenty of code space, I/O, timers, interrupts, etc. I also use
Arduinos (ATmega8/168/328), helping me keep in the same mindset and
use the same toolchain and programming device.
-ethan
5372
days inactive
5376
days old
14 comments
5 participants
participants (5)
-
ard＠p850ug1.demon.co.uk -
dm561＠torfree.net -
ethan.dicks＠gmail.com -
hilpert＠cs.ubc.ca -
pu1bzz.listas＠gmail.com