Editing CP/M v 2.2 asm for 8080 source to work on an 8085 computer with SID/SOD for serial communications

[andrewec]

Hi,

For this to work, I know I have to change CP/M CONIN( type and accept a character from a terminal), CONOUT( print a character to a terminal) and CONST( non blocking character in) to my own Cin, Cout routines( const yet to be written) on my 8085 computer and set up a virtual disk drive. Is there anything else to be done?

Thanks, Andrew

 

[WSM]

If I understand your question correctly, that sounds about right but it's obviously dependent upon the BIOS source you're starting with and any unique initialization requirements for your specific hardware. Typically the CBOOT routine can do one-time initialization for devices such as UARTs & disks.

For your initial development, you can just make LIST & PUNCH ignore the data and simply throw it away. READER can just return A=CTL-Z and LISTST can return A=0FFh. LIkewise for initial BIOS testing I would not implement the IOBYTE function. Most of your development will likely be in configuring the BIOS for disk drive(s), virtual or real.

 

[durgadas311]

I expect you'll have some challenges reliably receiving characters using SID in a CP/M environment. Timing is critical from the leading edge of the START bit, so anything that introduces uncertainty in the elapsed time since the START bit will lead to framing errors. Using interrupts to detect the START bit will place constraints on timing and anything that delays the start of the interrupt handler (e.g. other interrupts or DI/EI sections). Without interrupts, CONST would be useless and then any program that relies on CONST to do input will not work, and you must ensure that CONIN is entered before the (every) START bit arrives.

 

[andrewec]

If I understand your question correctly, that sounds about right but it's obviously dependent upon the BIOS source you're starting with and any unique initialization requirements for your specific hardware. Typically the CBOOT routine can do one-time initialization for devices such as UARTs & disks.

For your initial development, you can just make LIST & PUNCH ignore the data and simply throw it away. READER can just return A=CTL-Z and LISTST can return A=0FFh. LIkewise for initial BIOS testing I would not implement the IOBYTE function. Most of your development will likely be in configuring the BIOS for disk drive(s), virtual or real.

Thanks WSM, for the details , I will focus on that.

Andrew

 

[andrewec]

I expect you'll have some challenges reliably receiving characters using SID in a CP/M environment. Timing is critical from the leading edge of the START bit, so anything that introduces uncertainty in the elapsed time since the START bit will lead to framing errors. Using interrupts to detect the START bit will place constraints on timing and anything that delays the start of the interrupt handler (e.g. other interrupts or DI/EI sections). Without interrupts, CONST would be useless and then any program that relies on CONST to do input will not work, and you must ensure that CONIN is entered before the (every) START bit arrives.

I expect you'll have some challenges reliably receiving characters using SID in a CP/M environment. Timing is critical from the leading edge of the START bit, so anything that introduces uncertainty in the elapsed time since the START bit will lead to framing errors. Using interrupts to detect the START bit will place constraints on timing and anything that delays the start of the interrupt handler (e.g. other interrupts or DI/EI sections). Without interrupts, CONST would be useless and then any program that relies on CONST to do input will not work, and you must ensure that CONIN is entered before the (every) START bit arrives.

Thanks durgadas311,

I understand your concerns, but I believe that there is a way to check the start bit to see if a char is waiting via 8085 RIM (sid pin) and that won't have the DI/EI around it and it is won't block CP/M from continuing to execute. Then the code will set a flag that CP/M reads. Then I can do the CONIN( has DI/EI around it), if the flag indicated a char, which utilizes rim again, and consumes the char, but I need to test this, of course...

Andrew

 

[durgadas311]

The problem is that you can detect SID is zero but you'll have no idea whether that is the START bit or any other bit of the character. And since you won't know exactly when the START bit actually began, you'll have problems trying to determine when the first data bit is ready to be sampled. This has to do with not knowing when a CONST will be called in relation to the character being sent by the remote terminal.

 

[durgadas311]

Also, if interrupts are in use on the platform, you must DI when detecting the START bit and keep interrupts disable for the duration of the character. But the interrupt concern I have is about using interrupts to detect the START bit, which would be delayed until any critical section has then done EI - by which time you've probably lost the chance to reliably receive the character.

 

[CODOR]

For this to work, I know I have to change CP/M CONIN( type and accept a character from a terminal), CONOUT( print a character to a terminal) and CONST( non blocking character in) to my own Cin, Cout routines( const yet to be written) on my 8085 computer and set up a virtual disk drive. Is there anything else to be done?

Are you using the routines from Intel appnote AP-29 "Using The Intel 8085 Serial I/O Lines"? I've done something similar but with a dedicated UART so the SID/SOD lines are treated as an auxiliary port and rarely used as a console.

My implementation of CONST is basically:

RIM         ; get state of SID in A
CMA         ; start bit is low, invert it
ANI 80h     ; strip other bits, set A to zero if no character
RZ          ; return if so
ORI 0FFh    ; otherwise set to FFh to indicate a character is ready
RET

But this relies on software immediately attempting to read the character if one's available. In retrospect maybe I should be reading the character anyways and stashing it in a buffer for the next CONIN.

Surprisingly it still works... most of the time, probably for reasons durgadas311 explains. Not sure I'd trust it for file transfers but it seems okay as a backup console (and I'd like to use it for a printer).

 

[andrewec]

Also, if interrupts are in use on the platform, you must DI when detecting the START bit and keep interrupts disable for the duration of the character. But the interrupt concern I have is about using interrupts to detect the START bit, which would be delayed until any critical section has then done EI - by which time you've probably lost the chance to reliably receive the character.

Thanks, I am grateful, I understand it better now.

p.s. Maybe that's why a lot of 8085 geeks like me use the 8251 UART instead

Andrew

 

[durgadas311]

Yup, for embedded applications it might make sense to use SID/SOD, but generally it is more work than is usually practical. It is interesting work, but just be aware of the limitations.

 

[andrewec]

Are you using the routines from Intel appnote AP-29 "Using The Intel 8085 Serial I/O Lines"? I've done something similar but with a dedicated UART so the SID/SOD lines are treated as an auxiliary port and rarely used as a console.

My implementation of CONST is basically:

RIM         ; get state of SID in A
CMA         ; start bit is low, invert it
ANI 80h     ; strip other bits, set A to zero if no character
RZ          ; return if so
ORI 0FFh    ; otherwise set to FFh to indicate a character is ready
RET

But this relies on software immediately attempting to read the character if one's available. In retrospect maybe I should be reading the character anyways and stashing it in a buffer for the next CONIN.

Surprisingly it still works... most of the time, probably for reasons durgadas311 explains. Not sure I'd trust it for file transfers but it seems okay as a backup console (and I'd like to use it for a printer).

Thanks Codor, yes , I use the AP 29 guide