Log In  

Hello.

As I'm experimenting with 8-bit compression, I came across an anomaly that I feel deserves some attention.

Try this code:

cls()
a=chr(6)
b="⁶"
?ord(a)
?ord(b)

I created the ⁶ by typing in immediate mode, printh(chr(6),"@clip") and then in the source-code pressing CTRL+V.

My question is how can BOTH of these be the same character and - is this an error of some kind ?

Because if you type out in immediate mode, print(chr(6)) you won't get that symbol back. You can only get that symbol if you use printh()

Because if for some reason this is correct, it means that you are NOT saving a single byte per character in your source-code, that you are in fact using an extended unknown set to create that special character of 6, yes ?

The bug is this. You cannot get a visual for printing a character < ASCII of 16, however you CAN if you transfer it solely to the clipboard and then use CTRL+V. There is still no way to print it. It should appear either way you access it for output or at least give you an option of doing so with an obscure poke() or direct extcmd().

It would also be useful to have total access of 256-characters in a string. Use LENGTH of string for storage instead of locking out chars #0, #9, #10, and #13 which cannot be included even via printh() This is just something requested though, it is not a bug.

The extra characters could appear like this:
[24x8]

It would also allow you to use quote " and backslash. So the string itself would be pretty special. Maybe a new command:

data=rawstring("all kinds of characters.")
printraw(data)

It would require " and ) on the end and likely giving the string length at the front of the definition in memory and you could not use .. or anything else to add to it on the END lest it be accidentally thought of as more 8-bit string for data. Yet the unprintable characters would be completely allowed, #0-15, #34, and #92 allowing true 8-bit storage to a string on a single programming line.

So, let's see. You could have this:

pet = rawstring("dog")
memory: p=112, e=101, t=116, ==61,
(2-bytes for command type, in this case, `rawstring`),
3 (number of bytes in this string), d=100, o=111, g=103.
No CR or zero to denote end, the length in bytes was
already given so we are done with this single
programming line.
P#122442 2022-12-15 02:32 ( Edited 2022-12-15 19:08)

AFAIK that's correct.
Please see: https://pico-8.fandom.com/wiki/P8SCII

Character number #6, is the symbol . You are encoding it as a string in both a and b.

P#122445 2022-12-15 02:43

Hi @aced.

Then let me ask, when you have that 6 in your code, is it counting as a single byte ? And if so, from where ? And why isn't when you print chr(6) show that same character ?

They both can't be correct because that would mean somehow source-code is actually using 2- or more bytes per character of the 65536 total, and it is not registering.

P#122446 2022-12-15 02:45 ( Edited 2022-12-15 02:46)

. . .

Well now wait a minute. If you try this: a="⁶"

And then print(ord(a)) you will get back 6.

However, if you print that afterwards, print(a) you do not get it.

So ... I guess this is a bit of a shortcut for your source-code to have that ⁶ in it, however there is no way to reproduce or even print it out later.

If you do a="⁶" and then print(a) you won't get anything back.

So it can only be created inside of printh() and even then it will only appear in immediate mode or your source-code from CTRL+V. There is NO WAY at all to have it appear during runtime in any capacity.

That itself might be useful for later, @zep. To have a POKE() or EXTCMD() that will display the extended set when you use PRINT() for it.

P#122451 2022-12-15 03:16

we already have https://www.lexaloffle.com/bbs/?tid=38692 to encode non-printable bytes (which are also interpreted as control codes by print).
it doesn’t make sense to want to print unprintable bytes!

P#122461 2022-12-15 07:33

alternate option to print fancy glyph is the custom font (either via p8scii or upload to memory), but yes, need to redraw the little figures 🤷‍♂️

P#122462 2022-12-15 08:42

what do you mean by: custom font via p8scii?

and I don’t see how that would help: it’s print that interprets these bytes as unprintable control codes, so it does not matter if the font has glyphs.

P#122477 2022-12-15 16:47
1

sure - proposal is to print “6” (regular \056) using a custom glyph.

P#122479 2022-12-15 17:32

Yep, @merwok. @freds72 totally got what I want. :)

Just not print nothing.

So you get this:

Cause currently ^^ this does not work. That's me using spr() to show what it will look like when it does work.

I did something similar to this for my ASCII chart:

https://www.lexaloffle.com/bbs/?pid=100125

If you look in the Spritesheet there, you will see that I drew what characters are not seen below ASCII 16:

[64x8]

How about it, @zep ?

P#122481 2022-12-15 17:42 ( Edited 2022-12-15 19:08)

If I understand what you're asking, it's not a bug- it's an enhancement request.
These special characters aren't printable in ASCII.
Also null / /0 may not be possible- as it has a very special meaning on most computing systems...

P#122485 2022-12-15 18:56

Alright @aced just for you I'll change it back. Wow.

But yeah at least to me to be able to set one thing one way and then to display it back and get completely different results - sure, let's call that an enhancement.

And yes I understand chr(0). Yet it =IS= still possible for a string to contain chr(0), so it should also be possible in source-code using the method I described in the first post, counting characters rather than looking for 0, 10, or 13.

t=""
for i=1,8 do
  t=t..chr(0)
end
?#t

8

Now obviously if you copy a string to say clipboard that contains true zero or what have you, then yeah, then it won't work correctly. I understand that. I just want 8-bit string data and the ability to enter it via a single line in Pico-8.

Although to date ZEP has been using special glyphs to represent special characters so I imagine 0, 10, and 13 can also be glyphed, making all that code once again able to be copied to Notepad or what have you.

⁰ ᵃ ᵈ

And you are correct, @aced, in the sense of not printing out these characters.

As always I appreciate all input on the subject. Sometimes I get frustrated trying to figure out things the way they are - and I apologize if that gets reflected in my writing ...

Even the old programming languages wouldn't let you display these characters. In this case I POKED directly into the screen to get it.

Yet I still maintain that it would be useful to get a match so it is displayed in Pico-8 not just for pasting clipboard but in PRINT().

P#122486 2022-12-15 19:08 ( Edited 2022-12-15 20:03)

[Please log in to post a comment]