Nice PET but garbage screen

[tezza]

Thanks Andres,

I had a go last night at doing the PC ---> Pet transfer via cassette without much luck.

I saved the PET ROM dump/comparison program as a TAP file from VICE then used a utility called audiotap to convert this to a WAV I could output through the sound card to a conventional cassette recorder. After recording I'd transfer to a C-64 datasette attached to the PET and try loading.

No joy. Occasionally using certain volume levels the PET would "find" the file but the name would usually be garbled and no load would occur.

I suspect it's because my cheap and nasty MODERN cassette recorder (really a dictaphone) only has a MIC input and automatic levelling. Although the final tape sounds loud it probably has any peaks cut off.

Anyway, there are many ways to skin a cat with this one. Unfortunately, they are all with a blunt spoon! I need to solve the problem though, for along with wanting to do this ROM comparison, I want to get a library of tape software for the PET also.

I don't want to build any more hardware except as a last resort. So tonight I'll try one more TAP-->Wave converter (TAPClean) and if that doesn't work I'll look at..

Hooking up the 1541 C-64 drive via my X1541 series cable, booting opencmb and copying a D64 disk with the pet program(s) on it. I'll then use the C-64 as an intermediary, loading from disk and saving out the program(s) on cassette. I'll then load the programs in to the PET, applying the necessary m/l monitor hacks to get the PET to find the BASIC program location (which apparently would have loaded in to a location a C64 would expect..but one that is different for the PET). After recovering the program I'll then save it as a PET cassette file.

Whew! If this works, all should be sweet (maybe it IS faster to build a cable..lol).

If it doesn't work. Well...err. I'll cross that bridge when I come to it. I don't want to unpack my DOS machine if I can avoid it which means I've limited myself to Windows XP solutions at the moment. We'll see how they go.

Solving these problems is largely the fun of it all, isn't it? :D

Tez

 

[carlsson]

Be aware of the slight speed/frequency difference between various CBM computers. Since you live in PAL land, your C64 probably runs at 0.985 MHz, your PET close to 1.00 MHz and your VIC-20 at 1.01 or even 1.02 MHz. These values may seem indifferent but since the computer is timing the pulses on tape it may be the make or break difference. In NTSC land, I believe all three run at the same clock speed or at least closer to eachother.

 

[tezza]

Right. Good news.

1. On the software transfer front...

I managed to sucessfully get a PET BASIC program from a D64 disk image off the net into the PET via the X1541/opencmb method described above. It worked the very first time!

I'm confident I can get whatever BASIC program I need for the PET transferred this way. This means I can start to build my software library. Not sure just how you would do machine code ones. Maybe it's even easier as it's simply a memory dump? No BASIC pointers to move about.

2. On the ROM testing front.

I've decided I don't actually need to move a program to the PET for this. I can use my C64 to compare the ROM data.

The program I wrote on the PET can interrogate the ROMS including the expansion ROM. I can dump the data of each BASIC 4 ROM IC onto cassette, by fitting them one at a time into a spare expansion socket and reading the whole IC.

I've also wrote a small program on the VICE PET emulator (in BASIC 4.0) on my Windows machine, which does the same thing except it dumps it's ROM contents out into virtual disk in D64 format. So I've now interrogated "good" ROM 4.0 contents, in chunks (five sequential disk dumps) which correspond to the 5 separate ROM ICs in the original board.

Tomorrow, make real C-64 floppy disks from the D64 images. I'll then write a THIRD program, this time on the real c64 which will take data from the tape dump made from the PET (of the ROM IC under test) and compare this data with the corresponding ROM data from the floppy disk made from the D64 disk dump produced in the PET emulator. This comparison should tell me exactly what ROM (and which addresses in the ROM) are faulty.

So. A program on the PET to read an expansion ROM socket and dump to tape, a program on the PC (in PET VICE) to read segments of BASIC 4.0 ROM and write it to disk, and a program on the c64 hooked up to drive and tape, to compare the two sets of data.

Should work, yes?

Tez

 

[carlsson]

Basic and machine code pretty much are the same thing. A machine code routine can be located elsewhere than the start of Basic programs, it is when you load ,1,1 and need to know a SYS address to start it. Other machine code programs may have a Basic stub already containing the SYS, which makes it easier to start. Only if you want to save a block of memory (machine code) it gets a bit tricky.

By the way, VICE already comes with the ROMs as binary files. You may need to add a load address to them and merge onto a D64 although your way to do it will work too.

 

[pavery]

Go Tezza

Go Tezza

Great progress Tezza. I am impressed with those PETSCII graphics - that's the first time I've seen them in action.

Those fine lines, on angles and all - amazing what's in those character graphics. Makes the TRS-80 I/III look prehistoric :shocked:

Following ROM Check with major interest.

Philip

 

[billdeg]

Awesome. I never saw a working 3032 before.

 

[tezza]

Ok, a progress report.

I decided in the end to check the ROMS this way..

1. Dump all ROM contents to cassette from the PET.
2. Use the C64 to transfer the ROM files from cassette to sequential files on disk
3. Make a D64 disk image from the disk with the ROM files
4. Use the Vice PET emulator configured as a 32k 3032 with BASIC 2.0 and whatever Basic 4.0 ROM (using ROM files found on the net) in the spare ROM slot B (as set up in the VICE Settings-->Rom Settings-->Computer menu) to do the comparison.

The idea is then to read in the sequential file from virtual disk of whatever ROM is under test and compare that to the ROM contents in the B ROM slot. All virtual, using the emulator.

I've written the programs and tested them. At the moment the C64 is churning away reading the ROMs on cassette and transferring them to disk.

I've already discovered one thing watching the data flow even without a comparison. The F000 kernal ROM certainly seems damaged (good deduction both Philip and Anders). What comes out of that is a series of triplets .ie. 234, 234, 234, 124, 124,124, 154, 154, 154 and so on. This is clearly wrong. Quite different from the dumps from the other ROMS, which is the expected seemingly random collection of numbers.

Anyway, once the ROM transfer is complete and I can check them all with the comparison program, I can see if any others are damaged.

I thought some of you might like to see the workbench while all this is going on:

Casual readers might wonder WHY I'm going to this extent to diagnose just one broken IC rather than using checksums (I have wondered myself!). I guess it's a challenge and fun, and in doing so I've learnt a lot about Commodore DOS and file handling (this was mostly unknown to me), revisited some old programming skills and found out more about the (impressive) VICE emulator.

I'll let you know if the other ROMS check out ok.

Tez

 

[tezza]

I've already discovered one thing watching the data flow even without a comparison. The F000 kernal ROM certainly seems damaged (good deduction both Philip and Anders). What comes out of that is a series of triplets .ie. 234, 234, 234, 124, 124,124, 154, 154, 154 and so on. This is clearly wrong.

And that was wrong. Actually on closer examination they are in a series of fours, not threes.

Tez

 

[tezza]

right, finished. It looks like TWO of the Basic 4.0 ROMS were damaged. The F000H one as mentioned previously and also the one starting B000H. The other three checked out just fine.

The data in the B000H is not in fours like the F000 one. However, I've compared it to the two verisons of the ROM I could find (one was a "patched" version) and neither come close.

As a final check I got the test program to output the data to the screen in ASCII. I was hoping to see some embedded keywords or error messages there. Sure enough, on both the stock ROMs images those words appeared. Not on the test B000 ROM though. Nothing I could recognise at all.

It occurred to me that I might have read the wrong ROM chip so as a final, final check I re-inserted the IC in the PET and PEEKed at some values. They corresponded with the ROM dump so it was definitely a dump of B000.

It must be faulty too.

So...the old PET board is almost fully diagnosed. A faulty 2114, faulty F000 and B000 ROM ICs and (possibly) a second video 2114.

Now it's on to getting a few more PET programs from the NET to cassette.

Tez


Tez

 

[MikeS]

My hat's off to both you and Philip; you guys are really making progress, all the more remarkable since neither of you has much experience with these babies nor a very comprehensive set of relevant tools. Are ya sure you don't want to build one of those quick & dirty EPROM reader/programmers?

Following your exploits is definitely tempting me to dig mine out and play with them a bit; I used to work with and on PETs professionally back in the dark ages, but I seem to have forgotten what little I knew; time for a few refresh cycles...

Enjoy!

m

 

[MikeS]

By the way, AFAIK the 6332 type ROMs are pin-compatible with the ROM chips used in the old PCs & XTs (although only half the size); if you've got an old PC/XT with empty sockets it might be easier to read them there and have the contents on a PC in the first place.

They are NOT the standard JEDEC pinout for 27xxx EPROMS though; if you're going to replace single chips you'd need 2532s or equivalent, not 2732s (unless you want to make or buy an adapter).

Don't remember off-hand if they match the pinouts of a C64 game cart, but they weren't usually socketed (and probably not standard anyway)

If you're running with the old ROMs you probably don't have the built-in machine language monitor; that might be one of the programs you want to downoad if you're going to poke around in the ROMs...

Have fun!

m

 

[tezza]

If you're running with the old ROMs you probably don't have the built-in machine language monitor; that might be one of the programs you want to downoad if you're going to poke around in the ROMs...

Actually Basic 2.0 (the one on the replacement Anders-sourced CPU board) DOES have the built-in machine language monitor. And just as well. I have to use it to tweak the Pet to recognise BASIC programs (even PET ones) sourced from the Internet but saved on the cassete from the C64. I have to do this is because BASIC programs saved on 64 loads in the wrong place on the PET to be seen by the BASIC interpreter. PET BASIC starts at location 1025 ($0401 in hex) and the later Commodore machines have different, higher starting locations.

Of course I have to use the c-64 as an intermediary to get Internet-sourced programs as Cassette is the only way this PET communicates with other machines.

My hat's off to both you and Philip; you guys are really making progress, all the more remarkable since neither of you has much experience with these babies nor a very comprehensive set of relevant tools.

Hey, I did play with a PET once in a shop 30 years ago!

Thanks for the encouragement Mike. Well, where this is a will there is a way. Having the right tools and experience would have made things quicker and more straightforward but we probably would have learned less and it wouldn't have been half as rewarding. In the end, albeit by a fairly torturous route, we got there.

Tez

 

[carlsson]

I still own a few 2532's, but my regular EPROM programmer won't handle them. Currently I have borrowed a different programmer that theoretically could program them, but it is mostly of academic interest.

 

[pavery]

ROM diagnosis

ROM diagnosis

While faultfinding the old board, we noticed one of the Basic ROMs was actually an EPROM. During its earlier life, this PET presumely must have had a ROM failure and it was repaired by burning & fitting an EPROM as a replacement. Tezza: Was that ROM one of the faulties?

Great work Tezza on identifying the bad ROMs with tools available. Brings me to the question: If a ROM isn't socketed, is it possible to read it with another system while it's in a dead board? Perhaps you can attach a clip or, last resort, solder a heap of wires to pins so to connect it to reader/another computer.

With emulators & ready access to ROM images on the net, this would make it easy to verify ROMs in the early stages of faultfinding a system.

Philip

 

[tezza]

While faultfinding the old board, we noticed one of the Basic ROMs was actually an EPROM. During its earlier life, this PET presumely must have had a ROM failure and it was repaired by burning & fitting an EPROM as a replacement. Tezza: Was that ROM one of the faulties?

No, the EPROM ROM was actually OK. The two that were faulty were standard production ROMS.

It was interesting to see what a zapped ROM had inside it. The F000 one was repeating sequences of 4 bytes each. Makes you wonder why it happened?

The B000 is still a bit mysterious. It must be damaged as it doesn't correspond to the ROM dumps. However, it looks "normal" in that there is just a collection of bytes rather than being a pattern like the F000 one.

Out of curiosity, it would be interesting to try to disassemble it to assembly language just to make sure it IS garbage. It would be easy to do, as I have an image now and I'm sure I could find a PET disassembler on the net. I could do it all with the VICE emulator. I'd have to learn a bit of 6502 assembly language though otherwise I might think that it's talking sense.

Hmm...Maybe that's taking the diagnostic process just a little TOO far

Tez

 

[pavery]

It was interesting to see what a zapped ROM had inside it. The F000 one was repeating sequences of 4 bytes each. Makes you wonder why it happened?

I reckon A0 & A1 are stuck internally - that would give 4 consecutive reads the same.

Philip

 

[tezza]

I reckon A0 & A1 are stuck internally - that would give 4 consecutive reads the same.

Philip

Good point. That's probably it.

I wonder if a firm tap on the edge of a benchtop would unstick those things? (naa..just joking!)

Tez

 

[MikeS]

<snip>
If a ROM isn't socketed, is it possible to read it with another system while it's in a dead board? Perhaps you can attach a clip or, last resort, solder a heap of wires to pins so to connect it to reader/another computer.

With emulators & ready access to ROM images on the net, this would make it easy to verify ROMs in the early stages of faultfinding a system.

Philip

------
I'd think that it wouldn't be too difficult to just plug into the CPU socket and read memory from there (assuming the decoders & buffers are OK); reading at the ROM chip pins might be a little trickier since you'd be driving the *outputs* of address decoders & buffers etc. Also wouldn't help much if a bad memory chip was holding one of the address or data lines high or low permanently...

Interesting idea to explore though.

m

 

[MikeS]

Hmm, usually a bad ROM shows a pattern of some sort; any possibility that you're comparing that B000 Rom to a different image?

Have I got this right BTW: you've presumably unsoldered all 5 ROMs from a BASIC 4 board and are putting them into a BASIC 2 spare socket one at a time, saving to tape, and comparing that file to an image from the VICE set?

m

 

[tezza]

Hmm, usually a bad ROM shows a pattern of some sort; any possibility that you're comparing that B000 Rom to a different image?

Have I got this right BTW: you've presumably unsoldered all 5 ROMs from a BASIC 4 board and are putting them into a BASIC 2 spare socket one at a time, saving to tape, and comparing that file to an image from the VICE set?

m

Yes, that is correct Mike. Except they were socketed so no soldering was required. Also the board they were taken from is exactly the same type as the (Anders-sourced working) board with BASIC 2.0. I think the original board was a genuine 3032 one, which had a BASIC 4.0 upgrade.

From cassette the ROM data was transferred to a sequential disk file via a C64, then imaged into a .d64 disk image file the VICE emulator could read.

Both the VICE set of ROMS were looked at, and also ROM dumps sourced from the net. When testing, a 4k binary ROM DUMP matching the ROM under test was attached to the virtual ROM B socket in the VICE PET emulator running the 3032 configuration with 32k and BASIC 2.0. Essentially this reproduced exactly the system (our working PET) from which the test ROM data was sourced. The emulator read test data from the sequential file on the D64 disk image and compared this to the ROM data in the (virtual) spare socket.

For three of the ROMS it was a perfect match. The F000 test data showed all these 4x repeating values. However, The B000 showed no repeating values but it was a complete mismatch notheless.

The suspect B000 IC in question has the letters 901465-23 stamped on it. The ROM file I got from the Net had basic-4-b000.901465-23.bin as the file name and the website said it was from B000 of the BASIC 4.0. I also found another earlier version of B000 ROM 4.0 called basic-4-b000.901465-19.bin. I tried this one too, but again no match. I also compared the first 4k of the VICE BASIC 4.0 binary against the basic-4-b000.901465-23.bin and found it to be the same. Also, the standard B000 VICE or Net-sourced ROM image when viewed in ASCII shows a lot of BASIC error messages and keywords (as you would expect). The test B000 ROM DUMP shows none.

I thought perhaps I might have got the ROM dumps mixed up? So I inserted the B000 IC in the real PET's spare socket and peeked a few values, comparing them both with the standard ROM data and Test ROM data off the D64 disk image. No, the test ROM data showed exactly the same numbers, shown that it had indeed, come from this IC.

So I'm satisfied that the standard ROM B000 image I'm using for the test is correct. I'm also satisfied that the programming and transfer methodology is sound, as it worked fine for the other three ROMS. I've also verified that the ROM dump data is correctly labelled and did come from my real B000 IC.

I'm puzzelled about the lack of pattern too. Why might this be? I'm very tempted to disassemble the code to see if it is indeed garbage.

Tez