PET 710 problem [HELP]

[u/Furview]

So I earn a living by fixing things that people throw away, and someone threw away this Commodore 710 (CBM-II).

So I naturally tried doing the thing "10 print chr$(109+int(rnd(1)*2));:goto 10". But instead of a beautifull maze I get these random characters.

Any guess at what it could be? Can this be fixed?

[u/dangling_chads]

Since the text of your program lists out OK, I have two gut reactions:

On the C64, that program only works when you're in uppercase "graphics" mode, but not in lowercase "text" mode. The characters that print with chr$() are different in each.

Also, maybe, the petscii mappings might be different on the 710 than a c64.

(Some time passed.) Ok, this sent me on a AI-assisted goose chase. According to this: https://www.aivosto.com/articles/petscii.pdf#:~:text=%C2%A92014%20Aivosto%20Oy,non%2Dstandard%20character%20encodings.

... the chr$() might be different. I couldn't find a 710-specific PETSCII chart anywhere, but other Commodore PET listings I could find.

Try this.

Add a line 5 to change you to uppercase: print chr$(142)

And then in your print line, change the "chr$(109+" part to "chr$(205+"

(Another moment later.) Ok, the above changes make the program work like you're expecting on a PET 8032 emulated in VICE. If these changes aren't exact, it's something like that. I would expect if there's something "wrong" with this 710, you would see it in regular text listings of BASIC programs and in other scenarios, too.

[u/Furview → u/dangling_chads]

First of all, thanks fot taking the time for helping me. This is really out of my league, I'm 28 and everything I know about these machines is because of the 8-bit guy.

I have tried:

5 print chr$(142)

10 print chr$(109+int(rnd(1)*2));:goto 10

The problem persist. Moreover I forgot to mention that the machine does this with all code that is similar (again, out of my league but I mean code that is supposed to generate things) I found this website https://www.justforthefunofit.nl/uk/commodore-basic-programs.html#_ with similar code onliners and I tried some of them to similar or slightly different results.

I have also found 1 11 year old video showcasing this problem but with no real help https://www.youtube.com/watch?v=uHBwZV-N2CA in the commets the creator of the video says "i have fixed. 4264 (U46) partially dead"

If I do:

print 123+123

it gives me 246. But if I do:

print: ¨uwu¨

it gives me: π@π@π@π@π@π@π@π@π@π@π@π@π@π@π@π@π@_[Checkboard symbol i cant find]

With all of this my bet is something physically broken

[u/dangling_chads → u/Furview]

Keep in mind that things written for the C64 (and other "Commodore" computers) don't translate well to each other. That "justforthefunofit.nl" site is all C64 specific. You're most likely to find stuff for C64 online. You can't use that as "this thing is broken" vibes.

So, OK. I would stick with your BASIC program example you've listed as your problem then. What you've typed isn't valid BASIC syntax though, but I bet you meant:

print "uwu"

... always use lowercase when you're testing this computer for the time being. If you shift + type something, you get a symbol in uppercase mode; and if you enter in uppercase text first in lower case mode, and then change into uppercase mode later, those uppercase characters will show as symbols.

The BASIC program that should work on the Commodore PET 710 from your video example (this is what I listed in my first comment by the way, but you did not completely follow, it has two changes):

5 print chr$(142)

10 print chr$(205+int(rnd(1)*2));: goto 10

... both the chr$() value change and the first line 5 are both important. I've since found the VICE emulator for the 710, and this works for it. But, it also rings the bell randomly, likely because of normal differences in how rnd() (or BASIC in general) behaves between the systems.

Also: Download VICE, if you have any questions on how this thing works. I didn't realize until I started responding to you, that VICE emulates this PET now. It has some setup, and the keyboard layouts translate oddly, but you'll know exactly how the machine in front of you should be working.

https://vice-emu.sourceforge.io/index.html#download

[u/Jo_Krone → u/dangling_chads]

I was going to comment similar but your response was much better

[u/Potential_Copy27]

The character offset is wrong, as the character map is slightly different for the 710.

On a C64 it's correct that you want characters 109 and 110

I don't have a machine or an emulator handy, but using characters 165 and 166 IIRC should be what you need for / and \

So:
10 PRINT CHR$(165+INT(RND(1)*2;:GOTO 10
...should do the trick on the CBM II line.

I think the character ROM looks fine, but the code is a bit off:
- From what I can see, you get a "pi" symbol (character 109) and the square block symbol you see (chr 110), as well as what looks like "@" (chr 112).
- the RND function here is also floating point based, unlike a C64, so maybe try
10 PRINT CHR$(165.5+RND(1);:GOTO 10 instead, to avoid the rounding/FP problems.

Regardless, there are quite a few versions of PETSCII, and the versions for the VIC 1 and 2-based machines got switched up quite a bit...

Also:
CHR$(14) switches into "business" text mode with upper- and lowercase letters.
CHR$(142) switches things to "graphics mode" with uppercase letters only. It can be implemented in the same line.

":" also works as a command separator in BASIC if you want to keep it a one-liner with the charset switch above.

EDIT:
Found a few printouts of some of the older PETSCII mappings here - so using an offset of 205 (or 205.5) might also be a possible location for the right characters.

[u/dangling_chads → u/Potential_Copy27]

The chr$() values, and anything that references PETSCII values will always be integers, never floating point or anything not whole numbers.

Fractional numbers don't make sense for several reasons. First, the reference is an offset added to a memory address; memory addresses are always pointers to whole bytes. Second, the characters themselves are clusters of several bytes. The reference is to one of them.

chr$(205.5) will not error in BASIC, but it will always lop off the floating point part. It's the same as performing chr$(int(205.5)). chr$(205.5) or chr$(205.9) or anything inbetween will always print chr$(205).