The DRAGON.BA file is 2098 bytes because it includes:
- APRAW encoded ML strings
- PRTSCR (print screen) encoded ML strings
- BASIC code to load the above 2 ML programs to ALTLCD and LCD memory
space
- BASIC progress bar printing to show ML load status
- BASIC code to validate the ML
Oh and I just realized, you would have to load a BMP file as a .CO since
it is raw binary data, and BASIC would have to access by manually
finding it's address in the MENU directory, then use PEEKs to read the
data since it is binary.
Ken
On 12/15/22 11:39 AM, Peter Vollan wrote:
so what is
so what is the .BA file?
On Thu, 15 Dec 2022 at 11:19, Ken Pettit wrote:
> Feasible? Yes. Slow? ABSOLUTELY!
>
> This is the reason I created AsciiPixels. It provides two main features
> critical to the M100:
>
>1. It is machine language graphics routines, so it is blazingly fast
>
I remember from my "demoscene era times" that bmp decoding is actually quite
simple. It might be feasible to decode a BMP in plain basic on a T100/T200
imho. Le 2022-12-15 10:12, VANDEN BOSSCHE JAN a
écrit : > > > > It might be difficult to code, but would a conversion to BMP
not be possible?
It might be difficult to code, but would a conversion to BMP not be possible?
Considering the never-changing nature of the Model T's screen (240x64,
monochrome) it shouldn't take too much place. Even if .BMP is a wastefull
standard, it would give an easy way to interchange screendumps and logos
Yes, it would be possible to write a "screendump" ML routine that
converts to BMP, but it surely wouldn't fit into ALTLCD's 320 byte code
space and would have to be a .CO file that is loaded somewhere in
HIMEM. A screendump could be useful for some applications I suppose.
Of course the BASIC
Feasible? Yes. Slow? ABSOLUTELY!
This is the reason I created AsciiPixels. It provides two main features
critical to the M100:
1. It is machine language graphics routines, so it is blazingly
fast relative to BASIC.
2. It provides a level of image compression similar to Linux 'xz'
