Threaded Mode | Linear Mode

ThomasF · 05-11-2023, 02:57 PM

Sorry if I was unclear.
I was thinking about rows and columns in the ASCII table.
Ie look at this one. Rows are the lower 4 bits of the character code, and columns the upper 3 (or 4) bits. And with bit 6 failing, column 4-7 are unreachable, just as the problem seems to indicate.

The "Line 4 Column: 21" is the text on your screen-shot if I "decode" it correctly. Maybe that is the current cursor position when you are writing on the screen (you added some lines with characters).
I was just trying to prove that this also indicates that the problem really is with bit 6, since that makes more sense then the "garbage" on the screen ...

Cheers,
Thomas

Jeff_Birt · 05-11-2023, 05:25 PM

Ah, the 'row' and 'column' nomenclature will only work if the ASCII table is laid out exactly as the one you referenced. It is a very unusual way to describe but makes sense given the reference you were using.

A more generic way is to refer to the upper or lower nibble (4 bits) of the byte. Other languages may use a different term than nibble but it is much more universal.

Non the less I think you probably were on the right track with the data latch. We'll see what the OP finds.

ThomasF · 05-11-2023, 05:39 PM

(05-11-2023 05:25 PM)Jeff_Birt Wrote: Ah, the 'row' and 'column' nomenclature will only work if the ASCII table is laid out exactly as the one you referenced. It is a very unusual way to describe but makes sense given the reference you were using.

Well, it was the first ASCII table I found on Wikipedia, also being a MIL-STD ... ?

Seeing it that way also makes it very easy to understand what happens when that bit is erroneous, not as obvious looking at a normal 8-bit table ...

Good luck with the machine, I hope you find something!

Cheers,
Thomas

Jeff_Birt · 05-11-2023, 06:02 PM

It is not my machine, I'm just making suggestions like you.

ThomasF · 05-11-2023, 07:34 PM

Ah, sorry for that! Should have read more carefully!
Let's hope the original owner gets some use of the tips we provide!

Cheers,
Thomas

dave-in-kc · 05-11-2023, 08:11 PM

I pulled the board and U11, U12, U23, U24 all look ok but I re-soldered them anyway. No luck.
Just to be clear, the example I posted earlier was of me typing each key twice. as in:
11223344...
qqwweerr...
aassddff...
zzxxccvv...

I reposted that photo with my typing (surrounded by a red box).

On a different note, I'd like to post some directions for display removal and some photos of the boards. Would 'general forum' be a good place?

agarza · 05-11-2023, 11:08 PM

It seems that the problem is the keyboard (alternating between two buttons), and not the display.

Can you use the serial port to display what is been pressed?

dave-in-kc · 05-11-2023, 11:13 PM

But what about the display before I even type anything? Everything displayed is jumbled (menu, boot messages, etc).
I don't know how I'd use the serial port?

agarza · 05-11-2023, 11:21 PM

(05-11-2023 11:13 PM)dave-in-kc Wrote: But what about the display before I even type anything? Everything displayed is jumbled (menu, boot messages, etc).
I don't know how I'd use the serial port?

I'm not familiar with the HP110, but I guess you could connect a serial printer or a serial terminal (Windows/Mac/Linux).

ThomasF · 05-12-2023, 06:18 AM

(05-11-2023 08:11 PM)dave-in-kc Wrote: Just to be clear, the example I posted earlier was of me typing each key twice. as in:
11223344...
qqwweerr...

Yes, I think it is very clear that it is every second character that is garbeled (char = char & 0xBF - ie bit 6 is clear).
Applying the same transformation on the top 2 lines, we can see that it says (so again confirming your findings):

Code:

MEMOMAKER

Line: 4 Column:21 Length

What is strange is that the background of the top 2 lines should be solid black (inverted), but starting with character at position 3 (if first is position 0, ie pos 3,11,19,27,...), the character is not inverted, and this then repeats with every 8 characters.
But, there is probably some ESC-sequence written to invert the display so we don't know exactly what and when it is actually sent to the display.
This might also explain why the "A" in MEMOMAKER is strange. It is shown as 0xB0 ("upperline"), but should have been 0x01 (SOH) since the actual character is 0x41.

I still think that the 16-bit to 8-bit latches are the most obvious cause to the problem, but it is easy for me to say Wink

Would need an logic analyzer or oscilloscope and look at data coming in and out from the latches since the pins and soldering looks ok.

Cheers,
Thomas