Chiclet pet working with some issue on the CHR$ instruction

[giobbi]

Hi all,

I finally got my PET/2001 working; since I have 4 bad ram chips, I had to build the RAM adapter with a single 6264 ram chip instead of the 16 x 6550 ram chips.
The PET boots fine, showing the right amount of memory, but it has some strange behavior.

First issue: if I try to run the CHR$(<N>) instruction, I always get the same symbol equivalent to CHR$(222) on my 8032, no matter what is the <N> value.

Second issue: if I run some simple basic program, after some time I get some kind of error (like "syntax error in ...", but not only).

Third issue: if I try to play Invaders (the 1977 one, with rough cubes instead of the space ships) it seems to reset in some way every few seconds (the game doesn't stop, I can continue to play but the ships position and number change).

Strange, isn't it?

I'm using the original 6540 ROM set plus the RAM adapter.

What do you think: would be a ROM or RAM problem? Well, I only wish to know your opinion before to start doing some test and diagnosis

--Giovi

 

[Thomas_]

Hello Giovi,

how about writing a little basic program including your chr$(.) test only. Then run it. Afterwards, add a few lines before the chr$(.) instruction, simply to move it somewhere else in memory. If you get another result, you have an (obvious) memory problem. If you get the same result, you can't tell.

The artifacts could either come from a ROM or RAM bug from my perspective. If you want to do a thorough ROM test you might want to try my 6540 reader:

http://www.vintage-computer.com/vcf...-Chicklet-pet-displays-single-line-only/page6

Or if your basic is working well enough, build a checksum for the different ROM areas from
c000-c7ff,
c800-cfff,
d000-d7ff,
d800-dfff

and so on. A simple sum would do for a quick test unless you want to implement a propper CRC checksum adder.

Then run the same program on an emulator (using the same ROMs from the zimmers page) and compare.

This would be the software-only test for the ROM integrity. Keep in mind that a simple sum of the ROM content might hide a problem - though not very likely.

Thomas

 

[giobbi]

Hi Thomas,

I tried to write a little program, changing it in many times, adding lines, etc.: I always get the same result.
a simple program like this:

for i=1 to 254rint i;chr$(i):next

returns always the same char.

if I add the command ASC to the char on the screen, it return the value 255.

About the checksum, unfortunately I'm not good enough to write a program on my self; maybe somebody here (Dave, Mike? Somebody?) can help me with that?

 

[Thomas_]

that's an easy one:

(you might have to correct the keywords a little, I don't know the Commodore BASIC interpreter by heart)

100 sum = 0
110 for i = 49152 to 49147 : REM mismatching checksumes? ROM H1 is broken
120 sum = sum + peek(i)
130 next i
140 print sum

That should yield the same sum on your Pet and on the emulator. But be careful to use the rom image for the emulator that corresponds to your Pet ROMs!

You can test all 7 memory blocks:

49152 to 51199 : REM mismatching checksumes? ROM H1 is broken
51200 to 53247 : REM mismatching checksumes? ROM H5 is broken
53248 to 55295 : REM mismatching checksumes? ROM H2 is broken
55296 to 57343 : REM mismatching checksumes? ROM H6 is broken
57344 to 59391 : REM mismatching checksumes? ROM H3 is broken
61440 to 63487 : REM mismatching checksumes? ROM H4 is broken
63488 to 65535 : REM mismatching checksumes? ROM H7 is broken

Best,

Thomas

PS: The more professional option is of course to get a Raspberry Pi and use my hex dump program

 

[giobbi]

Hi Thomas,
thanks for your help.

I tried your program; I'm getting some errors on both PET and Vice. I tried Vice with rom1g romset - 2001/8 - 8 kB config.
Are you sure the values are ok? Well, I've seen you did a little mistake in row 110, but I used the values from the table you passed.

In the PET, I get a syntax error (telling no line number) and I also get some errors on the s=s+peek(i) line

After some tests, I tried to write the program in a single line:
10 s=0:fori=49152to51199:s=s+peek(i):nextrints

In Vice, the program with the 49152-51199 corrupts itself: when I run it I get a syntax error and the program simply disappear (a list command will return just the "ready" prompt).

boooh? maybe a wrong address range? However it seems to me your table is ok

c000-c7ff = 49152 to 51199
c800-cfff = 51200 to 53247
d000-d7ff = 53248 to 55295
d800-dfff = 55296 to 57343
.....
f800-ffff = 63488 to 65535

 

[Thomas_]

hm... mysterious. I worked for me (see screenshot)

This is how I invoked pet.

xpet -basic basic.bin -editor edit-2-b.901474-01.bin -kernal kernal-2.901465-03.bin -chargen ./characters-2.901447-10.bin

basic.bin was created by

> cat basic-2-c000.901465-01.bin basic-2-d000.901465-02.bin > basic.bin

In the emulator, I switched to model 2001N.

My guess would be that in vice, you used some non-matching binary images or that the model chosen in the emulator does not match the binaries.

On the real pet the error might be due to defective ROMs (or RAM).

On my Pet the kernal rom is broken and I also get syntax errors, however on every possible entry in the editor. I would not be surprised if you had a similar problem.

 

[giobbi]

hm... mysterious. I worked for me (see screenshot)

This is how I invoked pet.

xpet -basic basic.bin -editor edit-2-b.901474-01.bin -kernal kernal-2.901465-03.bin -chargen ./characters-2.901447-10.bin

basic.bin was created by

> cat basic-2-c000.901465-01.bin basic-2-d000.901465-02.bin > basic.bin

ok, that's the difference: you're using the basic 2 set (used i.e. in the CBM 3032), while the PET/2001 has a basic 1 set.

You can also see the difference on the boot screen:

*** COMMODORE BASIC *** = BASIC 1
### COMMODORE BASIC ### = BASIC 2


PET 2001 ................ CBM 3032

I'm not sure if it's enough, but in Vice i opened the Settings -> Rom settings page, I've chosen the "ROMset file" option: C:\WinVICE\PET\rom1g.vrs

I believe it should force Vice (if needed) to use the basic 1 romset for the PET/2001. Of course in the PET setting I've chosen PET/2001 - 8 kb

 

[crock]

Also remember that the peek() function is broken for locations > 49152 in the BASIC 1 roms.

ROB

 

[Thomas_]

I knew Basic 1 was buggy but not to this degree

In this case the basic check will simply not work and you have to use my hexdump program :>

 

[giobbi]

Also remember that the peek() function is broken for locations > 49152 in the BASIC 1 roms.

ROB

eeeecccchhhhhh..... I didn't know that :-(

Thomas: your idea is very good but it requires too much work to me (and I have no Raspberry Pi); I will try to put back the ROM adapter; at least I will discover if it's a ROM or RAM problem; then I will see what to do next... I'm also expecting some parts from an old PET and there should be some untested ROMs too. I will see.

thanks for the help

--Giovi

 

[crock]

If you can handle a bit more typing, the program in the image above will work on a basic-1 machine. It runs a short ML routine to checksum a 256-byte page of memory. The BASIC wrapper calls it for 16 pages at a time (4k). You can change the block by changing the A=192 on line 20 according to the following table:

192 - C000 - CFFF
208 - D000 - DFFF
224 - E000 - EFFF
240 - F000 - FFFF

You could also do 2k block by changing the A+15 to A+7 on line 30. It works in VICE so you have something to compare it to.

cheers, Rob

Rob

 

[dave_m]

Also remember that the peek() function is broken for locations > 49152 in the BASIC 1 roms.

ROB,
Does the 901439-09 image for the Revised BASIC 1 C000 ROM fix this problem? I know it fixes the IEEE 488 problem with the floppy drives, or should one go with BASIC 2 or 4?

I would think that only people who need a totally authentic early PET for resale or collection value would stay with BASIC 1. If one intends on using the PET, one should upgrade the firmware.
-Dave

 

[crock]

ROB,
Does the 901439-09 image for the Revised BASIC 1 C000 ROM fix this problem? I know it fixes the IEEE 488 problem with the floppy drives, or should one go with BASIC 2 or 4?

I would think that only people who need a totally authentic early PET for resale or collection value would stay with BASIC 1. If one intends on using the PET, one should upgrade the firmware.
-Dave

Hey Dave - No, I don't think so, it's broken in both versions. The default basic-1 version in VICE is the -09 ROM and it fails there. There's only 16 bytes changed between the two versions difference between $c598 and $c589 and it doesn't get touched during the 'peek' function call.

I've got two 2001's - one of which is almost mint, so that one has basic-1 on white ceramic ROM's - the 'every day' PET has, as you say, the considerably more useful basic 2 roms.

cheers, Rob

 

[giobbi]

Hi Rob,

thank you for that. When I was typing your program the PET crashed, so I decided it was a RAM problem. In the end, I discovered the 6264 ram chips I bought on eBay are bad, every one giving me wrong results (different results one chip from another, but wrong results).

I will try to find another brand/seller for those ICs.

thank you for your support

--Giovi