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 checksum
- Keyboard input logic
- DRAGON.DO encoded image strings
If I remove the printscreen code, keyboard scan logic and progress bar
logic, the size reduces to 1488 bytes.
Ken
On 12/15/22 11:39 AM, Peter Vollan wrote:
so what is the .BA file?
On Thu, 15 Dec 2022 at 11:19, Ken Pettit <[email protected]
<mailto:[email protected]>> 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 relative to BASIC.
2. It provides a level of image compression similar to Linux
'xz' compression in most cases:
Full screen image (i.e. image size is 240 x 64 pixels):
dragon.do 825 bytes This is the APRAW encoding
dragon.ap 640 bytes AsciiPixels encoding
dragon.pbm.xz 628 bytes Linux xz compression
dragon.bmp 2178 bytes
dragon.pbm 1969 bytesOriginal non-compressed 1-BPP bitmap:
240x64 pixels / 8
pixels/byte = 1920 + header
Ken
On 12/15/22 9:20 AM, Cedric Amand wrote:
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
<[email protected]>
<mailto:[email protected]> a écrit :
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 to and
from the Model T.
