Random Characters Issue on a COMMOODRE PET 2001

[dave_m]

If anyone cares about Stèphane's PET, the French post service is in the middle of taking a two week strike right now, so he will be slightly delayed sending the chips to me. Hopefully he'll have a working PET by New Year 2010/2011 at least.

Anders,
Well, "C'est la vie". Maybe we can work on Alex's machine. We left off with him having a working machine but then it would only come up in the machine language monitor.

 

[MikeS]

Maybe I don't understand something here in the 30 pages shock of discussions.

Why is anyone calculating simple arithmetic checksums to identify ROMS (if that is the objective)? A CRC would be far preferable, no? CRC-16 should be more than adequate.

'Cause it's quick and dirty, can be done in one line of BASIC, and will probably (although admittedly not definitely) catch a discrepancy? And it's not to identify a ROM, but to compare it to a known checksum, a slightly different requirement.

 

[Chuck(G)]

'Cause it's quick and dirty, can be done in one line of BASIC, and will probably (although admittedly not definitely) catch a discrepancy? And it's not to identify a ROM, but to compare it to a known checksum, a slightly different requirement.

Maybe, but I tend not to think of arithmetic checksums as "identifiers"--integrity checks, sure, but not to ID anything. Swapped bytes, for example, will fool an arithmetic checksum, but not a CRC.

But you already know about that. A CRC doesn't take that much more code than a checksum, but yes, it will be slower...

 

[dave_m]

'Cause it's quick and dirty, can be done in one line of BASIC, and will probably (although admittedly not definitely) catch a discrepancy? And it's not to identify a ROM, but to compare it to a known checksum, a slightly different requirement.

Mike,
The gauntlet has been thrown down. I want to see a one line BASIC program that calculates a 17 bit CRC. Get your polynomials in order.

 

[dave_m]

I protest!!! :angry:

The analysis was done; roughly .29 seconds to calculate 300*5000, draw on experience and common sense to ask "will 1.5 million exceed the FP accuracy of a PET?" and come up with the answer: "Nah!"

By the way, that was your multi-line version that took 22 seconds; mine only took 19!!!

I was about to concede the point when I remembered that by coincidence (300 * 5000) was the exact same calculation used by the guy at Intel to determine that he had no issues with the P5 Pentium design with the famous FDIV error in 1994.

So no, without at least a little groveling on your part, the asterisk stays. And the time will stay at 22 Seconds as I firmly believe in code with "pretty printing".

 

[MikeS]

I was about to concede the point when I remembered that by coincidence (300 * 5000) was the exact same calculation used by the guy at Intel to determine that he had no issues with the P5 Pentium design with the famous FDIV error in 1994.

So no, without at least a little groveling on your part, the asterisk stays. And the time will stay at 22 Seconds as I firmly believe in code with "pretty printing".

I WILL NOT GROVEL!!! And I don't care a fig about your asterisk!

Had we discovered after all these years that the PET has a bug in its interpreter and can not count to 1.5 million, the harm done would have been trivial; we would not have blown up the wrong house or missed the moon, and we would in fact have done a great service to the PET community and enriched the world body of knowledge (and, should a PET ever be used to steer a Patriot missile, possibly avoided a catastrophe).

But mainly I just like to argue with Dwight...

As to the format of my program, I agree that legibility is important but when it comes to the final executable accuracy, speed and minimal memory requirements are usually more important criteria (which is why there are compilers instead of just interpreters). Consider what I presented as a pseudo-hand-compiled "executable"; if you want the documented source you have but to ask.

So there!

;-)

 

[MikeS]

Bythe way, I assume that Stephane has sent all the spare ROMs to Anders in the meantime so there's no point in testing them on his PET (with a little map for the moved keys) to find the bad one(s), just for fun?

 

[carlsson]

Regarding the chips, I can't tell if they're on the post box or not.

 

[sbo]

Hi,

Sorry for being so "away" lastly, but I have to be honest with you, I did not understand everything since a few posts :D. (I am doing my best !).

Precisely, I was wondering where to start : should I buy a book like this one in french from Ebay : http://cgi.ebay.fr/Programmation-6502-Atari-VCS-8bits-Commodore-C64-/200544872356?pt=FR_JG_Collections_Objets_religieux&hash=item2eb167e7a4 (very expensive !)

Or is there some quality documentation I could get access to on the web ?

I was wondering how it all started for you and what would be your best advices to an absolute beginner ...

Thank you.

Stéphane.

 

[sbo]

Bythe way, I assume that Stephane has sent all the spare ROMs to Anders in the meantime so there's no point in testing them on his PET (with a little map for the moved keys) to find the bad one(s), just for fun?

Actually not !! My post Office is closed till November, the 26th !!

So I have to wait ... I can receive, but cannot send in the meantime ...

Stéphane.

 

[dave_m]

but I have to be honest with you, I did not understand everything since a few posts :D.

Not to worry. It is mostly 'noise' from me.

Precisely, I was wondering where to start : should I buy a book like this one in french from Ebay : http://cgi.ebay.fr/Programmation-65...lections_Objets_religieux&hash=item2eb167e7a4 (very expensive !)

Or is there some quality documentation I could get access to on the web ?

I remember those type of books by Rodney Zaks. They were mostly a listing of the instruction set. They were not worth the money. There is good stuff on the web. Start with the document archive at http://6502.org/
-Dave

 

[MikeS]

Also a lot of books and magazines here:

http://www.bombjack.org/commodore/books-kim-pet-vic.htm

 

[Dwight Elvey]

Hi
I'm glad that all have given a little though about numbers
and limitations. I just don't like blindly taking things
just because it seemed convenient at the time.
There are several things that even integer math does
that are annoying. Things like rounding towards zero
is correct for floating point but can and has cause problems
when used in integer math ( I have a GPS with this problem.
It is older and newer ones don't seem to have the problem
any more ).
It is important to truly understand what numbers do and
don't do on a computer.
By the way, the largest number that can be displayed without
causing it to go to E notation has nothing ( usually ) to do
with lost LSB bits.
Dwight

 

[dave_m]

So I have to wait ... I can receive, but cannot send in the meantime ...

Do you still have the borrowed PET or did you return it?

 

[sbo]

Do you still have the borrowed PET or did you return it?

Hi Dave. I stille have it.
Stéphane.

 

[Dwight Elvey]

Hi
I always like to do CRCs with a table lookup. It should be about
as fast as the check sum.
If you don't like big tables ( 256 entries ) a smaller one
with two tables, one for each nibble would work. That is two
tables of 16 entries each. That would take longer because
you'd need to split out the nibbles( 4 bits ).
The tables can be generated by code to keep from making
mistakes on entries.
Dwight

 

[MikeS]

Hi Dave. I still have it.
Stéphane.

Âllo Stéphane!

What we have been talking about among all the silliness is how to use the PET to test those suspicious ROM chips.

It doesn't matter now since you and Anders have sorted everything out, but if you want to try it just for fun and curiosity:

Put three of the spare ROMs into the empty sockets. Note which one is where.

Turn on the PET and enter this little program:
1 INPUT R:for I = R*4096 to I+4095:S=S+PEEK(I)RINT S

Run the program 3 times, entering 9, 10 and 11; you should get 3 numbers, which are the sums of all the bytes in the three ROMS in sockets D3, D4 and D5 respectively.

If one of the ROMs is either 901474-02 or 901447-24 then change the 4095 to 2047 and run the program again, entering whichever number corresponds to the socket it's in; that's because the Exxx ROM is only 2KB in size vs. 4KB for all the rest (except the character generator, but we're not testing that).

Write down the numbers of the chips and their corresponding sums, and repeat for any other chips you want to check.

Here's a list of the ROM sizes and what the sums should be:

901439-01 2048 256095
901439-02 2048 274940
901439-03 2048 248466
901439-04 2048 258588
901439-05 2048 255230
901439-06 2048 269897
901439-07 2048 268936
901439-09 2048 255947
901447-01 2048 256095
901447-02 2048 255230
901447-03 2048 274940
901447-04 2048 269897
901447-05 2048 248466
901447-06 2048 258588
901447-07 2048 268936
901447-08 2048 97127
901447-09 2048 255947
901447-10 2048 97127
901447-24 2048 261567
901447-29 2048 297044
901465-01 4096 473144
901465-02 4096 479338
901465-03 4096 556184
901465-19 4096 478302
901465-20 4096 481632
901465-21 4096 500773
901465-22 4096 577305
901465-23 4096 475496
901474-01 2048 263658
901474-02 2048 289394
901474-03 2048 283274
901474-04 2048 283274
901498-01 2048 276306
901499-01 2048 276608

Have fun!

 

[Chuck(G)]

I always like to do CRCs with a table lookup. It should be about
as fast as the check sum.

Hi Dwight,

Unfortunately, not in PET BASIC--the language lacks an exclusive-or operator. You could synthesize it using AND OR NOT operators or even by table lookup, but there goes your speed. Shifting is accomplished by multiply/divide.

 

[Dwight Elvey]

Hi Chuck
The multiply and divide can
be avoided by keeping only bytes in integer
variables. You only need the shifting while
generating the tables. After that it is just
moving values in variables or even just
pointers to variables.
While doing the CRC, it is just byte operations
and byte moves.
XOR could be a pain but no one said life was
easy. I wonder if there was an easy way to
undo carries in adds. Adding is just XORs with
shifts from the results of ANDs. I suspect it
would be just as complicated but it might
be just keeping two running totals and a
subtraction ( correction ) at the last. I'll need to
fiddle a little at home on this.
Dwight

 

[dave_m]

Write down the numbers of the chips and their corresponding sums, and repeat for any other chips you want to check.

Stephane,
We know that your V2 set from Anders is good except that you will need the 901474-01 business editor in a 2716 EPROM.

We know that you have the correct V4 business editor 901474-02.

Also, you may find bad V4 chips using Mike's test. Those will be the only chips you need from Anders. You will then have a working set of V2 and V4 chips.

The other V2 set from Ebay and the 2532 EPROMs and the extra graphics editor can be sent to Sweden.

While both versions of BASIC are great, I would install V4 if there is a possibility of you adding a floppy drive later as V4 has extra disk commands. You may want to keep the V2 as a backup set to protect against future failed chips.