!PC has troubles with serial line, and sometime it freezes the kb

hi
as I have posted here and here I am dealing with two bad behaviors about !PC/Pro under risks on the RPC platform

I am equipped with

• RiscPC/600
• StrongArm 200Mhz
• 66Mbyte of ram
• RiscOS v4.39
• !PC/Pro v308
• GuestPC 486DX4 @100Mhz
• MSDOS v6.22

bad behaviors

• under MSDOS I had to remove ALL the keyboard’s lines in autoexec.bat and config.sys, elseway I got strange behavior with Turbo{C,Pascal,…}, and sometimes they freeze
• sometimes !PC/Pro freezes the keyboard and I have to reset it (physically unplug and reconnect saves me, elseway the RiscOS’s kb is gone and I have to reboot)
• sometimes (too oftern) cougar.exe under DOS under !PC/Pro has issues with the serial handshake
• under DRDOS-v6 the hard drive D: is completely destroyed or not recognized, while it works perfectly under MSDOS-v6.22

I am not expert about RiscOS, I am writing here to get some tips

Within DOS, a good serial terminal is Procomm.exe, it works pretty good with NULL-modem equipment, I can’t say a world about handshake.
Within RISC OS, a good serial terminal is “!Connector”, it works pretty good with NULL-modem equipment, I can’t say a world about handshake.

Within RISC OS,

…Hearsay.

It is free, now, and it is in !Store. Or on David’s website.
David sent me a copy of the manual with his blessing to scan it. Which I have done.
http://heyrick.co.uk/random/hearsay_2_user_guide_raw.pdf
It is 12MiB, raw scanned images. I don’t have any fancy OCR software and as much as I’d love to make a cut-down “text and pictures” version applicable to using Hearsay on the Pi(etc), I just don’t have the time…

…Hearsay.
It is free, now, and it is in !Store. Or on David’s website.

Have you had this going on a Raspberry with Tank’s driver?
I got it to work on my Iyonix today for the first time.
I editted !Hearsay.Library.!SerialDev, the line
setserialdev(“Telnet”,0);
to
setserialdev(“Internal32”,0);
and Replaced the newer dated Internal32 driver from X-Ample Tech with the one in Davids archive.
Alternative modules (also Raspberry) do not show up in the “!Serial” status program (which is from X-Ample Tech)

Edit: pdf p190 (182) has a bit on the subject of Serial versus SerialDev blockdrivers

Note: the correct driver for RiscPC is normally the InternalPC.driver, The Internal.driver refers to older Acorn
hardware/special cables, though it may be possible to use an old cable with this driver, It would not be needed normally.
AFAICS Hearsay allows not using these blockdrivers, and may work
with the supplied “!Serial” put in Hearsay.Library (RiscPC)

what have I to do and install with a fresh install of RiscOS v4.39 ?

You do understand that RISC OS 4.xx is nothing to do with us – so very specific questions might be problematic if there are differences between our versions of RISC OS and the ROLtd branch.

For what it’s worth, the PC co processor worked okay on my RiscPC with no keyboard weirdness and I used internal serial to talk to an EPROM programmer with its DOS software.
I was using RISC OS 3.70. Whether or not this makes an important difference, I don’t know. That Aleph1 needed to make alterations for RISC OS 4 implies something is different…

I was using RISC OS 3.70. Whether or not this makes an important difference, I don’t know.

Haven’t run the PC card in ages, but I do recall a few changes between 3.70 and 4.02¹ (as well as a few with the StrongARM 3.60 → 3.70 upgrade)
I think reading through Justins RISC OS Rambles would pick out most of the 4.02 – 4.39 changes and point toward possible niggles arising from those changes.

¹ Don’t recall what offhand, it was a few years ago after all.

> to talk to an EPROM programmer with its DOS software.

you do understand that “it works” does not mean anything! What does work ? Does the handshake work ? Does the break work ? With a NULL modem setup, !PC/PRO DOS is perfectly able to run Procomm.exe in order to connect a DataMan S4 EPROM programmer to internal serial, and it works marvelous, while cougar.exe and evm.exe are NOT working at all, this because

1) there is certainly a bug in the handshake level
2) there is certainly a bug in the “break” feature

I am posting here because I’d like to hear a developer’s opinion, or just to collect a few tips

if it’s not the best place to ask, let me know where I have to post.

if it’s not the best place to ask, let me know where I have to post.

Unfortunately the PCPro software is a legacy item. As Chris Evans mentioned in the other thread you referenced:

“n.b. The !PC/Pro authors have left the RISC OS scene a long time ago.”

When he says a long time he means about 15 years ago.

At least one of the programmers¹ of the application has a web presence easy to find. Whether he recalls anything of the work he did² other than that he did it is an interesting question.

Of course the fact that the OS has changed since he wrote the app doesn’t help either.

¹ Wookey
² There are shell scripts and VBScripting items I did about 9 years ago that someone fished up for a re-write last week – I needed to read through before I even recalled writing it. Seeing my name in there sort of helped.

I am looking at on line manual for the M68300PFB and it states
“In order for high-baud rate serial communication between CPU32Bug and the terminal to function properly, the terminal must use XON/XOFF handshaking. If messages are garbled and have missing characters, check the terminal to verify XON/XOFF handshaking is enabled.
3. Power up the system. CPU32Bug executes a self-test and displays the sign on message (which includes version number) and the debugger prompt CPU32Bug>”

Do you get that far?

What a mess! See the photos I have included in the other thread and note the EVS board is composed by two modules! The problem with the !PC/PRO serial is not related to the CPU32bug firmware, which is working perfectly with a common terminal like procomm.exe, the problem is cougar.exe which talks to the BBCDI module, that is strongly using BREAK signals and HANDSHAKE lines. There is a debug processor chip on the EVS board, this chip has nothing to deal with the 68332 CPU (except they fact they are linked through a BDM connection, and they partially share resources), the BBCDI module is based on a special 68HC11 chip plus a custom ASIC companion.

Please note there are two DB9 connectors on the EVS board, see this photo, you can see the 68332 module on the left and the BBCDI module on the right.

EVS.COM1: to CPU32Bug, 68332 CPU’s serial line → NULL MODEM setup, perfectly working, it talks with a human protocol, so you can use the uart terminal App you like
EVS.COM2: to BCCDI, debug processor’s serial line → breaks and handshakes are strongly used, … it talks a custom binary protocol (actually unknown, I am reversing it) it’s not human, so you need a special control program like cougar.exe, which under !PC/Pro sometimes works (rarely), too often it doesn’t. With a laptop it always works, and it has never failed.

My Logic Analyzer tells me there are “break” events on the serial line, and a strong use of the handshake lines. I haven’t understood yet exactly where is the problem.

Also, the EVM (56002 DSP Evaluation Board) is not working too, again the board has a debug processor (based on 6805), its control program is called EVM.exe and under !PC/pro it goes out of synchronism quite immediately, while it works perfectly with a laptop.

I’d like to buy a RiscOS v3.* PROM to test the PC/PRO v2 with cougar.exe. Maybe the bug is older than how we believe =D

you do understand that “it works” does not mean anything! What does work ? Does the handshake work ? Does the break work ?

Why would I know any of that? I connected the (borrowed) EPROM programmer to the RiscPC with the (PC wired) serial lead provided. I loaded the DOS software. I was able to retrieve ROM images from the programmer, and send new images to write to ROM. Given that I reprogrammed the firmware in my Econet FileStore with a slightly later version that somebody sent me, I would say that this particular piece of hardware worked (using the standard definition of “it works” meaning “it isn’t broken”) and as such, no further investigation was necessary. Perhaps it was using 9600bps with XON/XOFF? I don’t know. I just know I plugged it in, loaded the software, and got on with it.

What raises a flag for me is you said:

that means the delay in the handshake phase was under 50msec.

It sounds like Cougar has protocol that hasn’t been designed very well. That would probably fail on my (real) PC when it is very busy (like when the anti-virus updates itself). 50msec (5cs?) is short. Given we’re talking serial, it doesn’t leave a lot of leeway.

By the way – !PC. Are you running it windowed or full screen? I find full screen is faster (and less distracting).

binary protocol, not human

What do you mean regarding “binary” and “human”? Data is data – the serial hardware (running at 8N1) doesn’t make a distinction.

The problem with the !PC/PRO serial is not related to the CPU32bug firmware, which is working perfectly with a common terminal like procomm.exe

I see, but I can’t find technical details of the main board.
I think the Iyonix was the first machine to have proper high voltage serial ports, and it is possible that a laptop would have full voltage serial also. It is not a problem I have run into, but I guess if the receiver was expecting 12 or more volts it could upset things.
At a slow speed of 9600, you’d think timing wouldn’t be a problem.
Do you know for sure that the board depends on HW handshaking? I can have hardware handshaking on one machine, and the other machine using no handshaking simply ignores them and works OK.

@Rick Murray
Windowed or full screen doesn’t help at all. Already tested.

@Ronald May
i trust it’s RS232 standard, my Logic Analyzer is not reporting strange things from the analog world.
Btw, I could use a follower amplifier, if you are afraid about that. I could prepare it in a few minutes.

I think I mentioned it before – there is no general handshaking problem with !PC and the serial port. I used to transfer rather a lot of data via the serial port and various modems which absolutely relied on hardware handshaking working.

Your problem with cougar.exe sounds like a hardware timing problem. I bet there are also real PCs out there that won’t be able to run it reliably. Trying to fix !PC to be able to run it reliably sounds like a lost cause. Is there a special reason why you need to run it under the PC card?

Have you also tested breaks ?

also, as reported above, the keyboard sometimes get freezed under !PC/Pro, and I physically need to unplug in order to reset.

http://www.freescale.com/files/soft_dev_tools/doc/data_sheet/M68340EVS.pdf
For a similar model, mentions
“The user can interface with EVSbug via the BCCDI RS-232C port or the PFB PC RS-232C port. The BCCDI hardware
features are as follows:
• MC68HC811E2 Programmable Microcontroller Unit (MCU)
• Motorola Custom Hardware Breakpoint Chip
• RS-232C-Compatible Terminal/Host Computer I/O Port
• Background Mode Interface Port
• EVS Interface Connectors
EVSbug, in conjunction with the BCCDI, implements a debug monitor for the MC68340. EVSbug differs
from 340Bug in that it requires no resources from the MC68340 to operate. EVSbug functions by
placing the MC68340 into background mode when executing the debug monitor commands.”

Maybe this alternate port could be worth trying?

the keyboard sometimes get freezed under !PC/Pro

I’ve seen that on real PC’s (back in the 90’s) where the PC keyboard/mouse driver couldn’t handle hardware that was faster than expected. Software polling loop missed the returned data.¹ We got a rewritten driver set from Microsoft via Apricot (their boards were well designed and basically faster than pretty much everything else around)
Essentially, while no one can guarantee that it isn’t a problem in the I/O of the card the software and OS aren’t likely to be guaranteed blame free.

¹ Basically PC’s generally had a really shitty OS on them.

@Ronald May
> Maybe this alternate port could be worth trying?

it’s not an “alternate port”, that port is the only one you have to use if you want to talk with the debug processor. There are no other possibilities to talk with the debug processor (already explained above), and certainly I have already tried. That documents is telling you that you have two levels of debugging

• (basic level) using software stub, so using the 332Bug, which runs inside the 332CPU, it could debug, but … it has reduced features, e.g. software breakpoint instead of hardware breakpoints. It uses a NULL model setup, and it talks with human protocol (no burst, no handshake, no breaks, each line ends with CR)
• (advanced level) using the debug processor … which speaks a binary protocol (with burst, handshakes and breaks), so, as the fact it’s undocumented, then it requires a special software to be interfaced, and this software is called cougar.exe

@Steve Pampling
what do you suggest ?

I am using MSDOS-v6.22, and I had to remove ALL the lines about the keyboard in both config.sys and autoexec.bat. Without commenting these lines I get strange behavior with TurboC, TurboPascal and other stuff, while If I use DRDOS, I get a completely corruption of the disk D: and it means data lost and bad things. I haven’t tried PC-DOS because I do not have it

Any tips ? Do you need to see my config.sys and autoexec.bat ? I could post here.

I haven’t tried PC-DOS because I do not have it

Ah, that was the version supplied with the cards when Aleph1 were still in business. It did seem to work better for many things.

Any tips ? Do you need to see my config.sys and autoexec.bat ? I could post here.

I’m afraid I’m totally on memories of very old setups. I have been giving the info I recall. I haven’t done any PC maintenance for over 12 years.¹

I would suggest you post the current config.sys and autoexec here so that others can comment.

¹Truth be told, since I got people using imaging software the even guys in desktop support drifted to re-imaging rather than fixing niggling problems. I spend my time dealing with esoteric “network” problems, most of which turn out to have no network aspect at all.

it’s not an “alternate port"

The way I read it they are talking about two ports for EVSbug which is different to 340bug. I assumed they are talking about the connector on the board by the gold topped processor. (in your photo)
There are other diagrams with three possible rs232 connections to that board.
Quote"The user can interface with EVSbug via the BCCDI RS-232C port or the PFB PC RS-232C port. "
Perhaps confusing, but in the previous paragraph they say
“The user can interface with the 340Bug via the PFB terminal RS-232C port or the BCC RS-232C connector.”
Have the pc cards cards got serial connections in one form or another?
You would need to check them with your laptop (known to work) if there is one.

I can recall using dosv5 or similar because it was smaller and was adequate for running things.

I’d like to write a few C/Pascal sources in order to verify the serial line is fully working under !PC/Pro. I do not trust it is, especially with breaks, also I’d like to check how good is the PIC under PC.

I am going to post the full autoexec.bat and config.sys. Next post, I will shoot as “disruption-workaround”. It’s not a fix up.

About PC-DOS, i’d like to know why/where it’s better than MSDOS, because I have to purchase it (more money).