Old RPG Character Generation program...

[leech]

I've been trying to figure out how to get this to work.  I first was copy/pasting it into a .bas file on Linux, then trying to get it into a floppy disk image for vice.. that seemed to fail, I managed to get it to work with in c64 forever in Windows... but then when I ran it, it did some odd stuff then crashed.

 

That's when I noticed the instructions on how to type it in, and then it just confused me...
https://web.archive.org/web/20230608183623/http://powersandperils.org/ComputerCharGen.htm

The section here;
 

Quote

Entering the Program

The program listing contains a few symbols that are not entered as they are shown. The first ofthese is (C/UP) and (C/DN). (C/UP) is entered by hitting the shift/cursor. (C/DN) uses the unshifted cursor.

I mean, in BASIC, all that does is move the cursor around... since this website is already seemingly gone (trying to go there without archive.org just times out.  Not sure if the web hoster gave up on it a few months ago, or what, but it seems the last snapshots from archive.org was a few months ago).  I guess this could go under preservation at this point. 

[leech]

Oh, nevermind, maybe it is working as expected (tried on the real c64, and it also does funky symbols with up/down arrows)

Here's the attached file (ppcar.bas is the 'fixed' file) but I'm getting 'bad subscript  error in 3'
ppchrgen.d64

3 on cr(28,8)

 

Edited November 2 by leech

[drchuckradio]

Maybe line 3 should be:

 

3 DIM CR(28,8)

 

The ON keyword works like a CASE statement in VB or SWITCH statement in C/C++. In the current context, ON doesn't make much sense, as there's no branching going on. Try using DIM instead of ON.

 

The cursor keys add funky symbols when you're in quote mode, as you have found out. The characters move the cursor on the screen when executing a PRINT statement, like this line:

26 PRINT"(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)SELECT A RACE-"

[leech]

Awesome, that got me further.  The new error is a syntax error on line 292.

292 DATA 1.6,1.4,2,1.6,2.2,1.7,2.4.1.8

Seems to me that '2.4.1.8' at the end would be what is confusing it.  As if there should be a , in place of one of those .

Ha, my level of BASIC is essentially entering in listings from Compute in the 80s.  I never did quite figure out how the DATA stuff worked (and for that matter, it was on the 800xl).

I figured if I could get more understanding of how this program works, I may rewrite it for the Atari as well. 

[drchuckradio]

Yes, that line should have a comma:

292 DATA 1.6,1.4,2,1.6,2.2,1.7,2.4,1.8

I remember typing in those listings, too. I'm an old hand at C64 BASIC, and actually submitted a program to Compute's Gazette in the early 90's. Got published, too!

 

Converting this code into Atari BASIC shouldn't be too difficult, as the keywords PRINT, INPUT, READ/DATA work similarly. The POKE commands may not translate, but they're only used to change the screen/character colors. Also, the section that prints to a printer would work differently. The C64 uses device #4 as the printer, but I'm not totally sure how Atari BASIC handles that.

[leech]

New error!

? OUT OF DATA  ERROR IN 278

278 READ VR:CR(I,J)=

 

[+OLD CS1]

On 11/2/2024 at 12:23 PM, drchuckradio said:

The cursor keys add funky symbols when you're in quote mode, as you have found out. The characters move the cursor on the screen when executing a PRINT statement, like this line:

26 PRINT"(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)(C/DN)SELECT A RACE-"

Yup yup.  These special characters make it (nearly) impossible to cut-and-paste in the PC world, unless the pasted code has the exact characters needed.  We run into this in the TI world, as well, as you can generate almost the entire usable ASCII table as some keystroke in TI BASIC/XB, but not (easily) in the PC world.

[leech]

10 hours ago, leech said:

New error!

? OUT OF DATA  ERROR IN 278

278 READ VR:CR(I,J)=

 

Oops, that was
278 READ VR:CR(I,J)=VR

not sure why the VR was eaten.

3 hours ago, OLD CS1 said:

Yup yup.  These special characters make it (nearly) impossible to cut-and-paste in the PC world, unless the pasted code has the exact characters needed.  We run into this in the TI world, as well, as you can generate almost the entire usable ASCII table as some keystroke in TI BASIC/XB, but not (easily) in the PC world.

This definitely makes it frustrating for the novice people...

It's also frustrating that for some reason doing
 

SAVE"PPCAR.BAS",8

doesn't seem to actually be saving the file on my U64...

[+OLD CS1]

3 hours ago, leech said:

278 READ VR:CR(I,J)=VR

FWIW, missing the variable at the end should not cause the ?OUT OF DATA error.  That would be READing past the last DATA value.  I would think there are more type-os (missing commas) in the DATA statements.

 

3 hours ago, leech said:

doesn't seem to actually be saving the file on my U64...

I am assuming you have a disk image mounted, correct?

[drchuckradio]

9 hours ago, OLD CS1 said:

FWIW, missing the variable at the end should not cause the ?OUT OF DATA error.  That would be READing past the last DATA value.  I would think there are more type-os (missing commas) in the DATA statements.

Yes, that's the issue. Each line of DATA should have eight numbers separated by commas. We've already spotted line 292, and fixed the comma there. These two lines need commas for eight numbers:

 

Quote

 

299 DATA 1.8,1.6,1.3,1.2,2.8,2.6,0,0

302 DATA 2.1,1.9,1.6,1.4,3.5,3,0,0

 

I didn't spot any other DATA lines with mistyped commas. Hopefully that takes care of the out of data error.

[leech]

9 hours ago, OLD CS1 said:

FWIW, missing the variable at the end should not cause the ?OUT OF DATA error.  That would be READing past the last DATA value.  I would think there are more type-os (missing commas) in the DATA statements.

 

I am assuming you have a disk image mounted, correct?

I would hope I have it mounted right, it loads.  I am just selecting Mount Disk.  I can put it back onto the c64, but the keyboard on it is a bit stiff.  I'll fix it up in Vice and try it again.

[leech]

Hmm, fixed up those errors, still getting the error on line 278.

[+OLD CS1]

6 minutes ago, leech said:

Hmm, fixed up those errors, still getting the error on line 278.

When it stops, print the value of I and J.  Since the FOR loops start with 0, add 1 to each value and multiply them.  Then, compare that result to the number of DATA items.  The array population section is expecting too much data, there are DATA statements missing from the program listing, or there are missing commas in the DATA statements.

[leech]

8 hours ago, OLD CS1 said:

When it stops, print the value of I and J.  Since the FOR loops start with 0, add 1 to each value and multiply them.  Then, compare that result to the number of DATA items.  The array population section is expecting too much data, there are DATA statements missing from the program listing, or there are missing commas in the DATA statements.

Using 'PRINT I' gives me '?OUT OF DATA  ERROR'
PRINT J gives me '7'

[+OLD CS1]

26 minutes ago, leech said:

Using 'PRINT I' gives me '?OUT OF DATA  ERROR'

That should not have happened.

 

Anyway, I pasted the program into WinVICE and made the corrections noted above, and the problem lies here:

286 data 0,2,0,2,1,3.2,1

 

This data line only has seven values.  Because of this, the last READ is past the end of the DATA statements.  One should be able to assume the error is the "3.2" which probably should be "3,2" as that area of data does not have decimal numbers.  Fix this line, as well as the other errant lines, and the array populates properly and the program prompts for the character's name.

[leech]

69 GOSUB57

I fixed this line.

Got as far as selecting the race (human in this case) and Male, but then it gave me an error on line 155.

?UNDEF'D STATEMENT ERROR IN 155

We're getting closer.  And that one looks to be also a typo, 'gosubs9' I changed to 'gosub59'

This gave me a syntax error on line 159.

[+OLD CS1]

17 minutes ago, leech said:

Change RB<1O to RB<10.

[leech]

28 minutes ago, OLD CS1 said:

Change RB<1O to RB<10.

Wow, I don't even know how I didn't see that.  The c64 properly uses the slash in the 0 vs nada in the O.  (also, all fonts that don't do that should die off... it's as annoying as the I and l being the same in so many fonts.)

 

There were a few more that were o instead of 0.  Fixed those, and made some progress.  Found a few more 'gosubs' and a missing "  and now onto a new error... looks to me like there should be a number here instead of a /

Edited November 5 by leech

[leech]

I changed that / to a 1 (I'm starting to wonder if this was scanned in from somewhere using OCR).  Got a little further where the program runs, but asks to enter something and I get 'Number out of range, try again'

 

[+OLD CS1]

39 minutes ago, leech said:

looks to me like there should be a number here instead of a /

Yeah, I saw that, too.  This will prove to be quite the mystery: what is that supposed to be?  I was thinking it should be something /.5, but what?  A number?  A variable?  Would need to examine the program flow and see what is being handled in that section, or what is missing.

[+OLD CS1]

1 minute ago, leech said:

I changed that / to a 1 (I'm starting to wonder if this was scanned in from somewhere using OCR).  Got a little further where the program runs, but asks to enter something and I get 'Number out of range, try again'

More than likely scanned.  But, I do not think that / should be a 1, given the context.

[leech]

Attached is the current version with all the modifications I've done so far.  Should the 'then#' lines have spaces in them so that they are 'then #' Ha, also, I found yet another 'gosu8239' on line 230... and a few more...

ppchrgen.d64

[leech]

Ha, I just noticed this section....

frint?  I'm not sure what 'printim' or 'print#4' is... Looks like print#4 would be for printing to a file number.  I'll update that and upload a new d64 file.

 

Edit, the PPCAR1.BAS is the updated file.

ppchrgen.d64

Edited November 5 by leech

[leech]

30 minutes ago, OLD CS1 said:

More than likely scanned.  But, I do not think that / should be a 1, given the context.

I also attempted a 7, but that didn't work either.  Is that supposed to be a divisor of .5? 

[+OLD CS1]

1 minute ago, leech said:

I also attempted a 7, but that didn't work either.  Is that supposed to be a divisor of .5? 

If it is, it assumes the number it is range checking will be a value 1/2 of the range.  I do not know the rule set of the characters being generated, so I really have no way to work this back.  But, that routine appears to be used to range-check every value provided.