SIO configuration query -

[Jim McGinnis]

Wayne,

SIOnxDIV - can SIO0ADIV be used to FORCE the SIO divider instead of using the internal calculations you use?

Build: SC126

The RomWBW 3.0.1 SIO configuration, when configured for 1.8432 MHz clock and 19200 Baud is calculating a 64 divisor which is not the same as the divisor being calculated for RomWBW 2.9.2.pre32 with the same parameters - .pre32 installs 16 as the divisor.

I use a CTC device to feed the SIO/0 or SIO/2 clocks. Unfortunately, when 64 is instilled into the SIO, my baud options are limited to 9600 or less.

I tried to search all changes to SIO.ASM and was not successful in isolating a change that would affect the divisor calculation. But I am a git noob and it may be there in actuality ;-)

I am currently using a utility to set up the CTC A and B for the two SIO channels that are COM2 and COM3 on the SC126.

I will develop another utility to manually set the SIO registers next.

Just curious why I am getting different results with these builds for SIO divisor setting and wondering if I can hard wire the divisor using SIO0ADIV, SIO0BDIV, etc?

I am very happy with the other beneficial changes found in 3.0.1.  Really great work on your part to maintain such a "heavy" implementation that addresses so much hardware. Phenominal, actually. Gutsy.

For reference, the only differences in the configurations are that in the 3.0.1 setup, I limit the SIO discovery to a single chip and the 3.0.1 addition of a CTCC parameter, which I am not using (-1).

The SIO is addressed per EZZ80 nets and is configured to 0x80 base. The CTC is fed via a 1.84320 mHz clock.

When the CTC Counter is /6 on the 2.9.2.pre32 build, I can clock the SIO A or B port to 19,200. the CTC clock is 307.202 kHz.

307202 / 16 = 19200.

When the CTC Counter is /3 on the 3.0.1 build, the CTC clock is 614.404 kHz.

614404 / 64 = 9,600

When the CTC Counter is /6 on the 3.0.1 build, the CTC clock is 307.202 kHz

307202 / 64 = 4,800

I have tested the setups using a Kermit4.11 client built for CPM3 and a Linux C-Kermit Server. When the Baud rates are set according to the data above, everything works.

I assume that my configuration settings are misleading the algorithm on 3.0.1.

Very best regards and thank you in advance for your most valuable time!

Stay safe.

Jim

RomWBW 2.9.2.pre32 configuration SCZ180_126.asm text excerpt - the added lines are between the dashed bars...

;
;-------------------------------------------------------------------------------------------
SIOENABLE       .SET    TRUE            ; SIO: ENABLE ZILOG SIO SERIAL DRIVER (SIO.ASM)
SIODEBUG        .set    TRUE            ; SIO: ENABLE DEBUG OUTPUT
;
SIO0MODE        .SET    SIOMODE_EZZ80   ; SIO 0: CHIP TYPE: SIOMODE_[RC|SMB|ZP|EZZ80]
;
SIO0ACLK        .SET    1843200         ; SIO 0A: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO0ADIV        .SET    1               ; SIO 0A: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO0ACFG        .SET    SER_19200_8N1   ; SIO 0A: SERIAL LINE CONFIG
;
SIO0BCLK        .SET    1843200         ; SIO 0B: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO0BDIV        .SET    1               ; SIO 0B: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO0BCFG        .SET    SER_19200_8N1   ; SIO 0B: SERIAL LINE CONFIG
;
;
SIO1MODE        .SET    SIOMODE_EZZ80   ; SIO 1: CHIP TYPE: SIOMODE_[RC|SMB|ZP|EZZ80]
;
SIO1ACLK        .SET    1843200         ; SIO 1A: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO1ADIV        .SET    1               ; SIO 1A: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO1ACFG        .SET    SER_19200_8N1   ; SIO 1A: SERIAL LINE CONFIG
;
SIO1BCLK        .SET    1843200         ; SIO 1B: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO1BDIV        .SET    1               ; SIO 1B: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO1BCFG        .SET    SER_19200_8N1   ; SIO 1B: SERIAL LINE CONFIG
;

RomWBW 3.0.1 configuration SCZ180_126.asm text excerpt - the added lines are between the dashed bars...

SIOENABLE       .SET    TRUE            ; SIO: ENABLE ZILOG SIO SERIAL DRIVER (SIO.ASM)
;-----------------------------------------------------------------------------------------------------------------
SIODEBUG        .SET    FALSE           ; SIO: ENABLE DEBUG OUTPUT
SIOCNT          .SET    1               ; SIO: NUMBER OF CHIPS TO DETECT (1-2), 2 CHANNELS PER CHIP
SIO0MODE        .SET    SIOMODE_EZZ80   ; SIO 0: CHIP TYPE: SIOMODE_[RC|SMB|ZP|EZZ80]
SIO0CTCC        .SET    -1              ; SIO 0: CTC CHANNEL CLOCK SCALER, (0-3), -1 FOR NONE
SIO0BASE        .SET    $80             ; SIO 0: REGISTERS BASE ADR
SIO0ACLK        .SET    1843200         ; SIO 0A: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO0ADIV        .SET    1               ; SIO 0A: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO0ACFG        .SET    SER_19200_8N1   ; SIO 0A: SERIAL LINE CONFIG
SIO0BCLK        .SET    1843200         ; SIO 0B: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO0BDIV        .SET    1               ; SIO 0B: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO0BCFG        .SET    SER_19200_8N1   ; SIO 0B: SERIAL LINE CONFIG
;
SIO1MODE        .SET    SIOMODE_EZZ80   ; SIO 1: CHIP TYPE: SIOMODE_[RC|SMB|ZP|EZZ80]
SIO1CTCC        .SET    -1              ; SIO 1: CTC CHANNEL CLOCK SCALER, (0-3), -1 FOR NONE
SIO1BASE        .SET    $84             ; SIO 1: REGISTERS BASE ADR
SIO1ACLK        .SET    1843200         ; SIO 1A: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO1ADIV        .SET    1               ; SIO 1A: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO1ACFG        .SET    SER_19200_8N1   ; SIO 1A: SERIAL LINE CONFIG
SIO1BCLK        .SET    1843200         ; SIO 1B: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO1BDIV        .SET    1               ; SIO 1B: SERIAL CLOCK DIVIDER, RC2014/SMB=1, ZP=2/4/8/16/32/64/128/256 (X5)
SIO1BCFG        .SET    SER_19200_8N1   ; SIO 1B: SERIAL LINE CONFIG
;-----------------------------------------------------------------------------------------------------------------

[Jim McGinnis]

Wayne,

Just as an experiment I went ahead and set the DIV values to 16. I didn't scan the source code to determine if it would be processed.

In the end, the build it created behaved the same as if the DIV settings were 1. Likely ignored.

I will gen up a utility to configure both the CTC and SIO devices.

Cheers

Jim

[Wayne Warthen]

Hi Jim,

I just checked in a fairly significant update to the SIO driver that makes it CTC aware (if a CTC is configured in the system).  I think this will completely address your issues.  For systems where a CTC is configured, the SIO driver will intelligently combine the available divisors of the SIO and the CTC to produce any possible baud rate the system can support.  The MODE command can be used to implement the baud rates.

This update was checked into the dev branch at GitHub.  You will need to download the source and build it.  The config variables have changed a little, so review those.

Thanks,

Wayne

[Jim McGinnis]

Wayne,

THANKS!!!

Just amazing how generous you are with your time. Just amazing. Let us know if there is anything we can do to make your life easier or more interesting.

I will pull the dev branch down and build. I have an SC126 triple stack designed and the CTC and CIO/0 or SIO/2 bord is in the middle. FDC adn PPIDE on top.

I understand that there are likely parameter changes involved. Very fine!!!

Jim

[Jim McGinnis]

Wayne,

I have pulled the dev branch and configured what I could find for the CTC.

I am somewhat confused by the very simple CTC enable - but nothing else in the cfg_scz180.asm relative CTC addressing. What are the assumptions and how are they configured?  I looked at CTC.asm and it seems to be a 50 Hz timer configuration that utilizes A/B or C/D CTC channels - depending on which "production" board you are using. I am not using a production board - tit is similar to the EZZ80 implementation. That seems to be now called STD in your selectors.

I assume that SIO0ACTCC is intended to select the CTC Channel (A,B,C,D) that feeds the SIO Port A, B, etc.. Is this correct? I am thrown by the terminology in the comment.

I can configure my CTC and SIO chips as follows:

SIO 0x80 or 0x84

CTC 0x88 or 0x8C

I have made the following assumptions that are not correlated to the code or actual operation, yet.

For SIO at 0x80, corresponding CTC is at 0x88?

For SIO at 0x84, corresponding CTC is at 0x8C?

Thanks for your help and guidance!!

Jim

SCZ180_126.asm snippet...

;------------------------------------------------------------------------------------------------
CTCENABLE       .SET    TRUE            ; ENABLE ZILOG CTC SUPPORT

SIOENABLE       .SET    TRUE            ; SIO: ENABLE ZILOG SIO SERIAL DRIVER (SIO.ASM)
;

SIODEBUG        .SET    FALSE           ; SIO: ENABLE DEBUG OUTPUT

SIOCNT          .SET    1               ; SIO: NUMBER OF CHIPS TO DETECT (1-2), 2 CHANNELS PER CHIP

SIO0MODE        .SET    SIOMODE_STD     ; SIO 0: CHIP TYPE: SIOMODE_[STD|RC|SMB|ZP]

SIO0BASE        .SET    $80             ; SIO 0: REGISTERS BASE ADR
;
SIO0ACLK        .SET    1843200         ; SIO 0A: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800

SIO0ACFG        .SET    SER_19200_8N1   ; SIO 0A: SERIAL LINE CONFIG
SIO0ACTCC       .SET    0               ; SIO 0A: CTC CHANNEL CLOCK SCALER, (0-3), -1 FOR NONE

;
SIO0BCLK        .SET    1843200         ; SIO 0B: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800

SIO0BCFG        .SET    SER_19200_8N1   ; SIO 0B: SERIAL LINE CONFIG
SIO0BCTCC       .SET    1               ; SIO 0B: CTC CHANNEL CLOCK SCALER, (0-3), -1 FOR NONE

[Jim McGinnis]

Wayne,

I read your post to Anna.

The board I am using has the interrupt chain pass through the CTC and SIO in a typical fashion. And the CTC A and B are connected to the corresponding SIO clocks for A and B.

Thanks!

Jim

[Wayne Warthen]

Hi Jim,

Will try to answer inline below...

-Wayne

On Friday, April 17, 2020 at 12:22:08 PM UTC-7, Jim McGinnis wrote:

Wayne,

I have pulled the dev branch and configured what I could find for the CTC.

I am somewhat confused by the very simple CTC enable - but nothing else in the cfg_scz180.asm relative CTC addressing. What are the assumptions and how are they configured?  I looked at CTC.asm and it seems to be a 50 Hz timer configuration that utilizes A/B or C/D CTC channels - depending on which "production" board you are using. I am not using a production board - tit is similar to the EZZ80 implementation. That seems to be now called STD in your selectors.

Yes, the CTC driver just handles the CTC timer interrupts.  The base port address of the CTC is set in your config file as CTCBASE.  The CTC driver has 4 modes which determine the two channels and the timer constants for each channel.  Yes, they are designed to produce a 50Hz periodic timer interrupt which is the RomWBW standard.  Since your hardware is not one of the standard CTC modules, you will either need to configure your hardware to match one of the existing ones or add a new "mode" for your hardware.  With all that said, in your case, I would think you do not want CTC interrupts at all.  I would assume you want to use the Z180 for the 50Hz timer interrupt.  Is this correct?  If so, I need to add a way to allow the CTC to be enabled, but not be configured for timer interrupts at all.  Please let me know.

 

I assume that SIO0ACTCC is intended to select the CTC Channel (A,B,C,D) that feeds the SIO Port A, B, etc.. Is this correct? I am thrown by the terminology in the comment.

Yes, poorly worded, I will fix it.  You are correct.  You are selecting the CTC channel to associate with the SIO port.

 

I can configure my CTC and SIO chips as follows:

SIO 0x80 or 0x84

CTC 0x88 or 0x8C

Having the SIO at 0x80 and the CTC at 0x88 is pretty standard, but either should be fine for RomWBW as long as you configure the SIO and CTC base addresses apropriately.

 

I have made the following assumptions that are not correlated to the code or actual operation, yet.

For SIO at 0x80, corresponding CTC is at 0x88?

For SIO at 0x84, corresponding CTC is at 0x8C?

There is no hard-coded tie between the SIO address and the CTC address.  The CTC address is defined by CTCBASE.  The SIO address is defined by SIO0BASE (and potentially SIO1BASE if there is a second SIO).

 

Thanks for your help and guidance!!

Jim

SCZ180_126.asm snippet...

;------------------------------------------------------------------------------------------------
CTCENABLE       .SET    TRUE            ; ENABLE ZILOG CTC SUPPORT
SIOENABLE       .SET    TRUE            ; SIO: ENABLE ZILOG SIO SERIAL DRIVER (SIO.ASM)
;
SIODEBUG        .SET    FALSE           ; SIO: ENABLE DEBUG OUTPUT
SIOCNT          .SET    1               ; SIO: NUMBER OF CHIPS TO DETECT (1-2), 2 CHANNELS PER CHIP
SIO0MODE        .SET    SIOMODE_STD     ; SIO 0: CHIP TYPE: SIOMODE_[STD|RC|SMB|ZP]
SIO0BASE        .SET    $80             ; SIO 0: REGISTERS BASE ADR
;
SIO0ACLK        .SET    1843200         ; SIO 0A: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO0ACFG        .SET    SER_19200_8N1   ; SIO 0A: SERIAL LINE CONFIG
SIO0ACTCC       .SET    0               ; SIO 0A: CTC CHANNEL CLOCK SCALER, (0-3), -1 FOR NONE
;
SIO0BCLK        .SET    1843200         ; SIO 0B: OSC FREQ IN HZ, ZP=2457600/4915200, RC/SMB=7372800
SIO0BCFG        .SET    SER_19200_8N1   ; SIO 0B: SERIAL LINE CONFIG
SIO0BCTCC       .SET    1               ; SIO 0B: CTC CHANNEL CLOCK SCALER, (0-3), -1 FOR NONE

This looks correct, but I think the problem you are going to have is that the CTC will still be defaulting to CTCMODE_RC and will setup interrupt vectors that collide with the Z180.  I think I need to provide a way for your to allow the CTC to be used for SIO dividing, but not be configured as the timer interrupt.

Sound right? 

[Wayne Warthen]

On Friday, April 17, 2020 at 12:25:33 PM UTC-7, Jim McGinnis wrote:

The board I am using has the interrupt chain pass through the CTC and SIO in a typical fashion. And the CTC A and B are connected to the corresponding SIO clocks for A and B.

Sounds good. 

[Wayne Warthen]

I thought I should do a better job addressing some of the specific questions you originally asked.  See below.

Thanks,

Wayne

On Friday, April 17, 2020 at 10:47:58 AM UTC-7, Jim McGinnis wrote:

SIOnxDIV - can SIO0ADIV be used to FORCE the SIO divider instead of using the internal calculations you use?

The SIOnxDIV variables have been removed from the new SIO driver.  They were very misleading.  They were never a mechanism to select the hardware divisor.  They were intended to be a way to simplify the entry of a the SIO clock rate for some SIO boards that had onboard chips to pre-divide the incoming clock.  It never applied to the RC hardware.

 

Build: SC126

The RomWBW 3.0.1 SIO configuration, when configured for 1.8432 MHz clock and 19200 Baud is calculating a 64 divisor which is not the same as the divisor being calculated for RomWBW 2.9.2.pre32 with the same parameters - .pre32 installs 16 as the divisor.

Yeah, I can't remember why I changed this, but it was always just a hack.  The new driver does the baud rate divisor derivation correctly and robustly using all possible combinations of SIO and CTC divisors.

 

I use a CTC device to feed the SIO/0 or SIO/2 clocks. Unfortunately, when 64 is instilled into the SIO, my baud options are limited to 9600 or less.

I tried to search all changes to SIO.ASM and was not successful in isolating a change that would affect the divisor calculation. But I am a git noob and it may be there in actuality ;-)

Not your fault.  This was a limitation of the old SIO driver.

 

I am currently using a utility to set up the CTC A and B for the two SIO channels that are COM2 and COM3 on the SC126.

I will develop another utility to manually set the SIO registers next.

This should be possible, but I think the MODE command will do what you need.

 

Just curious why I am getting different results with these builds for SIO divisor setting and wondering if I can hard wire the divisor using SIO0ADIV, SIO0BDIV, etc?

Nope, SIOnxDIV never controlled the SIO divisor itself.  They were terribly misleading variables and they are now gone.

 

I am very happy with the other beneficial changes found in 3.0.1.  Really great work on your part to maintain such a "heavy" implementation that addresses so much hardware. Phenominal, actually. Gutsy.

Thanks!  :-) 

For reference, the only differences in the configurations are that in the 3.0.1 setup, I limit the SIO discovery to a single chip and the 3.0.1 addition of a CTCC parameter, which I am not using (-1).

The SIO is addressed per EZZ80 nets and is configured to 0x80 base. The CTC is fed via a 1.84320 mHz clock.

 

When the CTC Counter is /6 on the 2.9.2.pre32 build, I can clock the SIO A or B port to 19,200. the CTC clock is 307.202 kHz.

307202 / 16 = 19200.

When the CTC Counter is /3 on the 3.0.1 build, the CTC clock is 614.404 kHz.

614404 / 64 = 9,600

When the CTC Counter is /6 on the 3.0.1 build, the CTC clock is 307.202 kHz

307202 / 64 = 4,800

This all makes sense.  The new SIO driver should obviate some of this hand computation though.

 

I have tested the setups using a Kermit4.11 client built for CPM3 and a Linux C-Kermit Server. When the Baud rates are set according to the data above, everything works.

Great.

 

I assume that my configuration settings are misleading the algorithm on 3.0.1.

Hopefully no longer the case in the latest code. 

[Jim McGinnis]

Wayne:

I performed a Build and ran into errors (see below) when using "SCZ180"/"SC126" selection.

The errors are all CTC related in the "SC126" build. I am researching those since I am very interested in how these references are defined...

I did find the cfg_master.asm file with the SAMPLE definitions inside. I will put the missing definitions into the top level customization file as equates (since they don't exist as .EQU elsewhere) and proceed.

I also found that after resolving those, that the INT_CTC0D is undefined. I found that defined in std.asm. Again, not sure why this is being missed.

Ahhh....   I just tripped over the following code in std.asm that indicates the CTC interrupt is not provisioned for Z180 processors. Only the Z80 processors. I need to just go back and create a utility for CTC/SIO configuration until the 50 Hz timer configuration is resolved for Z180 processors. I need to learn why the 50 Hz interrupt is required anyway. Perhaps for those without RTCs??

I will stop now - I think I may be stepping in the wrong direction here...

Comments or thoughts?

Jim

#IF (INTMODE == 2)

  #IF (CPUFAM == CPU_Z180)

; Z180-BASED SYSTEMS

INT_INT1        .EQU    0       ; Z180 INT 1
INT_INT2        .EQU    1       ; Z180 INT 2
INT_TIM0        .EQU    2       ; Z180 TIMER 0
INT_TIM1        .EQU    3       ; Z180 TIMER 1
INT_DMA0        .EQU    4       ; Z180 DMA 0
INT_DMA1        .EQU    5       ; Z180 DMA 1
INT_CSIO        .EQU    6       ; Z180 CSIO
INT_SER0        .EQU    7       ; Z180 SERIAL 0
INT_SER1        .EQU    8       ; Z180 SERIAL 0
INT_PIO0A       .EQU    9       ; ZILOG PIO 0, CHANNEL A
INT_PIO0B       .EQU    10      ; ZILOG PIO 0, CHANNEL B
INT_PIO1A       .EQU    11      ; ZILOG PIO 1, CHANNEL A
INT_PIO1B       .EQU    12      ; ZILOG PIO 1, CHANNEL B
INT_SIO0        .EQU    13      ; ZILOG SIO 0, CHANNEL A & B
INT_SIO1        .EQU    14      ; ZILOG SIO 1, CHANNEL A & B

  #ELSE
  
; Z80-BASED SYSTEMS

INT_CTC0A       .EQU    0       ; ZILOG CTC 0, CHANNEL A
INT_CTC0B       .EQU    1       ; ZILOG CTC 0, CHANNEL B
INT_CTC0C       .EQU    2       ; ZILOG CTC 0, CHANNEL C
INT_CTC0D       .EQU    3       ; ZILOG CTC 0, CHANNEL D
INT_SIO0        .EQU    7       ; ZILOG SIO 0, CHANNEL A & B
INT_SIO1        .EQU    8       ; ZILOG SIO 1, CHANNEL A & B
INT_PIO0A       .EQU    9       ; ZILOG PIO 0, CHANNEL A
INT_PIO0B       .EQU    10      ; ZILOG PIO 0, CHANNEL B
INT_PIO1A       .EQU    11      ; ZILOG PIO 1, CHANNEL A
INT_PIO1B       .EQU    12      ; ZILOG PIO 1, CHANNEL B

  #ENDIF

/////////////////////////////////////////// 1st Error Capture ///////////////////////////////////////////////

tasm -t180 -g3 -e -dROMBOOT hbios.asm hbios_rom.bin hbios_rom.lst
TASM Z180 Assembler.       Version 3.2 September, 2001.
 Copyright (C) 2001 Squak Valley Software
hbios.asm line 0129: Forward reference in equate: (CTCBASE)
hbios.asm line 0130: Forward reference in equate: (CTCBASE)
hbios.asm line 0131: Forward reference in equate: (CTCBASE)
hbios.asm line 0132: Forward reference in equate: (CTCBASE)
tasm: pass 1 complete.
hbios.asm line 0129: Forward reference in equate: (CTCBASE)
hbios.asm line 0130: Forward reference in equate: (CTCBASE)
hbios.asm line 0131: Forward reference in equate: (CTCBASE)
hbios.asm line 0132: Forward reference in equate: (CTCBASE)
HBIOS INT STACK space: 49 bytes.
HBIOS TEMP STACK space: 20 bytes.
DSRTC occupies 653 bytes.
ASCI occupies 834 bytes.
UART occupies 677 bytes.
sio.asm line 0665: Unused data in MS byte of argument. (200)
sio.asm line 0764: Unused data in MS byte of argument. (200)
SIO occupies 935 bytes.
FONTS occupy 0 bytes.
MD occupies 502 bytes.
FD occupies 2303 bytes.
PPIDE occupies 1594 bytes.
SD occupies 1951 bytes.
ctc.asm line 0020: Label not found: (CTCMODE)
ctc.asm line 0028: Label not found: (CTCMODE)
ctc.asm line 0036: Label not found: (CTCMODE)
ctc.asm line 0044: Label not found: (CTCMODE)
ctc.asm line 0057: Label not found: (CTCTIVT)
ctc.asm line 0057: Unused data in MS byte of argument. (8)
ctc.asm line 0064: Label not found: (CTCBASE)
ctc.asm line 0064: Unused data in MS byte of argument. (200)
ctc.asm line 0080: Label not found: (CTCPC)
ctc.asm line 0080: Unused data in MS byte of argument. (200)
ctc.asm line 0081: Label not found: (CTCPCC)
ctc.asm line 0081: Unused data in MS byte of argument. (200)
ctc.asm line 0082: Label not found: (CTCPC)
ctc.asm line 0082: Unused data in MS byte of argument. (200)
ctc.asm line 0093: Label not found: (CTCTC)
ctc.asm line 0093: Unused data in MS byte of argument. (200)
ctc.asm line 0094: Label not found: (CTCTCC)
ctc.asm line 0094: Unused data in MS byte of argument. (200)
ctc.asm line 0095: Label not found: (CTCTC)
ctc.asm line 0095: Unused data in MS byte of argument. (200)
ctc.asm line 0107: Label not found: (CTCMODE)
ctc.asm line 0110: Label not found: (CTCMODE)
ctc.asm line 0113: Label not found: (CTCMODE)
ctc.asm line 0116: Label not found: (CTCMODE)
ctc.asm line 0120: Label not found: (CTCBASE)
ctc.asm line 0120: Unused data in MS byte of argument. (200)
CTC occupies 62 bytes.
HBIOS space remaining: 16654 bytes.
tasm: pass 2 complete.
tasm: Number of errors = 36
TASM returned exit code 1
At C:\Users\Jim\Desktop\RomWBW-dev\Source\HBIOS\Build.ps1:128 char:29
+ ... ($LASTEXITCODE -gt 0) {throw "TASM returned exit code $LASTEXITCODE"}
+                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (TASM returned exit code 1:String) [], RuntimeException
    + FullyQualifiedErrorId : TASM returned exit code 1


C:\Users\Jim\Desktop\RomWBW-dev\Source>

/////////////////////////////////////////// 2nd Error Capture ///////////////////////////////////////////////

...

...

...

tasm -t180 -g3 -e  eastaegg.asm eastaegg.bin eastaegg.lst
TASM Z180 Assembler.       Version 3.2 September, 2001.
 Copyright (C) 2001 Squak Valley Software
tasm: pass 1 complete.
EASTEREGG space remaining: 77 bytes.
tasm: pass 2 complete.
tasm: Number of errors = 0
tasm -t180 -g3 -e  imgpad.asm imgpad.bin imgpad.lst
TASM Z180 Assembler.       Version 3.2 September, 2001.
 Copyright (C) 2001 Squak Valley Software
tasm: pass 1 complete.
Padspace space created: 512 bytes.
tasm: pass 2 complete.
tasm: Number of errors = 0
tasm -t180 -g3 -e -dROMBOOT hbios.asm hbios_rom.bin hbios_rom.lst
TASM Z180 Assembler.       Version 3.2 September, 2001.
 Copyright (C) 2001 Squak Valley Software
ctc.asm line 0041: Forward reference in equate: (INT_CTC0D)
tasm: pass 1 complete.
HBIOS INT STACK space: 49 bytes.
HBIOS TEMP STACK space: 20 bytes.
DSRTC occupies 653 bytes.
ASCI occupies 834 bytes.
UART occupies 677 bytes.
SIO occupies 935 bytes.
FONTS occupy 0 bytes.
MD occupies 502 bytes.
FD occupies 2303 bytes.
PPIDE occupies 1594 bytes.
SD occupies 1951 bytes.
ctc.asm line 0041: Forward reference in equate: (INT_CTC0D)
ctc.asm line 0057: Unused data in MS byte of argument. (8)
CTC occupies 68 bytes.
HBIOS space remaining: 16648 bytes.
tasm: pass 2 complete.
tasm: Number of errors = 3
TASM returned exit code 1
At C:\Users\Jim\Desktop\RomWBW-dev\Source\HBIOS\Build.ps1:128 char:29
+ ... ($LASTEXITCODE -gt 0) {throw "TASM returned exit code $LASTEXITCODE"}
+                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (TASM returned exit code 1:String) [], RuntimeException
    + FullyQualifiedErrorId : TASM returned exit code 1


C:\Users\Jim\Desktop\RomWBW-dev\Source>

[Jim McGinnis]

Hi Wayne. Wow. Brilliant replies. Thanks!

Sorry for the out of order replies. I didn't see your very thorough replies until after I waded through the assembly errors.  ;-))

I think the overall solution is to prevent, for Z180 builds, the configuration of the CTC timer. You are right. Although at some time I might want to use the CTC ports C/D for very long timer - and an interrupt may be in store IF i can learn enough to determine how to place that generic interrupt into the scheme.

I will fiddle a bit to block generation of the CTC timer driver - since it is not used in the Z180 cobntext and see what flows from that....

I am pleased to be challenged by this right now. Thanks!!

Jim

[Wayne Warthen]

Hi Jim,

Give me a little time to work through.  Basically, you are bumping into problems because I never really expected the CTC to be used in Z180 systems.  However, I see how what you are doing is logical.  Basically, the same issue I brought up before -- I need to provide a way to enable the CTC, but not use it as a timer.

Give me  an hour or two.

Thanks,

Wayne

[Jim McGinnis]

Wayne:

I am giggling like a little girl here... ;-//   A few hours? I have been so involved with Safety Critical Avionics development and certification that nothing happens in a couple of hours!  Weeks is normal. Days for crude protos without safety testing. Now I am working in retirement doing Hybrid Fiber-Optic Transceiver design where the software is a few thousand SLOC.  Bare die stuff. I have it memorized it is so compact...

Thanks again. Just so much fun! Seriously!

Jim

[Wayne Warthen]

On Friday, April 17, 2020 at 1:38:23 PM UTC-7, Jim McGinnis wrote:

Wayne:

I am giggling like a little girl here... ;-//   A few hours? I have been so involved with Safety Critical Avionics development and certification that nothing happens in a couple of hours!  Weeks is normal. Days for crude protos without safety testing. Now I am working in retirement doing Hybrid Fiber-Optic Transceiver design where the software is a few thousand SLOC.  Bare die stuff. I have it memorized it is so compact..

OK, well, I don't know what half of those words mean.  :-)

Anyway, I just checked in some updates at GitHub on branch dev.  There is a new config variable called CTCTIMER.  If CTCENABLE is true, then CTCTIMER will determine if the CTC will be programmed to do the periodic interrupt timer.  For all Z180 platforms, CTCTIMER defaults to false.

So, in your case, just set CTCENABLE to true (as you have been) and leave CTCTIMER false.  This should result in the CTC being used only for the SIO which is what I think you are after.

Won't be surprised if we need to go one more round on this, but try it and let me know how you do.

Thanks,

Wayne

[Jim McGinnis]

Hi Wayne,

I will proceed to trying the new dev branch. I will keep you posted!

Thanks

Jim

[Jim McGinnis]

Hi Wayne:

RomWBW v3.1-pre.4 is loaded and running. I am able to configure the SIO port speed and the boot up default is following the configuration - 19200.

I have set the baud rate successfully (tx verified) from 150 baud through 921,600 baud. And most of the values in between! The scope traces are good.

I can text send data (using pip) to COM2 or COM3 and the data appears on a TeraTerm session just fine.

What is not clear is why Kermit-80 is sending data to the C-Kermit Server (pi) and immediately experiences an interrupt panic. This is new for this hardware configuration. I can't see why an interrupt could being generated from the ctc.asm file. It is not setting the generate int bit in the SIO. At least not there. I wish I knew how to decode the panic text. I will research that segment of the code. It might tell if it is SIO or CTC?

The build compiles cleanly. No anomalies.

Any thoughts on why receive characters are causing the panic?

The C-Kermit Server is receiving data from the Z180 via the serial port. It records receipt of the first packet. Normally, it responds to each packet. I am assuming that it is the handshake reply back to the Z180 that is generating the panic.

If you can decode the panic string, I can copy it and send it here:

>>> PANIC: @0A26[022A:FEFF:FFFF:FFFF:04FC:8B60:07D5]  Continue? (Y/N):

                        PC     AF    BC    DE     HL    SP     IX     IY           

I tried to exchange data from the TeraTerm back to the Z180. The first character sent from TT causes the same INT panic.

Thanks for your help!

Jim

;

[Wayne Warthen]

Hi Jim,

OK, well some progress.

The panic does not imply an interrupt was generated.  Do you have some other reason to believe an interrupt caused this?

Which serial port is Kermit server running on?  If you are saying that you can PIP data out of a serial port, but when Kermit sends data out of the same port the system panics, that is very odd.

I want to be clear.  You can send and receive data over the serial port, but any attempt to do a file transfer over the same serial port causes this panic?

Thanks,

Wayne

[Jim McGinnis]

HI Wayne.

Yes, I realize my data isn't very clear. I assumed an INT was occurring based on the INT keyword appearing during some of the panic output.

The two setup cases are as follows:

Case1: Kermit Session

Kermit-80 is being used on the SC126 running CPM3 to talk to a C-Kermit Server on a Raspberry Pi. This has been my traditional method of moving files between the outside world and the SC126. Prior to RomWBW 3.1, I was using RomWBW 2.9.2.pre32 and earlier versions with a very successful experience.  I would bring up the system where the SIO would be recognized and initialized by RomWBW with a 16 divisor. Knowing that, I simply programmed the CTC (simple MBASIC program for now) for the A and B ports which feed the SIO rx/tx clocks for ports A and B. Prior to 3.1pre.4, this always worked.

The case setup is quite simple and establishes a COUNTER mode operation with a divisor of 6. The math works out such that the source crystal for the CTC is 1.8432 mHz and the resulting clock into the SIO from the CTC is 16x19,200.

I have been transferring files using this setup for months or so very successfully. Even when pushing large images and libraries. No errors.Using CPM2.2 prior to CPM3 was also successful in this setup.The only difference was that the SC126 Kermit build was for CPM2.2 - KERM411.

To translate that setup to RomWBW 3.1pre.4 I have done the following:

Flashed a new chip with RomWBW 3.1.pre.4 off-board and verified the flash contents. Brought up the board using CPM3 boot image on a new SD card with Kermit411A (my nomenclature for a build that runs on CPM3 instead of CPM2.2)

Physically connected the Raspberry Pi via a DE-9 connector and a breakout of Pi pins to a DE-9 ttl to RS-232 translator. This has been in use for months without issues.  I have a serial cable breakout for looking at the signals on the wire with a scope. The SC126 mezzanione card is equipped with MAX232 chip to provide RS-232 IO. THis has been in use for about 50 days without issues - driving a printer and exercising Kermit to the Pi for RomWBW 2.9.2preXX

When booting, the CTC address (0x88) is reported and the SIO chip iports A and B are configured at port 0x80+.

At command prompt (CPM3) the MODE command reports all four serial ports as expected and with the RomWBW configured defaults.

Using the DEVICE command, AUXIN: and AUXOUT: are set to COM2: or COM3:, depending on the test.

CPM3 version of Kermit is started using 19,200 default, no parity, and no flow control.COM2 is being used. Pi C-Kermit is also started and set into server mode - as is usually the case. It is also set for 19,200 with no parity and flow control. This is traditionally how it has been setup in the past.

Issuing a REMOTE DIRECTORY (REM DIR) command on the SC126 Kermit session causes C-Kermit to see the packet (count goes up, no errors generated by C-Kermit). This is when the PANIC occurs on the SC126.

If I kill the C_Kermit session on the Pi and rerun the exact same scenario, the SC126 Kermit application simply waits until the server replies to the initial packet. I can Ctrl-C out of the Remote Directory request or any other Kerfmit command involving the C-Kermit server without fail. It simply returns to the Kermit command prompt. IN this case, no data has been sent from the server and SC126 Kermit is OK.

I repeat this scenario avoiding the MAX232 and instead use COM3 which is using one of the provided TTL to USB converters and utilize a USB port on the Pi Server. this also works correctly prior to RomWBW 3.1pre.4. I limit the speed to 19,200 in this case. When tested with RomWBW 3.1pre.4 - the same conditions are present and the PANIC occurs.

Case 2: Serial IO to a Terminal Program.

This setup is similar to the last expect that COM2 or COM3 is connected to a TerraTerm session on a PC.

I can PIP a test file to the TT session without failures.

If I connect SC126 Kermit to the same port, I can see the REM DIR packet on TT (Capture it). The second I hit return or any other character on the TT session sending the keyboard stroke to the SC126, the PANIC occurs.

I am open to another scenario that involves simple IO transfers via the COM ports. The latter case is fraught with uncertainty.

I will revert to RomWBW 2.9.2pre32 this morning to ensure that the HW setup is still in tact and that Kermit works; it will use the RomWBW 16

SIO divisor. As an additional test, I will de-configure the CTC in 3.1pre.4 and see if I am able to get Kermit running with the limited baud rates available there.

I will look for a terminal program for CPM2.2 to test with the TeraTerm setup.

I will report those results after breakfast here.

Best regards,

Jim

[Jim McGinnis]

Comments below...

On Saturday, April 18, 2020 at 12:11:06 AM UTC-4, Wayne Warthen wrote:

Hi Jim,

OK, well some progress.

The panic does not imply an interrupt was generated.  Do you have some other reason to believe an interrupt caused this?

 Reasonable. I am over my head with the PANIC right now.

Which serial port is Kermit server running on?  If you are saying that you can PIP data out of a serial port, but when Kermit sends data out of the same port the system panics, that is very odd.

See proper explanation in next reply. ;-)

I want to be clear.  You can send and receive data over the serial port, but any attempt to do a file transfer over the same serial port causes this panic?

Not quite. Any character sent back to the SC126 appears to cause the panic. I need a third case using a program that does simple IO to the remote side. Like a TALK program or similar. See next reply.

[Jim McGinnis]

Wayne: I have edited the replies for more clarity and content. So, the email versions may be slow to arrive with the corrected text...

Cheers

Jim

[Jim McGinnis]

Wayne:

Now I assume it is a cabling problem. But can't be sure. Replaced all the cables. Plugged and unplugged everything associated with the test setup and now Kermit is HAPPY. I can change speeds and the Kermit connection works perfectly. I now need to see which cable is flaky by elimination. EBay serial DE-9 cables. So, that says something.

I think we can all sleep soundly tonight. I will suggest that 3.1pre.4 is in pretty good shape!

Thanks again for your patience!

Jim

[Jim McGinnis]

Well, it is not cabling.

Problems repeat themselves after reboots or resets - not every time, but most of the time. Have tried reprogramming the CTC after boot for 3.1pre.4. No joy. I have not tried to reprogram the SIO after boot. It is a shame that Zilog decided you just don't need to read back certain registers after writing them.   I see PANICs with the "INT" text embedded as well.

I reverted back to 2.9.2pre32 and I get reliable behavior. Every reboot or reset. I have to program the CTC using the tool and it just works.

Using Kermit-80 as a terminal to the PC running TeraTerm is the test case tool set.

For now I am going back to 2.9.2 build and write the tool for setting up SIO and CTC after boot. I need to get past this for now.

I am concerned about programming the SIO and CTC using the system bus clock of 18 MHz and I believe 1 ws. My layout is somewhat "long" on the paths. Perhaps 3.1pre.4 has some different timings vs 2.9.2 regarding the programming of the SIO or CTC. Perhaps there is more time between writes. In my case, the SIO and CTC parts are both 8 MHz rated parts.

If I make any discoveries, I will be sure to pass them on even though they may be limited to just my case.

Take care,

Jim

[Wayne Warthen]

On Saturday, April 18, 2020 at 8:54:42 AM UTC-7, Jim McGinnis wrote:

Well, it is not cabling.

Problems repeat themselves after reboots or resets - not every time, but most of the time. Have tried reprogramming the CTC after boot for 3.1pre.4. No joy. I have not tried to reprogram the SIO after boot. It is a shame that Zilog decided you just don't need to read back certain registers after writing them.   I see PANICs with the "INT" text embedded as well.

I reverted back to 2.9.2pre32 and I get reliable behavior. Every reboot or reset. I have to program the CTC using the tool and it just works.

Using Kermit-80 as a terminal to the PC running TeraTerm is the test case tool set.

For now I am going back to 2.9.2 build and write the tool for setting up SIO and CTC after boot. I need to get past this for now.

I am concerned about programming the SIO and CTC using the system bus clock of 18 MHz and I believe 1 ws. My layout is somewhat "long" on the paths. Perhaps 3.1pre.4 has some different timings vs 2.9.2 regarding the programming of the SIO or CTC. Perhaps there is more time between writes. In my case, the SIO and CTC parts are both 8 MHz rated parts.

If I make any discoveries, I will be sure to pass them on even though they may be limited to just my case.

Hi Jim,

Thanks for all the detailed info.  I am somewhat stymied by this behavior.  It does sound a little like you might be on the edge of what the SIO/CTC can do.  Definitely worth trying to slow things down.  You could increase the Z180 wait states and even reduce it's speed to half oscillator.  These lines in your config would do that:

Z180_CLKDIV .EQU 0 ; Z180: CHK DIV: 0=OSC/2, 1=OSC, 2=OSC*2

Z180_IOWAIT .EQU 2 ; Z180: I/O WAIT STATES TO ADD ABOVE 1 W/S BUILT-IN (0-3)

I am going to try some testing on my SC126.  I will see how close I can come to recreating your setup.

Thanks,

Wayne

[Wayne Warthen]

On Saturday, April 18, 2020 at 9:01:21 AM UTC-7, Wayne Warthen wrote:

I am going to try some testing on my SC126.  I will see how close I can come to recreating your setup.

So, I now have my SC126 running with a KIO card which is essentially a CTC and SIO.  Although RomWBW sends a simple config byte to the KIO at boot, it otherwise does not know the difference.  COM0/1 are the ASCI ports of the Z180.  COM2/3 are the SIO ports.  The SIO port clocks are fed from the CTC and I have no trouble setting any standard baud rate.  It seems to be working correctly.

I tried running KERM411 under CP/M 3 on my SC126 w/ AUX port set to COM2 (the first SIO port).  COM2 is set to 19200 baud.  I am using Tera Term on my PC.  I am having no trouble sending and receiving files.  My config file is below.

Not quite sure where to go from here Jim.  Let me know if you are making any progress on your end.

Thanks,

Wayne

KIOENABLE .SET TRUE ; ENABLE ZILOG KIO SUPPORT

;

CTCENABLE .SET TRUE ; ENABLE ZILOG CTC SUPPORT

CTCBASE .SET KIOBASE+$04 ; CTC BASE I/O ADDRESS

;

SIOENABLE .SET TRUE ; SIO: ENABLE ZILOG SIO SERIAL DRIVER (SIO.ASM)

SIOCNT .SET 1 ; SIO: NUMBER OF CHIPS TO DETECT (1-2)

SIO0MODE .SET SIOMODE_STD ; SIO 0: CHIP TYPE: SIOMODE_[STD|RC|SMB|ZP]

SIO0BASE .SET KIOBASE+$08 ; SIO 0: REGISTERS BASE ADR

SIO0ACLK .SET 1843200 ; SIO 0A: OSC FREQ IN HZ

SIO0ACTCC .SET 0 ; SIO 0A: CTC CHANNEL 0=A, 1=B, 2=C, 3=D, -1 FOR NONE

SIO0BCLK .SET 1843200 ; SIO 0B: OSC FREQ IN HZ

SIO0BCTCC .SET 1 ; SIO 0B: CTC CHANNEL 0=A, 1=B, 2=C, 3=D, -1 FOR NONE

[Jim McGinnis]

Hi Wayne,

Thanks for the extensive support. I created an MBASIC program to slow program the CTC  and SIO chips.

It seems to be reliably programming the chips as the clock rates change as expected.

The very odd thing is that without the panics, the SIO channels can send data but not receive.

The data appears at the pins of the SIO as expected. I can transmit all day long; regardless of speed.

The SIO handles the CTS inputs from the distant devices. The printer is very happy.

I tried putting the SIO ports A or B into loopback and I cannot get the received data to be processed.

Kermit connects but does not see any returned data. Either in terminal mode or in file transfer mode.

The DEVICE settings for AUXIN and AUXOUT are set to the same SIO port in use, either COM2, or COM3.

COM3 is TTL requiring conversion to USB.

COM2 is TTL to MAX232CPE and then mechanically to a DE-9.

I scoped all the Address and Data bus signals on the "SIO/CTC" board and they look very reasonable.

Slowing the SC126 clock (adjusting baud rate with that slowdown) and inserting more wait states makes no difference. ;-((

So, now I believe the issue is in the mezzanine card layout and routing. I don't have the logic analyzer setup. But will do that.

I have a SIO/CTC card in RC2014 format that I am going to install to see how that works.

I will also put 3.1pre.4 back into the system with new sd card for it and see how the MBASIC CTC and SIO programmer works - to see if the PANIC events go away. Just for grins.

I will keep you posted if there is anything of interest.

Very best regards and have a good evening!

Jim

[Jim McGinnis]

Hi Wayne. I sent two PMs. The second one has the good news. I had an old card I designed with simple sio + osc. I put jumpers for IEI and IEI pull ups. 10k. Installed the card and setup for loop back. It works just fine.
I determine INT and IEO get asserted in this chain of one with both pull ups engaged. Scope shows the signals.

I have a logical path forward. Once I am sure the sc126 mezzanine card SIO/CTC combo works, I can explore RomWBW 3.1 and whether programming the chips on my board are sensitive to faster writes, etc.

Enjoy the weekend.

Cheers
Jim

[Jim McGinnis]

Good morning Wayne:

Wow! What a roller-coaster.

I found out what, in addition to the IEI and IEO pull-ups that was hamstringing me!   BAD CHIPS.

I have a collection of SIO/2, SIO/0, and CTC chips. I waited for the latest SIO/2 batch for three months from Mouser.

The JM002 mezzanine board has jumpers to use SIO/2 or SIO/0 bonded chips. Both work if the chips are good.

Executive Summary:

SIO/2 chips with reasonable looking markings but with production dates 1138 were good to TX but not a single interrupt could be coerced from them.

BAD CHIPS!

SIO/2 chips with production dates 1903 or 1801 are good. They work properly.

SIO/0 chips with production date 1832 work properly.

CTC chips with 1828 date codes all work correctly.

I just happened to pick a good SIO/2 chip when I tried the old JM001 board. And it worked.

Now, I have three SIO/2 chips for the bin!

I do need to modify the JM002 board to include optional 10K pull-ups for IEI and IEO nets.

I am exhausted.

What a trip.

Thank you for being a willing participant!

Ever grateful.

Jim

[Jim McGinnis]

Oh, and I did move over to RomWBW 3.1pre.4 and all is well with that build and the JM002 card.

What a relief!

Jim

[Wayne Warthen]

Excellent.  Very happy this is all working for you Jim.

-Wayne