Jump to content
slx

BASIC Ten-Liners are back for 2018!

Recommended Posts

Hey dmsc, how long can be source lines in FastBasic? I guess that it is 255 bytes for the IDE, but I don't know for the cross compiler.

 

 

Share this post


Link to post
Share on other sites

Hi!

 

Hey dmsc, how long can be source lines in FastBasic? I guess that it is 255 bytes for the IDE, but I don't know for the cross compiler.

Currently the IDE editor is limited to 128 byte lines, and the Atari PARSER is limited to 255 byte lines, but the cross-compiler should not have any limit...

Share this post


Link to post
Share on other sites

Hmmm, let's do some nitpicking. In the "pure-80" category they say that the Basic must be built-in... but they do NOT say it must have been factory built-in when the computer was made...

 

One can build-in Turbo Basic XL into any XL/XE machine and/or replace the Atari Basic ROM with TB XL (with some work and more than just an 8k ROM/Eprom replacement, but possible). With Altirra Basic it is even easier, burn it onto an 8k Eprom and replace that with the Atari Basic ROM, voila built-in Altirra Basic.

 

You own a U1MB ? It is built-in into your computer, thus you may have several built-in programming languages...

 

So, if you do send your entry in some A8 Basic dialect, also send them photos of your Atari 8bit, which shows that this Basic dialect is built-in in your computer and it is running your program.

Edited by CharlieChaplin
  • Like 2

Share this post


Link to post
Share on other sites

No need for nitpicking. The rules are simple, why do people try to find backdoors? That leads to more complicated rules, which will destroy contest. It´s the BASIC Ten-Liners contest, that alone says it all. Get the most out of the built in BASIC of a stock machine. If you want to do something more advanced, there is the FREI category. Or simply go for the ABBUC software contest with a "full" program. Please keep it as simple as it is. The last years have shown, that amazing things are possible with all the restrictions of the stock BASIC.

  • Like 6

Share this post


Link to post
Share on other sites

Get the most out of the built in BASIC of a stock machine.

 

Please let us know which are the allowed BASIC dialects for the PUR-80 category. Is Atari BASIC (any Rev) the only one?

 

The last years have shown, that amazing things are possible with all the restrictions of the stock BASIC.

 

In the asumption that Atari BASIC is the only stock BASIC for the A8, I searched how many games have been programmed for this contest using it, and found the following:

 

2011: 6/6 PUR(120) - Only Atari BASIC was allowed

2013: 6/6 PUR(120) - Only Atari BASIC was allowed

2014: 1/28 PUR(120), 0/12 EXTREM(256) - TurboBasic XL was also allowed

2015: 3/22 PUR(120), 0/2 EXTREM(256) - Many BASIC dialects and some other systems allowed

2016: 0/2 PUR-80, 0/15 PUR-120, 0/9 EXTREM-256 - Any 8-bit system and BASIC dialec allowed

2017: 0/8 PUR-80, 0/9 PUR-120, 0/2 EXTREM-256 - Any 8-bit system and BASIC dialec allowed

 

As it can be seen, only 16 of 121 games for the A8 were written in stock BASIC, and 12 of them are from the contests were it was the only dialect allowed. All of them fitted PUR-120 category, and I wouldn't say that they were amazing (with few exceptions). Sorry! In my opinion, the amazing ones were written in TurboBasic XL.

 

So, what should be expected for PUR-80 category this year? As I see, just let other architectures/brands to win the category. :(

 

But this new rule is THE RULE, and we have to comply it and do our best to build a quality game for the PUR-80 category.

 

... and my already finished 80 columns TurboBasic XL game should be submitted to the PUR-120 category. :x Might it could get an extra "small size" bonus score. :lol:

 

If you want to do something more advanced, there is the FREI category.

 

I was joking with my USR demo for the FREI category, just because there was no limit in what a BASIC tenliner is and the (ab)use of machine language "routines". I think that it was difficult for the panel of experts to asign a fair score to the games on many different 8-bit systems... Now, in this new category, it will be worst!!!

 

Also, the unlimited line length also allows more interesting and impressive results, even without USR instruction. I'll try a FastBasic one-liner in this category if I have the time and a good idea.

 

But analyzing my statistics, the tendency is to make smaller programs, i.e. mini-games, not more complex ones. Last year, 42% of Atari games were written for the PUR-80 category in contrast to 11% for EXTREM-256. The previous year were 8% and 35% percent respectivelly.

Share this post


Link to post
Share on other sites

Hi! Currently the IDE editor is limited to 128 byte lines, and the Atari PARSER is limited to 255 byte lines, but the cross-compiler should not have any limit...

With no limit ?

Of course. If I have a procedure then the tool will create at least two lines ?

Share this post


Link to post
Share on other sites

After submitting my entry I came here to see what was up (not having seen anything else submitted for Atari).

 

So, besides the one coder who is pissed, what's up?

Share this post


Link to post
Share on other sites

After submitting my entry I came here to see what was up (not having seen anything else submitted for Atari).

 

Congrats! I was also missing an Atari entry.

 

So, besides the one coder who is pissed, what's up?

 

Will it be me, master? ;)

 

I guess that some of the 10-liner coders are trying to hack Atari BASIC to get an amazing game for the "stock" PUR-80 category. Other might be doing some experiments with FastBasic for the other categories. But do not expect too many contributions, as there is less time than the previous years.

 

BTW, I've finished a small game that fits the new PUR-80 category. I named it "Deep Canyon" (the 1st working version was named "Deep Forest"). Guess what? It is very similar to "Crazy Baloon II". I haven't submitted it yet because I must write the docs first. Here is a screenshot:

 

DEEP.PNG

 

Anyone else?

 

  • Like 7

Share this post


Link to post
Share on other sites

Have some ideas and some graphics but not a lot of code yet. My son has some ideas, too, but I don't know if he will pull away from his smartphone long enough to write some code..... ;)

  • Like 2

Share this post


Link to post
Share on other sites

Those. Look. Amazing! Well done lads.

 

Deep Canyon shames my PUR-120 category :)

 

I'm glad you're still entering vitoco - I meant no disrespect, I just hadn't seen much else of anything in the thread and there weren't any other Atari submissions as yet, so I was just wondering if I missed something :)

 

Good luck to all!

Share this post


Link to post
Share on other sites

In case it makes any of you feel any better, computers like the Sega SC-3000, Sord M5, Sharp MZ-700 and MZ-800 (to name a few) will also be "disqualified" from the PUR-80 challenge as neither of these have a built-in ROM BASIC. I would think the correct regulation the arranger would like to use is "any BASIC variant originally sold or supplied by the system manufacturer". As far as I can tell, it would include the ATARI BASIC cartridge, the SC-3000, M5 and Sharps, even the TI-99/4A Extended BASIC and less commonly used stuff like Simons' BASIC on the C64 but keep 3rd party BASIC variants out of the PUR category.

Edited by carlsson

Share this post


Link to post
Share on other sites

Atari had Atari BASIC rev A,B,C and Microsoft BASIC 1,2. Those were officially produced and distributed as they were officially commissioned for the Atari 8 bits and sold on cartridge and disk. Very old (early depending on your way of looking at it) magazines even had program listings for the Atari 800 in Microsoft BASIC.

Edited by _The Doctor__
  • Like 1

Share this post


Link to post
Share on other sites

Microsoft BASIC does not allow abbreviations. Useless for PUR-80 category. Loading my abbeviated listings using ENTER and expanding them using LIST, in average, the size of the sources increases in 30%. That means that you have about 25% less of space of code for a game. It's like programming in Atari BASIC with lines with a max length of 60 (just like my game "Alby", which I programmed last year in TurboBasic XL for the old PUR-80 category and now I have to submit it for the PUR-120 category... I might submit it without abbreviations and it still fit that category!!!).

 

Also, MS BASIC and MS BASIC II uses more memory, leaving less free RAM to be used for buffering to create simple animations.

 

So, Atari BASIC is the only way to go for PUR-80. It is well documented to try some hacks. And all revisions (A, B and C) are the same, just with different bugs.

 

  • Like 1

Share this post


Link to post
Share on other sites

Going for completeness and accuracy. Never said you would choose it. :)

who knows what a people will do..

Edited by _The Doctor__

Share this post


Link to post
Share on other sites

Hi!

 

 

Currently the IDE editor is limited to 128 byte lines, and the Atari PARSER is limited to 255 byte lines, but the cross-compiler should not have any limit...

If the IDE editor is limited to 127 bytes per line, how can we feed the parser with lines of 255 bytes? Is it possible to feed it directly from disk like using ENTER "D:*.LST" in Atari BASIC?

 

Also, could you give us some technical info about used memory locations and the structure of parsed programs? Is there a variables table, stack, etc? I know that FastBasic is a work in progress and some things might change in the next version, but we need something to start.

 

Thanks!

 

EDIT: I think this is not the appropiate thread to talk about FastBasic. Lets go to the programming subforum...

Edited by vitoco

Share this post


Link to post
Share on other sites

Hi!

 

If the IDE editor is limited to 127 bytes per line, how can we feed the parser with lines of 255 bytes? Is it possible to feed it directly from disk like using ENTER "D:*.LST" in Atari BASIC?

You can load a file with big lines in the IDE and run from there, you just can't edit it currently.

 

Note that the parser uses LBUFF ($580) as the current line buffer, so any line more than 128 bytes of length will overwrite $600 and up, the same as with AtariBASIC.

 

I can change the IDE to support lines of more that 128 bytes, but then the $600 area will be used by the IDE and not available as free RAM.

 

Also, could you give us some technical info about used memory locations and the structure of parsed programs? Is there a variables table, stack, etc? I know that FastBasic is a work in progress and some things might change in the next version, but we need something to start.

The memory map is like:

  • ZEROPAGE:
    • $82 to $93: the interpreter main loop, in ZP for faster execution. Here is also the interpreter program counter (cptr) and stack pointer (sptr)
    • $94 to $9F: interpreter variables, like COLOR, IOERROR, IOCHN, TABPOS and 7 temporary variables.
    • $A0 to $A9: parser and interpreter pointers, here is the pointer to bytecode, end of bytecode, variable table, array data and labels. Only the pointers to variable table and array data are used in the interpreter, other pointers are only used in the parser.
    • $AA to $AD: floating point data: floating-point stack pointer, DEG/RAD flag and two temporaries.
    • $AE to $D1: UNUSED
    • $D2 to $FF: used by the OS math package, note that some of these locations are used by "INPUT", "VAL" and "PRINT" even in the integer FastBasic.
  • MAIN DATA:
    • $480 to $4A7: low bytes of the integer stack (40 entries)
    • $4A8 to $4CF: high bytes of the integer stack (40 entries)
    • $4D0 to $4FF: floating-point stack, 8 entries of 6 bytes each.
  • INTERPRETER (starts at $2000):
    • $2000-$20C7: First 200 bytes are a jump-table with the address of execution of each token.
    • $20C8-$2C1F: Runtime, copied to compiled programs.
  • IDE (starts at end of runtime):
    • $2C20-....: Parser and Editor, used only in the IDE.

Thanks!

 

EDIT: I think this is not the appropiate thread to talk about FastBasic. Lets go to the programming subforum...

You are right!

Share this post


Link to post
Share on other sites

And now Flappy Bird has become Flappy Bat !

 

But gameplay seems to be easier than in most flappy Bird games, so I will give this one a try.

 

Besides, Stan Ockers also used a white bat (and black background) in his game "Bats" 1982/1983...

Share this post


Link to post
Share on other sites

And now Flappy Bird has become Flappy Bat !

 

But gameplay seems to be easier than in most flappy Bird games, so I will give this one a try.

 

Besides, Stan Ockers also used a white bat (and black background) in his game "Bats" 1982/1983...

 

I don't know if it was Flappy Bird the game my son was playing when I started the coding of this game. It might be one of the Pou minigames or another with geometrical sprites.

 

About "Bats", I never knew about it. I've just searched for it and found a promising image from in Antic Magazine:

 

inthepublicdomain.GIF

 

I then downloaded it and tryed it, but it was dissaponting what I got:

 

bats.gif

 

Anyway, the gameplay is different: in Bats you go up when you press the joystick and down when you release it. In Alby, you must press the button many many many times in a row to keep flying.

  • Like 4

Share this post


Link to post
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.

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