I've been tinkering around with CP/M 2 and an RC2014 system (SC114 + ACIA boards and even the native SC114 bitbang I/O). I've been successful at getting LPT:, LST: and PUN: devices working. Basically anything that outputs. But I'm kind of stumped with regards to RDR: and it's associated devices. Is this polled by CP/M? If so when/how? There is a console status call in bios, but no equivalent I can see with regards to non-console reader devices and I'm kind of stumped on how it works. Does anybody have experience with this and can provide some clues? I've tried just implementing something assuming the RDR: is polled, but it doesn't seem to work. Thoughts?

Thanks,
Robert

RDR and PUN are leftovers from the early days when paper tape was still common.

The devices have BIOS entries but it's up to the BIOS developer to decide how to implement them.

Please not there is no status entry. Normally when called the hang until the operation is complete like CONIN and CONOUT.

I have used PUN as a second printer.

Randy

I've managed to get it working as intended. But if anyone *wants* to add any additional help (possibly for others) feel free.

Robert Kincaid <rhkincaid@gmail.com> writes:
> no equivalent I can see with regards to non-console reader devices an=
> d I'm kind of stumped on how it works. Does anybody have experience with th=
> is and can provide some clues? I've tried just implementing something assum=
> ing the RDR: is polled, but it doesn't seem to work. Thoughts?

All of the input devices need to be actively polled by an application to
function. An alternative is to have the input device interrupt driven. But
that will only store characters in a buffer.

An application of some description (even a TSR) will still need to
specifically take control of that interrupt or actively poll the buffer
itself for available characters.

CP/M as such (except when the CCP is active) does not monitor any input devices.

Jack
--
"My mother says I don't know what good, clean fun is.
She's right. I don't know what good it is."

- Laugh-In, 1968

CP/M 2 added a LST: status, but nothing for RDR: or PUN: - those were blocking interfaces. An alternative some people used was to implement device redirection ("iobyte"), and then switch the console around to other devices. That can get messy, though.

CP/M 3 implements full polling for CON:, LST:, and AUX: (formerly RDR:/PUN:), plus extended redirection.

Am 09/24/2021 09:56 PM, Robert Kincaid schrieb:
> I've managed to get it working as intended. But if anyone *wants* to add any additional help (possibly for others) feel free.
>

Implement the I/O Byte!

If you ever want to do serial communication, you will need it.
The READER/PUNCH is mostly unusable without it.

It works in this way:
You switch the input to BAT:
You use CONST for polling the READER
You use CONIN for reading from the READER
You switch the input back to TTY:

This is very fast, just set the relevant bits in the I/O Byte.
Normally you save the existing state at startup and restore on exit.

*Kermit* is one of the best examples.

In its "generic" implementation,
it does *everyhing* only using the I/O Byte!

Want an example implementation?

In my BIOS, I have done it the following way...

1) Addidional jump verctors:
============================

[...]

;*****************************************************
; jump vector for indiviual routines
; JP BOOT
WBOOTE: JP WBOOT
JP CONST
JP CONIN
JP CONOUT
JP LIST
JP PUNCH
JP READER
JP HOME
JP SELDSK
JP SETTRK
JP SETSEC
JP SETDMA
JP READ
JP WRITE
JP LISTST
JP SECTRAN
; JP CONOST ; <<< Console output status
JP AUXIST ; <<< Reader input status
JP AUXOST ; <<< Punch output status
;

[...]

2) Implementing the I/O Byte:
=============================

[...]

;*****************************************************
; VCONST:
DW S1RXSE ; TTY:
DW S1RXSE ; CRT:
DW AUXIST ; BAT:
DW NONST ; UC1:
VCONIN:
DW S1RXIE ; TTY:
DW S1RXIE ; CRT:
DW READER ; BAT:
DW NONIN ; UC1:
VCONOST:
DW S1TXSE ; TTY:
DW S1TXSE ; CRT:
DW LISTST ; BAT:
DW NONST ; UC1:
VCONOUT:
DW S1TXOE ; TTY:
DW S1TXOE ; CRT:
DW LIST ; BAT:
DW NONOUT ; UC1:
; VAUXIST:
DW S1RXSE ; TTY:
DW S2RXS ; PTR:
DW S2RXS ; UR1:
DW NONST ; UR2:
VREADER:
DW S1RXIE ; TTY:
DW S2RXI ; PTR:
DW S2RXIN ; UR1:
DW NONIN ; UR2:
; VAUXOST:
DW S1TXSE ; TTY:
DW S2TXST ; PTP:
DW NONST ; UP1:
DW NONST ; UP2:
VPUNCH:
DW S1TXOE ; TTY:
DW S2TXOTE ; PTP:
DW NONOUT ; UP1:
DW NONOUT ; UP2:
; VLISTST:
DW S1TXSE ; TTY:
DW S1TXSE ; CRT:
DW S2TXST ; LPT:
DW NONST ; UL1:
VLIST:
DW S1TXOE ; TTY:
DW S1TXOE ; CRT:
DW S2TXOTE ; LPT:
DW NONOUT ; UL1:
; ;
CONST:
XOR A
LD HL,VCONST
JR IODISP
CONIN:
XOR A
LD HL,VCONIN
JR IODISP
CONOST:
XOR A
LD HL,VCONOST
JR IODISP
CONOUT:
XOR A
LD HL,VCONOUT
JR IODISP
; AUXIST:
LD A,1
LD HL,VAUXIST
JR IODISP
READER:
LD A,1
LD HL,VREADER
JR IODISP
; AUXOST:
LD A,2
LD HL,VAUXOST
JR IODISP
PUNCH:
LD A,2
LD HL,VPUNCH
JR IODISP
; LISTST:
LD A,3
LD HL,VLISTST
JR IODISP
LIST:
LD A,3
LD HL,VLIST
JR IODISP
; IODISP: LD B,A
OR A
LD A,(IOBYTE)
JR Z,IODISC
IODISL: RRCA
RRCA
DJNZ IODISL
IODISC: AND 3
RLCA
LD D,B
LD E,A
ADD HL,DE
LD A,(HL)
INC HL
LD H,(HL)
LD L,A
JP (HL)
;

[...]

;*****************************************************
; NONIN: LD A,1AH
RET
; NONST: XOR A
NONOUT: RET

[...]

The source speaks for itself :-)
Martin

Note: if you are going to add non-standard JMPs to the BIOS vectors, you may not need iobyte as your program(s) can just make BIOS calls for RDR:/PUN: (AUX:) status. Of course, those programs become non-standard then (not very portable to other CP/M implementations). Even using iobyte, that limits the platforms your programs can run on (many did not implement iobyte).

Am 09/25/2021 02:08 PM, Douglas Miller schrieb:
> Note: if you are going to add non-standard JMPs to the BIOS vectors, you may not need iobyte as your program(s) can just make BIOS calls for RDR:/PUN: (AUX:) status. Of course, those programs become non-standard then (not very portable to other CP/M implementations). Even using iobyte, that limits the platforms your programs can run on (many did not implement iobyte).
>

Thanks for your note!

The part with the 3 extra entries in my BIOS jump table
was inserted very late without much explanation.

I just wanted to include this as an optional, but very
non-standard possibility.

In my case, these JMPs were already included in the stock BIOS
and I took them over only for compatibility.

If one really wants to extend his BIOS with more advanced features,
I suggest at least reading Section 2 (the BIOS Overview)
in the "CP/M Plus System Guide".

Martin

On 9/24/21 10:42 PM, Martin wrote:
> Am 09/24/2021 09:56 PM, Robert Kincaid schrieb:
>> I've managed to get it working as intended. But if anyone *wants* to add any additional help (possibly for others) feel free.
>>
>
> Implement the I/O Byte!

I dug around my floppy disk images and found where I once did this for
CP/M-68K. Pretty much the same way.

--
http://davesrocketworks.com
David Schultz

Am 09/25/2021 09:12 PM, David Schultz schrieb:
> On 9/24/21 10:42 PM, Martin wrote:
>> Am 09/24/2021 09:56 PM, Robert Kincaid schrieb:
>>> I've managed to get it working as intended. But if anyone *wants* to
>>> add any additional help (possibly for others) feel free.
>>>
>>
>> Implement the I/O Byte!
>
> I dug around my floppy disk images and found where I once did this for
> CP/M-68K. Pretty much the same way.
>

Hi, David!

Just (re)visited your new CP/M-68K site on:
<http://davesrocketworks.com/electronics/cpm68/index.html>

There is something wrong with the simulator zip-file
<http://davesrocketworks.com/electronics/cpm68/cpmsim.zip>

This file is very out of date!

It is the same as the very first version from 2014:
-rw-r--r-- 1 martin users 924309 Apr 27 2014 cpmsim.zip

These are the newer versions I have:
-rw-r--r-- 1 martin users 924891 Jun 24 2016 cpmsim.zip
-rw-r--r-- 1 martin users 924894 Feb 6 2018 cpmsim.zip

Martin

On 9/25/21 8:07 PM, Martin wrote:
> This file is very out of date!
>
> It is the same as the very first version from 2014:
> -rw-r--r-- 1 martin users 924309 Apr 27  2014 cpmsim.zip
>
> These are the newer versions I have:
> -rw-r--r-- 1 martin users 924891 Jun 24  2016 cpmsim.zip
> -rw-r--r-- 1 martin users 924894 Feb  6  2018 cpmsim.zip
>
> Martin
>
Thanks. I figured out what happened. I have a directory where I keep all
of the web page files and that is what I copied to the new server.
Unfortunately, when I updated cpmsim.zip (in its working directory), I
didn't copy it over to the space for the web pages when I updated the
server.

It should be better now.

--
http://davesrocketworks.com
David Schultz