Epson PF10 problems

[Roy J. Tellason]

On Friday 23 December 2005 11:24 am, Dave Dunfield wrote:
> > > 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.
> >
> > You got my attention with that one!  Assuming that I can get this thing
> > working again,  that is...
>
> I'll dig em out over the holiday and see if I can read them.

No rush,  I still need to get that thing working...

> > > 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.
> >
> > For which chips?
>
> Lots! ("My day job is producing development tools for a large number of
> embedded processors).

Hmm.

> > > Lastly, one little tool I have in my "homebuilt gadgets" box is a 28
> > > pin "plug" attached to a little board with a ROM socket ,a bit of logic
> > > and a really dumb UART (the kind you setup in hardware).
> >
> > This sounds interesting.  Which UART would that be?  I'm vaguely
> > remembering something of the sort,  but can't remember the part number, 
> > and am pretty sure I don't have any,  though I have lots of the other
> > sort in various families...
>
> I'd have to look at it to be certain (haven't had to write anything for it
> in a long time), but I'm pretty certain I used a 6402 - but you could use
> any of the "hardare programmable" uarts (AY-5-1013, COM2502 etc.) - You
> don't NEED to use a "hardware programmable" uart, but doing so means that
> the only thing you need to write is the data register. And with this setup,
> "writes" are best kept to a minimum :-)

Yeah,  and it sure simplifies things when you don't need all that extra 
"stuff" that the programmable ones give you.  I should get a hold of a couple 
of those chpis one of these days.  Is that 6402 a single-supply part?  I 
guess I need to fetch a few more datasheets...

> > > What the logic does is map one 256 byte block to read the status (RX
> > > ready, TX ready) and Data registers (you don't need 256 bytes for this
> > > but it was easy), and one 256 byte block to write the data register
> > > (The low byte of the address is the data you write). To make it work in
> > > either "high vector" or "low vector" systems, it's worth putting on
> > > jumper to move the block to either end.
> >
> > Hm.  I'm not sure I grasp this completely,  but it sounds interesting.
>
> The idea is to have a "monitor" that you can plug into the EPROM socket
> of just about any machine, and talk to it (assuming that you write code for
> that particular CPU), and also to assume that the rest of the hardware is
> unknown, and possibly not working.
>
> It's possible to write a simple montor that does not use RAM, however you
> still need a way to communicate with the debug terminal - since an EPROM
> socket does not have a -WR line, you can't write in the "normal" sense -
> also, you don't want to risk contention with something else on the bus.
> So what I did was to generate selects for two 256 byte pages in the
> ROM area - reading the top 1/2 of the first page gets me two bits
> which are the RXready and TXready signals from the UART. Reading
> the bottom 1/2 of that page gets me the receive data register. Reading
> the second 256 byte page actually writes the bottom byte of the
> address to the UART transmit data register - this allows me to read/write
> to a terminal without having to do anything other than read the EPROM
> space. This lets me get "inside the bus" and be able to do basic reads
> and writes on most any system.

I like it.   :-)

> > > I've written a number of "Hardware Debug Monitors" which work on
> > > this board, and don't use any RAM which enable me to to basic
> > > Display/Write memory operations - With this tool, as long as the ROM
> > > runs, you can "get inside" the BUS - Btw, I also include "loop read"
> > > and "loop write" function - terminated by RESET - very handy when
> > > debugging at this level.
> >
> > Since I have a whole pile of assorted 8-bit parts a ROM emulator was
> > something I was thinking about.  This stuff you describe sounds as if it
> > might also be useful,  too.
> >
> > Got more info up anyplace?
>
> No more info about my "ROM socket monitor", as I built it a long time ago,
> and don't even have schematics (at least I don't know where they would be)
> - but it is pretty simple and should not take much to replicate.

I think I've got a better idea of what you're talking about now...

> As far as tools, assemblers, disassemblers, compilers, monitors etc. go -
> these are described and have downloadable demos on my comercial site
> (www.dunfield.com) - Yes, I generally expect people to pay if they want a
> complete package, however I often give individual component tools to people
> who are doing a worthy cause (like fixing a classic computer) and have a
> specific need.

I think I need to get some hardware together first,  and maybe come up with 
some kind of a simple eprom emulator...

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin