PET 2001 B Garbled letters all over screen!!!!

[dave_m]

Note that it replaces the ROMs AND the RAM...

Mike,
A question I have is it is necessary to remove existing RAM and ROM on the mainboard?

The picture of the system board using the expansion mod shows all devices removed. I hope this is not the case as it would involve a lot of work since my mainboard has most RAM and ROM soldered in.

Also it would not be as useful for troubleshooting mainboard memory problems.

If the existing memory can be left alone, I would be interested in buying a kit or populated board. My Data I/O can program the 16V8 GAL.
-Dave

 

[dave_m]

...is it is necessary to remove existing RAM and ROM on the mainboard?

OK, I downloaded the Eagle Lite CAD software so that I could view the schematic and it is clear that the old memory can be left in the mainboard as there is a bus transceiver which isolates the mainboard from the adapter when required. Typically the transceiver is only enabled for video RAM and I/O.

It would be easy to add diagnostic code in another bank of F000 - FFFF space to run things like sum-checks of ROM and RAM tests and make a really handy tool for fixing PETs. A slight mod of the equations in the 16V8 logic device would be necessary to map the desired block of ROM/RAM to test. This assumes the video RAM and screen were working, but if not you could latch pass/fail answers on the user port.

 

[dave_m]

I'll PM you (Andrew) with my address; keep in mind that although it's likely it's not certain that it is in fact a bad ROM or, if it is, that that's the only problem.

BUMP:

Mike, did you ever hear from Andrew?

Also did you ever contact Nicolas about the adapter kit for replacing all of RAM & ROM? I'm thinking I should get one in preparation for the day when one of my ROM chips goes "belly up".
-Dave

 

[MikeS]

BUMP:

Mike, did you ever hear from Andrew?

Also did you ever contact Nicolas about the adapter kit for replacing all of RAM & ROM? I'm thinking I should get one in preparation for the day when one of my ROM chips goes "belly up".
-Dave

Yes, and yes.

I've sent you Nicolas' reply in a PM. Sounds like he's got the important parts but no time to assemble or even ship; maybe you can become the world-wide distributor ;-)

Regarding Andrew's baby: I have his RAM and ROM chips here and although all the RAM chips look OK two of the ROMs are bad. One of them is the E ROM and of course Murphy dictates that although I do have some spare BASIC2 6540s I don't have any E ROMs; must be something about those 2K chips.

No problem you say; put in one of JB's adapters with a 2716 and Bob's your uncle. Well, there's a small complication:

The other bad ROM is actually a 2532 in a Skyles Electric Works adapter; these were passive adapters that sat in the lower ROM slot and replaced both lower and upper 6540s with a 4K chip (or the single E chip with a 2716). The problem is that they're a side-by-side design; in this case it contains Fxxx in socket 4 and doesn't leave space underneath it for the JB adapter which is of course taller than the original chip that it replaces in socket 3 beside and underneath it.

Instead of sticking 4 or 5 sockets underneath the SEW adapter to raise it up I modified a bare JB adapter PCB so that it would be only slightly higher than a 6540 and trimmed some pins on the bottom of the SEW.

That worked but I thought it'd be a neater solution to just swap the two standard adapters' locations so they wouldn't interfere, but it turned out that Jim's adapters are too 'smart' to allow using a 4K ROM to replace both halves of a 4K block; you can use any size chip but only 2K out of it. I even recall arguing with Jim a little about this at the time; an advantage in some cases, but a disadvantage in this particular one.

But thanks for the bump; time to send Andrew's chips back and play around with this on my own time.

 

[MikeS]

Pictures vs. 1K words:



Skyles adapter "on stilts" on the left; Skyles, normal JB, and custom JB PCB adapters on the right.

That Skyles 2532 F ROM is kind of odd; it's not really all bad, just a few bytes are different; almost looks legitimate but it does keep the PET from running.

Anders, feel like looking at a disassembly and seeing if this makes any kind of sense?

Comparing files SEWROM and PETROM
***** SEWROM
0280 0320 B1FF A903 85B0 A900 85AF 60A6 AECA | ` |
***** PETROM
0280 0320 7FF1 A903 85B0 A900 85AF 60A6 AECA | ` |
*****

***** SEWROM
0FB0 FDAD 40E8 29FB 8D40 E84C 7FF1 20AA AAAA | @ ) @ L |
***** PETROM
0FB0 FD43 2E20 3039 3738 2043 424D 20AA AAAA | C. 0978 CBM |
*****

 

[carlsson]

Which of those numbers are addresses and which are data? At first I thought you looked at 16 bytes in locations $0280 and $0FB0 but those are RAM areas. I booted the emulator as a 2001N and was unable to find any of the references you mention.

 

[MikeS]

Which of those numbers are addresses and which are data? At first I thought you looked at 16 bytes in locations $0280 and $0FB0 but those are RAM areas. I booted the emulator as a 2001N and was unable to find any of the references you mention.

Sorry, those are the ROM addresses, not system addresses; change the leading zero to an F.

So, it's the two bytes at $F282 and 11 bytes at $FFB1 that are different.

 

[dave_m]

I've sent you Nicolas' reply in a PM. Sounds like he's got the important parts but no time to assemble or even ship; maybe you can become the world-wide distributor ;-)

Mike,
There is getting to be a real market for his gadget, what with all these broken PETs being reported. I wish he would get back into the game.

Or maybe YOU should buy his stock and start selling these things. I'll be your first customer.

Or as your silent partner, I'll even program the EPROMs and PALs for you. I still have a GangPak in the garage for my Data I/O that would make the programming less time-consuming.

Nickolas said he was getting 30 euros per unit times 10 units per year will pay for your Starbucks coffee habit.
-Dave

 

[dave_m]

Comparing files SEWROM and PETROM
***** SEWROM
0280 0320 B1FF A903 85B0 A900 85AF 60A6 AECA | ` |
***** PETROM
0280 0320 7FF1 A903 85B0 A900 85AF 60A6 AECA | ` |
*****

The SEWROM has a JSR FFB1 rather than the proper JSR F17F ....

***** SEWROM
0FB0 FDAD 40E8 29FB 8D40 E84C 7FF1 20AA AAAA | @ ) @ L |
***** PETROM
0FB0 FD43 2E20 3039 3738 2043 424D 20AA AAAA | C. 0978 CBM |
*****

This just seems like an erasure of the copywrite info

 

[MikeS]

So, do the bytes at $FFB1 make any sense? Kinda looks like this should do something besides just crashing the PET.

 

[dave_m]

So, do the bytes at $FFB1 make any sense? Kinda looks like this should do something besides just crashing the PET.

It looks a little weird and I did not notice that it goes to the other altered address at $FFB1:
FFB1 AD 40 E8 LDA $E840
FFB4 29 FB AND #$FB
FFB6 8D 40 E8 STA $E840
FFB9 4C 7F F1 JMP $F17F
FFBC 20 00 00 JSR $0000

After loading something from an I/O address (IEEE port?), it clear the ATN bit and writes it back, then jumps to $F17F rather than JSR as the the original code does, so there is no guarantee it will get back to here, but if it does, it then does a JSR to $0 which forces a jump to a user function.

The code seems intentional but you might need some hardware on the IEEE port or ???

 

[carlsson]

Well, if the original ROM does JSR $F17F and this modified code does JSR $FFB1; JMP $F17F the net result is the same. When the routine at $F17F returns, it will come back to the place where the original call was made.

 

[dave_m]

Well, if the original ROM does JSR $F17F and this modified code does JSR $FFB1; JMP $F17F the net result is the same. When the routine at $F17F returns, it will come back to the place where the original call was made.

Oh, I see, then except for setting the /ATN line low, it should work the same as the original kernal chip since the JSR to the USR function will not happen.

Why would holding down the /ATN line cause the PET to crash? Is Mike going to make me find my IEEE 488 book?

 

[carlsson]

$F281 in Kernal V2 is part of the routine Close All Files which begins at $F24A. The entry for the CLOSE command is at $F2A9.

$E840 is the I/O location for the Parallel User Port VIA, I/O Port B. The default value is 254, $FE. Typical values are POKE 59456,207 to enable the motor on cassette #2. POKE 59456,223 to stop the motor. WAIT 59456,23,23 to wait for vertical retrace of the display. Bit 1 is PB1 (NFRD on the IEEE connector), bit 3 is PB3 (ATN on the IEEE connector).

In theory it seems to bring the ATN line low on the user port VIA together with closing all open files?

I generated a hacked Kernal ROM file as per MikeS' observations and booted the VICE emulator. It runs fine and happily both OPENs and CLOSEs files as it should. Therefore I don't think the problem is in the ROM chip as such, but somewhere else in that particular PET. Perhaps VIA #2 simply is partly bad, thus the PET locks up in this process. I've had 6522's that work for 90% but one or two of its functions would fail.

 

[MikeS]

Interesting... Thanks Anders & Dave, I'll have to check that out.

 

[dave_m]

I generated a hacked Kernal ROM file as per MikeS' observations and booted the VICE emulator. It runs fine and happily both OPENs and CLOSEs files as it should. Therefore I don't think the problem is in the ROM chip as such, but somewhere else in that particular PET. Perhaps VIA #2 simply is partly bad, thus the PET locks up in this process. I've had 6522's that work for 90% but one or two of its functions would fail.

Yes, this sounds right so the problem may probably be caused by the bad E000 ROM only.

Do you happen to have an annotated disassembly of BASIC 4? I once had the Commodore source code with added detailed comments by the creators of BATPRO, but it was in a large binder that went into a dumpster some 15-20 years ago.
-Dave

 

[carlsson]

Dunno about annotated disassembly, but I found a reasonably good reference at Zimmers FTP, check the "maps" directory where you find memory maps. There is a huge document consisting of three scanned PDF's. Apart from that, I also have that Dr. Watson folder on assembly language programming which ends with a detailed memory map, cross referenced over PET V2, PET V4, VIC-20 and C64. I don't know if anyone yet has scanned it, otherwise I really should do it. I should look at Bombjack first.

Update: Yes, the Dr. Watson book is found in Bombjack's Commodore section, under Books -> Assembly Language. The file is 7.5 MB and the really interesting part are pages 203-225 in the PDF. However I happen to know there are a couple of typos in the list of addresses so it should be read with some care.

 

[dave_m]

Update: Yes, the Dr. Watson book is found in Bombjack's Commodore section, under Books -> Assembly Language. The file is 7.5 MB and the really interesting part are pages 203-225 in the PDF. However I happen to know there are a couple of typos in the list of addresses so it should be read with some care.

Anders,
Thanks for the info. I had seen the book listed but never looked at it because I thought it was only a C64 book.
-Dave

 

[carlsson]

According to the leading pages, they had previously published assembly language programming books for the PET 2/3/4/8000 and VIC-20. Therefore I suppose it was a simple measure to add cross-referencing columns for those machines also in the C64 edition, as so much of the RAM and ROM content are the same.