Epson PF10 problems

Tony Duell ard at
Thu Dec 22 19:15:40 CST 2005

> > I am currently working on an Epson PX8 system. I bought this on E-bay, so 
> I don't hve the PF10 so I can't offer specific help, however I will mention that
> I have a few of the application ROMs for the PX-8 if you are interested in
> the content.

Quite possibly, yes. But let me get the machine working properly first :-)

Other (related) things that I am looking for....

1) The plastic ROM carriers. These are plastic mouldings that you put a 
DIP-packaged EPROM into, then crimp the pins over. The same carriers were 
used in the Tandy M100, and I think 24-pin versions were used in that 
Panasonic hand-held machine that gets mentioned here. I need the 28 pin 
ones, I think Molex once made them.

2) Is the PX4 technical manual on the net anywhere (I've found the PX8 
one already). The thing I need most at the moment is the pinout of the 
cartridge connector. I have a 3rd party 512K (!) RAMdisk module there 
which doesn't seem to work.

> > clocking (1.23MHz on the Eclk pin), it's accessing the ROM, but it also 
> > appears to be wandering around the memory map (outputs on the '138 
> > decoder that are not used for anything are being asserted at times). The 
> > address lines look odd to me, with pulses narrower than the Eclk on some 
> > of them.
> > 
> > Since the ROM is socketed, I pulled it and read it out. It looks sane. 
> > Certainly no data bit is stuck high or stuck low, and all the address 
> > lines do something. Assuming it's like a 68xx processor, with reset and 
> > interrupt vectors at the top of memory, that looks sane too.
> If you have correctly identified the vectors, they should point into the
> ROM space ...

That's what I mean by sane....

The ROM sits in the second half of the address space (it's an 8K ROM, 
27C64, and it's enabled when A15 is high. It's ghosted 4 times). If this 
is like a 68xx, I would expect vectors at the very top of the address 
space, with the highest one of all to be the reset vector MSB first.

This ROM contains what looks like code in the first half or so. Then a 
large block of FFs. And then the vectors. The very top one is 'E000' 
which would point to the first byte of the ROM. Most of the others are 
EExx, again in the 'code-like' part of the ROM.

Obviously this doesn't mean that the ROM is good, but it does mean it's 
not totally defective.

> If you can get the exact CPU type, I may have a disassembler that will
> let you peek into the startup code a little better.

It's an HD6303X. I can look up all the letters (things like the clock 
rating) if you need them, but that should be enough. In any case, writing 
a disassembler is not going to take me too long if I need to do it.

> > I suspect the microocontroller or the RAM. Alas both are SMD (and 
> > therefore a pain to remove), I have spares for neither and no way to get 
> > them.
> > 
> > Any comments, suggestions, or things to check?
> As noted above I don't have a PF10, so this is only general info.
> If the code in the EPROM is good, it's likely bad RAM (stack), contention
> on the bus causing corrupted reads, or a bad buffer (or even the micro)
> also causing bad reads. - But I suspect you already know this.

There are no bus buffers in this unit (there don't need to be, the only 
things on the bus are the microcontroller, ROM, RAM, and 765 disk 
controller chip). The 765 is powered down (I think this is correct, it is 
powered from the switched 5V line. Since that line direclty powers the 
in-use LED on the drive frontpanel, I suspect it should be off when the 
thing is not actually reading/writing). 

I don't think it's a contention either. The address decoder seems to be 
doing the right things too. THis leaves the 2 devices I suspected -- RAM 
and microcontroller.

> Given that so many parts are SMD but the EPROM is socketed, the first
> thing I would probably do is to use my EPROM emulator (or program
> another 2764 if you don't have one) to do a simple single JMP instruction
> infinite loop out of reset - this will tell you if the CPU can read and execute
> code from the ROM, and will give you a much more stable bus to look at.
> Assumign that works, I might then fill the ROM with NOPs (and a JMP at
> the end to the beginning) so that I could see activity on the address bus.
> MOV immediates can be used to get a specific (or incrementing) data
> pattern every few cycles as well (now you know what I like to use an
> EPROM emulator for this).

Fortunately I do have an EPROM emulator. This is a good idea, well worth 
trying. Next thing is to get out the datasheets and find the opcodes for 
jmp and nop ;-)


More information about the cctech mailing list