Problems with rdstat() (bios console status call) on cpm3 from pli program.

[rwd...@gmail.com]

I hope that some of you may have some knowledge of pli programs on cpm3, from having built the cpm3 utility programs.

I have a working pli hexdump program which behaves correctly under cp/m 2.2 but fails under cp/m 3 due to problems with the console status call rdstat().

The rdstat call can work, but when my program is in a loop of read record, write record to screen it is as though the rdstat call is blocked and does not register the key pushes

To demonstrate the problem run "hdx hdx.rel /s". this will run the program to display one record at a time, of  the hdx.rel file,  "s" or " " (space) will step record - this shows that console status and read character can work. enter "c" to go into continuous mode, showing a stream of records. it should  now be possible to quickly enter "s" or space to go back to stepping mode. Under cpm3 this is not detected. works fine under cpm2.

if you have a fast system you may need a larger file to dump than hdx.rel

I wondered whether my link hdx,cpmdio should be link hdx,plibios3,cpmdio but  that doesn't improve the behaviour.

I am aware that cpm3 moved away from exposing bios calls for user programs but I thought that rdstat and coninp were still supported.

Any suggestions for how to fix this? I don't mind having a version of my program for each os type but  I would prefer just one version. I have tested under cpm3 of romwbw and on cpm3 on z80mbc2 to rule out any strange romwbw hbios behaviour. The program works fine under cpm22 of romwbw.

I attach the program and make file for use with pli-80 1.4

Richard

[Douglas Miller]

There have been many utilities made that operate on both CP/M 2 and CP/M 3. There are lots of ways of doing that, but basically it comes down to checking the CP/M version and setting up alternate (internal) jump vectors or doing an IF-ELSE where it matters.

I think the CP/M 3 Systems guide suggests that char-io BIOS routines should be fully-contained in common memory - and not require bank switching - but that depends on the BIOS implementation. If char-io routines need bank 0 switched in - and don't do that themselves - then they would crash in unpredictable ways whenever called directly from a user program (I forget whether BDOS char-io calls always switch to bank 0).

You also may be running into a problem where the BDOS is snooping console input in order to detect ^C. This can create a problem for programs calling the BIOS directly, as they won't ever see the fact that the BDOS captured the character and is holding it. Do you really need to call the BIOS directly? Using BDOS calls for all console I/O might fix things. Even CP/M 2 has BDOS function 11 for console status, as well as func 6 "Direct Console I/O" that can be used for a similar purpose.

[Douglas Miller]

I see that plidio.asm contains a 'break' routine that calls BDOS function 11. Maybe try that instead of 'rdstat'.

[Alan Cox]

On Mon, 18 Oct 2021 at 17:33, Douglas Miller <durga...@gmail.com> wrote:

I think the CP/M 3 Systems guide suggests that char-io BIOS routines should be fully-contained in common memory - and not require bank switching

All CP/M 3 BIOS entry points are in common space. For the console routines an implementation may choose to put code/data in banked space but is required to do the actual switch/restore itself including providing its own stack (as the console I/O can be called from a non common stack). A lot of CP/M 3 implementations bank the console because in that period it was often a full VT emulator and video card driver.

[Richard Deane]

I have sort of solved my problem - I say "sort of" because it is a workaround rather than a bug fix.

The program is essentially a loop of disk record read followed by display record to console with keyboard status check in the loop to see if any user interaction should be actioned.

This works fine in CP/M 22 but stops detecting console input under cp/m 3

The troublesome call is bdos 6  get console status.

The  work around is to replace the  pli put statements  with calls to bdos conout, console status  then works. By doing this I lose the flexibility of choosing a different output device. I can add code to resolve this.

As an exercise to learn more I converted the original pli program to HiSoft / FTL / Cerenkov Modula-2, a nice (Australian)  implementation of Modula-2 on CP/M - this works fine on both CP/M 22 and CP/M 3 using the BusyRead function (same bdos console status call as in PLI). As a language I prefer PLI for general programming but modula-2 is ok. Nice twist in the product name FTL was the US marketing name for the product (Faster than light) and it just so happens that Cerenkov radiation occurs when a particle travels faster than light in a medium. I suspect the author was associated with Nuclear Physics. HiSoft sold the product in the UK for use on  Amstrad PCW. The documentation is quite thorough. My impression is that this Modula-2 is better than Turbo Modula-2 and Peter Hockstrasser's Modula-2 but I have not used those in over a year so I don't remember much of the specific details other than one of the others was awkward trying to mix use of characters and strings. I hope to port this latest version of hexdump to these two compilers to highlight any problems - and make a note this time.

Richard

 

--
You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/bKemmtR3_x4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/f35061a4-2d48-4cd9-a9b6-1c683a5c7944n%40googlegroups.com.

[Douglas Miller]

BDOS function 6 bypasses the BDOS "status check" a.k.a. break check, so you're into the same scenario where console input is being trapped by BDOS but your program is skipping that, and missing the console input.

[Douglas Miller]

Correction: BDOS func 6 does NOT bypass the BDOS break check. so, doesn't explain your issue. But, how does that prevent you from choosing the console output device? BIOS redirection should still be in affect - provided your BIOS supports that.

[Richard Deane]

My PLI code was opening CON:,LST:  or filename for output then writing the display text to it; when I replaced those PLI calls with direct BDOS conout, I lost the flexibility of choice of output device.  I would need to add in code to change the bdos call to a different device, and use PLI code if the display output is redirected to a disk file.

As my interest is around the code and functionality to learn the system, more than creating a perfect hex dump program (whatever that means - the spec is evolving in my mind), I think I will port it across to C to learn HiTech C  or BDS C. I never learnt C in my programming career (Assembler, Fortran, PLI, Pascal, HAL/S, Coral) and so far it was more natural to drift into Modula-2 than C. I am averse to C on the grounds of Computer Science recognising the benefits of strongly typed languages. In my career portion as QA/Test I have seen too many avoidable C program defects.

Richard

--

You received this message because you are subscribed to a topic in the Google Groups "retro-comp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/retro-comp/bKemmtR3_x4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to retro-comp+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/0a4fd2ab-ffb8-4219-9a4a-4cad7acf02b3n%40googlegroups.com.

[Douglas Miller]

That makes it sound like PLI is "snooping" the console, in addition to the BDOS. That would explain why by-passing PLI console I/O routines (using BDOS/BIOS ones) for "break check" causes input to be lost (i.e. mixing PLI I/O routines with BDOS/BIOS status check).

On Sunday, November 7, 2021 at 5:53:41 AM UTC-6 rwd...@gmail.com wrote:

My PLI code was opening CON:,LST:  or filename for output then writing the display text to it; when I replaced those PLI calls with direct BDOS conout, I lost the flexibility of choice of output device.  I would need to add in code to change the bdos call to a different device, and use PLI code if the display output is redirected to a disk file.

...