ROMWBW color sequences don't work about pigfx HOT 13 CLOSED

Hello
You are right about that the version which gets delivered with RC2014 is very old. They want do use a stable and well known release (which has lots uf bugs).
Could you figure out, what is getting sent in the moment this game screen is drawn? So I would be interested in the ASCII chars on the serial line. Maybe you could capture this by using a windows machine with putty as terminal.
There is a pigfx.txt which should be on the SD card. There are options to configure the behaviour of the enter key.

from pigfx.

I used putty to pull three separate instances of the system. There's the inital boot (when you hit the reset button), the CPM boot w/ dir command, and then the launching of the 2048 game.
romwbwboot.log
romwbwcpmboot.log
2048.log

I'll investigate the enter key issue. It shouldn't be complicated, but it is lol

from pigfx.

Thanks for the logs.
It seems that we have 2 problems. The first one is that the font on PiGfx is probably not what this game expects. I'll have to investigate the differences between the PiGfx versions.
The second problem is that PiGFX does not yet know the way this game uses colors. It's using this system:
[xx;yym
I think this would correspond to this table:
Set Attribute Mode [{attr1};...;{attrn}m

Sets multiple display attribute settings. The following lists standard attributes:

0	Reset all attributes
1	Bright
2	Dim
4	Underscore	
5	Blink
7	Reverse
8	Hidden

	Foreground Colors
30	Black
31	Red
32	Green
33	Yellow
34	Blue
35	Magenta
36	Cyan
37	White

	Background Colors
40	Black
41	Red
42	Green
43	Yellow
44	Blue
45	Magenta
46	Cyan
47	White

That would have to be implemented.

from pigfx.

Very very interesting. Ideally, I'd like to to work like it does with putty, but yeah, it is interesting to see how the old version worked (sort of) but the new one doesn't behave the same way.

I'll go run some other applications, like te.com and turbopascal to see if that formatting works as expected. I'll also try to get to the bottom of the enter key mystery.

from pigfx.

Okay, so I've done some investigating on the enter key issue.
I found that I got the same outputs when I enabled sendCRLF or replaceLFwithCR or with both disabled.

When I used TE.COM (a text editor) I was able to see what the enter key actually output. If I just hit ENTER to do a newline like normal, it put me into the save file option. If I hit ENTER instead of characters to name the file, I got these characters (one per key strike):

So that was a bust. I then tried running turbo pascal, because it uses bold characters to denote menu options. Although its really hard to see, I think the formatting here is correct:

So that's not a worry.

I then tried running mazezam.com. This is a tricky one. There aren't any special characters printed to the screen, but it uses sequences to move characters around the screen without a full blanking, much like Ladder does.

However, there's this quirk to it (I don't really know the reason) but mazezam and Ladder work only if I run the catchum.com configure utility and set it to option 7, a vt-52 terminal. This makes the mazezam game run correctly in Putty.

So, I wanted to know if existing bugs were fixed, I know someone had issues running Ladder before. So I opened up the utility...and chose option 6... and hit enter...

but all I got was the same screen again, as if I entered something that it didn't recognize. I got this behavior with both pigfx.txt options, too.

from pigfx.

I finally figured out that me hitting the Enter key on my keyboard sends the character 0x0D

from pigfx.

What gets sent on hitting enter is configurable in pigfx.txt
Enter Key can send either CR, LF or even both.
0x0D is CR.

from pigfx.

I just implemented the missing escape codes for selecting colors. It's in the develop branch. Feel free to give this a try. I sent your 2048 log to PiGFX. This is the result:

from pigfx.

Thanks a bunch! I'll check this out this evening/tomorrow and let you know how it goes. This is totally awesome!

from pigfx.

So I tested out the new image just now, and aside from the colors looking darker than their traditional ansi counterparts, the colors and cursor work so far!

I did a bit of a deep dive into what is going on with the enter key. I wrote up a cp/m program that spits out what's on the serial buffer (keypresses). I have it attached if you want to test it out.

I found that no matter what combination of sendCRLF and replaceLFwithCR options I set, it ALWAYS sends a LF with a mystery character:

I can set either to 1 or both to 1, same result every time. When I run the program over normal serial, I get 13 (0x0D)
CHARTOOL.zip

from pigfx.

Are you capturing the data on the TX pin of the Pi?
I just tested the output of my Pi.

If sendCRLF = 0 and replaceLFwithCR = 0, I get 0x0A.
If sendCRLF = 0 and replaceLFwithCR = 1, I get 0x0D.
If sendCRLF = 1 and replaceLFwithCR = 0, I get 0x0D 0x0A.

You can also check the output of the Pi by connecting it to a windows terminal like Putty. Putty can display and log what gets sent by the Pi. The Pi always sends the same output to any connected device. Take care not to bring 5V to the Pi pins.

from pigfx.

I'm capturing the data coming into the z80 on its own rx/tx port. Interestingly enough, if I press CTRL-m, it sends a 0x0D and works as an enter press.

from pigfx.

As the main purpose of this topic has been fixed as far as I can tell, I will now close this topic.

from pigfx.