ROMWBW color sequences don't work

[ProgrammingCube]

I got a pi graphics card for the rc2014 and figured I could slap it in my z180 system. It works, mostly, but there were some issues.

1. I think that the image that came with the pi was specifically the rc2014, or at least an older version. The text was absolutely horrific to look at, and the colors didn't exactly work as expected. However, the colors did work in the sense they showed up. The attached pictures are from this stock, older image.

The first one is the included 2048 clone in romwbw. The second is the romwbw boot screen, and the last is the pigfx boot screen. An interesting note is that the graphic charaters for the 20480 clone seemed to have worked on the border, but not on the numberrs.

In addition, the wireless keyboard I was using didn't work with the older image. I had experienced this before, sub par usb compatibility and errors on the screen. I fixed it before by putting together a new sd card.

I used the master branch's bin folder and the latest bootcode.bin and start.elf, and I rebooted. I was greeted with a better looking screen:

So this was an improvement. Booting into cp/m seemed to work well too:

However, the 2048 game didn't look right. It at least was the right dimensions, but there was no color and in place of the solid blocks there were the codes for weird U thing:

There is another issue where the enter key seems to have a mind of its own. I hit ENTER and it seems to work, mostly, but I don't know what it's sending. Hitting ENTER in zde doesn't do a new line, it thinks I hit escape or something else, it switches me to the menu.

Any ideas on how to fix this?

[chregu82]

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.

[ProgrammingCube]

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

[chregu82]

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.

[ProgrammingCube]

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.

[ProgrammingCube]

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.

[ProgrammingCube]

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

[chregu82]

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

[chregu82]

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:

[ProgrammingCube]

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

[ProgrammingCube]

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

[chregu82]

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.

[ProgrammingCube]

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.

[ProgrammingCube]

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