PL65 Review, World's hardest game, progress thread

[Mark2008]

Happy Thanksgiving, to those celebrating, and happy regular day to everyone else!

 

I have finished a level of "World's Hardest Game" and so now I believe I have enough experience with PL65 to talk about it some.

 

This is a program from Noahsoft that was released in the latter half of the 80's and was eventually re-discovered and made available by AtariAge users.

As I type this, the wiki page is not available, so I cannot look up the name to give proper credit, but google on it.  There is available manuals and disks to get started.

 

The one thing I had to do, as an SDX 4.49 default user is allow more open files.  So my config sys says DEVICE SPARTA 8,8

 

OK - the language is Algol like, would be totally familiar to somene who programs, in say, oracle's pl/sql.  Or snowsql.

 

But what I want to say, is basic programmers, this is for you - it's a high level language, like basic.  No line numbers.

 

The single most amazing thing about this language is it fully supports assembler with few compromises.

 

Say you need to increase a variable:   x=x+1

 

You can either, simply type x=x+1 or type in assember:  INC X

 

That separates it from ACTION! or even Atari Basic where you could add assembly routines, but it was more complex than just typing assembly.

 

OK, I'm not writing any particularly organized post - because I will just share over time.  I am porting SnubbyLand's "The world's hardest game"  The first level is done, it is at the end of the video.

 

Speed:  if fully writing in PL/65 the speed may be better than basic, but just wasn't fast enough, even with writing assembly aware type syntax.  So, for speed, gotta drop into assembly, but you can do it inline, and that is really neat.

 

Vertical blank, display list interrupt support - I'm a big fan.  What makes PL65 so productive is that you can stick in its easy to use, high level syntax for organization of code and for everything except speed critical.  That includes creating the structure of a display list interrupt or vertical blank interrupt - which can be, if you wish, just regular pl65 code.  That makes unlocking the Atari's graphical capability quite easy with this language.

 

OK finally - on the game itself - there is a philosophy here, which is favor getting the game finished over coding elegance.  Nobody can play a game that isn't released (*edit: to be clear, i will never finish this game, what I meant to say is to code an engine that is usable - understandable, potentially finishable- release it as open source - whether anyone finds it of interest, is not known)..  So, I've gone with, each level will be, in a manner of speaking, its own game that can take up to 16k.  The overall structure will feature loading in 16k level, after each level, or even into banks on 1mb machines, this way I can go a full 30 x 16k - I won't have to be hemmed in by memory and that will just result in a lot of coding convenience.  Therefore I'm trading memory for speed - and all the animations you see are character set animations, not pixel drawn.  The red square is a player, everything else is character set drawn.  Despite that should've made it easy to draw, it still requires tuned assembly to work, at this time.

 

 

 

 

 

 

 

 

 

Edited November 24, 2022 by Mark2008

[Mark2008]

Not surprising that being it is a holiday weekend here, I finally got some programming time.

 

Today all I did was convert code form PL65 syntax into assembler....which I decided may be worth talking about in terms of the PL65 review.

 

I'm not delving deep into the code that the PL65 compiler produces, but I'm just taking various math and IF-THEN logic and converting it to assembler, and then checking the total size of the binary, as a confirmation that the hand coded logic probably produced less steps than the compiler.   Sure enough, the xex size has dropped from 15633 to 15046.  btw, I just point that for relative size, the overall size is way too large, because I'm attaching too many libraries.  I'll gut that at some point.

 

This is, of course expected.  The compiler would have to write more generic code to handle many situations, whereas I've been free to write only exactly what I need.  But - it still points to the fact that one is forever needing a bit more oomph than a high level language produces, luckily PL65 makes it easy to convert just exactly as much as needed, and inline.

 

still, it is a pity, that the final code will have this much assembler in it.  But PL65, especially in modern times using it with a rapidus is great.  Because with the rapidus, none of the assembler was needed. I could write the mockup in pl65 alone, wiht the rapidus it had plenty of oomph to run it.  And it is an easier process to have workign code, then going step by step optimizing it down to where it would run on a 6502c at 1.79mhz.   At this time it does, but its like 50% assembler, lol  I mean it ran before, but you'd see little glitches, those are gone.

 

OK, on to level2!...that one should be fairly easy.  Although it has to move 12 blue balls...12 balls, oh my!!!! woot.

 

[Mark2008]

So, what I have done for sound, is implemented from Antic Magazine Vol. 2, no. 8 the Chris Chabris VBI 4-channel, 8-bit player as described in "Breaking the BASIC Barrier"

 

And the song here is Monkeys Spinning Monkeys by Kevin Macleod.

 

Unfortunately, the result is very disturbing.  Making the "World's hardest game" even harder - attempting to live through the soundtrack.

 

ACK! It's going to be an endless time sink....

 

I'm thinking just trying to lower the octave, to avoid the screeching nature of it.  Or maybe - take up Chris's original challenge to implement 16-bit sound, and add a bass track.

 

I don't really understand music.

 

Edit: also attached is the PL65 version of the table based VBI sound player.  No features added, still assembler, just moved around to work within the PL65 limitations such as no JMP forward. 

 

 

PL65_VBI_SOUND.txt

Edited November 30, 2022 by Mark2008
Add PL65 source

[Mark2008]

 

So, the original author had a 1/20th of second space between notes, had to account for that, to get the timing right.

Then, I had to correctly initialize sound/remove the use of keywords - and I was able to use the 3rd sound channel.

 

I still moved one voice up an octave, which I could potentially solve later with combinging two 8-bit channels into 1 16-bit, but I'll do that later, if time allows.

Moving on.... 

Edited December 2, 2022 by Mark2008

[Mark2008]

Over on Atari FB group, there is a cross post from GOTO10 on drawing spirals, said something like Atari Basic took 21 minutes and BASIC XE took 6 minutes.

 

PL65 I think is under 30s.....if it counts to do it this way.   Of course, PL65 just doesn't support floating point at all, so it all has to be done in unsigned integer arithmetic.

 

 

Drawing a Spiral in BASIC - by Paul Lefebvre - Goto 10 (substack.com)

TRIG.LIB

Edited December 3, 2022 by Mark2008

[Mark2008]

SPIRAL.XEX

SPIRAL.P65

Edited December 3, 2022 by Mark2008

[Geister]

What is the background of PL65?  Is it related to PL/M?

 

[Mark2008]

2 hours ago, Geister said:

What is the background of PL65?  Is it related to PL/M?

 

Short answer is, I have no idea.   Also, it doesn't even appear to be an exact match of Rockwell's PL/65.  

 

This picture was done in 1980, trying to show the evolution of various languages, like PL/M, it is from a PDF "PLZ-SYS PL/65 PL/M RPL/2 Mistral PLZ Special Feature A Survey of Microprocessor Languages":

 

 

I find that chart interesting, but those languages don't fit as an "exact match" for Noahsoft's PL65 for Atari (circa 1987), but PL65 should be very familiar to anyone that used, for example PL/SQL.

 

Unlike PL/SQL, PL65 does not require the keyword DECLARE.  Variables are declared, anyway, just without the declare keyword at the top of a declare section.

 

Probably Noahsoft's PL65 would be familiar to rockwell pl/65 or even pl/m coders, but it has many differences.   One thing that I find interesting, is it was meant to replace Assembler.  It does seem to be in the tradition of the languages on the left of the chart above, while being also somehow algol like.

 

In my view it does a very good job of being an assembler replacement.

 

Take the Spiral example.  I really appreciate the original poster on GOTO10 working on that fun project.  But he had concluded that Atari Basic took 20+ minutes, and Basic XE took 6 minutes.

Those are the speeds only as written, those languages would do much better if the code was optimized.  And BASIC doesnt' prevent the optimization, per se, its just that BASIC programmers never do it. Here is what I mean by that, the original program code, written in basic, did 10 spirals and stepped through a circle in .01 increments up to 2 x PI.  Or 618 steps.  Each time you calculate the sine of the radian, you get the same value.

 

The original program, therefore repeated the same calculate 10x more than was necessary.   And it's actually even worse than that.  Cosine gets the same values too, just shifted by 90 degrees.  So the original code did expensive calculations 20x more than what was necessary.   So performance enhancement, even possible in BASIC, would be to calculate the values once, and remember them.

 

It's interesting, if I were writing in BASIC, I also would've written it to waste processor time, and in PL65 - the language itself enforces efficiency.

 

 

 

 

 

 

[+MrFish]

Not that it helps answer the question asked, but here's a fairly comprehensive chart I found, which has a timeline and also color-codes languages in terms of their current activity (or lack thereof -- at least up to 2001).

 

 

[Geister]

Thank you both for your responses.  These charts are very enlightening.  The history and evolution of languages is interesting to me.  I'm afraid I don't see PL/M or PL/I in the second chart, but you can't include everything (or I can't see everything with my old eyes.

[danwinslow]

It's interesting to see the first steps towards separating specification and body in this language. This was a major inflection point for programming languages in general. The syntax also reminds me of Ada a bit with the BEGIN/END and the CASE syntax.