Jump to content
IGNORED

What modern high level languages are available for the 8-Bit Atari?


Geister

Recommended Posts

Hi. By high level, I mean Basic, Pascal, C, etc. and by Modern I mean languages developed since the 1980's.

 

I'm not interested in assembler. I don't have the mindset to develop at that level. It's too much like the art form of composing a picture using seeds. You can do amazing things with it, but it just seems tedious to me.

 

I know about all the older software like Turbo Basic XL and Action!. They are both great and I've used them both, but i want to hear about what has been happening in the years since I left the scene.

 

I've heard about Fast Basic, but real information on the language seems hard to find. Is there a Github or a website with documentation on this language?

 

What is Mads Pascal. I've seen the website and it is very reasonable to read in translation, but it seems to assume you know some basics about the system that are not obvious to me...like does this actually run on the Atari or is it a Windows-based development system that targets the Atari?

 

What else is out there?

 

I'm also interested in some of the older languages that I was never able to get my hands on BITD. I've tried the APX Atari Pascal, and I vaguely remember Kyan Pascal, but they both seem to suffer from being a closed system like many Pascals back then. They were an ecosystem that your compiled code had to live within and they couldn't produce a native executable, more like a P-Code that had to be executed in the Pascal Monitor. Because of this performance suffers and seems to run as slowly as Atari Basic...or slower! Maybe CLSN Pascal is better but I haven't had time to dig in yet.

 

Older versions of C like Deep Blue C or C65 seem to be either lost to the sands of time, or I've heard that they were buggy. I can't find the images on Atarimania for C65, if anyone knows where to find a copy, I'd appreciate a link.

 

I don't mind hearing about Windows based tools like WUDSN, but again. not a fan of assembler.

 

One reason I'm interested in doing this is an idea I had to benchmark the various languages running a familiar demo, the "HAT" sine program from a very early ANALOG issue. This program is only a dozen lines or so, but takes nearly 3 hours to run in Atari Basic. The finished image was pretty iconic for the A8 and it appeared in advertising and magazine covers. I translated it to C64 basic (which was a pain without graphic commands) and discovered that the program appears to have been designed for a 320x200 pixel display.. The TRAP statement catches any excursions beyond the bottom of the Atari hi-res screen and wasn't necessary (or even possible) in C64 Basic. The end result on the C64 looks pretty much the same as on the Atari if you ignore the fact that I had to remove the Drawto(X,Y) statement that cleans up any obscured points. I had enough trouble writing a "Plot(X,Y) subroutine.

 

I did not have an actual C64 to test the program on, but the emulator ran the program nearly as fast (or slow) as on the Atari emulator. If I'd taken the time to implement the Drawto in Basic code, it probably would have crawled.

 

Link to comment
Share on other sites

Do not cut yourself off from a development tool, language, or methodology, You never know until you try it.

 

The 6502 is a very simple processor, with the ability to have the entire instruction set in your head. It was never designed for what most people consider high level languages today. The reason is because the 6502 has a _VERY_ small stack, only 256 bytes, and it is fixed in memory, so languages that require a stack require an implementation that will give them a large enough stack to handle recursion, subroutine calls, and argument passing without exhausting the stack, this means implementing the stack in software, which means slower performance.

 

With that said, there is a C implementation for the 6502, called CC65, which provides a modern C99 implementation, and can create binaries for any 6502 based machine. The constraints aren't obvious unless you've DONE 6502 assembler:

 

* For best results use unsigned char as your primary data type.

* Use linear arrays for access as much as possible, these get turned into directly indexed X loads and stores.

* Use global variables wherever possible, this cuts down on software stack use, greatly increasing performance and reducing size.

* Use multiplies and divides provided by the compiler and runtime sparingly, the 6502 does not have a multiply or divide, and doing so will chew tons of cycles each time you use one of them.

 

Again, you should seriously spend some time and actually learn 6502 assembler, the effort will help you, should you decide to use a high level language.

 

-Thom

  • Like 2
Link to comment
Share on other sites

Hi Geister,

 

Hi. By high level, I mean Basic, Pascal, C, etc. and by Modern I mean languages developed since the 1980's.

Are you interested in Atari tool or cross-compilers?

 

I've heard about Fast Basic, but real information on the language seems hard to find. Is there a Github or a website with documentation on this language?

Of course, FastBasic is open-source and lives on https://github.com/dmsc/fastbasic. There is a full manual at https://github.com/dmsc/fastbasic/blob/master/manual.md and a cross-compiler with more optimizations that the Atari one is also available.

 

What is Mads Pascal. I've seen the website and it is very reasonable to read in translation, but it seems to assume you know some basics about the system that are not obvious to me...like does this actually run on the Atari or is it a Windows-based development system that targets the Atari?

MadPascal is a cross-compiler, it's a command line tool that runs in a PC (Linux, Mac or Windows) and produces an atari executable, with a dialect similar to old Turbo Pascal 7.

 

 

What else is out there?

For cross-compiling from a PC, CC65 http://cc65.github.io/cc65/is a good C language compiler, that also tries to make C programming portable to other 6502 computers.

 

 

One reason I'm interested in doing this is an idea I had to benchmark the various languages running a familiar demo, the "HAT" sine program from a very early ANALOG issue. This program is only a dozen lines or so, but takes nearly 3 hours to run in Atari Basic. The finished image was pretty iconic for the A8 and it appeared in advertising and magazine covers. I translated it to C64 basic (which was a pain without graphic commands) and discovered that the program appears to have been designed for a 320x200 pixel display.. The TRAP statement catches any excursions beyond the bottom of the Atari hi-res screen and wasn't necessary (or even possible) in C64 Basic. The end result on the C64 looks pretty much the same as on the Atari if you ignore the fact that I had to remove the Drawto(X,Y) statement that cleans up any obscured points. I had enough trouble writing a "Plot(X,Y) subroutine.

The "hat" sine program is not a very demonstrative benchmark, as it is mostly trigonometric functions (really slow in the original Atari math-pack) and line plotting.

 

About 3 years ago I programmed a very fast version of that, in assembler, see http://atariage.com/forums/topic/218503-graphics-8-fedora-hat/?p=3198021, the runtime was about 22 seconds.

  • Like 4
Link to comment
Share on other sites

Back in the day I only used Atari Basic and Turbo Basic, which really limited what I could do on the machine. I wish I would have invested in Action! or better yet, learned Assembler.

 

Today I use either CC65 or MAD Pascal and cross compile. My current project is an excuse to learn MAD Pascal, and it is more approachable than C. I haven't touched Pascal in almost 30 years, but it comes back pretty easily.

 

Assembler is pretty tedious, but you probably will want to learn it eventually. I'm slowly learning it myself.

Link to comment
Share on other sites

I'm having some fun writing a cross-compiler at the moment - tailored to the 6502, so it locates variables in zero-page etc. I'm planning on using SQLite as the intermediate format of the compiler, which ought to open up some interesting things in terms of optimisation routines later. It'll be trivial to test one out in PHP before committing to writing it in c++ :)

 

There's a "spec" (it's really not [grin], it's a bunch of notes, but it'll give you an idea) in the GitHub repostitory

 

It'll do 'C' like type-promotion and expression-reduction (it already does a fair amount of this), it'll run the C pre-processor to handle includes, and since I'll have an intimate knowledge of the workings of it, I'll be able to expand it easily. I have a hardware project ongoing as well (in fact, this is the main focus) and giving support for that is one of the primary (but as yet unspoken) goals :)

 

I'd also like to get some support for native hardware - ie: handle bank-programming, PMG etc.

 

The plan is to produce assembly output from the intermediate stage, and then run Mads or something to produce the final executable. I'm more interested in the higher-level optimizations (loop unrolling, variable hoisting, etc.)

 

I've only had a week - give me another 3-6 months and it'll be a contender :)

  • Like 2
Link to comment
Share on other sites

I'm mostly looking for tools that run on the Atari, but I wouldn't mind a cross compiler if it had support for the 65c816. I'm not new to programming on either the Atari or the PC. However, I'm sick of the PC world and all the complications. Being pretty mush retired from IT and the type of programming I used to do (Lab and Plant automation) I wanted to get back to where it all started and do some fun things with the Atari again. Since I heard about the current hardware upgrades (and intend to play those as soon as I can afford to) I was wondering if there were similar improvements to the programming languages to take advantage of the new hardware.

 

To dmsc: the Hat Sine program has some emotional (nostalgic) connections with me as it was the first programming demonstration of the Atari's graphics that made me go wow! I guess I was easily impressed back then. I took nearly an hour to type the program in on the 400's membrane keyboard (actually I typed it twice because I didn't know the the break key didn't do the same thing as the enter key,,,it appeared to). Eventually, I got the program typed in and saved to cassette tape and then I never got to run it to completion because we always had somewhere to go or something to do and it took hours for this program to run! So one night, Superman was making it's network premier on TV and my wife wanted to watch it. We knew that with commercials, the run time of the movie and the demo would be about the same. So I started the program and sat down to watch the movie making a dash now and then to the computer to see the progress. After awhile, I got wrapped up in the movie and stopped running in to check on the program. My wife went into the kitchen to get some snacks and I heard her ask from the other room "is the screen supposed to be blank?" That's when I learned to check my typing of the program listing carefully before running the program. I had forgotten to type the last line of the program "260 GOTO 260" The program had plotted the last point and then dropped to Graphics 0.

 

My wife thought it was hilarious that I had wasted three hours for a blank screen. But I learned a lot from that little program.

 

I disagree with you than the program is not a demonstrative benchmark. I think it would demonstrate quite clearly whether a language has better math libraries, better graphics libraries, or just more optimized code than old Atari basic. Turbo Basic XL proved it has all three I suppose if I added instrumentation to the program I could even determine how the program was improved running on a different package. Conversely, Atari Pascal performed worse than Atari basic and I think it shows that the developers of this Pascal had been too successfully in replicating poor old Basic's graphics and math functions. In any case, that's not important It's still the measuring stick I plan to use while I explore the different programming languages. I think it's more visually interesting than say calculating primes. Who knows maybe I'll collect some other retro computers and see how well they do with this program. I already have a version that runs on the C64.

  • Like 2
Link to comment
Share on other sites

I'm having some fun writing a cross-compiler at the moment - tailored to the 6502, so it locates variables in zero-page etc. I'm planning on using SQLite as the intermediate format of the compiler, which ought to open up some interesting things in terms of optimisation routines later. It'll be trivial to test one out in PHP before committing to writing it in c++ :)

 

There's a "spec" (it's really not [grin], it's a bunch of notes, but it'll give you an idea) in the GitHub repostitory

 

It'll do 'C' like type-promotion and expression-reduction (it already does a fair amount of this), it'll run the C pre-processor to handle includes, and since I'll have an intimate knowledge of the workings of it, I'll be able to expand it easily. I have a hardware project ongoing as well (in fact, this is the main focus) and giving support for that is one of the primary (but as yet unspoken) goals :)

 

I'd also like to get some support for native hardware - ie: handle bank-programming, PMG etc.

 

The plan is to produce assembly output from the intermediate stage, and then run Mads or something to produce the final executable. I'm more interested in the higher-level optimizations (loop unrolling, variable hoisting, etc.)

 

I've only had a week - give me another 3-6 months and it'll be a contender :)

SQL?! Sounds intriguing. Hope you have fun ?
  • Like 1
Link to comment
Share on other sites

* Use global variables wherever possible, this cuts down on software stack use, greatly increasing performance and reducing size.

 

 

CC65 provides an option that treats automatic variables declared in functions as they were global variables. Of course, when this option is set, no recursive calls are possible.

I admit, I do like that option. The code stays legible (variables are declared close to the place where used in the source code), but has smaller footprint. I sacrifice recursion happily.

Link to comment
Share on other sites

  • 3 weeks later...

i’m planning to use http://atariage.com/forums/topic/247596-z80-6502-recompiler-used-with-pentagram-portcombined with Boriel’s ZX-Basic Compiler (really amazing one, i have being using it since years ago for most z80-based hardware, not only ZX-Spectrum) - perhaps in the future someone would fork both into a really great 6502 Basic compiler?

Link to comment
Share on other sites

Hi!

 

im planning to use http://atariage.com/forums/topic/247596-z80-6502-recompiler-used-with-pentagram-portcombined with Boriels ZX-Basic Compiler (really amazing one, i have being using it since years ago for most z80-based hardware, not only ZX-Spectrum) - perhaps in the future someone would fork both into a really great 6502 Basic compiler?

Problem with ZX-Basic Compiler is that is really tied to the Z-80, most sample programs use Z-80 assembly mixed with some basic statements.

 

If you want to develop a game for multiple platforms I really recommend using CC65, or MAD-Pascal. And if you like BASIC, you can use my FastBasic ;)

Link to comment
Share on other sites

Thank you for creating this topic, I was also looking for a high level language in order to do a few tech tests of the machines I acquired recently without having to delve into assembly.

 

Of course, FastBasic is open-source and lives on https://github.com/dmsc/fastbasic. There is a full manual at https://github.com/dmsc/fastbasic/blob/master/manual.md and a cross-compiler with more optimizations that the Atari one is also available.


MadPascal is a cross-compiler, it's a command line tool that runs in a PC (Linux, Mac or Windows) and produces an atari executable, with a dialect similar to old Turbo Pascal 7.

 

FastBasic looks really nice, a cursory read of the manual reminds me a bit of GFA Basic for the ST/Amiga.

It does not look like it has support for Display List creation so I am wondering if there are equivalent of STOS and AMOS on the Atari 8 bit with integrated support for low-level features such as Display Lists and Sprites (players + missiles)?

In any case, I will give FastBasic and MadPascal a try after I get a chance to unpack my machines. Thanks for the advice!

Link to comment
Share on other sites

  • 3 weeks later...

Thank you for creating this topic, I was also looking for a high level language in order to do a few tech tests of the machines I acquired recently without having to delve into assembly.

 

 

FastBasic looks really nice, a cursory read of the manual reminds me a bit of GFA Basic for the ST/Amiga.

 

It does not look like it has support for Display List creation so I am wondering if there are equivalent of STOS and AMOS on the Atari 8 bit with integrated support for low-level features such as Display Lists and Sprites (players + missiles)?

 

In any case, I will give FastBasic and MadPascal a try after I get a chance to unpack my machines. Thanks for the advice!

Using the "Low Level" functions in Fastbasic, you have access to use PMGs, DisplayLists, DLI, etc.

 

There are a lot of Atari basic tutorials, books, etc that have code which will work with Fastbasic to handle these assembly routines using USR, poke, peek, dpeek, adr, etc.

Not like STOS, but still pretty good.

 

I would love to see a STOS like language for the 8bits. Action kind of comes close, but not really.

  • Like 2
Link to comment
Share on other sites

The Advan Basic Compiler has support for PGMs, and DLIs and it's quite fast if you use the optimizing compiler and use the optional floating point package. It's fast already on integer based programs, but the need to ID integers with a "%" following both variables and in-line numeric expressions drives me nuts!

 

In any case, Turbo Basic XL as an interpreted language still blows the doors off the Advan Basic compiler in a direct head to head comparison.

  • Like 1
Link to comment
Share on other sites

Hi!

 

Using the "Low Level" functions in Fastbasic, you have access to use PMGs, DisplayLists, DLI, etc.

 

There are a lot of Atari basic tutorials, books, etc that have code which will work with Fastbasic to handle these assembly routines using USR, poke, peek, dpeek, adr, etc.

Not like STOS, but still pretty good.

 

I would love to see a STOS like language for the 8bits. Action kind of comes close, but not really.

I never used STOS BASIC (or the related AMOS), so I don't know which features has for game-oriented programming. Currently FastBasic is a fairly generic BASIC, I hesitated to add more P/M oriented statements because in my experience, generic PMMOVE and PMGRAPHICS are normally not flexible enough to actually program an Atari game.

Link to comment
Share on other sites

  • 3 weeks later...

Is there anyone here that has any experience with Advan Basic? I'm still fiddling around with my idea of a side by side comparison of the various languages on the Atari (the list is still growing). I've decided to pare the list down to just the Basics at this point and I'm running into problems with Advan Basic adding the instrumentation that I added to Atari Basic with a timer and a ML routine to print to a GR.8 screen.

 

The weird way that Advan Basic handles in-line machine code makes it unrealistic to use the embedded ML print routine that works well in Atari Basic and Turbo Basic XL. I was told that Turbo Basic has a built in print routine for printing in graphics modes, but I didn't need it because it ran the Atari Basic version flawlessly. I learned, while reading the documentation for Advan Basic, that it too has a graphics printing routine called CPRINT@ which takes a string and two integers for the X & Y positions as parameters. This seems like it could save a lot of grief as I gave up on the idea of converting the ML string into the funky pseudo-opcodes that Advan Basic uses. I tried a pure basic method of printing text to the GR.8 screen and while a little test harness worked to display a count-up timer, a fully integrated version crashed the program when it was compiled.

 

I though maybe the CPRINT@ command would save my frustrated butt, but when I tried it, it failed to print anything. The documentation for the CPRINT@ command onl;y exists in the screen design toolkit docs. It stated that you need to append the CPLOT.APP file to use the functionality and that the CPRINT@ and CPLOT@ functions are needed to print to custom displays created with the screen designer. Does anyone know if these commands only work with the custom scrolling displays and not normal Atari graphics screens? CPLOT@ is also supposed to allow you to print character to a graphics screen, but you set the character to print using the Color command using, I think, the ATASCII value of the character. This doesn't seem to work with normal graphics modes either.

 

I'd appreciate any light that anyone can shed on the subject. The Advan Screen Design manual didn't go into any real depth!

 

Thanks, Mike

Edited by Geister
Link to comment
Share on other sites

Hi Mike,

 

Is there anyone here that has any experience with Advan Basic? I'm still fiddling around with my idea of a side by side comparison of the various languages on the Atari (the list is still growing). I've decided to pare the list down to just the Basics at this point and I'm running into problems with Advan Basic adding the instrumentation that I added to Atari Basic with a timer and a ML routine to print to a GR.8 screen.

 

The weird way that Advan Basic handles in-line machine code makes it unrealistic to use the embedded ML print routine that works well in Atari Basic and Turbo Basic XL. I was told that Turbo Basic has a built in print routine for printing in graphics modes, but I didn't need it because it ran the Atari Basic version flawlessly. I learned, while reading the documentation for Advan Basic, that it too has a graphics printing routine called CPRINT@ which takes a string and two integers for the X & Y positions as parameters. This seems like it could save a lot of grief as I gave up on the idea of converting the ML string into the funky pseudo-opcodes that Advan Basic uses. I tried a pure basic method of printing text to the GR.8 screen and while a little test harness worked to display a count-up timer, a fully integrated version crashed the program when it was compiled.

 

I though maybe the CPRINT@ command would save my frustrated butt, but when I tried it, it failed to print anything. The documentation for the CPRINT@ command onl;y exists in the screen design toolkit docs. It stated that you need to append the CPLOT.APP file to use the functionality and that the CPRINT@ and CPLOT@ functions are needed to print to custom displays created with the screen designer. Does anyone know if these commands only work with the custom scrolling displays and not normal Atari graphics screens? CPLOT@ is also supposed to allow you to print character to a graphics screen, but you set the character to print using the Color command using, I think, the ATASCII value of the character. This doesn't seem to work with normal graphics modes either.

 

I'd appreciate any light that anyone can shed on the subject. The Advan Screen Design manual didn't go into any real depth!

 

Thanks, Mike

I have used AdvanBasic a little, and reading the documentation I think that you are wrong about CPRINT command. CPRINT is part of the "Screen Design" package, it function is allowing you to write custom display lists and use them from BASIC. This means, for example, one line of GR.1, then ten lines of GR.8, etc. In this mode, CPRINT prints text into the *text mode* lines, not into the graphics mode lines.

 

If you are trying to compare BASIC interpreters/compilers side-by-side, Why do you need printing to a gr.8 screen?. I think that the simplest solution for you is to port your ASM routine to AdvanBasic, so it does the same in all compared languages.

 

Perhaps if you show here your source code we can help parting to other BASICs.

Link to comment
Share on other sites

I'm having some fun writing a cross-compiler at the moment - tailored to the 6502, so it locates variables in zero-page etc. I'm planning on using SQLite as the intermediate format of the compiler, which ought to open up some interesting things in terms of optimisation routines later. It'll be trivial to test one out in PHP before committing to writing it in c++ :)

 

There's a "spec" (it's really not [grin], it's a bunch of notes, but it'll give you an idea) in the GitHub repostitory

 

It'll do 'C' like type-promotion and expression-reduction (it already does a fair amount of this), it'll run the C pre-processor to handle includes, and since I'll have an intimate knowledge of the workings of it, I'll be able to expand it easily. I have a hardware project ongoing as well (in fact, this is the main focus) and giving support for that is one of the primary (but as yet unspoken) goals :)

 

I'd also like to get some support for native hardware - ie: handle bank-programming, PMG etc.

 

The plan is to produce assembly output from the intermediate stage, and then run Mads or something to produce the final executable. I'm more interested in the higher-level optimizations (loop unrolling, variable hoisting, etc.)

 

I've only had a week - give me another 3-6 months and it'll be a contender :)

Lol, can you write something that compiles my PHP to a 6502 binary?

 

I only sort of jest -- I write primarily in PHP for my day job, so it's the language my brain thinks in these days.

Link to comment
Share on other sites

Hi. By high level, I mean Basic, Pascal, C, etc. and by Modern I mean languages developed since the 1980's.

 

[ snip ]

 

What else is out there?

 

[ snip ]

 

One reason I'm interested in doing this is an idea I had to benchmark the various languages running a familiar demo, the "HAT" sine program from a very early ANALOG issue. This program is only a dozen lines or so, but takes nearly 3 hours to run in Atari Basic. The finished image was pretty iconic for the A8 and it appeared in advertising and magazine covers. I translated it to C64 basic (which was a pain without graphic commands) and discovered that the program appears to have been designed for a 320x200 pixel display.. The TRAP statement catches any excursions beyond the bottom of the Atari hi-res screen and wasn't necessary (or even possible) in C64 Basic. The end result on the C64 looks pretty much the same as on the Atari if you ignore the fact that I had to remove the Drawto(X,Y) statement that cleans up any obscured points. I had enough trouble writing a "Plot(X,Y) subroutine.

 

I did not have an actual C64 to test the program on, but the emulator ran the program nearly as fast (or slow) as on the Atari emulator. If I'd taken the time to implement the Drawto in Basic code, it probably would have crawled.

 

 

David Schmenk has been working on PLASMA for a few 6502, 65c02 and 65c802 platforms. Steve F is already porting it to the BBC micro, and an Atari 8-bit version shouldn't be far from reach, with a bit of time and effort from someone willing and able.

 

https://github.com/dschmenk/PLASMA

 

https://www.youtube.com/watch?v=_JEqbczrvsk&list=PLlPKgUMQbJ79VJvZRfv1CJQf4SP2Gw3yU

 

 

Dave has recently released version 2.0, with a JIT compiler.

 

The Hat sine program has been making the rounds for some time. I had ported it to the 280x192 Apple ][ hires display by playing with the various constants many years ago. The symmetry of the algorithm allows several easy optimizations, but I think that John Brooks took things to a "whole nother level" on usenet last year, with a z-buffer and all kinds of other cool stuff. He was eventually able to get a compiled BASIC version to complete in about 61 seconds @ 1 MHz!

 

https://groups.google.com/forum/#!searchin/comp.sys.apple2/hats$20off|sort:date/comp.sys.apple2/buTFvk-VnTo/F-4KSEd4AAAJ

 

https://groups.google.com/forum/#!searchin/comp.sys.apple2/hats$20off|sort:date/comp.sys.apple2/Uc4EmM3xX88/WRGQCTWLAQAJ

 

Mike B.

Edited by barrym95838
  • Like 3
Link to comment
Share on other sites

...on usenet last year, ...

Wow, I'm amazed usenet is still used for proper communication between people. I quit usenet in the late 90's / early 00's. There was just way too much spam. I thought at later days it was mainly used for distributing pirated movies/music/warez under the radar, because everybody had forgot about usenet :) So, does anybody ever post on comp.sys.atari.8bit ?

  • Like 1
Link to comment
Share on other sites

Hi Mike,

 

 

I have used AdvanBasic a little, and reading the documentation I think that you are wrong about CPRINT command. CPRINT is part of the "Screen Design" package, it function is allowing you to write custom display lists and use them from BASIC. This means, for example, one line of GR.1, then ten lines of GR.8, etc. In this mode, CPRINT prints text into the *text mode* lines, not into the graphics mode lines.

 

If you are trying to compare BASIC interpreters/compilers side-by-side, Why do you need printing to a gr.8 screen?. I think that the simplest solution for you is to port your ASM routine to AdvanBasic, so it does the same in all compared languages.

 

Perhaps if you show here your source code we can help parting to other BASICs.

I think you are right. I think it was wishful thinking on my part because I didn't want to convert the ML in the string into the pseudo opcodes used by Advan Basic. There's a lot to like about this compiler but his handling of inline machine code is unnecessarily complicated from my point of view. I also dislike the need to hang a "%" off of every integer variable to differentiate from floating point, but that's a minor gripe.

 

The only point of the ML code is to display an elapsed time and it's how I compare performance of the language, not part of the test. It is the Compute magazine code that David_P and others provided in my other thread about text in graphics 8. I want to show the run time of the routine in the current language without dropping out of graphics mode so I can screen capture the results. I'm attaching the Atari Basic version and the Turbo Basic version.

 

post-63094-0-25837100-1524358172_thumb.jpg

post-63094-0-75203100-1524358250_thumb.jpg:

 

@barrym95838 I'm not interested in optimizing the code. The goal is comparing the performance of the individual languages on a well-known, and slow, icon of the Atari computer. First I want to do all the BasicsI can find and then move on to other well-known languages that were or are currently available on the old workhorse.

 

Yes, I'm using Altirra instead of the real hardware because it's so easy to scrape a screen shot off of it. I may be using it to create some videos at some point to capture draw speed samples.

  • Like 1
Link to comment
Share on other sites

Hi!

 

The only point of the ML code is to display an elapsed time and it's how I compare performance of the language, not part of the test. It is the Compute magazine code that David_P and others provided in my other thread about text in graphics 8. I want to show the run time of the routine in the current language without dropping out of graphics mode so I can screen capture the results. I'm attaching the Atari Basic version and the Turbo Basic version.

 

attachicon.gifHat ATBasic.jpg

Why not simply write the elapsed time in the text window then? You can enable the text window just before printing the time by doing a "GRAPHICS 8+32", the "+32" preserves the screen contents, and then simply use "PRINT" to output.

 

This is a version of the Fedora Hat program for FastBasic, without any optimizations:

' Reads start time'
ETIME%=0
EXEC GetTime
STIME%=ETIME%

DIM RR(320)
FOR I=0 TO 320:RR(I)=193:NEXT I

GRAPHICS 8+16
SETCOLOR 2,0,0
COLOR 1

XP=144:XR%=4.71238905:XF%=XR%/XP

FOR ZI=64 TO -64 STEP -1
ZT%=ZI*2.25:ZS%=ZT%*ZT%
XL=INT(SQR(20736-ZS%)+0.5)
FOR XI=0-XL TO XL
XT% = SQR(XI*XI+ZS%)*XF%
YY = INT((SIN(XT%)+SIN(XT%*3)*0.4)*56)
X1=XI+ZI+160:Y1=90-YY+ZI
IF RR(X1)>Y1
RR(X1)=Y1
PLOT X1,Y1
ENDIF
NEXT XI
NEXT ZI

' Reads End time'
EXEC GetTime
ETIME%=ETIME%-STIME%

' Enable text window'
GRAPHICS 8+32 : SE.2,0,0

' Convert to seconds (NTSC, use 49.86074 for PAL)'
ESEC = INT(ETIME%/59.92271 + 0.5)
EHOUR = ESEC / 3600
EMIN = (ESEC MOD 3600) / 60
ESEC = ESEC MOD 60
? "ELLAPSED:";EHOUR;":";EMIN;":";ESEC

PROC GetTime
REPEAT
QT = PEEK(18)
ETIME% = TIME
UNTIL QT = PEEK(18)
IF ETIME%<0
QT = QT + 1
ENDIF
ETIME% = 65536.0 * QT + ETIME%
ENDPROC
With the standard Atari mathpack, compiled from the IDE, it gives 1:53:24 of run-time:

post-18634-0-72933600-1524364778_thumb.png

 

Using Altirra mathpack, the run-time decreases to 0:56:53:

post-18634-0-06281900-1524365117_thumb.png

  • Like 2
Link to comment
Share on other sites

OK, I have to admit it never occurred to me to simply open the text window and print. Always making life harder on myself. Speaking of making things harder on myself. I was sure I already had done a Fast Basic version, but now I seem to have misplaced it because I have been moving ATR images around and may have overwritten it. Thank God I didn't lose the Atari Pascal version because I think I'd rather rub gravel in my eyes than use that software again!

 

Although I am using the Altirra emulator as a test system, the idea is to produce something that will run on my box-stock 800XL and not take advantage of the speed boosts that the Altirra and the PC provides.

 

I want to repeat that I really enjoy using your Fast Basic. It still feels the most like a modern language of everything I've tried on the Atari. Best of luck to you whichever way you decide to go with it in the future.

Link to comment
Share on other sites

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