June 24, 2021 at 7:36 am #930kevinParticipant
I have the exact same Minicom as you. I can confirm (because I just tried it) that the “-8” switch is necessary; otherwise Minicom does weird things to charaters > 127. Incidentally — sorry if my laziness made this unclear — the “…” in my previous note was supposed to be short for “all the rest of the minicom arguments”.
What I’m actually running is more like
minicom –colour=on -b 230400 -D /dev/ttyUSB0 -8
You’ll see I have reduced the baud rate, at both the Z80-PG and the Minicom end. I had to do that, because otherwise the Z80-PG could output characters faster than the Linux console could render them — particularly where line scrolling happened.
That makes me wonder whether you could have a similar problem? I wonder also if the serial communication method you’re using could also be messing about with the data flow? I’m only using USB because the hardware was already there, and I couldn’t be bothered to construct a level changer. But I wonder if there are other benefits (related to buffering, for example)?
KevinJune 24, 2021 at 9:11 am #931johnwParticipant
I’m actually using 115200 baud so that should be OK.
As the pi zero only has 1 usb connector, are you using a usb hub to connect both the Z80 and a keyboard?
I am going to try a complete re-install of raspbian to see if that cures the problem.
JohnJune 24, 2021 at 10:43 am #932kevinParticipant
Yes — I’m using a USB HAT like this:
I toyed with using proper UART-to-UART connection, but it just seemed easier to spend the eight quid or whatever it was, to get a USB connection. It’s not very elegant, of course — a pointless conversion from USB to serial and back again annoys me. But it’s a more-or-less soldering-free solution, which matters when your eyesight is a crappy as mine.
It’s plausible that the Raspbian start-up procedure does something odd with the console or the UART. I’m happy to plunder the Raspbian repository for binaries, but Raspbian itself seems like a brutal thing to inflict on such an underspecified hardware platform, so I don’t use it.
KevinJune 26, 2021 at 2:13 pm #933johnwParticipant
I was doing some digging around and came across this in the manual page for setfont:
“If the console is in utf-8 mode (see
unicode_start(1)) then the kernel expects that user program
output is coded as UTF-8 (see utf-8(7)), and converts that to
Unicode (ucs2). Otherwise, a translation table is used from the
8-bit program output to 16-bit Unicode values.”
My installations have always defaulted to utf-8, and this seems to say that the kernel will do an automatic unicode translation regardless of any tables. So I tried changing the console to iso8859, and voila, it works!!
Thanks for all your suggestions.
- You must be logged in to reply to this topic.