In fact, OS 2.71MP almost became a reality with Boot 1.03)

By the way, what is the aim of the boot code 1.0.3 ? It blocks people to MP OSes but why ?
On Nspires the protections prevent people from using native code but on z80s, we still can use native code even on MP OSes (with some bugs) so what is the goal ?

Quote from: Hayleia on November 29, 2012, 12:42:23 pm

There are some image to hex converters lying around, including SourceCoder on Cemetech

How do I use it to convert it to hex? Will it read Axe sources well?

Have it parse a png file. Note that this png should only have shades of grey (no pink, etc) if you don't want random results.
As for it reading Axe sources, I never tried, I only use it for converting images
I guess that it will manage to open it, but custom Axe tokens won't be displayed well (like Data being ΔList, etc).

That looks great...

You must run the program under DCS7, since it uses the AxeDCS axiom by me for the GUI stuffs.

...but seems like I won't be able to try it

(offtopic, is it normal to have post ratings disabled on this topic ?)

Anyway, this is great to see an update on this project, even a "tiny" one. It shows that even if you don't have a lot of time, you did not discontinue it completely

Hi, Welcome to the forums, have some
Yeah, Kerm's book is great to learn Basic and also introduces ASM (afaict) but he "forgot" to tell about Grammer an Axe in his book, so before you buy anything, I'd recommend you to look at those languages a bit

Or do that, using hex code:
[0000000000000000000000007FFFFFFFFFFFFFFFFFFFFFFE4000004000000000000000024E00004000000000000000025B00004000000000000000025100004000000000000000025B00004000000000000000024E00004000000000000000024000004000000000000000027FFFFFC000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000024000000000000000000000027FFFFFC01FFFFF00000000024000000000000100000000024000000000000100000000024000000000000100000000024000000000000100000000025FC0000000000100000000025040000000000100000000025040000000000100000000025040000000000000000000025040000000000000000000025040000000000000000000025040000000000000000000025040000000000000000000025FC0000000000000000000024000000000000100000000024000000000000100000000024000000000000100000000024000000000000100000000024000000000000100000000027FFFFFFFFFFFFFFFFFFFFFFE40008001000200040000000240008FF903020024000000024FF88AF93FCA3C44000000024FF09C013FFAFFF4000000024E0098013282EE44000000024C00980104420C24000000024C00900100020C04000000024000900100020004000000024000800100020004000000024000800100020004000000024000800100020004000000024000800100020004000000024000800100020004000000027FFFFFFFFFFFFFFFFFFFFFFE000000000000000000000000]->GDB1
Copy(GDB1,L6)
Now, I won't let you with that solution without explaining how it works, that won't help you in the long term

First of all, notice that your screen has a width that is a multiple of 8 (96=8*12). This is because it is not only composed of pixels, but is (behind the scenes) composed of bytes. Those bytes are pointed by L6.

Now, try to do that (where "pi" is the pi token, not pi in lowercase):
   ClrDraw
   pi11111111→{L6}
   DispGraph
You'll see a line of 8 pixels on the top left corner of the screen.
This is because you set the first 8 bits of "the screen" as black.

Now, try this:
   ClrDraw
   pi11000011→{L6}
   DispGraph
You'll see 2 black pixels followed by 4 white ones followed by 2 black ones, still in the top left corner, according to the bits you set to black.

Now, try this:
   ClrDraw
   pi11000011→{L6+1}
   DispGraph
You'll see the same pattern as the previous one, but not on the top left corner, there will first be 8 white pixels. This is because you did not set the first byte of "the screen" but the second byte, so the first byte is white, untouched, and the second one has the pattern.

Now, try this
   ClrDraw
   pi11000011→{L6+12}
   DispGraph
Still the same pattern but not in the first line: in the second line of bytes, because as I said, 96=8*12, so the 12^th byte of "the screen" is the first one of the second line.

---

I guess you understood all so now how does my code work ?
Well I put in the hex code the values of each byte of "the screen" and I copy them to the screen. To easily get those values, you can draw the image on Paint and convert it to hex code using SourceCoder

---

By the way, since there is a lot of white space in your image, I guess that you could in fact only use hex code for the bottom and use another way to draw the top part of it (using lines or rectangles or anything else).

This sounds pretty cool! Maybe you could also do stuff like set program on ram clear or at startup if you know what i mean

zStart can already do this
Or maybe I misunderstood the question ?

Quote from: Hayleia on November 27, 2012, 12:57:04 pm

Are you going to make the label menu support up to 13 characters, as the new Axe version allows it ?

I don't know if it is a good idea or a bad one, since there won't be a lot of label columns on the screen if you support 13 chars, and I don't know if people will really use more than 5 chars
In fact, I think I'll only use 13 characters in my label if zStart supports it

Definitely no. This would totally break the way that I store them and I would only be able to support like 51 labels. (As opposed to 109).

Ok
But if I use a label with 13 characters, it will still appear in the menu, just only with its 5 first letters, right ?
Because I plan to use 5 chars in my main labels (to keep them compatible with the menu, and I don't need more anyway) but maybe more in some subroutines that need explicit names.