View Full Version : Non-deterministic BASIC 4.0 program?

January 29th, 2016, 09:16 AM
I wrote a quick BASIC program to generate hex values from integers.


when I ran it, I got odd results..


These only appear between 0-31 so I ran the loop four times. Note the row of 0s starting where 0A should be, then on the next run, a row of 1s (but 1F is correct), then subsequently the correct values in the next three sets. I have a suspicion it is caused by memory corruption, but it does seem strange.

Note: At this time, the PET it's running on has its top bank missing due to a problem with /CAS1 generation (see my PET 4032 restoration thread). Perhaps this is the cause. Likely?


PS, the reason I wanted to do this was to disassemble a nifty screen reverse routine that's written in decimal. In the end, I rewrote the program to convert the decimal values to hex on a Sharp MZ-80A (first time I used this to write some BASIC) and here it is:

As shown in BASIC:

10 data 162,128,134,2,169,0,133,1,202,160,0,177,1,73,128
15 data 145,1,200,208,247,230,2,224,124,208,238,96
20 for i=826 to 852:read j:poke i,j:next j
30 rem Reverse Screen!
40 sys(852)
60 end

As hexadecimal:

a2 80 86 02 a9 00 85 01
ca a0 00 b1 01 49 80 91
01 c8 d0 f7 e6 02 e0 7c
d0 ee 60

As disassembled from the hex dump via a web tool:

* = 0852
0852 A2 80 LDX #$80
0854 86 02 STX $02
0856 A9 00 LDA #$00
0858 85 01 STA $01
085B A0 00 LDY #$00
085D B1 01 LDA ($01),Y
085F 49 80 EOR #$80
0861 91 01 STA ($01),Y
0863 C8 INY
0864 D0 F7 BNE $085D
0866 E6 02 INC $02
0868 E0 7C CPX #$7C
086A D0 EE BNE $085A
086C 60 RTS
086D .END

Note: Copyright belongs to whoever wrote it. I found it on a PET at the local technical college in 1982 and used it in several games I wrote..

January 29th, 2016, 11:51 AM
If you index 0 to 15 instead of 1 to 16 it's a little faster. :)

January 29th, 2016, 11:55 AM
It's programmed correctly as if arrays start at 1 even though they actually start at 0 in PET BASIC 4.0.

Yet there's no subscript out of bounds error, and it will work, just not all the time.

When I DIM h$(16), am I allocating elements 0-15 or saying maximum index is 16 (so elements 0-16)?

January 30th, 2016, 03:26 AM
You are allocating h$(0) to h$(16).

I agree - your program looks OK from a quick look, but the results are not as I would expect either. I have seen similar things myself with memory corruption as you say.


January 30th, 2016, 05:31 AM
I rewrote it with dim h$(15) and tested h$(0) to h$(15), no problems.

But there are still odd problems. It must be linked to corrupted memory - add to that the fact that the PET doesn't always report the same amount of free RAM at boot up - I have a hardware problem. I was going to try it on my 3016 but it's not reading tapes at the moment. Will have to retype it (again)...