Jump to content
IGNORED

PL65 'cracked'


Fujix

Recommended Posts

Here's a working disk image of PL65 for anyone who wants to try what must be the rarest of Atari 8-bit languages.

 

To use it, boot with SpartaDOS (an X cart image in one of the emulators is a good development environment) then run PL65.COM and choose from the various menu options.

 

SAMPLE.PRG is a useful example program to figure out some of the finer points of the language (there's no manual on the disk) and S.OBJ is the compiled source.

 

Little or no third-party documentation exists and I don't have a manual. I have one in-depth magazine article (in 8:16, BaPAUG's magazine, written by Simon Trew).

 

Have fun!

 

(Thanks to Tickled_Pink... one of the few people with an original disk!)

pl65.zip

Link to comment
Share on other sites

Here's a working disk image of PL65 for anyone who wants to try what must be the rarest of Atari 8-bit languages.

 

To use it, boot with SpartaDOS (an X cart image in one of the emulators is a good development environment) then run PL65.COM and choose from the various menu options.

 

SAMPLE.PRG is a useful example program to figure out some of the finer points of the language (there's no manual on the disk) and S.OBJ is the compiled source.

 

Little or no third-party documentation exists and I don't have a manual. I have one in-depth magazine article (in 8:16, BaPAUG's magazine, written by Simon Trew).

 

Have fun!

 

(Thanks to Tickled_Pink... one of the few people with an original disk!)

 

Great news!

 

Thanks!

 

- Steve Sheppard

Link to comment
Share on other sites

Here's a working disk image of PL65 for anyone who wants to try what must be the rarest of Atari 8-bit languages.

 

snip...

 

I've never heard of PL65 before that I can remember -- what is it "like" if it can be described that way?

 

-Larry

Link to comment
Share on other sites

Bare bones, heavy use of libraries for anything other than the most basic operations (though there are some sophisticated conditional control and looping devices), embedded assembly language... it's a lot like Action! (of course) or PPP's Quick. Screen editor, no line numbers, compiles to machine code. Appears to be fast and tight (I've done only a very small amount of reverse engineering compiled files -- main efforts were concentrated on getting PL65 up and running!).

 

Have a look at SAMPLE.PRG on the disk image for an example.

 

Vital next step to reclaim this powerful language for all users is to get a manual online. I'm happy to scan or retype if anyone can supply one.

Link to comment
Share on other sites

It really resembles Action! in many ways: variable declaration (plus memory assignments), procs, funcs, direct inline assembly... What I miss in Action!, but PL/65 has, is CASE statement and direct assembler memnonic directives (which is of course possible in Action! with existing library/include file). I just don't know how PL/65 handles the memory for variables and routines. Similar to Action!?

Edited by Gury
Link to comment
Share on other sites

  • 2 weeks later...
It really resembles Action! in many ways: variable declaration (plus memory assignments), procs, funcs, direct inline assembly... What I miss in Action!, but PL/65 has, is CASE statement and direct assembler memnonic directives (which is of course possible in Action! with existing library/include file). I just don't know how PL/65 handles the memory for variables and routines. Similar to Action!?

 

I took a look at the disassembly of the sample program along with the source and PL/65 seems to manage memory like Action does, storing local variable in RAM just above the routine that uses it. This leads the same the same drawbacks as in Action, no recursion, and it would not adapt to cartridge based systems.

 

From the perspective of optimization, the PL/65 compiler definitely doesn't optimize as well as Action. For example PL/65 uses it's own stack for passing parameters, and uses this stack no matter how many parameters there are. Action on the other hand will use the A, X and Y registers if there are only a few parameters which makes for much more efficient code.

 

Dan

Link to comment
Share on other sites

Has anyone figured out how to get out of the editor? I've been able to load and edit a file, but I can't figure out how to save the file and get back to the main menu.

 

Dan

Sorry Dan, can't help you there but if you don't mind I have a question.

 

What combination of ORG and STACK addresses should I use?

 

I seem to be able to compile the sample program fine but on my 800 XL I need to use an ORG value of $4100 or higher otherwise the program will never run. I have not been successful at all using my 800, yet the precompiled sample does run on that machine. I mean I can compile the program without errors but it won't run.

 

- Steve

Link to comment
Share on other sites

Sorry Dan, can't help you there but if you don't mind I have a question.

 

What combination of ORG and STACK addresses should I use?

 

I seem to be able to compile the sample program fine but on my 800 XL I need to use an ORG value of $4100 or higher otherwise the program will never run. I have not been successful at all using my 800, yet the precompiled sample does run on that machine. I mean I can compile the program without errors but it won't run.

 

- Steve

 

Looking at the disassembly of the pre-compiled version it appears that the stack is at $2000 and the code is at $2100 which is the default settings for the compiler, but when I compile it using the Atari800Win emulator it the binary is close the the precompiled version but there is a section towards that top of the code that is messed up. Not really sure why. $2000 should be the start of free RAM on both the 800 and 800xl.

 

Dan

Link to comment
Share on other sites

  • 2 months later...

Hi

 

You mentioned my name in an article (http://www.atariage.com/forums/index.php?showuser=6661) and I found it via Google.

 

To give you some more information, some of which I am sure you already know:

 

BaPAUG was the Bournemouth & Poole Atari Users Group. I lived (and live) north of London, so I never got to see them except at shows; if you Google around a bit you will find a few pictures of me at Stafford, where the shows were generally held, and is utterly dismal.

 

I was closer to LACE (London Atari Computer Enthusiasts); the chairman of which lived in Leytonstone, though it was a fairly wide bunch, with one member living south of the river and we generally met at member’s house in Kensal Green (NW London). We used also to dial in to a BBS in Brum, I forget who ran that, but later LACE ran it. Algie in Kensal Green is the man to contact, but I forget his surname (if I ever knew it). His long-time partner Cat was sweetheart too.

 

As for PL65, it is no doubt derived from PL/M (and unlikely from PL/1, a much more complex language) and was pretty swift. I programmed for PL/960 on truly obscure processors. If you Google around, you will find several programs that I wrote in PL65—none of them my best. It is basically an ALGOL-based language and was advertised in Page 6 and I imagine in Atari User etc. As you suggest, it was somewhat obscure, but considering we had no C or C++ at the time, was better than Atari Basic or even Turbo Basic, for the power user. It will run on standard AtariDOS, you don’t need SpartaDOS. I hope I shan’tbe in trouble for cracking it open! Bit too late now I imagine. If I recall correctly, it was deliberate bad sector, and knocking out the code to read the bad sector made the1 problem go away. As a professional software engineer, I don’t tend to do that kind of thing, since I am simply taking money out of one pocket to put in another, but it was a pain to use before cracking it open, so I did it for my own sake having legitimately bought a copy. I never knowingly gave anyone else a copy, so I can’t imagine how you got hold of it.

 

I can remember most of the details of PL65. It had a distinction between PROC and FUNC, if I recall, and also a very queer feature (which resembles LISP lamda-functions in some respects) whereby a procedure could be passed to another procedure, i.e. the address of it, to save having to push and pop arguments unnecessarily. I also wrote—God knows if you would ever find this—a “defragmenter” that removed all the fragments in assembly language programs and made them much faster to load. AtariDOS had a four-byte header on each segment indicating the length of the segment and its address in memory, which was then followed by the data. This was especially important for PL65 which typically would have 80+ segments.

 

Bear in mind that I had the 6502 instruction set off by heart at that point (and 8086 and 68000 too). I wrote an 80-column emulator which would be nice to find again, and a few demos for LACE that are quite nice. I wrote a prog to solve Kriss Kross puzzles which was probably the first to use a real windowing system on the Atari 8-bits (the prog was more or less a demo of the underlying windowing system), The Cube Demo which demonstrated rotating cubes using the DMI etc (apparently not so good in the US as it only *just* made it under 20ms and with a faster screen refresh rate and slower processor on US machines, would demand two screen cycles), and did other bits and bobs that I can tell you about later.

 

Best Wishes

 

Simon Trew.

Link to comment
Share on other sites

I'm sorry I'm new to this forum so didn't realise the chronological order.

 

As far as I recall, the stack does indeed go from $2000 or $2100. This leaves Page 6 free of course. The assembler is actually better in many respects than the Atari Macro Assembler, as far as formatting goes etc. For example you wrote ASLA for arithmetic shift left accumulator because ASL A would be ambiguous if you had a variable called A. (I forget whether variable names were case sensitive.) IMHO it was the most "structured" language available on the market at the time. There was a small run-time library with integer multiplication and division; I don't think floating point was available. The FP, if I recall correctly, was part of the Atari Basic ROM not part of the OS proper. It was awful (a BCD encoding) and I think Turbo Basic sped it up enormously by changing to a binary representation rather than BCD-- again I am just going from memory.

 

Simon Trew.

Edited by SimonTrew
Link to comment
Share on other sites

Actually yes I remember there were two stacks. There was the hardware stack at $100 and the software stack at $2000. The hardware stack was used for JSR etc (opviously) and the software stack to push parameters, etc. It *did*, if I recall correctly, allow recursion, but obviously not very much. The Kriss Kross example that I mentioned in another post made its own stack since essentially it's a recursive problem (as indeed is Sudoku), and needs a bigger stack than is available, at least for high-speed solutions (or generations).

 

And I think it was a duplicate sector, not a bad sector.

 

S.

Edited by SimonTrew
Link to comment
Share on other sites

Hi Simon,

 

Nice to have you around! I think you'll find most of your game creations various Atari sites. I remember uploading Kriss Kross to our database not too long ago. Your board games are pretty nice as well!

 

Did you write other games besides the stuff found on LACE disks? I know you also converted some programs for Atlantis Software... Anything else you may still have that was coded but never released?

 

--

Atari Frog

http://www.atarimania.com

Link to comment
Share on other sites

Thanks for the welcome!

 

I don't know what's on the LACE disks-- often they were toy examples to try to get people started, rather than particularly useable programs. The main one to try to track down, if it's not already there, is the 8: driver (the 80-column driver) which can be directly substituted for E:. The only thing I should have done to this but didn't, was that the scrolling could be faster by manipulating the display list instead of actually moving the stuff in memory. However, as you might be aware, you have to be careful with the display at that resolution as Antic had certain requirements at (IIRC) 4K boundaries. Of course the fonts are *tiny*, and I believe they displayed worse on NTSC machines than on PAL ones-- someone once provided a substitute font. Nevertheless it was truly useable.

 

I didn't do any commercial work for Ataris at any time-- it was just a hobby.

 

I designed quite a number of fonts-- of course in the limitations of the 8x8 bitmap-- not sure if they're still around. I actually used the Atari to do video captions, end titles etc when I was at school-- so this must be about 1986/87-- and it was quite good at it, with the smooth scrolling etc. By the standards of the day, of course.

Link to comment
Share on other sites

Ah, have you ever seen the Pig Demo?

 

There was a fantastic demo by the standards of the day called the Big Demo. I wrote a small program, essentially a screensaver, called the Pig Demo, which was just repeated tiles of flying, animated pigs, with rudimentary "oink" noises. It's not particularly brilliant but is quite amusing when you see it for the first time. I think written in pure Assembler, as it was under 2K (including the screen memory required) so could not have been done in PL65.

 

Unfortunately I threw out all my Atari stuff-- one of the few times in my life where I *knew* I'd live to regret it.

Link to comment
Share on other sites

No, come to think of it, recursion wasn't allowed, since variables were allocated in fixed memory positions, not on a stack. And indirection on the 650x series was very limited, so to access variables on a moving stack would have been quite a burden. The 650x series had indirect addressing via X and Y registers, one which would go one way and one the other (the Y register was the more useful), IIRC, but it was still rather cumbersome. IIRC, the software stack was used only to push and pop parameters. I was programming in CORAL-66 at the time, for embedded processors, and this had keywords for marking recursive or re-entrant procedures/functions, at that time it was certainly not considered the norm to create a stack frame for each new procedure unless absolutely necessary. The 68000 series had specific instructions for creating and demolishing the stack frame, but even now on the 80x86 series it requires two or three separate instructions.

Edited by SimonTrew
Link to comment
Share on other sites

  • 9 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...