Hearsay

Has anyone managed to get Hearsay working with SerialUSB? Connector works but the Ansi terminal has display problems – not too bad but it would be nice to have none – when logged on to a linux machine.

Hearsay working with SerialUSB?

How do you set it up for SerialUSB, I notice there has been a lot of changes in Hearsay since the last time I looked at it but no sign of USB options. (downloaded with !Store)

I altered !Hearsay.Library.!Serialdev. Near the end you have

setserialdev("Telnet",0);

changed that to

setserialdev("SerialUSB",0);

It seems to be reading a lot of things but not word format I messed around a bit faking values but still no luck. Without the manuals I’m just guessing.

Without the manuals I’m just guessing.

There is the Hearsay scanned manual available online, see here for more info (you need to read it very closely, no clickable link provided…):

http://www.heyrick.co.uk/blog/index.php?diary=20150101

But IIRC from configuring ArcFax and Hearsay from the early 90s, you did the right thing to configure it. So it might be a real code problem.

you need to read it very closely

Especially the big purple box saying you’re not using https. ;-)

https://www.heyrick.co.uk/blog/index.php?diary=20150101&keitai=0

I need a better clue than that. I don’t see any manual link and I don’t see it in the Hearsay zip file

need a better clue than that. I don’t see any manual link and I don’t see it in the Hearsay zip file

You can’t see the link as a link because it is not a link on the page but a typed link in a Hearsay window – a true “Rick special”.

https://heyrick.co.uk/random/hearsay_2_user_guide_raw.pdf

link
Here is my copy.
Afraid Hearsay doesn’t keep any settings here, something broken or missing.
I connected through the ftdi usb to Raspbian with Connector and SerialTerminal OK.
Has to be said, how handy and quick SerialTerminal just works.
I was expecting to find freeBSD on the pi zero but must have moved it. FreeBSD puts out the escape codes by default, The others I would have to look up to switch them on, but hearsay is a long way from working.

Thanks I’ve got it now.

SerialTerminal is handy for testing stuff – it has no expectations of the other end. But some things you can’t do in a taskwindow – an ansi taskwindow would be nice. I use my orangepipc for Linux – mainly use git – but only in server mode. I was using a modified serialterminal to link to it – gives me cursor editing – but using a task window was causing me problems. I just tried connector and that would be great if it wasn’t for the flaws in the Ansi driver. I fixed a few problems, oddly nano displays better in tmux than it does outside. htop seems much better.

I’m trying to figure out the easiest way to get a terminal either fix connector or get serialusb working on hearsay. Even if I got Hearsay working I’d like it to treat utf8 chars as a single character even if it is just a square block but I’d have to compile hearsay for that and it’s not obvious how on first glance. Has anyone compiled Hearsay?

a true “Rick special”.

Nah, just keeping true to the spirit of BBSs where you don’t have hyperlinks… ;-)

an ansi taskwindow would be nice

GraphTask and a slightly more advanced serialterm?

I’d like it to treat utf8 chars as a single character even if it is just a square block

Why not drop a quick email to David? There’s a part of me that suspects (though I reserve the right to be wrong) that the script language might be able to intercept bytes received, and translate UTF8 sequences into the character of your choice.

but I’d have to compile hearsay for that and it’s not obvious how on first glance. Has anyone compiled Hearsay?

First, you’ll need the XL bits. They go in $.XL, if I remember correctly. Then it’s a set of command line scripts to do the building.

I did start making a MakeFile, but never got the build set up as Hearsay’s swallowing of Ctrl-F12 hasn’t bugged me enough to want to fix it…yet.

The build process is described at the top of the page: https://www.davidpilling.com/wiki/index.php/Software
All the stuff I failed to read while looking at Ovation, but it’s for the better as Ovation is now a proper DDE-built app. With throwback and everything, whooo!

Dammit. I’ve defined XL$Path so the compiler can see XL:Tasks. as a path to follow. It can now pick up the “h.bbc” style #includes, but it’s continually failing in XL:Task.h.wos due to not knowing what wimp_palettestr is. I’ve added a direct #include to pull in XL:Task.h.wimp where it is defined, but it steadfastly refuses to ‘see’ it.

I sort of remember getting frustrated the last time I tried to get Hearsay to build the DDE way, and don’t feel like revising the code as much as I did for getting Ovation sorted.

Okay, I’ve patched together David’s command line process, and it builds, but fails.

h.zmodem and h.zmextra are missing.

There are many many more errors, but I suspect the majority are due to those files not being found. You know how C likes to throw wobblies and spit out screenfuls of gibberish as it gets more and more confused…

I’ve sent an email.

Not received. Try my ftpc address.

I thought I might get away with just writing a script file but unfortunately the swi function is rather limited.

Rick has pointed out I blundered with the Hearsay source, we’ll fix that asap. But I don’t understand why the serial block driver (setserialdev()) is not the end of the matter. If you have a good block driver Hearsay should use it with no problems. The whole idea of the block drivers was to put device dependent stuff outside applications.

As to character mapping, yes you can do that, much effort to allow that. Also you could do whatever you want inside the block driver.

When I wrote it I had not heard of UTF8 – probably not invented. Interesting to know what the terminal standard for UTF8 is. Not going to be called “ANSI”.

The linenoise library is only a few files, and has a discipline for receiving escape characters, but more interestingly the linenoise NG (next generation) has utf support. Not a bad reference.
Edit: I was heading in that direction for Debian Ash, until I found I
could just use kernel.h _kernel_swi to get to readline32.
Outputting would be a matter of the degree of output required. Graphtask may be the only app that allows full navigation around the window. Zap partly does, but I think it is better to stick with a raw display in the long run.
Possibly Hearsay would have less overhead for the job?

Found this… https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-VUVP/%5BMS-VUVP%5D.pdf

If you have a good block driver Hearsay should use it with no problems.

I agree and it does work with Connector. Part of the problem is probably that I wrote SerialUSB with a DeviceFS interface and Devices do different things natively. The block driver may have to jump through hoops to provide a blockdriver interface so there may be some feature used by Hearsay and not used by connector that is causing problems – though I don’t understand why reading the wordformat should fail.

When I wrote it I had not heard of UTF8 – probably not invented. Interesting to know what the terminal standard for UTF8 is. Not going to be called “ANSI”

No it’s probably called Linux. I only noticed the UTF8 because the login screen on my orangepipc uses Unicode for the temperature’s degree symbol.

edit: ah VT-UTF8 thanks Rick.

Coming to it from a different angle – does Nettle support serial comms? As a terminal emulator, it should come with everything else necessary for Colin’s use case.

I also remember a terminal emulation from Graham Shaw (of “RiscPKG, RTK, the replacement SharedCLib…” fame) with Kerberos support called “RiscTerm”, but it seems slightly dead…erm outdated.

http://source.riscpkg.org/websvn/listing.php?repname=RiscTerm

Colin – I understand more, but I am out of my depth – “word format”?. The file SerialDev is a Hearsay script language file and it should be possible to fake values or stop it reading things. I believe all Hearsay interaction with the block driver will go through that file, apart from the actual data streams.

SerialDev does look complicated through. 30 years later…

I’ve updated the Hearsay source on my website page (now complete).

word format: like 8 data bits 1 stop bit noparity.

SerialDev does look complicated through. 30 years later…

It certainly does. I haven’t found where you read the stream yet. I hope I can get it working without recompiling. I managed to get debug output from the serialdev script using reporter so thats good news. Preliminary findings appear to be no response from the driver. I need to work out how serialdev blockdrivers work now.

I can fake readings and the fake readings appear in the hearsay status line but it doesn’t help.

The block driver may have to jump through hoops to provide a blockdriver interface

If you’re using my SerialUSB blockdriver, I ought to point out that it was thrown together as a demonstration of making a blockdriver for SerialUSB.

though I don’t understand why reading the wordformat should fail.

Probably because I ballsed it up? I should point out that the driver is hardwired to 8N1. The reason why is explained in the help file. Y’all did read that, right? ;-)

https://www.riscosopen.org/forum/forums/12/topics/4069

Not going to be called “ANSI”

Nothing should be called ANSI, really. ANSI withdrew their standard when the ISO took it on.
Of course, talking about “ANSI graphics” is ubiquitous. And when Microsoft introduced a double-byte format (for East Asian languages), they called it ANSIW. Not sure how it works, but it’s in XP’s HyperTerminal.
It’s interesting to note that Microsoft are also the originators of the VT UTF-8 standard. Which is really weird given their lacklustre and halfhearted support for ANSI sequences in the terminal. I believe it’s only a very recent version build of Windows 10 that has support for ANSI colours in the terminal. You know, something Linux had sorted right back to the Slackware distro I tried in the mid ’90s.

does Nettle support serial comms?

No, Nettle is a telnet client.

I believe all Hearsay interaction with the block driver will go through that file, apart from the actual data streams.

My emphasis. ‘cos it’s the actual data stream that we want to be fiddling with. ;-)

SerialDev does look complicated through. 30 years later…

Not really. It’s a 4K wodge of code with some defined entry points (flags, name, author, etc) and one of those goes to a jump table not unlike SWI handlers.

Pass a command code and call the entry point and you can read or write bytes, change the serial speed, check control lines, blah blah. There’s a facility for block reads and writes for devices that support it (many don’t), and there’s polling for things that need to be regularly entered (the telnet driver is an example).

Preliminary findings appear to be no response from the driver. I need to work out how serialdev blockdrivers work now.

Off the top of my head:

• Load driver into memory.
• Read flags to know what driver is capable of. They’re at offset +&C4, I think.
• Call the driver entry point to initialise. That’s calling the base (+&0) with 17 in R0, and the port number in R1 (set R2 and R3 to zero).
• Read speed table (offset +&100). List of speeds terminated by null.
• Call the driver entry points to read/set the speeds, control lines, word format, etc as applicable.
• Then, call driver with R0=1 (R1 = port; returns byte in R0 or -1 if none) to get a byte, and R0=0 to send a byte (R1 = port, R2 = byte to send).
• If the driver needs polling (flags word bit 4), call driver with R0=19 and port in R1 as part of the polling routine. 3-4 times a second is okay.

It’s a little more involved in reality, but that’s the basics of it.

On a RISC OS 5 machine, it may be worth checking the flags word bit 16. If not set, you should reject the driver as it is not flagged as being 32 bit safe.

I don’t see a method in the script language to intercept and process all bytes received.

Looking at the code, it looks like a place to patch in some munging for UTF-8 sequences may be the function vtbyte() in Main.c.vtact.

You’ll want to trap >127 and suppress the bytes while remembering them (will need a small module static array).
When you have read a valid UTF-8 sequence, discard the remembered bytes and call printable(‘?’) (or whatever character you want to send).
If you encounter an invalid UTF-8 sequence, spit out the remembered bytes to printable() so they’ll show up. Do that, and you’ll be better than FontManager. ;-)

I think that ought to do it. But no guarantees!
[extra bonus points: make it optional and bake in a checkbox setting to turn it on and off]

If you’re using my SerialUSB blockdriver,

I’m using the one from XAT that is included with the blockdrivers.

I should point out that the driver is hardwired to 8N1

Unless I’ve done something wrong the XAT version is returning the reason code (15) which translates to 5N2 OS_Args returns 8N1 – that should be fixed soon.

SerialDev does look complicated through. 30 years later…

For some reason when I replied earlier I read SerialDev as Hearsay.

I’m using the one from XAT that is included with the blockdrivers.

Okay, that’ll surely be better than mine…but…what the hell is with all that turning interrupts off around everything?!?

I imagine that I did not want to put the script language in the path of the datastream – machines were slow then – but what goes on in the block driver is telling Hearsay what functions to call to read/write bytes. You could tell it to call your function which in turn calls the block driver function.

There are translation tables in Hearsay you can set up to map bytes.

There is a system of trap functions, see page 135 in the manual, which will let Hearsay take the strain of mapping escape sequences.