BASIC Tenliners Contest 2016

[+slx]

I don't think I can post the code with abbreviations as they get 'lost' when the parser checks the line. I hardly used them anyway because I knew I would use the concatenation utility and once parsed all commands & functions are only one byte long anyway.

 

Most if not all of my lines could not be entered even with abbreviations. My 'trick' is to write multiple lines and then 'fuse' them together until reaching the limit of 255 bytes allowed by BASIC using the utility I programmed and posted last year (at the expense of not finishing Steinkraft for the 2015 competition). The utility is on the ATR with one bug fixed (it would allow 256 bytes per line which seems to be one too much).

 

The utility works better with BASICs allowing structured programming and avoiding GOTOs as you don't have to keep lines 'unfused' that are the target of a GOTO.

 

 

Gesendet von meinem iPhone mit Tapatalk

[+slx]

 

It called my attention a REM statement in the middle of line 7. In Atari BASIC, all the text after the REM is part of the comment. In this case, is the comment terminated by the "ball" char?

 

I also tried your son's game AVOID! It's very nice...

 

I actually forgot that REM statement commenting out a line for testing which I never needed again..... Apparently the concatenation works for REM as well as the executor (the part of BASIC executing the commands one after another jumps over it like any other statement. There is just no way to enter this via the keyboard as the parser will not consider the colon a delimiter but just part of the REM text. Why it appears as a ball I can't tell....

 

I also realized that I wasted space during the initialization as BASIC XL actually supports string arrays which would have allowed the string to page 6 copying to go into a loop.

 

And finally thanks for the positive feedback on Avoid which I shall pass on to the programmer.

Edited March 29, 2016 by slx

[+slx]

edited due to duplicate post

Edited March 30, 2016 by slx

[+slx]

Attached is a "working copy" of the finished source for Steinkraft including some lines with DATA statements and tools that are no longer required for the finished program but show a bit of what I did.

 

STEINSRC.BMP

 

The DATA lines from line 10000 onwards contain the character and sprite data as exported from Superfont+ or a similar program.

Line 20000 contains a very basic method of displaying the tokens in the program file. The strings CH1$, CH2$, etc. were originally filled with "AAAA...." and I used "GOTO 20000" to list the file, look for the AAAAAs and note the address, i.e. where the string is located in memory. I then entered that address in line 30000 and then used "GOTO 30000" to read the data statements and poke them into the memory instead of the "AAAAAA...." string, repeating this process for all four strings.

 

Thereafter everything after 10000 can be deleted and the program saved and run through the compactor utility (SLXPRESS.BA2). Presto!

 

I used four strings as the 248 data bytes required were a tad to long to fit into one line but with a bit of fiddling it could be done with a string array or two strings only, but all that was done with about 1,5 hours left before the deadline so I had no time to be inventive. That's the reason why there is no title screen and no replay option either and why there is actually a lot of unused space within the 10 lines allowed.

 

I am the first to admit that this method is less elegant than PUR-80 by far as it replaces clever minimum space coding by making more space available by circumventing the BASIC editor's limits but then a lot of 1980s programming involved stretching things to the technical limit and the line concatenation could be "useful" beyond ten-liners as it actually saves space by reducing the byte overhead required for every new line (at least if one is willing to entertain the notion that improved programming techniques requiring byte-wise space saving for an obsolete dialect of a programming language last published 25 years ago can be considered "useful" ).

 

I don't think there's a way to stuff more into a BASIC line and I found it interesting that BASIC did not balk at listing these very long lines which is a testament to the flexibility (or lack of assumptions) the people at SMI built into Atari BASIC (try SUPERCAL.BAS on the ATR for a demo).

Steinkraft with source.atr

STEINSRC.BMP

STEINSRC.LST

Edited March 30, 2016 by slx

[vitoco]

@slx: it seems that you missed half of the listing in your source's BMP!!! Check for other images in the ATASCII Printer result.

 

I found very interesting your tool to reduce the number of lines, but if it does not check the abbreviated source length, It shouldn't be used for this contest.

 

I wrote my own set of tools to abbreviate TurboBASIC XL source code and used them to get the abbreviated listing for every entry of the previous contests. So I wanted to try them with your game.

 

I had to modify one script to accept OSS BASIC XL tokens and applied it to SteinKraft. Result: the longest abbreviated line had 321 chars. I renamed all the variables to a single or two chars name but it was not enough. The size of the abbreviated listing of your game was only of 2062 bytes (less that 2560=10*256) so it seems that it could be fixed. As the file with the renamed variables had 1837, there were no GOTO or such statements and only 8 lines of code where used, I tried to adjust this program finding where to cut every line. During the process, OSS BASIC complained for many things when I ENTER this, like "line too big" or some syntax errors, and it also seems that an IF statement without a THEN can't be the last one in a line (TurboBASIC also has an issue on this). At the moment, I'm unable to run it after sucessfully ENTERed it. I don't know what I'm missing or what I did wrong that fails with a "nesting" error when RUNing it.

 

During this "experiment", I found that you defined the varianble C62=62 and used it as the string size in the 4 DIM instructions (that could be joined in a single DIM statement), but later you MOVE the contents of that strings to a fixed memory address respectively, but in two of them, you used the constant 62 instead of the variable as the number of bytes to move, and in the other two, you specified 45 (less than 62) and 79 (MORE THAN 62!!!!). I know 45+79=124=62+62, but I doubt that's OK as the source strings are not contiguous in memory... some garbage should appear somewhere. BTW, I didn't check the source version from your latest post for this issue.

 

[+slx]

So here's all of it. Thanks vitoco for alerting me to the missing file and of course for the great printing utility.

 

As for the abbreviated source length check, it would require a lot more "knowledge" for the tool as it does not concern itself with what the tokens mean in its present form. You basically need a listing utility because IMHO there is no other way to find out how long numbers are when listed.

 

When I wrote the tool in 2015 the EXTREM category allowed 256 characters per logical line so the output was according to the rules. This year using logical lines with 255 bytes would still be legal but fall into the WILD category.

 

As for the C62 and different string lengths you're right. I used strings of different length in a previous version and forgot to correct that. I just wonder why it doesn't show in the game. Probably because the error concers some graphics I designed but then didn't use in the game.

 

As I wrote above, the last hours before the deadline were quite frantic as I managed the gameplay to work around 15:30 and didn't have more than two hours to actually "pack" the game and insert the data for the graphics I hope that explains a lot of sloppy last-minute programming.

 

IF without THEN indeed can't be the last statement although that would make for elegant listings using the indent feature.

STEINSRC1.BMP

STEINSRC2.BMP

Edited March 30, 2016 by slx

[vitoco]

As for the abbreviated source length check, it would require a lot more "knowledge" for the tool as it does not concern itself with what the tokens mean in its present form. You basically need a listing utility because IMHO there is no other way to find out how long numbers are when listed.

You are right, both of us need more knowledge. Your utility doesn't know about abbreviated listings, and mine doesn't know about tokenized lines. DMSC's parsing tool takes care about both situations at the same time, but it doesn't know about OSS BASIC XL

 

When I wrote the tool in 2015 the EXTREM category allowed 256 characters per logical line so the output was according to the rules. This year using logical lines with 255 bytes would still be legal but fall into the WILD category.

 

I think that a "logical line" means "3 physical lines" in the editor, not a "tokenized line". EXTREM-256 category extended those 40*3=120 chars to 256 (actually 255) bytes to be ENTERed from a disk file.

 

But don't worry, your program fits EXTREM-256 category with minor changes. I renamed variable C62 to W and joined the DIMs in one statement, then I cut lines in some statements where both abbreviated listing and tokenized line fit. Then ENTERed the file in Altirra and voila! It run as the original entry. I finally substract 17 from ADR(CH4$) to point the MOVE to the proper memory address to see if something happens, but as you said, it is probably data that is not being used anymore. BTW, I also removed the REM with a ball and 2 more statements that were included twice at the end of line 5 (a FOR and a RANDOM assignment).

 

The new listing looks like this:

 

I've attached the new listing of your game. I hope that Gunnar won't classify it as WILD, because it is not.

 

KRAFT2.LST

[+slx]

You are right, both of us need more knowledge. Your utility doesn't know about abbreviated listings, and mine doesn't know about tokenized lines. DMSC's parsing tool takes care about both situations at the same time, but it doesn't know about OSS BASIC XL

Does that prove Heisenberg was right

I think it is much easier to make your program "tokenized length aware" than to get mine to know abbreviated length.

 

But don't worry, your program fits EXTREM-256 category with minor changes.

Wow, thanks for a lot of diligent work you put into my program!

 

 

I've attached the new listing of your game. I hope that Gunnar won't classify it as WILD, because it is not.

He didn't, it's classified as EXTREM-256 on the games list. OTOH I would have been the only entry in WILD , making me an automatic winner.

 

Now let's hold our breath and wait who's going to win! There are a lot of great-looking games on the list and what I could play so far was astonishing. It's amazing that people still come up with lots of great ideas after a couple of years of Tenliners.

[vitoco]

Wow, thanks for a lot of diligent work you put into my program!

 

Well, that was fun! And you still have space to fix some bugs...

 

He didn't, it's classified as EXTREM-256 on the games list. OTOH I would have been the only entry in WILD , making me an automatic winner.

 

Actually, it exists a WILD entry: a game for C=64 that uses an instruction simillar to our USR function. It's interesting that the game does not include a machine language routine in it's data, but it creates one taking parts from the ROM!

[Bunsen]

Find the results on contest homepage...

 

http://gkanold.wix.com/homeputerium#!results-2016/c1snz

[+Adam+]

Congratulations to all participants, especially to the double winner Vitoco! Jeff Piepmeier, Kevin Savetz and 8BIT1337 are also close to the top

Edited April 2, 2016 by +Adam+

[8BIT 1337]

Congratulations to all participants, especially to the double winner Vitoco! Jeff Piepmeier, Kevin Savetz and 8BIT1337 are also close to the top

 

I love that our beloved machine medaled in each category and swept the 120 category.

 

 

Doubly happy I could be a part of it, as I really enjoyed the challenge.

[jeffpiep]

Congratulations to all participants, especially to the double winner Vitoco! Jeff Piepmeier, Kevin Savetz and 8BIT1337 are also close to the top

That was a lot of fun. Great to see AtariAge users in the top!

[vitoco]

That was a lot of fun. Great to see AtariAge users in the top!

 

I agree.

 

As I promissed, all of my games are available through my home page with the code description and a video of the gameplay.

[+therealbountybob]

Here is my entry GRAVITY X.

I was surprised that I could get a decent game out of this - the game is based on my Turbo BASIC abbuc entry from 2015 Gravity which you have all played and beaten level 10 by now

Download: Gravity X - 10 Liner 2016.ATR

Info:

>>>

Gravity X
10 Liners Contest 2016
by Jason Kendall
© Kendallsoft 2016

NOTE: "Gravity X" works perfectly on a real Atari with a reliable joystick but does NOT work well under emulation - there is some delay / timing issue in reading the joysick / firing...

Your mission is to reach the top of the screen by dropping the moving blocks onto the pile. You start with 3 blocks, if any miss they are eliminated. If you reach the top of the screen you will go on to the next level which is faster.

The game is written in turbo basic. You will need to get used to the timing of the firing, and hold the button in, *NOT* just press it. Be careful not to hold fire in too long, especially when you are near the top of the pile.

Gravity X was based on my abbuc 2015 game Gravity, but it was re-coded from scratch. It does not have any bonus screens but does give you an extra block on each new level if you have lost any.

I've reached about 4 screens so far!

Line 1 Setup and Titles
Line 2 High Score, Game Over, Wait for Start
Line 3 New go: Setup screen
Line 4 New go: Colour and blocks
Line 5 Main Game Loop: draw blocks, Check fire
Line 6 Drop routine: On target
Line 7 Missed
Line 8 Drop blocks
Line 9 Check and reverse blocks direction
Line 10 Check and reverse blocks direction. Delay based on level and height. Loop to 5 if alive or 2 if not!

Have fun
trbb

<<<

 

Hopefully Bunsen will do a nice menu disk (or disks) again with all the A8 entries

[vitoco]

Hello!

I was curious and wanted to know how it would look like if I put all entries together. Here are the resulting listings for each category, only Atari XL/XE entries:

• PUR-80
• PUR-120
• EXTREM-256

I think I'll add listings from previous contests.

 

BTW, while I was doing this, I found another game that had to be classified as WILD, or it had to be accommodated to qualify in the next category, because it has 11 lines of code (without REM statements).

 

[doctor_x]

Graviten looks AMAZING for being that little code... Love the colors - i dont remember seeing a color combo like that in atari games back in the day...

 

Also - to the person whos son is writing atari competition programs - you've got an awesome kid!!!!

[Mr SQL]

That was a lot of fun. Great to see AtariAge users in the top!

 

 

I agree.

 

As I promissed, all of my games are available through my home page with the code description and a video of the gameplay.

 

X2! Very cool to see the Atari VCS place ahead of the Speccy, ZX-81, TRS-80, MSX and c64!

[Bunsen]

All prizes are sent now. Wait some weeks until it arrives. Last year one got lost and one arrived after 2 months.

[vitoco]

Hopefully Bunsen will do a nice menu disk (or disks) again with all the A8 entries

 

I've put all A8 entries in a single ATR with TurboBASIC XL and a menu. There are two entries that won't load because they are OSS BASIC XL programs and require that cartridge.

NOMAM2016.ATR

[+CharlieChaplin]

Well,

 

"for every problem there is a solution" on the A8 this means, for every problem there are several solutions...

 

1) Altirra Basic does contain some of the Basic XL commands, so it can load some Basic XL programs...

(TB XL may also load a few BXL programs)

 

2) OSS knew of this problem too, so they created the Basic XL runtime, where runtime is a bit misleading - since it loads standard, un-compiled BXL programs (no need to compile them!). The BXL runtime was made freely available to the A8 users, so they could share their BXL programs with everyone, even users that did not own the Basic XL cart. The BXL runtime will only run/execute BXL programs, one cannot list nor edit them (but executing them is enough for most users anyway). The BXL runtime will automatically load a program named Autorun.BXL and it will not stop searching for such a program (in case it does not exist, you may press Break and an Error message will appear, that there is no Autorun.BXL on the diskette and you can insert another disk with Autorun.BXL on it or just press Reset to do a coldstart)...

 

So, you can display & load several Basic dialects from the menu (e.g. menu1, which shows TB XL, Basic XL, Atari Basic, Altirra Basic, etc.), assuming it allows loading ML files and the Basic dialects will then load another menu (e.g. menu2 as an Autorun.BAS) that will show all the appropriate Basic programs (Basic XL shows .BXL programs, TB XL shows .TUR programs, Atari Basic and Altirra Basic show .BAS programs, etc.) which will be loaded/executed from this Basic dialect...

 

 

BXLRUNT.xex

[Savetz]

For a little Sunday project, I made a series of YouTube videos where I tried all of the TurboBASIC XL-based 10-liners.

 

 

I totally confused Gravity X and Graviten in the first video, but correct it in a later video. There are 7 videos in all. There will be 8 if I decide to go back and play the OSS BASIC entries.

Edited April 17, 2016 by Savetz

[+Adam+]

Hi, I have a question regarding "Steinkraft" game - what kind of "shelter" has to be built? Does the game end after building such shelter?

[Mr SQL]

For a little Sunday project, I made a series of YouTube videos where I tried all of the TurboBASIC XL-based 10-liners.

 

 

I totally confused Gravity X and Graviten in the first video, but correct it in a later video. There are 7 videos in all. There will be 8 if I decide to go back and play the OSS BASIC entries.

 

Great production and awesome commentary Savetz!

 

It's amazing how good the Atari homebrews look - many of the games perform like Machine Language games rather than BASIC.

[vitoco]

2) ... The BXL runtime will automatically load a program named Autorun.BXL and it will not stop searching for such a program...

 

Thank you. I've already found BASICXL.COM and tried it, but I thought that it could work only on OSS DOS... After I read that, I tried it in DOS2.5 with a custom version of the menu as AUTORUN.BXL and it worked, so I added both BASIC versions in the same disk. TurboBASIC XL menu is able to load OSS BASIC XL when options 20 or 21 are selected. A cold start is required to return to TurboBASIC, or the menu might lock. The new version of the ATR is attached and also available in my 10liner's page (with a compilation of entries from previous contests).

 

 

For a little Sunday project, I made a series of YouTube videos where I tried all of the TurboBASIC XL-based 10-liners.

...

There are 7 videos in all. There will be 8 if I decide to go back and play the OSS BASIC entries.

 

That was very interesting... thank you for your comments on my games.

 

Now, you can add your 8th part about OSS entries with my new ATR.

 

I noticed that you used a standard Atari joystick with your emulator. Which kind of interfase are you using?

NOMAM2016.ATR