Z85C30

[Tadeusz Pycio]

I don't want to interrupt an interesting discussion in a thread about RCBus projects. I have started to investigate the SCC module and its behaviour during vector interrupts. It seems to work and I wonder if the generation of the WAIT signal is necessary, the interrupt vector appears quite early (0x40 in this example). I still need to analyse this in detail.

I have put particular emphasis in this module on compatibility with IM2 and.... I swapped the IEI lines with IEO :( 
A new version of the module has to be created. I will add the possibility of choosing address 0x80 or 0xA0.

[Tadeusz Pycio]

I decided not to build a fix version 1.1, but to go straight to development version 2. The default value for WAIT cycles was left in place, and the possibility of requesting it via (E)SCC was added. Allowing different clock sources for each channel. Added address selection jumper (0x80 or 0xA0).

[Tadeusz Pycio]

I think I have completed the hardware work for the moment. It remains, smooth out the software and the ESCC and SCC ICs can be considered to work in the RCBus ecosystem. It's a bit of a shame to use these controllers only for asynchronous transmissions, maybe one day I'll take up the challenge to use them for CP/Net networking. As soon as the new modules are fully tested I will make the production files available and maybe someone will build a similar module under PLCC chips. These can also often be obtained for a pittance.

[Tadeusz Pycio]

I have built a revised (E)SCC module, time for testing. I hope I haven't made any mistakes this time.

[Tadeusz Pycio]

I have not been able to buy an ESCC in a DIP housing, but have found in PLCC. The Z85230 chips, compared to the SCC Z85C30, have a larger receiver FIFO buffer (8 bytes instead of 3) and a 4 byte transmitter FIFO is available. It seems that I am forced to design such a module under PLCC.

Why? Thanks to such buying opportunities, I am able to build two complete modules for the price of one Z80 SIO from the official distribution channel.

[Tadeusz Pycio]

I am forced to stop working on the new module until I solve an unexpected problem with the current one. So far I have been using the SCC as a terminal port and have not discovered the error this module was generating. The error occurs when transferring more data and consists of incorrect readings of incoming data. The graph shows the moment of failure caused by the increasing delay in reporting the available character in the buffer. Normally, the information that a received character is available appears in the middle of the STOP signal of a serial transmission. I have already ruled out the input circuit as a source of potential errors. At the moment there is no idea how to solve this problem, I assume that the SCC chips from VLSI are licensed chips from Zilog. Perhaps I should look for one from Zilog?

[Tadeusz Pycio]

A questionable lead in the search for a solution to the problem. In the documentation I found a paragraph about the SCC read cycle requirements that my module does not meet (even though the analysed waveforms contradict this, but it is possible that this is the internal SCC requirements that cause the build-up of delay in reporting the availability of a character in the buffer).

"All register addresses and /INTACK are stable throughout the cycle. The timing specification of SCC requires that the /CE signal (and address) be stable when /RD is active."

The document also includes a glue logic diagram (for the Z180) which is overkill to be realised with discrete TTL ICs (they go on to suggest using CPLDs). It also does not solve the problem it generates when accepting interrupts in IM2 mode (generation of /WAIT signal for all devices using interrupts on the bus). I admit that I did not expect to encounter so many problems with the implementation of this project.

[Tadeusz Pycio]

It appears that full implementation of the SCC requirements will require such an layout. This has expanded a bit, but fortunately it will be possible to implement on the GAL22V10 chip saving the glue logic shown here along with the address decoder - instead of 5 ICs there will be one. I will build the model and see if the bug plaguing previous models will be eliminated.

[Tadeusz Pycio]

I couldn't find an SCC from Zilog on short notice, but I did get AMD chips. The behaviour of AMD's SCCs is the same as VLSI, so I'm ruling out manufacturer specifics.

While waiting for delivery, I designed and programmed the GAL, so it's time to try it out with changing the read and write controls.

During the design process I was once again disappointed with the WinCUPL software, after some source change the jedec file stopped generating, without any error message. I needed to learn the specifics of GALasm quickly to be able to finish the project. Am I the only one having such problems with WinCUPL, or is this its typical behaviour? The source file with changes adapted for GALasm generated in it without any problem. The GALasm compiler can be found here: https://github.com/daveho/GALasm

[Bill Shen]

I've read many negative comments regarding WinCUPL and stayed away from it until last few months when I needed a tool to design 22V10.  After half dozen 22V10 designs, I found WinCUPL adequate if I do the following:
* Do not use its simulator
* Write equations using a plain text editor and only use WinCUPL to compile the design.
* This part is due to my inexperience, but where possible I write out the logic expression as sums of products without using FIELD statement.  However, I do use FIELD statements when building truth table.
  Bill

[Tadeusz Pycio]

I went back to trying to get my SCC module up and running. It looks like it is working correctly though, but when the clock divider is higher than 1 for BRG. There are divisors of 1, 16, 32 and 64 available for the SCC chips.
With a divisor of 1 transmission errors occur, with 16 there are no longer any errors, but this significantly limits the available transmission speeds, for a clock of 7.37MHz a maximum of 57600bps can be achieved. I'll admit that I have no idea how to solve this problem, and maybe someone has more experience with these chips and can suggest why divider 1 is so capricious.

[Mark T]

Is a divisor of 1 only for synchronous serial? I have seen this limit on other serial interfaces.

It might need a higher clock speed so it can sample close to the centre of each serial bit.

[Douglas Miller]

It is for receiving that 16x or higher is needed. The receive engine has to sync-up with the start bit and be able to remain in sync for the data bits. 16x seems to be the minimum in order to guarantee that - provided there is not too much difference between the receiver's clock rate and the sender's clock rate. Note that often time the clock source for baud rate dividers may not exactly divide down to the selected baud, and if the other end of the connection does not have exactly the same baud then there is the potential for being out of sync by the time the 8th bit is being received. Even if both sides have the exact same baud frequency, there is no guarantee that the receiver clock is exactly in sync with the send.

[Tadeusz Pycio]

I was not very clear, it is the division of the pre-divider that goes to the count down counter that determines the transmission rate. I don't understand why dividing by 1 and counting down 96 gives transmission errors, but dividing by 16 and counting by 6 does not (the count values are two less).

Time Constant=CLK/(2*(baud rate)*(divider))   CLK=7.3728MHz; divider=1,16,32 or 64; Counter=Time Constant-2

[Douglas Miller]

It is the receive engine that needs to have it's input clock be 16x the data rate (baud). setting pre-divider to 96x and recv divider to 1x is NOT the same as pre-divider at 6x and recv divider at 16x. The receive engine needs to have a clock that is at least 16x the data rate in order to be able to sync-up with the character.

[Tadeusz Pycio]

It is not clearly stated in the documentation whether the pre-divider is related to the sampling of the incoming signal. If it is linked, this would be a big step backwards from the earlier Z80-SIO, as the 8MHz SCC would not cope with asynchronous transmission at speeds higher than 57600bps. Admittedly, my experience suggests that this is true of what you write about, but somehow I don't want to believe it since the SCC has a built-in DPLL to oversample the signal and it would be a huge waste of this chip's potential.

[Douglas Miller]

I am looking at the Z85C30 datasheet now. It appears to be essentially a Z80-SIO with a baud rate generator builtin. In the section on the BRG it does state:

"The clock mode is 1, 16, 32, or 64, as selected in Write Register 4, bits D6 and D7. Synchronous operation modes select 1 and Asynchronous modes select 16, 32 or 64."

It sounds like the DPLL is used for recovering clocks from NRZI and other such encoded synchronous streams. It is not part of the BRG or serial clock sources.

There do seem to be various limitations noted throughout the datasheet. One is:

"PCLK is not required to have any phase relationship with the master system clock. The maximum transmit rate is 1/4 PCLK."

I've not found what clock provides the input to the BRG, but assuming it is PCLK then you have some limitations imposed on the relationship to data rate.

[Tadeusz Pycio]

 Synchronous operation modes select 1 and Asynchronous modes select 16, 32 or 64."

You're right, I hadn't paid attention to that sentence. It suggests that the pre-division is related to sampling, especially as there is no mention by DPLL of support for NRZ coding which is used in asynchronous transmission for oversampling which confirms your assumption. It remains for me to see if I can disable the countdown timer by entering a value of 0 which would enable a transmission rate of 115200bps with a 7.37MHz clock.

[Tom Storey]

Very late reply, but I thought I'd chip in my experiences using WinCUPL and WinSIM.

I've done a lot of work in WinCUPL from GALs to the ATF750, and the ATF150x series CPLDs. It has its quirks, no two ways about it! You can start to recognise them with enough time spent "experiencing" it. :-) I think I have rarely experienced the issue with it failing to compile changes. But the tried and tested "fix" for these kinds of issues is to just quit and re-open.

WinSIM has even more quirks, and can sometimes get itself into a state where it stops responding to changes in the source file compiled in WinCUPL. Restarting WinSIM will resume normal operation. I haven't yet been able to figure out why this happens, but the "fix" is easy enough. I've probably experienced this more when compiling for the ATF150x CPLDs than simpler GALs.

There are also more severe cases where WinSIM will get itself into a proper twist and will quit with an error, and if you try to re-open the simulation it quits again with the same or similar error. In such cases you just have to start over again and rebuild your simulation. One thing that can absolutely contribute to this is deleting signals from the source file and recompiling while leaving those signals in the simulation. If you're going to do something like that I have found it safer to follow a simple procedure: delete the signal(s) from WinSIM first, save and close, then make the changes in WinCUPL, recompile and re-open WinSIM and carry on.

It's definitely very clunky software, and won't be to everyone's taste as a result. If you're inclined to push through and learn how to handle it, then you can still be productive. More time in the seat helps you recognise when something isn't right and then a restart of either or both applications will put things right again for a while. I push through for WinSIM more specifically, because I am big on simulating my designs rather than trying iteratively in-circuit. It may be clunky, but WinCUPL and WinSIM work well together and its extremely easy to make changes in WinCUPL and test them quickly in WinSIM, and many of my designs will work first time in-circuit as a result.

--
You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-comp/bd7bd856-d5ba-48e5-b30d-5822ea70d107n%40googlegroups.com.

[Tadeusz Pycio]

I have been able to build several projects using WinCUPL, only this project proved to be such a problem. I design the GAL a little differently, I first create the logic in Digital and simulate there. If it meets my expectations, I create the rules in WinCUPL based on the generated equations (theoretically Digital should be able to generate a WinCUPL file, but I've never succeeded). For this project, I did not build a GAL circuit, as analysis of the waveforms in the logic analyser did not show the SCC circuit to be particularly sensitive to the earlier appearance of the /CS signal before the /RD (/WR).

For information, in the SCC, the countdown timer can be disabled by entering a value of 0 into it, which allows a transmission rate of 115200bps at a clock of 7.37MHz.

It's a pity that this project has been sitting on the shelf for so many months, because I didn't pay attention to the sentence quoted earlier then I would have understood that the problem was with the software , not the hardware (I console myself that it's not only mine ;-), SCM also uses a divisor by 1).

[Brian Cockburn]

Tadeusz,

Have you considered trying to make a PCB layout that is dual-footprint (PLCC-44 & DIP-40)?  Overlapping the pad layouts is physically possible, just.  One side of the DIP-40 runs through the PLCC-44 meaning seven pads are on a 0.05" offset grid (twice).  Admittedly, routing is another, harder, issue.  But it does mean one PCB and the ability to use the much lower cost PLCC parts.

Cheers, Brian.

[Tadeusz Pycio]

Hi Brian,

This was my intention so that the final version of the module could use (E)SCC in DIP and PLCC housings. There was even such a preliminary design before I stopped work.

Today I should receive a shipment of the Z85230 in DIP (this one was already not as cheap as the previously presented chips), so I'll be able to get back to work, as I have one more thing to check - the behaviour of the glue logic on this module when acknowledging an IM2 interrupt for a source other than this module. It seems to me that the concept proposed by Zilog, which I used, would generate an unnecessary /WAIT signal in such a case. As I mentioned earlier, in this module I have placed particular emphasis on making it work correctly in IM2 mode.

[Tadeusz Pycio]

Design completed, now I need to check if the WAIT signal appearing (I won't be able to eliminate it completely, but I can shorten it significantly) during the interrupt acknowledgement will have a destructive effect on the slaves in the interrupt cascade. The PCB is not the prettiest, but I didn't want to deviate from the two-layer one.

[Brian Cockburn]

That's excellent work.

[Tadeusz Pycio]

The project is nearing completion. I have dispensed with a dedicated serial transmission clock, relying on the built-in divider being flexible enough that it is not necessary. I do regret a little that I didn't use soldered jumpers for the DMA handling request line, but these will be rare enough instances of such systems that a path can then be cut. The interrupts in IM2 mode work, the interrupt priority cascade does too. Interrupts from other devices in IM2 mode do not trigger the WAIT signal generator from this module.

The driver software in SCM has been corrected, I am currently planning to add support for the SCC family of chips to RomWBW, but this will take some time as I never got into the ins and outs of building drivers in RomWBW.

I also need to find some elegant way of detecting the 85C30 and 85230, so that I can take advantage of the benefits of ESCC.

[Alan Cox]

I also need to find some elegant way of detecting the 85C30 and 85230, so that I can take advantage of the benefits of ESCC.

See the Linux code I did long long ago

dev->type=Z8530;

/*
* See the application note.
*/

write_zsreg(&dev->chanA, R15, 0x01);

/*
* If we can set the low bit of R15 then
* the chip is enhanced.
*/

if(read_zsreg(&dev->chanA, R15)==0x01)
{
/* This C30 versus 230 detect is from Klaus Kudielka's dmascc */
/* Put a char in the fifo */
write_zsreg(&dev->chanA, R8, 0);
if(read_zsreg(&dev->chanA, R0)&Tx_BUF_EMP)
dev->type = Z85230; /* Has a FIFO */
else
dev->type = Z85C30; /* Z85C30, 1 byte FIFO */
}

 

[Tadeusz Pycio]

Hi Alan,

This is a good idea. The datasheet note includes how to detect NMOS Z8530 and CMOS Z85C30 chips, which are slightly different, but I don't know if the NMOS version will work properly with my module and if faster versions than 6MHz are available. I did not assume support for SCC NMOS chips.

[Jaap van Ganswijk]

I used to be in love with the Z8530. Such a nice design and also useful for other processor families!

On Wednesday, September 20, 2023 at 10:33:00 PM UTC+2 Tadeusz Pycio wrote:

I don't want to interrupt an interesting discussion in a thread about RCBus projects. I have started to investigate the SCC module and its behaviour during vector interrupts. It seems to work and I wonder if the generation of the WAIT signal is necessary, the interrupt vector appears quite early (0x40 in this example). I still need to analyse this in detail.

I have put particular emphasis in this module on compatibility with IM2 and.... I swapped the IEI lines with IEO :( 
A new version of the module has to be created. I will add the possibility of choosing address 0x80 or 0xA0.

[Wayne Warthen]

On Saturday, January 25, 2025 at 6:55:12 AM UTC-8 Tadeusz Pycio wrote:

I am currently planning to add support for the SCC family of chips to RomWBW, but this will take some time as I never got into the ins and outs of building drivers in RomWBW.

Let me know if you need any help with the RomWBW driver Tadeusz.

Thanks, Wayne 

[Tadeusz Pycio]

I found the ESCC Users Manual (too bad it's so late) and there it is pictorially shown how to detect the differences between SCC and ESCC. For some reason the Linux kernel had a more elaborate way of detecting these differences, by writing to a FIFO buffer. Maybe what was in the user manual didn't always work? I'll have to check it out.

[Tadeusz Pycio]

Let me know if you need any help with the RomWBW driver Tadeusz.

Hi Wayne,

Thank you for your offer of assistance. It will certainly come in handy when I want to use interrupts in the SCC, from what I've gathered I should be able to handle polling (I think? :-) ).

 

[Tadeusz Pycio]

Well, that's an interesting challenge I've chosen for myself. After reviewing the DUART driver sources, it turned out that I had to take into account, when identifying the SCC chip, that there may also be UART and DUART chips at address 0xA0. Detection may not be destructive for pre-initialised ICs (UART or DUART) when there is no SCC in the system, but when it is enabled in the configuration file. This is really getting interesting.

[Wayne Warthen]

Yes, unfortunately, there is a lot going on in the 0xA0-0xAF port range.  RomWBW does not have a good mechanism for handling such conflicts at this point.

Yes, you can implement the driver with polling only.  Interrupt support could be added later if desired.

Thanks, Wayne

[Tadeusz Pycio]

Hi Wayne,

I don't think RomWBW has to have such mechanisms at all, which will make the code excessively large. The solution is to disable default support for devices that may cause conflicts in the configuration files for a particular processor and to be able to enable it for a specific machine. It is just a matter of what assumptions are made. For example, such a change will reduce the code, previously mentioned, of the DUART driver by a detection procedure in the UART system.
RomWBW has already grown so much that you will soon need a tool like this to configure the Linux kernel :)

[Wayne Warthen]

On Monday, January 27, 2025 at 3:25:59 AM UTC-8 Tadeusz Pycio wrote:

I don't think RomWBW has to have such mechanisms at all, which will make the code excessively large. The solution is to disable default support for devices that may cause conflicts in the configuration files for a particular processor and to be able to enable it for a specific machine. It is just a matter of what assumptions are made. For example, such a change will reduce the code, previously mentioned, of the DUART driver by a detection procedure in the UART system.

RomWBW has already grown so much that you will soon need a tool like this to configure the Linux kernel :)

I agree!  😀

Thanks, Wayne 

[Chris Odorjan]

Perhaps take out side-detection of the UART/DUART/SCC entirely and make them mutually-exclusize?

Right now the DUART goes out of its way to avoid stepping on anything else, but it doesn't need to...

Thanks,

Chris

[Jaap van Ganswijk]

New hardware should be compatible with old hardware!

--

You received this message because you are subscribed to the Google Groups "retro-comp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-comp+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/retro-comp/bd00bd1e-2f31-49b6-a865-35c0eaffd09an%40googlegroups.com.

[Michelle Lawson]

This looks very interesting. I'm looking to get started on my first RC2014 system to add to my other retro Z-80 systems. One of my systems uses the 85C30 and I have a few I could use. Of course, I also have a real old 8251A system too! I'm interested on a timeline for at least bare boards being ready to either purchase, or have the Gerbers (etc) ready so I can go off and order the boards from JCLPCB (example). Thanks

[Michelle Lawson]

Well, first I'll apologize for doing something stupid. You see, somehow, somewhere, I saw a post to the Git repository for this and 'thought' I had it bookmarked, but apparently I did not. So, if anyone is kind enough to provide it, I will most assuredly ensure I bookmark it this time. Thanks

[Tadeusz Pycio]

The project has been made public on Github.