On Wed, Aug 11, 2004 at 08:04:28AM -0400, Dave Dunfield wrote:
> Thanks for the very useful information!
You are welcome.
> I checked the funet archive and found some details, however the PET "IO" document
> describes only the 6520's and 6522 - there is no mention of the video controller.
The video controller is only present on later models. The earlier video is TTL
and non-programmable. Specifically, you should check documents related to the
4016 (16K 40 cols), 4032 (32K 40 cols), and 8032 (32K 80 cols). These all use the
same board, but with different ROMs and different jumper settings.
> The only other references I found to I/O addresses were obviously a disassembley,
> with such meaningful labels as:
>
> AE810 DS 1
> AE811 DS 1
> AE812 DS 1
>
> Can you tell me where (address) the 6545 is located?
I do not happen to know that.
> I'm going to begin disassembling the Kernel ROM and see if I can figure out enough
> to turn on the screen - don't need keyboard (yet) - just want to be able to display
> some info.
I have run across kernel disassemblies on funet. You shouldn't have to do it all
from scratch.
> >Once you extract the table and load the 6545, you should be able to sling
> >bytes at the screen starting at $8000. Remember that "POKE codes" are not
> >ASCII nor PETSCII, they are character codes from the chargen ROM...
> I didn't see an obvious reference - can you give me a pointer - all I really
> need right now is 0-9,A-F and SPACE - I can determine these by fooling with
> the working machine if I have to.
I just fired up 'xpet' (part of VICE) and got the following:
0x20 space
0x30-0x39 0-9
0x41-0x46 A-F
So I guess it's reasonable ASCII-like. I just made the caution because the
strangeness of the PET character set(s) throws people if all they've ever
worked with is genuine ASCII.
> Btw, do anyone have (or know of) a working stand-alone monitor program which
> can be stuffed into the Kernel ROM position?
Standalone? No. AFAIK, there's never been a case where someone ripped out
the C= kernel and replaced it with 100% home-grown code. There _is_ a
monitor program included with all PET ROMs except the first version (from
old 4K/8K SRAM PETs). The BRK vector points to it. If you execute a BRK
instruction (0x00), that's where you end up. If you do code your own ROM
for the $F000-$FFFF block, remember that there's a hardware interrupt at
60Hz on the IRQ line. You'll need an ISR to catch that. In the real ROMs,
that's what scans the keyboard matrix, updates the real-time clock, and
blinks the cursor (it's not hardware, like on an Apple II). To use it,
there has to be enough of the machine working that the keyboard is scanned,
and the kernel and editor ROMs ($Fxxx and $Exxx) are present and functional.
I had a BASIC ROM die on my 2001-N and it dropped into the monitor at
power on.
That reminds me, there is a 'diagnostic pin' on the user port (it's
documented in most of the user-level docs of the day)... if you reset
the processor with the diagnostic pin shorted to ground, it aborts
much of the POST logic and jumps to the TIM monitor program. If BASIC
is FUBAR, but you have RAM and upper ROM, that should work for you.
Something else to check, while I'm thinking about it, is the reset
circuit itself - you could wire a manual reset button onto the CPU
and give it a kick after powering on. I have lost the message with
your exact symptoms, but if it acts totally dead, the processor might
not be getting its reset line pulled down briefly at power on. It's
probably just a simple RC network hanging off of a 555 timer, acting
as a one-shot.
PETs, BTW, unlike VIC-20s and C-64s have no provision for user-installed
firmware from taking over the machine on power-up (like a game cartridge).
You can install 8K-12K of your own stuff, but you have to manually jump
to it when the machine finishes POST and gives you the "READY." prompt.
That would be a reason to install patched kernel ROMs, but I don't recall
it being common in the old days... instructions for that sort of stuff
were to turn on the machine and type "SYS X" to jump to the dedicated
application.
I can't do a lot from here, but recently I got a pod for my Fluke 9010
for the 6502... that would be really handy for checking things out,
testing RAM, checksumming ROMs, etc. It's a shame the RAM isn't
socketed. That would be an easy thing to test, then (and easy enough
to replace with a 62256 SRAM wired into the sockets since ISTR your
expansion bus has something on it already). Fortunately, screen RAM is
completely separate from the 32K of DRAM. On the old 40 col boards,
I think it's a pair of 2114s. Not sure about the 40/80 col selectable
boards. I never had to debug video RAM. The machine would still work,
but the visible output would be funny depending on how many bits were
bad.
One other thing to do might be to build a NO-OP tester - that's a 6502
with all 8 data pins bent up so they don't sit in the socket, then
certain bits are pulled up and certain bits are pulled down to force
an 0xEA on the chip for all read accesses (a NOP instruction). The
processor free-runs starting at address $EAEA, then cycles through all
addresses so you can watch various select lines on I/O chips and see
what pulses and what does not. It won't help diagnose dead RAM chips,
but it will help test all address select logic.
-ethan
--
Ethan Dicks, A-130-S Current South Pole Weather at 12-Aug-2004 08:10 Z
South Pole Station
PSC 468 Box 400 Temp -66.4 F (-54.7 C) Windchill -101.9 F (-74.40 C)
APO AP 96598 Wind 11 kts Grid 088 Barometer 685.2 mb (10432. ft)
Ethan.Dicks_at_amanda.spole.gov http://penguincentral.com/penguincentral.html
Received on Thu Aug 12 2004 - 03:43:23 BST