Jump to content

Photo

BASIC Ten-Liners are back for 2018!


108 replies to this topic

#1 slx OFFLINE  

slx

    Stargunner

  • 1,434 posts
  • Location:Vienna, Austria

Posted Fri Jan 26, 2018 12:30 AM

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.



#2 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Fri Jan 26, 2018 2:19 AM

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?

#3 slx OFFLINE  

slx

    Stargunner

  • Topic Starter
  • 1,434 posts
  • Location:Vienna, Austria

Posted Fri Jan 26, 2018 2:34 AM

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.



#4 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Fri Jan 26, 2018 3:01 AM

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 ?



#5 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,627 posts
  • Location:Australia

Posted Fri Jan 26, 2018 3:36 AM

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.



#6 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,627 posts
  • Location:Australia

Posted Fri Jan 26, 2018 3:44 AM

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.



#7 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Fri Jan 26, 2018 3:47 AM

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 by VladR, Fri Jan 26, 2018 3:49 AM.


#8 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,627 posts
  • Location:Australia

Posted Fri Jan 26, 2018 5:43 AM

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.



#9 vitoco OFFLINE  

vitoco

    Moonsweeper

  • 286 posts

Posted Fri Jan 26, 2018 6:54 AM

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?  :-o

 

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

 



#10 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 3,987 posts
  • Location:10-0-11-00:02

Posted Fri Jan 26, 2018 12:29 PM

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 by _The Doctor__, Fri Jan 26, 2018 12:31 PM.


#11 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Fri Jan 26, 2018 1:58 PM

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.



#12 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,627 posts
  • Location:Australia

Posted Fri Jan 26, 2018 8:00 PM

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.



#13 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Fri Jan 26, 2018 8:27 PM

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

 

 



#14 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,627 posts
  • Location:Australia

Posted Fri Jan 26, 2018 8:48 PM

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.



#15 VladR OFFLINE  

VladR

    Stargunner

  • 1,319 posts
  • Location:Montana

Posted Fri Jan 26, 2018 10:13 PM

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.



#16 erichenneke OFFLINE  

erichenneke

    Moonsweeper

  • 342 posts
  • Location:USA

Posted Sat Jan 27, 2018 1:06 AM

 

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

 

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

 

 

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. 



#17 slx OFFLINE  

slx

    Stargunner

  • Topic Starter
  • 1,434 posts
  • Location:Vienna, Austria

Posted Sat Jan 27, 2018 1:46 AM

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 by slx, Sat Jan 27, 2018 2:04 AM.


#18 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • 1,890 posts

Posted Sat Jan 27, 2018 8:08 AM

 

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

 

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

 

 

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?



#19 vitoco OFFLINE  

vitoco

    Moonsweeper

  • 286 posts

Posted Sat Jan 27, 2018 8:29 AM

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



#20 vitoco OFFLINE  

vitoco

    Moonsweeper

  • 286 posts

Posted Sat Jan 27, 2018 9:39 AM

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



#21 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 378 posts
  • Location:Viņa del Mar, Chile

Posted Sat Jan 27, 2018 11:50 AM

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/d...parser/releases) to generate lines up to the 256 byte limit, and include arbitrary data inside strings.

#22 pirx OFFLINE  

pirx

    Moonsweeper

  • 423 posts
  • Location:Poland

Posted Sat Jan 27, 2018 4:31 PM

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

#23 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 378 posts
  • Location:Viņa del Mar, Chile

Posted Sun Jan 28, 2018 10:03 AM

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


Well, you can easily generate a BASIC file with an arbitrary "invisible" payload. See the attached file: Attached File  fract.bas   732bytes   30 downloads

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

fract.png

The program has 605 bytes hidden. Try it!.

#24 vitoco OFFLINE  

vitoco

    Moonsweeper

  • 286 posts

Posted Sun Jan 28, 2018 10:09 AM

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

 

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?

Attached Files

  • Attached File  demo.atr   90.02KB   33 downloads


#25 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 378 posts
  • Location:Viņa del Mar, Chile

Posted Sun Jan 28, 2018 11:24 AM

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: Attached File  game.bas   16.14KB   29 downloads , or in an ATR: Attached File  game.atr   130KB   35 downloads

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

game.png




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users