• Please review our updated Terms and Rules here

Nice PET but garbage screen

patscc said:
From the schematic you've all been staring at so long, the 2114's act as a page buffer for a page of text, and the data drives the address of the char. ROM.
So, if it ain't in the ROM, it ain't drawin' it.

patscc
Click to expand...

Yea, Graphics as in PETSCII graphics of course. :)

Tez
 
tezza said:
Does anyone know of any diagnostic/ROM-verification programs out there already? I don't think it would take much to write one, but if something is already be out there we could use or adapt it would be quicker.

Actually a diagnostic program which checked out the machine generally (RAM, ROM, etc,) would be nice. Anyone know of one available as a cassette image, which could be converted to audio for loading into the PET?

Tez
Click to expand...

I see there is something in the link Anders supplied:
You can find a set of PET games here:
http://www.portcommodore.com/petfile...-cbmidx-petidx
Click to expand...

under The Pet Utilities Archive section, there is ROM.TEST.BAS and RAM.TEST.BAS (albeit Disk image).

Thanks for the links Anders. That should satisfy our appetite for PET games :)

@Carlsson
Correct me if I am wrong, but wouldn't an EPROM programmer be able to read a real ROM too, given the proper settings? At least it appears some of the ROM slots on the PET would accept either a ROM or an EPROM (2532?).
Click to expand...

I think you're entirely correct - just that neither Tezza or I have an EPROM programmer. So I think reading a ROM in a spare PET slot is good for us.

Philip
 
Okie. I got the feeling you (Philip) were "fully equipped" and that an EPROM programmer would be standard stuff to have around.

As for the disk images, does Tezza have a 40 track drive for the PET? If so, you can use a X-series cable (e.g. XM1541) connected to a 1541 compatible drive to download the images. Disks recorded on a 1541 are readable on 2031, 2040, 3040, 4040 drives. Just be cautious not to overwrite data on the floppy, it may cause sync marks to end up in the wrong places making it unreadable.
 
carlsson said:
Okie. I got the feeling you (Philip) were "fully equipped" and that an EPROM programmer would be standard stuff to have around.

As for the disk images, does Tezza have a 40 track drive for the PET? If so, you can use a X-series cable (e.g. XM1541) connected to a 1541 compatible drive to download the images. Disks recorded on a 1541 are readable on 2031, 2040, 3040, 4040 drives. Just be cautious not to overwrite data on the floppy, it may cause sync marks to end up in the wrong places making it unreadable.
Click to expand...

I have an X-series cable and a 1541 but I suspect these are of little use on the old PET. Unless a cheap PET drive suddenly appears on our local auction site I think it will need to be cassette or nothing.

Or manually typing in the program listing *horror*!

Tez
 
Speaking of typing things in, I'll be looking at that keyboard again tonight. Some of those keys still require a lot of presses before they activate. I was typing in a BASIC program last night and the L key in particular (which I used for LIST) needing repeated taps (and holding your tongue just right) before it worked.

I noticed while at Philip's place, the surface of the small (rubber) contacts at the bottom of the keys (the surface that hits the Circuit board during a keystroke) appear kind of pitted on the worse affected ones. I'm not sure if there is any fix for this. Hopefully there is! Anyway, I'll check them out under a magnifying glass once I've removed the keyboard tonight and see if the lead pencil trick sees further improvement.

I wonder if wiping them down with a damp cloth first would hinder or improve matters? Worth a go I guess.

Tez
 
For your knowledge, many of the PETs I rescued also have sturdy keyboards. I found most get better by cleaning the circuit board with isopropanol alcohol, but you may also need to improve the graphite layer on some rubber plungers.

Too bad about the lack of floppy drive. Tape it is then. In moments like those, the C2N232 interface (not currently available for sale) is very handy, something like a combined high speed null modem and tape interface working on any CBM except the B-Series (or perhaps even those if one installs some tape support ROM).
 
carlsson said:
Too bad about the lack of floppy drive. Tape it is then. In moments like those, the C2N232 interface (not currently available for sale) is very handy, something like a combined high speed null modem and tape interface working on any CBM except the B-Series (or perhaps even those if one installs some tape support ROM).
Click to expand...

Yes, I think the best option might be to use the PC<-->64 transfer option via X-series cable and 1541 drive (which I can do), then save to tape using a datasette attached to the 64. This should work with straight BASIC programs, yes? I can forsee problems for machine language programs though.

But before I do that, I'll try to get all these keys working properly.

Tez
 
EPROM readers & programmers are a lot simpler than many people think, especially if you're only interested in the "standard" 27xxx series; I've built a few from scratch in my time, including one for the PET as a matter of fact.

Here's a reader using a couple of cheap CMOS 4040s that runs off a PC's parallel port; add a couple of transistors and a PS and you've got a burner:

http://www.zws.com/products/index.html

It's even easier on something like a PET where you have a fully programmable parallel port, but then you'd have to write your own software.
---
Re graphics: I don't recall any on-the-fly-programmable CGs from those days, but that doesn't mean they didn't exist; we certainly programmed custom EPROMs for different character sets. But any software doing graphics that way would probably be a lot slower than using one of the available "real" hi-res graphics boards, not to mention non-standard.
---
BTW, another option for the PC <> XM1541/C64 <> PET transfer problem is an IEEE cartridge for the C64 (or VIC-20) if you happen to run across one; also, there were RS-232 interfaces for the PET, and these days there are several other solutions including a couple of IDE HD/CF card interfaces for the PET in the works.
 
Dunno about IDE PET interfaces - can you enlighten me? However you're correct that one could wire up cbmlink with a null modem and transfer files that way. If one has a regular tape recorder, you may even generate WAV files out of any PRG and record those directly to tape without going via another computer.

I have a few IEEE interfaces, but I figured they're only good to connect an IEEE storage device (read: floppy disk), not to hook up a PET in the other end and use a VIC/C64 as a slave drive.
 
Yep, I commented on your entry too. :)

Basically I think your old Kernel chip may be the first candidate to blame, 901465-22 if I understand correctly.
 
carlsson said:
Dunno about IDE PET interfaces - can you enlighten me? However you're correct that one could wire up cbmlink with a null modem and transfer files that way. If one has a regular tape recorder, you may even generate WAV files out of any PRG and record those directly to tape without going via another computer.

I have a few IEEE interfaces, but I figured they're only good to connect an IEEE storage device (read: floppy disk), not to hook up a PET in the other end and use a VIC/C64 as a slave drive.
Click to expand...
-----------
Jim Brain has an IEEE version of the uIEC in the works, and I thought that Ruud was also planning an IEEE interface to the IDE project he's working on, no?

Not IDE, but as you probably know there are several IEEE<>PC interfaces as well.

I only mentioned the C64/VIC20 IEEE interfaces in case an IEEE drive happens to turn up and you have a C64/VIC20 and XE1541 cable; I don't think you can easily communicate computer to computer. Cassette *audio* can be a little iffy, but you can of course transfer files semi-digitally between Commodores using the cassette ports.

As to the keyboard problem: this is a common issue these days with many of those conductive rubber types. Cleaning can sometimes help, but often the conductive material breaks down too much. Solutions that have worked include conductive PCB repair "pens", auto rear window defroster repair "ink", punching disks out of aluminium foil and gluing them on, etc.; I've tried all three of those and they all worked well.

I'm sure Tez will have many hours of fun with his new pet (lower case ;-) )
 
Old PET projects

Old PET projects

Pictures of a couple of PET projects from the dim past: my PET EPROM programmer, and the 25 foot cable that connected the 2001 game machine upstairs to the 8032/8050 "file & print server" in the office downstairs via the cassette ports.
 

Attachments

  • PetPgmr.JPG
    PetPgmr.JPG
    34 KB · Views: 1
  • CassCable.JPG
    CassCable.JPG
    31.6 KB · Views: 1
Cool, I haven't followed up on uIEC enough to know Jim is working on an IEEE version. I figure timing is much trickier than on the IEC bus though. Ruud's project is to fit an IDE hard drive inside a 1541, using as much as possible of the old electronics which makes me think IEEE currently is not a target although he borrows quite a few ideas from how 8X50 drives work.
 
carlsson said:
Yep, I commented on your entry too. :)

Basically I think your old Kernel chip may be the first candidate to blame, 901465-22 if I understand correctly.
Click to expand...

Yes, this is the one Philip suspects. We're working on verifying it. Tonight I played with the PET and wrote a couple of routines, one to dump ROM contents out to tape and other to load a dump in from tape and compare the values to those PEEKed from whatever test ROM is in an expansion socket.

The thought I had was to do a ROM 4.0 PEEK dump (4 parts representing the 4 real ICS) from the VICE Pet emulator saving the cassette data files as a WAV files. Record this on a tape, then read in the taped data on the real PET comparing the values to whatever the fitted test ROM contains.

Tez
 
If you only want to know *which* ROM is bad, it oughta be pretty easy to just calculate some kind of checksum for the ROMs and the VICE images & compare them, no?

But your plan using the cassette sounds like much more fun and also more versatile; keep us posted!
 
MikeS said:
If you only want to know *which* ROM is bad, it oughta be pretty easy to just calculate some kind of checksum for the ROMs and the VICE images & compare them, no?

But your plan using the cassette sounds like much more fun and also more versatile; keep us posted!
Click to expand...

This is exactly right. There is something sublimly vintage in writing a bit of simple piece of BASIC code which interrogates the system, then reads/writes out sequential data to cassette tape and does comparisons. All this on a vintage system in classic green screen with 40 columns.

Watching and listening to that tape spin whilst writing a block, then stop, then start again as the next block was written while seeing the ROM bytes scroll by on the green screen really took me back. Pure nostalgia.

I guess that's why we do these things.

Tez
 
On the other hand if you hurl a 15+ kg PET, you may get a slipped disc.

Tezza, you may want to build yourself a prlink cable and use the cbmlink software:
http://www.zimmers.net/anonftp/pub/cbm/crossplatform/transfer/C2N232/cbmlink.html#hw-conn-prlink

Here is a bootstrapping program that can be typed in, saved and run in order to download the cbmlink client software:
Code: 
99 hs=201:rem system type
100 av=32:ack=59468: rem ack (out) is cb2
110 dat=59471: rem port a
120 ddr=59459
130 sv=2:srobe=59469: rem strobe (in) is ca1
199 rem *** init handshaking lines
200 poke ack, (peek(ack) and 254) or (128+64+32)
300 print "waiting for command":gosub990
310 printby
320 if by then 330
322 by=hs:gosub 1190
324 by=0:gosub 1200:gosub 1200:gosub 1200:gosub 1200
326 goto 300
330 if by=1 then gosub2000:goto300
340 print"(unknown function)":goto 300
989 rem *** switch from send to receive, then receive a byte
990 poke ddr,0
999 rem *** receive a byte
1000 if (peek(sr) and sv) = 0 then 1000
1010 poke sr,sv
1020 by = peek(dat)
1030 i= peek(ack): i = (i or av) - (i and av) : poke ack,i
1040 return
1189 rem *** switch from receive to send, then send a byte
1190 rem
1199 rem *** send a byte
1200 if (peek(sr) and sv) = 0 then 1200
1210 poke sr,sv
1220 poke ddr,15:poke dat,by
1230 i= peek(ack): i = (i or av) - (i and av) : poke ack,i
1240 if (peek(sr) and sv) = 0 then 1240
1250 poke sr,sv
1260 poke dat,by/16
1270 i= peek(ack): i = (i or av) - (i and av) : poke ack,i
1280 return
1999 rem *** load
2000 gosub1000:print"bank"by
2010 by=0:gosub1190
2020 gosub990:f=by:gosub1000:f=f+256*by:print"from"f
2030 gosub1000:t=by:gosub1000:t=t+256*by:print"to "t
2040 for a=f to t-1
2050 gosub1000:printa,by
2060 next
2070 return
 
You must log in or register to reply here.
Back
Top