Logiker's Vintage Computing Christmas Challenge 2022

[carlsson]

Maybe he won't submit an entry, just posting here how far he has come. For that matter, I was thinking of bit patterns too but found an even shorter solution that should work on nearly every BASIC dialect, I think.

[reifsnyderb]

1 hour ago, _The Doctor__ said:

you are not supposed to be discussing what your size is or any that, you rule breakers you!

If you keep complaining, I'll post the source code for my longer version.   😜

Edited December 6, 2022 by reifsnyderb

[reifsnyderb]

1 hour ago, TGB1718 said:

Interestingly, this latest version although smaller on disk when LISTED

is 290 Bytes when SAVED

and 288 Bytes when FRE(0) is used, very close the the SAVED version

 

I've noticed that if I make the program smaller on the disk it's larger in memory and if it's larger in memory it's smaller on the disk.  But this is the first time I really worried about saving a single byte.  🙂

 

 

[reifsnyderb]

Well, I just realized that if I made a very minor change that my program could lose another 2 bytes.  It's done.    😁

 

It just lost another 7 bytes, in memory, as well.

[_The Doctor__]

remember your only and hour and 17 minutes away from work! If gas weren't so d*mned expensive, I'd buy some of your creations and and save a few bytes. heh

[carlsson]

3 hours ago, reifsnyderb said:

I make the program smaller on the disk it's larger in memory and if it's larger in memory it's smaller on the disk

The ways of the Atari are inscrutable!

[+MrFish]

Alright, I've been following this thread and messing around in TBXL.

 

I've got a listed version at 179 bytes; and it's centered, with no cursor or "READY" prompt.

 

 

 

If I leave a cursor in the upper-left, but still no "READY" prompt at the end, I can shave off 4 bytes; so, 175 bytes total.

 

 

[TGB1718]

28 minutes ago, MrFish said:

Alright, I've been following this thread and messing around in TBXL.

Wouldn't TBXL be classed as machine code as it's compiled ?

 

I can't get TBXL to run, it always hangs on Altirra, never tried on real hardware

Edited December 6, 2022 by TGB1718

[+MrFish]

Just now, TGB1718 said:

Wouldn't TBXL be classed as machine code as it's compiled ?

I'm playing in interpreted mode, which is like the Atari BASIC interpreter.

 

Just now, TGB1718 said:

I can't get TBXL to link, it always crashes on Altirra, never tried on real hardware

I assume you're talking about code that compiles and runs fine; but then won't link?

I haven't had any problems linking so far; although, I've only used it on a few programs.

 

[reifsnyderb]

18 hours ago, MrFish said:

Alright, I've been following this thread and messing around in TBXL.

 

I've got a listed version at 179 bytes; and it's centered, with no cursor or "READY" prompt.

 

If I leave a cursor in the upper-left, but still no "READY" prompt at the end, I can shave off 4 bytes; so, 175 bytes total.

 

How much does TBXL vary from Atari BASIC?  I am assuming it allows for smaller code?

[+MrFish]

15 minutes ago, reifsnyderb said:

How much does TBXL vary from Atari BASIC?  I am assuming it allows for smaller code?

TBXL is fully compatible (with a very few minor exceptions) with Atari BASIC. It basically takes Atari BASIC, adds 42 new commands and 22 new functions, and provides more free memory than Atari BASIC. It also speeds up interpreted code 3 times Atari BASIC's speed, and speeds up compiled code 10 to 15 times the speed of Atari BASIC. TBXL auto indents loops and structures, is case-insensitive, and allows 256 variable names (up from 128 in Atari BASIC).

 

Smaller code comes from utilizing TBXL commands and functions not available in Atari BASIC. I rewrote my TBXL program to run in Atari BASIC; but the quirkiness of trying to implement, in Atari BASIC, one command I used in TBXL ended up making the program 291 bytes (compared with 179 in TBXL).

 

[reifsnyderb]

5 minutes ago, MrFish said:

TBXL is fully compatible (with a very few minor exceptions) with Atari BASIC. It basically takes Atari BASIC, adds 42 new commands and 22 new functions, and provides more free memory than Atari BASIC. It also speeds up interpreted code 3 times Atari BASIC's speed, and speeds up compiled code 10 to 15 times the speed of Atari BASIC. TBXL auto indents loops and structures, is case-insensitive, and allows 256 variable names (up from 128 in Atari BASIC).

 

Smaller code comes from utilizing TBXL commands and functions not available in Atari BASIC. I rewrote my TBXL program to run in Atari BASIC; but the quirkiness of trying to implement, in Atari BASIC, one command I used in TBXL ended up making the program 291 bytes (compared with 179 in TBXL).

 

Ok.  That clears it up considerably.  I sort of figured there was some new command used.  I am using Atari BASIC Rev. C.  Yesterday, I figured out how to reduce the code by another 40 bytes or so as listed to disk.

[+MrFish]

On 12/6/2022 at 4:28 PM, MrFish said:

Alright, I've been following this thread and messing around in TBXL.

 

I've got a listed version at 179 bytes; and it's centered, with no cursor or "READY" prompt.

 

If I leave a cursor in the upper-left, but still no "READY" prompt at the end, I can shave off 4 bytes; so, 175 bytes total.

I've got my TBXL listed files down to 145 bytes and 141 bytes, respectively, now.

 

I think I'm near the end of optimizations.  

 

[reifsnyderb]

I was looking at the rules a little more and saw this:

 

Hardware:

  Use any machine you like, preferable vintage computers;)

  Make the size of the program file (e.g. PRG on C64) as small as possible 

  Don't manipulate the file (e.g. truncating the last bytes, changing the start address, etc.)

 

How would you manipulate the file and still have it work?

[carlsson]

For instance if a C64 BASIC PRG ends with three bytes 0,0,0 where the first indicates end of previous line, and the next two bytes is a pointer to the next line but if if it is 0, it means the program has ended. In theory, the RAM might already be partly initialized to 0 when you power on the computer so you could trim away at least the last two bytes and hope that there will be zero bytes in memory after the program loaded. It might as well be 255,255 and then you're screwed unless you have an END statement or something. It would give strange results if you start to edit the program too.

 

That would be one example of manipulation. I don't know how you do it on the Atari since you've been discussing various ways to save or list BASIC programs to disk, but as long as all methods are standardized, I suppose either is fine.

 

Remember you can use any language so you might want to try Mad Pascal, some cc65 or whatever language you have. I suppose still it is the size of the executable that matters. For BASIC it can be relatively short thanks to the built-in interpreter (unless you're using a compiled language) and for assembly language it already is optimized machine code. For other languages I believe the compiler overhead will be too much for this challenge. Also remember it is mostly for fun, there is not even given there will be a prize.

 

I'm more toying with the wild and creative aspect. What can you do with Christmas theme, can you make something more out of the star than just plotting it as seen on the screen?

[reifsnyderb]

4 minutes ago, carlsson said:

For instance if a C64 BASIC PRG ends with three bytes 0,0,0 where the first indicates end of previous line, and the next two bytes is a pointer to the next line but if if it is 0, it means the program has ended. In theory, the RAM might already be partly initialized to 0 when you power on the computer so you could trim away at least the last two bytes and hope that there will be zero bytes in memory after the program loaded. It might as well be 255,255 and then you're screwed unless you have an END statement or something. It would give strange results if you start to edit the program too.

 

That would be one example of manipulation. I don't know how you do it on the Atari since you've been discussing various ways to save or list BASIC programs to disk, but as long as all methods are standardized, I suppose either is fine.

 

Remember you can use any language so you might want to try Mad Pascal, some cc65 or whatever language you have. I suppose still it is the size of the executable that matters. For BASIC it can be relatively short thanks to the built-in interpreter (unless you're using a compiled language) and for assembly language it already is optimized machine code. For other languages I believe the compiler overhead will be too much for this challenge. Also remember it is mostly for fun, there is not even given there will be a prize.

 

I'm more toying with the wild and creative aspect. What can you do with Christmas theme, can you make something more out of the star than just plotting it as seen on the screen?

I guess a self-extracting executable is out, then?   

 

I am still working on a compact file.  I might have to load up TBXL, though.  😕

 

Maybe I should submit an Atari BASIC version and a TBXL version?

 

I think somebody would be hard-pressed to get an Atari BASIC file smaller than what I am working with, though.    🙂

 

A lot of languages would have a compiled program that is too big because of the libraries.  With BASIC, you are really leveraging the BASIC functions and not being concerned about how big they are.  So, really, your "file size" is over at least 8k...if we were counting the ROM.  My guess is that the smallest program might be pure assembly because you would leverage the hardware.  I am not sure if assembly could get the program under 141 bytes, though...

 

[+MrFish]

53 minutes ago, MrFish said:

I've got my TBXL listed files down to 145 bytes and 141 bytes, respectively, now.

Shaved 4 more bytes off of each one...

 

[reifsnyderb]

Ok.  I just trimmed another 44 bytes off of the Atari BASIC R. C. version.  I doubt anyone can get it smaller in Atari BASIC R. C.    🙂

 

[TGB1718]

I tried TBXL and tweaked my version, maybe I have to learn a little more about it's intricacies,

the FRE(0) test was smaller but on disk slightly bigger.

 

Using good old ATARI BASIC and BASIC XE I get the same results for FRE(0) and LISTED to disk. 

That's smaller on disk and obviously larger when in memory.

 

Don't think I can shave any more off. Unless I leave the cursor showing (save 19 bytes) but spoils the look.

Had an epiphany while writing this just saved 6 bytes on disk, same for FRE(0) though

 

[Wrathchild]

My assembler versions:

 

1st variant - < 130 bytes

2nd variant (clear cursor) - < 130 bytes (3 more than 1st)

3rd variant - < 140 bytes

Edited December 8, 2022 by Wrathchild
screenshot order

[reifsnyderb]

Ok.  Here's mine in Atari BASIC Rev. C.  The first file is the smallest and tightest.  The second file is 24 bytes larger and is centered with an invisible cursor and an infinite loop.  Both programs, as listed to disk, are less than 65,535 bytes.

 

 

[TGB1718]

46 minutes ago, reifsnyderb said:

Both programs, as listed to disk, are less than 65,535 bytes.

WOW less than 64K 🤣

 

Did you typo ??

[rensoup]

5 hours ago, Wrathchild said:

My assembler versions:

Cool, any chance that you could post the init code (not the challenge code) ? I'm guessing you don't have any graphics setup code and just rely on the A8 booting into gr0 ?

[Wrathchild]

32 minutes ago, rensoup said:

I'm guessing you don't have any graphics setup code and just rely on the A8 booting into gr0 ?

Indeed, there is no setup per-se. Except for clearing a cursor where I just use:

_MAIN:
    LDA #0
    LDY #2
    STA (SCRNPTR),Y

So yeah, launching from a DOS would probably could be problematic.

[TGB1718]

11 minutes ago, Wrathchild said:

So yeah, launching from a DOS would probably could be problematic.

Having a go at an assembler version, I'm putting a clear screen routine in just in case, if they run another

persons attempt before yours, there's no guarantee it will be clear.

getting close but will be over your 130 bytes by a little bit until I start to optimise the code, just

concentrating on getting it looking right first

 

Nearly there 128 bytes with clear screen in the code

Edited December 8, 2022 by TGB1718
Update