BASIC Ten-Liners are back for 2018!

[+slx]

Time to tighten up your code!

 

10-Liners are back for 2018

 

A new FREI (free) category allows for machine language and self-modifying code this year.

[VladR]

Question on 'die Frei Kategorie' :

" the line limit is not stipulated" - does it actually mean the line length is unlimited?

 

Meaning if the particular Basic editor allows more than 256 characters per line, it's allowed?

[+slx]

Question on 'die Frei Kategorie' :

" the line limit is not stipulated" - does it actually mean the line length is unlimited?

 

Meaning if the particular Basic editor allows more than 256 characters per line, it's allowed?

 

I'd read it that way, too. German text says basically the same. I assume for most existing BASICs the editor is the limit as the only way to save is through short variable names and abbreviated commands. Technically BASIC can do more but that would be restricted to unlimited category.

[VladR]

Thanks.

 

 

initializations and self-modifying code are allowed

Am I interpreting the initialization correctly as a loading screen during which time various tables are precomputed ?

[Rybags]

I might have to give this another shot... and for other platforms too.

 

The E: device allows only 120 character lines.

Basic allows entry of a 256 character record, which normally would only occur in an ENTER command usually from tape/disk. >120 char lines are usually the result of using abbreviated statements when typing in a program.

Another trick to get longer lines is use a PC-based editor to get >120 character lines with abbreviated statements, then transfer to the Atari via ENTER command.

 

Atari Basic only uses a single byte to represent the length of a tokenised line of the program which means the contents of a program line have to be under 256 bytes.

In practical use you'd usually stay under that even if the E: allowed 256 byte entered lines.

But stuff like heavy FP constant use in maths expressions could exceed it.

 

I suppose if you really wanted to be tricky you could do a program that appended together program segments to get maximal stuffed in per line. Though things like branches can make it harder.

By doing that you'd end up with a program that would only work so long as SAVE/LOADed and though it could be listed, attempting to edit it on the Atari would break it.

[Rybags]

Weird... I entered this line:

 

 

10 A=1+2+3+4+5+5+7+8+9:B=1+2+3+4+5+5+7
+8+9:C=1+2+3+4+5+5+7+8+9:D=1+2+3+4+5+5
+7+8+9:E=1+2+3+4+5+5+7+8+9

 

It should give an ERROR - 14 (line too long) but doesn't. Instead, locks up when you try to list it.

[VladR]

Yeah, I somehow was under impression Altirra Basic would allow > 256, but just looked it up in the manual, and limit is, of course, 256.

 

The idea is to use ASM code like this:

0Z=ADR("hQwdCCx0f88v")

 

Then just do USR (Z)

 

This way, you can cram a lot of code into 10 lines. Assuming, of course, this is technically possible from within Basic (not really sure, as in past I only used DATA command for USR).

 

If that would work, then the line could have 246 Bytes for ASM, that would average ~130-160 instructions per line. Multiply that by 10...

Edited January 26, 2018 by VladR

[Rybags]

You could just do USR(ADR("hXYZetc"))

 

In theory a smartly written assembly routine could just use branches to link to parts of the program that are on other lines.

So, e.g.

100 Z=USR(ADR("abcXYZ etc"))

110 REM abcXYZ etc

 

A potential problem though could be incorporating some special characters, like the EOL $9B character can't normally be incorporated into a program line. But tricky techniques could overcome that.

[vitoco]

Category "PUR-80":

Program a game in 10 lines (max 80 characters per logical line, abbreviations are allowed).

Attention: In this category only built-in BASIC variants are allowed

 

Built-in means only Atari BASIC in the Atari for PUR-80?

 

My first contribution would be for that category, but it was written using Turbo Basic XL, so it should be moved to PUR-120 category or it could fall into WILD category?

 

I want it to be in PUR-80 category for personal reasons.

 

[_The Doctor__]

um, on the 400/800 basic was on cartridge or disk and the official Basics were Atari Basic and Microsoft Basic... just saying, you don't get any more PURE than that.

Edited January 26, 2018 by _The Doctor__

[VladR]

You could just do USR(ADR("hXYZetc"))

Yeah, but wouldn't I then loose the address where BASIC put the code of the line if I don't put it into a variable? Or I could perhaps somehow infer that from something else ?

 

 

In theory a smartly written assembly routine could just use branches to link to parts of the program that are on other lines.

So, e.g.

100 Z=USR(ADR("abcXYZ etc"))

110 REM abcXYZ etc

That's what I'm scratching my head on, right now.

Obviously, register state will be lost between the separate lines.

 

I do suspect though, that once I start experimenting in Turbo Basic XL or Altirra Basic, the memory hexdump will quickly show any patterns where the code is being stored, the transition between two consecutive lines, etc...

 

So, I presume that once I jump into the very first line, the ASM code could just jump between BASIC lines on itself ? Even if the interpreter didn't yet get to line 2, it still must be stored somewhere.

 

A potential problem though could be incorporating some special characters, like the EOL $9B character can't normally be incorporated into a program line. But tricky techniques could overcome that.

Yeah, I could "fix" the hexcode op in the ASM soup at actual runtime, at the cost of few bytes of code. If it's a lot of bytes (which is highly likely, considering ~1,500 ops across 10 lines), then an array would have to be created, though that'd cost a lot of precious bytes.

 

It all depends on which opcodes are affected. It just might be easier to refactor the underlying ASM code to something that doesn't result in offending special chars.

[Rybags]

There's various ways a relocated asm program can do a "where am I?"

 

From Basic it's easy - the USR call places the start address in locations $D4-$D5.

[VladR]

There's various ways a relocated asm program can do a "where am I?"

 

From Basic it's easy - the USR call places the start address in locations $D4-$D5.

Thanks, but I just checked the Mapping the Atari and they place this address as FR0,so how do you know it's being reused for this ?

 

212·217 D4·D9 FRO

 

Floating point register zero; holds a six-byte internal form of the

FP number. The value at locations 212 and 213 are used to return

a two-byte hexadecima l va lue in the range of zero to 65536

($FFFF) to the BASIC program (low byte in 212, high byte in

213). The floating point package, if used, requires all locations

from 212 to 255 . All six bytes of FRO can be used by a machine

language routine, provided FRO isn't used and no FP functions

are used by that routine . To use 16 bit values in FP, you would

place the two bytes of the number into the least two bytes of FRO

(212,213; $D4, $D5), and then do a JSR to $D9AA (55722), which

will convert the integer to its FP representation, leaving the result

in FRO. To reverse this operation, do a JSR to $D9D2 (55762).

 

 

[Rybags]

It's dual use - holds FP number and also binary for conversions.

 

Atari Basic is well documented, The Atari Basic Source Book would also likely mention it.

[VladR]

Thanks - I wasn't aware of dual usage, so this is something to keep in mind and pay attention to.

 

I checked Altirra manual, and FR0 there is used for return value of ASM routines invoked via USR.

[erichenneke]

 

Built-in means only Atari BASIC in the Atari for PUR-80?

 

My first contribution would be for that category, but it was written using Turbo Basic XL, so it should be moved to PUR-120 category or it could fall into WILD category?

 

I want it to be in PUR-80 category for personal reasons.

 

 

I had the exact same reaction Vitoco.

 

Already had a couple of really good TBXL pur-80 entries cooking. Those are (well, were!) my favorite brain teasers of them all.

[+slx]

I suppose if you really wanted to be tricky you could do a program that appended together program segments to get maximal stuffed in per line. Though things like branches can make it harder.

By doing that you'd end up with a program that would only work so long as SAVE/LOADed and though it could be listed, attempting to edit it on the Atari would break it.

I wrote such a utility called SLXpress for the 2015 contest. See here.

 

SLXpress allows to use the absolute limit of 256 tokenized bytes per line but does not check whether such a line can be entered. As BASIC stores the variable names in a table when SAVEing, long variable names dont incur a penalty. There probably is a limit on how many characters BASIC can list. While the rules are not entirely clear about what the logical line limit refers to, the remarks for the FREI category seem to infer that all programs but those for WILD must be possible to be entered in the editor.

 

I solved the GOTO/GOSUB problem by not attaching even lines, that means if you put every GOTO/GOSUB target on an even line it will remain unharmed. You still need to take care to arrange stuff to maximize use of single lines.

 

The must be able to enter in the editor rule precludes using dummies for non-enterable graphics/ML bytes stored in strings or DATA and then altering the SAVEd file using a disc sector editor (which makes files unLISTable).

 

That was not prohibited in 2015 but would also be limited to the WILD category this year.

 

Now if I only had a great idea for a game...

Edited January 27, 2018 by slx

[Mr SQL]

 

Built-in means only Atari BASIC in the Atari for PUR-80?

 

My first contribution would be for that category, but it was written using Turbo Basic XL, so it should be moved to PUR-120 category or it could fall into WILD category?

 

I want it to be in PUR-80 category for personal reasons.

 

 

um, on the 400/800 basic was on cartridge or disk and the official Basics were Atari Basic and Microsoft Basic... just saying, you don't get any more PURE than that.

 

Agree but loaded from cartridge or disk is not built in so I guess the original 400/800 cannot enter the pur-80 category, only the XL and later series.

 

Maybe the rule should be appended to include the original BASIC for the machine even if it was loaded in, would be silly to exclude the Altair from this category for loading BASIC from paper tape.

 

Is the 120 category still open to machines without a native BASIC in ROM?

[vitoco]

Already had a couple of really good TBXL pur-80 entries cooking. Those are (well, were!) my favorite brain teasers of them all.

 

My game was finished, with the long version totally explained. I also previewed it in a local meetup some months ago. But it was written in TurboBasic XL.

 

Could I rewrite it in Atari BASIC? Of course the answer is NO. Why? Lets see:

 

- Speed: faster is better.

 

- Atari BASIC is line based, mastered by GOTO statement. Only 10 lines of code means only ten GOTO, GOSUB or THEN (implicit GOTO) destinations available.

- Conditions: it is required to use many lines to implement a single IF-ELSE-ENDIF with IF-THEN.

- Structured programming: WHILE-ENDW, REPEAT-UNTIL and DO-LOOP blocks are controls that can be nested in the same line or span between lines without the noeed of a GOTO. probably a FOR-NEXT with a STEP 0 could be used to simulate those.

 

- MOVE: Atari BASIC lacks of MOVE and -MOVE statements. Animations and P/M graphics require speed. You could replace them with a FOR-NEXT statements, but you'll only get slow a...n...i...m...a...t...i...o...n...s.......

 

- PAUSE 0: Needed to sync animations with the display. Just imagine how to implement a check for the timer.

 

- DPEEK and DPOKE: Simple instructions that would expand to long mathematical expresions that require half of a line, i.e. 5% of the code each! If you use it many times, it could be better to write subroutines, loosing two lines (20% of the available space).

 

- etc.

 

I've checked my own previous entries in the PUR-80 category, I think that SketchPadDles could be rewritten in Atari BASIC without the routines to save and load pictures, and a text based slow version of Oruga without levels could be released for the same category.

 

So, say good bye for quality Atari programs in the PUR-80 category.

[vitoco]

Is the 120 category still open to machines without a native BASIC in ROM?

 

The red warning appears only in PUR-80 category.

 

 

About the new FREI category, I'm thinking to submit a machine language game to the contest. Atari BASIC can load about 2K of binary data. You probaly could get larger binaries in other BASIC flavors. Is this fair for a BASIC contest? I think not. Anyway, I'll test this.

[dmsc]

Hi!

 

Weird... I entered this line:

 

 

10 A=1+2+3+4+5+5+7+8+9:B=1+2+3+4+5+5+7
+8+9:C=1+2+3+4+5+5+7+8+9:D=1+2+3+4+5+5
+7+8+9:E=1+2+3+4+5+5+7+8+9

It should give an ERROR - 14 (line too long) but doesn't. Instead, locks up when you try to list it.

 

Yes, the Atari Basic parser does not recover well from overflows, and the same is true for Turbo Basic XL. Funny think is that you can SAVE your bad file and on load it will also lockup on LIST.

 

Yo can use my basicParser tool (at https://github.com/dmsc/tbxl-parser/releases) to generate lines up to the 256 byte limit, and include arbitrary data inside strings.

[pirx]

basicParser is the real godsend and dmcs is a god of 10 liners.

[dmsc]

Hi!

 

The red warning appears only in PUR-80 category.

 

 

About the new FREI category, I'm thinking to submit a machine language game to the contest. Atari BASIC can load about 2K of binary data. You probaly could get larger binaries in other BASIC flavors. Is this fair for a BASIC contest? I think not. Anyway, I'll test this.

Well, you can easily generate a BASIC file with an arbitrary "invisible" payload. See the attached file: fract.bas

 

The program can be listed and saved from BASIC, without loosing the "special" code:

 

 

The program has 605 bytes hidden. Try it!.

[vitoco]

About the new FREI category, I'm thinking to submit a machine language game to the contest. Atari BASIC can load about 2K of binary data. You probaly could get larger binaries in other BASIC flavors. Is this fair for a BASIC contest? I think not. Anyway, I'll test this.

 

I wrote a simple demo game in Atari BASIC I'd like to be tested as an example or proof of concept for the FREI category.

 

As I said, it runs on XL/XE machines with in Atari BASIC ROM enabled. Just open and boot the attached ATR without OPTION key and then type RUN "D:DEMO.BAS" at the READY prompt. It takes almost a minute to initialize.

 

The source file in abbreviated form is DEMO.LST that can be loaded into Atari BASIC using ENTER "D:DEMO.LST" at the READY prompt. I didn't try it in TurboBasic XL, but I think it won't run there.

 

I said this is a proof of concept, not an actual submission... but, could it be accepted for FREI category if submitted?

demo.atr

[dmsc]

Hi!

 

I wrote a simple demo game in Atari BASIC I'd like to be tested as an example or proof of concept for the FREI category.

 

As I said, it runs on XL/XE machines with in Atari BASIC ROM enabled. Just open and boot the attached ATR without OPTION key and then type RUN "D:DEMO.BAS" at the READY prompt. It takes almost a minute to initialize.

 

The source file in abbreviated form is DEMO.LST that can be loaded into Atari BASIC using ENTER "D:DEMO.LST" at the READY prompt. I didn't try it in TurboBasic XL, but I think it won't run there.

 

I said this is a proof of concept, not an actual submission... but, could it be accepted for FREI category if submitted?

Very good. We could have a "best abuse of the rules" category.

 

Look at this: game.bas , or in an ATR: game.atr

 

Boot into Atari BASIC, load with LOAD "D:GAME.BAS" and type RUN, like this: