Random Characters Issue on a COMMOODRE PET 2001

[sbo]

Well for your information, the PET is still my main programming machine. More powerful machines and operating systems just get me confused!

Pet BASIC and 6502 assembly language - what more could one want in life?

Dave,

I have not been programming since about 15 years.
also, I have never touched assembly language.

I would like to start learning seriously the assembly language as it seems fascinating.
I am a little bit confused on modern machines and not really intersted in starting with big processors.

Do you think it could be a good idea to start learning with the 6502 ?
Will I be able to capitalize on this experience if I need to switch on modern computer later ?

It seems to me that this could be a great introduction to concepts and semantic of the language.
Am I right ? I like the fact that the PET seems to be a great learning platform as you can quickly get a good overview of the very basic notions.

On modern computers, I get a little disorientated by he fact that you are more passive ; you can not really play with the system, unless you already have a great experience.

In the case this idea would not be totally crazy nor stupid, should I use the VICE emulator ? Does it reproduce accurately the PET behavior ?

Thank you.

Stéphane.

 

[MikeS]

Well for your information, the PET is still my main programming machine. More powerful machines and operating systems just get me confused!

Pet BASIC and 6502 assembly language - what more could one want in life?

I hear ya! Especially with all the 'inside info' that's out there, thanks to folks like Jim Butterfield et al and the good folks who've made it accessible to all.

I think that simplicity and accessibility is why most of us are here playing with long-obsolete hardware; It's so much easier to get at and use the hardware and keep the big picture in mind with something like a PET.

For things that didn't need memory-mapped video I actually preferred the Rockwell AIM-65 with 40KB and an 80x24 terminal; BASIC (or Forth or Assembler or Pascal or PL/65) in ROM, the little onboard printer, serial I/O and somewhat compatible with the PET (and KIM and SYM of course).

I did finally jump ship when DOS came along, and I still use it and GW or Turbo BASIC for all those little programming and/or hardware projects, but one of these days I'll get back to those PETs and give them the attention they deserve...

 

[dave_m]

Do you think it could be a good idea to start learning with the 6502 ?
Will I be able to capitalize on this experience if I need to switch on modern computer later ?

Stéphane,
Yes the 6502 is great for learning the basic concepts of assembly programming. If you get your BASIC 4 system working, I can send you an EPROM toolkit to help with this.

I'm not sure how much help it would be in going to a Windows programming environment, that is a much tougher thing in assembly language and assembly is not really needed as high level languages for Windows are so powerful and fast.

I like the fact that the PET seems to be a great learning platform as you can quickly get a good overview of the very basic notions.

Yes, you will need a storage device like a cassette recorder (C2N) or better yet a floppy drive (4040) for saving your code.

should I use the VICE emulator ? Does it reproduce accurately the PET behavior ?

Yes it is accurate for both BASIC and assembly and useful as you could use the PC disk for storage until you get storage for the PET.
-Dave

 

[dave_m]

Will I be able to capitalize on this experience if I need to switch on modern computer later ?

Stéphane,
Let me give you a better answer about assembly language.

Once you learn the concepts on a 6502 machine, it is easy to transfer to the use of single chip microcomputers like the AVR, Programmable Interface Controllers (PIC) and the Intel 8051 family. These are powerful chips that have a CPU, RAM, EEPROM and input/output all in one chip. They are very useful for you to design and program any project you could wish from simple to complicated. And a lot of fun. They are available on small fairly inexpensive "development boards" that usually only require a 5V wall power brick and a USB port to a PC for downloading programs and (display if needed) to get started.
-Dave

 

[carlsson]

Well, what I lack in hardware skills I need to somehow compensate in software skills. However I'm far from an expert programmer, just using one or two tricks I have picked up in the past ~25 years.

As for your question on floating point numbers and bitwise logic, Commodore Basic internally works with all numbers in FLPT (or if it is MFLPT) format, so even if you store a variable A%, I believe Basic will convert it to floating point before making any internal conversion to integer and perform the bitwise logic. Thus if your numbers already are in floating point format, there is one or two conversions less to be done.

 

[Dwight Elvey]

Hi
I was looking at what some of you had done for a program.
Doing the modulo 256 after the loop has some risk. If you
don't know the size of the floating point number as it is
stored in memory, you don't know when it might lose LSBs.
If you were a coder for me, you'd have to justify such
code with a check to ensure that is could never do this.
I suspect that for the small ROM sizes your working with,
even the worst case of all 0FFH wouldn't be enough to
cause such a loss but I would rather see code that didn't
depend on code that had to be watched.
A good example of this was the code on the Patriot missles.
They'd coded time as a floating point value that they would
increment as time passed. At one point, the increment was
smaller than the smallest number that coulld be added.
While tracking missles, the time was not advancing
so a missle would go from one point to another in zero
time ( or so the program calculated ). If it was that fast,
it couldn't be a missle.
So, you see why I think code should be as correct as
possible and not necessarily as fast as could be done,
unless one explicitly stated the limitation.
In general, floating point should be avoided, especially
when integer math would work in it place.
Dwight

 

[carlsson]

As I tried to explain, Commodore Basic (and I presume most other Microsoft Basic dialects) internally works with floating point format. Even if you have integer variables, they get converted to floating point before operations are executed. You would need to code in assembly language or load your own Basic interpreter to make it behave differently.

 

[Dwight Elvey]

Hi
I realize that about basic. I know it works in floating point
for math operators. My note about floating point was mainly
that it was more dangerous to use, especially when used
with operators like factorial or modulo.
In this case, it is assumed that the sum will not reach
saturation of adding a small number to a vary large number.
By keeping the modulo operation inside the loop, you ensure
that it never allows the total to become too large.
As an example, if the floating point code had a 16 bit mantissa,
It would begin to saturate with as few as 258 entries if they were
all 255 in value. In other words, it would be dropping bits.
I don't know the size of the mantissa for the PET. It is
just that one should know the limitations of the machine they
are working with.
Code for that machine should be written with those limitations
in mind.
Dwight

 

[MikeS]

I hear what you're saying, Dwight, and was and am aware of what you're talking about.

The other side of the argument is that:

1 - We know the maximum number is slightly more than one million.
2 - Any computer that could not accurately count to one million would be useless.
3 - Wherever possible, a much-used loop should contain as few instructions as possible.
4 - To code this one-time PET routine according to the rules and constraints appropriate to a missile and as a result take 5 times longer to execute is pretty silly IMHO.

On the one hand it's useful to point out the problems associated with large (i.e. substantially larger than a million) floating point numbers.

On the other hand, to rigidly apply a worst case rule without considering the actual constraints of a particular situation and needlessly waste a lot of time and/or memory doesn't make much sense to me.

 

[carlsson]

By the way, integer variables A% can only have the values of -32768 to +32767. If we do the math at the end of the loop, we can in the worst case only read 128 bytes (128*255 = 32640) before the program crashes out with ?ILLEGAL QUANTITY. Thus if we stick to integer variables, we are forced to do the math inside the loop.

Floating point variables can be up to 999,999,999 until Basic starts to display them in E-notation.

However it strikes me that AND also only works with numbers up to 32767, so in this case the proposed listing to use bitwise AND requires it to be inside the loop. If you make the modulo operation afterwards, you need to use division or other kinds of math.

 

[carlsson]

I made some more calculations. The largest floating point number we can use in this program is 4294967295 = hex FFFFFFFF.

a=4294967295
print a => 4.2949673e+09
 
print a-int(a/256)*256 => 255
 
a=a+2
print a => 4.2949673e+09
 
print a-int(a/256)*256 => 2 
ERROR, should be 1

So PET Basic will be safe enough to get the checksum from a 16 MB large ROM. If we want to read a larger ROM than that, we need to either calculate checksums inside the loop or come up with a different method to store it.

 

[MikeS]

...So PET Basic will be safe enough to get the checksum from a 16 MB large ROM. If we want to read a larger ROM than that, we need to either calculate checksums inside the loop or come up with a different method to store it.

;-)

It would still probably be (much, if we're doing 16MB) faster to have two FP loops, with the inner one exiting periodically to reset to the modulo.

As you pointed out, calculating with integers is slower (on a PET; on some machines it's actually faster).

BTW, putting the code on separate lines also slows things down slightly, as does explicitly naming a loop variable ('next i' instead of just 'next')

 

[dave_m]

I made some more calculations. The largest floating point number we can use in this program is 4294967295 = hex FFFFFFFF.

So PET Basic will be safe enough to get the checksum from a 16 MB large ROM. If we want to read a larger ROM than that, we need to either calculate checksums inside the loop or come up with a different method to store it.

That's all that Dwight was saying:
Do the analysis first, then release the code.

We would have not have gotten a guy to the moon without worst case analysis.

 

[dave_m]

On the one hand it's useful to point out the problems associated with large (i.e. substantially larger than a million) floating point numbers.

On the other hand, to rigidly apply a worst case rule without considering the actual constraints of a particular situation and needlessly waste a lot of time and/or memory doesn't make much sense to me.

Mike,
Due to your forgetting to do the analysis before releasing this important code to the PET public, I an forced to put an asterisk (*) next to your 22 Second record.

 

[MikeS]

Mike,
Due to your forgetting to do the analysis before releasing this important code to the PET public, I an forced to put an asterisk (*) next to your 22 Second record.

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!!!

 

[MikeS]

That's all that Dwight was saying:
Do the analysis first, then release the code.

We would have not have gotten a guy to the moon without worst case analysis.

I do take issue with the sweeping statement though that "In general, floating point should be avoided, especially when integer math would work in it place" when we are dealing with the kinds of systems and problems that we deal with here. "General" statements like that, and "Gotos should be avoided" etc. that do not consider the specific case and circumstances "generally" tend to create inefficiencies which can be huge when dealing with a 1MHz system for example; look at the code from a compiler for instance which usually has to assume the worst case.

 

[dave_m]

I do take issue with the sweeping statement though that "In general, floating point should be avoided, especially when integer math would work in it place" when we are dealing with the kinds of systems and problems that we deal with here.

I think he only meant that statement for things like MOD calculations of very large numbers. I'm guessing he would be satisfied with your 0.29 Second analysis for using FP in our specific case.

The subject of numeric precision in mathematics/computers can get pretty involved.

 

[carlsson]

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.

 

[Chuck(G)]

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.

 

[MikeS]

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.

Of course we care; I was just going to ask whether there are ROMs with tiny wings flying between France and Sweden while we're discussing numeric precision on a PET. Ah, the French civil service... say no more, say no more, squire...