Thoughts on 40-pin long modules

[Steve Cousins]

I would like to make modules that are 40-pins long, rather than the usual 39-pins.

The attached illustration shows some possible board outlines.

The RED outline shows a module which has simply been extended by 0.1". In a backplane with 39-pin modules this would stick out a bit and spoil the consistent look.

The BLUE outline has a little bump to take pin 40 (and 80). From most viewing angles the bump would not be obvious and thus would retain the consistent look.

My main reason for wanting 40-pin long modules is to support the Z80 interrupt daisy chain signals (IEI and IEO) on my modular backplanes.

Another option would be to break with consistency and create a new module size, say approximately 100mm by 75mm, rather than approximately 100mm by 50mm. This would give much more real estate for interesting designs.

Comments appreciated.

Steve

[Spencer Owen]

Looks good to me. The standard module form factor is more of a 'recommended serving suggestion' than a hard and fast rule.  Sub-100mm was chosen for Eagle compatibility and to keep things within some PCB manufacturers budget priced PCB manufacturing limits, but at the expense of 1 of the 40 pins.  

Likewise with the height.  I think somewhere (although an initial search didn't find it) I've mentioned before about low profile (25mm high), plus size (75mm high) and jumbo (100mm high) modules.  It wouldn't be so visually pleasing, but that should be secondary to functionality.

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/72714967-895d-4595-9bf9-87548fcc8dc1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark T]

I've also been thinking about larger modules. I think I'd like to have either a card guide or a pc type mounting bracket on the pin 40 edge. Pc type bracket would allow for io connector mounting better than a slide. The extra width of the card without the notch would not be so noticeable and I prefer the outline without the notch.

Main driver for a 25mm height would be pcb cost. I use 102x100 panel for two 50x100 designs, separate the two with hacksaw between the modules where the connector hides the edge. This wouldn't work for 25mm height without a manual cut edge on the top of some cards. I guess it might work for 25x100 and 75x100 in a panel.

Mark

[Steve Cousins]

I really like 100 x 75'ish size. I use this size on my own homebrew. Actually, I use 4" by 3" as I like working with multiples of 0.1". 

This size card is stable with double row header type connectors and allows enough real estate for projects like 2 x SIO plus 1 x CTC, giving 4 serial ports with baud rate control on several of them. By putting more Z80 family components on a single card, the need for off card interrupt lookahead is reduced. 

Another plus is the extra height gives more connector mounting space on the back edge. I like to have all external connections on the back edge, so this is a significant advantage for me. 

On the negative side though, I like the consistent looking modules of the RC2014. The huge range of modules built on 100x50mm suggests there are not many things that need bigger boards.

If anyone wants to build RC2014 modules on larger boards it would be nice if we could agree on a common size and shape to avoid having lots of different outlines out there.

Steve

[Peter Willard]

Doesn't this place you *outside* the low cost JLCPCB pricing?

[Richard Lewis]

This won't fix the pin issue but as far as card space goes why not switch over to SMD (or at least partially)? The 0805 parts are not that hard to hand solder. I guess if someone is new to soldering or has only done through-hole stuff before it can seem daunting. The only other negative is you can't pop over to your local electronics shop and buy them off the shelf (if such places still exist). 

Before I started working with SMD I got a couple of practice kits on eBay for around $3 each. With the right solder and flux it's pretty easy. In fact, "drag soldering" a QFP is much quicker than soldering 40 individual pins on a PDIP.  On a side note, one practice kit I purchased even included 01005 parts which I didn't bother to attempt because I don't own an electron microscope...  

-Richard

[Mark T]

JLCPCB cost limit is 102x102mm. So 4 inch is just inside the limit.

[Mark T]

The other advantage of through hole ICs is you can put them in sockets. Then swap them to a next revision pcb or a new project. It's not so easy to do that with set.

Mark

[Bill Shen]

As I look around my bench I see a number of RC2014 boards in 3"x4" size, some of them are quite dusty that I have not used for quite a while.  My experiences with the 3"x4" size are very good.  The board is stable even with single row of 40-pin connector.  The 3"x4" board is still small enough that no signal termination or impedance match are required.  Interestingly, using CPLD and surface mount components in 3"x4" board means memory & basic I/O all fit in one board so the number of expansion pins is reduced.  Specifically, the high order addresses, A15 to A8 are not necessary because all memory are already on board.   The 40-pin RC2014 bus becomes 26-pin I/O expansion bus.
  Bill

[Phillip Stevens]

I’m actually quite surprised the no one has made use of Spencer’s/ Ed’s 82c55 PIO board for expansion options. Since that is what a PIO is for. Spencer’s Board is not just for PATA disks.

The IDE interface pin out carries all of the signals buffered and registered required for cool things. Keyboards, printers, etc. See the 82c55 data sheet for hints.

I’d hope to build some things along this path soon. It would be great to be beaten to the first build.

Phillip

[Marten Feldtmann]

Some remarks and questions:

a) Yes I like the 100x75 size also very much and would also go for 100x100 - if needed (e.g. CPU and memory).

b) Actually I use 102x75 to get 40 pins on one side and this works very well and the price is still cheap.

c) Why is the need for card-off interrupt lookahead reduced ? I thought, that 4 ICs are the limited ... it does not matter if you put it on ONE card or on several cards.

d) Same shape ? Ok, define one - I will follow, when possible. Define what is front ... what is back. Where are most place for connectors ...

Marten

[Steve Cousins]

Hi Marten

If, say, three Z80 I/O devices are on a single card rather than on three separate cards, then the card can contain the look-ahead logic for these three devices. Several such cards can be in the system before additional look-ahead logic is required. Thus "the need for off card interrupt lookahead is reduced".

Steve

[Steve Cousins]

I've given quite a bit of thought to implementing look-ahead on the backplane or via flying leads and have not come up with a scheme I really like. If anyone has a good solution to this problem please post for discussion.

Actually, the whole IEI/IEO chain on the backplane seems to spoil the simplicity of what I think a backplane should be. It is very nice to be able to put the modules in any slot you fancy and not worry about interrupt order, breaking the chain by leaving gaps, or using a module that doesn't link IEI to IEO. With enough dedicated pins you can solve these problems and even have look-ahead on a separate card. This method was mentioned recently by Tom Storey here: https://groups.google.com/d/msg/rc2014-z80/oGw1MAQXfn0/JQ89M6LiCAAJ

Ideally, the bus would support a large number of interrupt generating Z80 devices. Realistically though, I'd accept a solution with a very limited number of such devices. The largest system I've considered would have these:

2 x SIOs giving 4 serial ports

1 x CTC to generate baud rates for some of the serial ports, plus provide tick interrupt*

2 x CTC to generate mode 2 interrupts for up to 8 non-Z80 devices

2 x PIO for anything else!

So that's only 7 devices. Split across 3 modules, each with its own look-ahead, there is no need for additional off-card look-ahead.

* Actually the CTC is not an idea baud rate generator as clock synchronisation issues pretty much forces you to use the CPU clock as its source, thus preventing it working in a system where you want to experiment with different CPU clock speeds or control the clock with something like BusRaider.

A scheme limited to the above could be simple and even avoid the IEI/IEO chain problem by using the equivalent two bus pins as Tom described. This is currently my preferred solution. 

There seems to be precious little software out there to make use of a proper Z80 mode 2 system. Trying to write such software when the hardware can be so diverse is quite possible, but not trivial. I've been considering making this part of SCM v2, with an API to install interrupt handlers for both mode 1 and mode 2 devices. It would be an interesting project, but has not got to the top of my list yet. I find myself wondering if we would be better off defining the above hardware as some form of standard to make software support easier. Thoughts?

Steve

 

On Monday, 18 March 2019 08:40:55 UTC, Marten Feldtmann wrote:

[Steve Cousins]

How about the attached module dimensions?

Steve

On Monday, 18 March 2019 08:40:55 UTC, Marten Feldtmann wrote:

[Spencer Owen]

Regardless of height (25, 50, 75 or 100mm), I personally would keep the corner cut off at 15mm (0.6") for consistency.  It really doesn't lose you much real estate.  If, for example, 75mm high modules are used, I can then envisage a simple 25mm high riser to bring any 50mm modules up to the same level.

And, although the 3.2mm hole isn't really needed for stability on the 50mm high modules, for taller ones it might be a lot more useful.  If it's kept no the same location relative to the bottom left corner as on the 50mm high modules then it can be either bolted to one of them with a PCB spacer, or a bar pushed through the entire rack of boards.  Alternatively, keeping the location relative to the top left corner would allow the same thing if a 50mm module was used with a 25mm riser.

Spencer

--

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

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/6fd4de74-8eea-48a5-abf0-91105325541a%40googlegroups.com.

[karlab]

Hi

I think you have some very interesting ideas.

If we decide for a new layout standard I would also like to see a standardized housing that fit the new system.

The case should be large enough to house a backplane with 6 slots, a power brick, room for floppy or harddisk.

Karl

 

[Peter Willard]

I just wanted to say that a few of my own personal designs have been 100 x 75 already.

The only difference is that I felt the need to add pull handles at the top to assist with insertion and removal.

[Tom Storey]

On Monday, March 18, 2019 at 9:30:06 AM UTC, Steve Cousins wrote:

CTC to generate mode 2 interrupts for up to 8 non-Z80 devices

Hi Steve,

Could I pick your brain quickly about using a CTC to generate mode 2 interrupts for non family devices?

If I guesstimate correctly, you use one of the CTCs channels as a counter, triggered by the falling edge generated by the other devices interrupt pin. You load the counter with a value of 1, such that when the other device generates an interrupt, the counter decrements to 0 and the CTC then follows suit and provides a vector?

This is quite a neat solution, and I think I may use it in my current project! Just in time too, because I havent yet started building the board where that function would be used.

Thanks

Tom 

[Alan Cox]

You can also use a Z80 PIO as an interrupt controller, which is
actually easier in software in most cases because you get proper
interrupt masking features out of it trivially and you still have
plenty of bits left over even if you need several for the interrupt
lines.

You don't get a per interrupt vector for each of those devices but
it's one read to get the pending interrupts _and_ you can make it give
you interrupt prioritization behaviour which means you can take an
interrupt off the PIO and in the interrupt handler you can then change
the mode 3 control mask on the PIO to block that interrupt and reset
the pending interrupt, enable interrupts and carry on.

This allows you to do do proper priority driven interrupts where you
can interrupt and interrupt handler which the CTC one can't really do
well. Plus of course you get 16 unique interrupt sources per PIO if
you used a whole one rather than using the rest of it for joysticks,
SD card. MMU etc.

[Steve Cousins]

Hi Karl

I agree with your additions to the illustration. I'd like to add "indicators" to "Primary area for jumper and switches".

If we are considering a standard for larger modules, then I agree it would be sensible to consider all related aspects of a system design. So on the case issue, I'd add my preferences:

Avoid connections and indicators on the top edge of the board (so no access is required from the top of the case). This would mean a different Compact Flash mounting, as recently discussed, unless you are happy not to have the card removable whilst cased up.

On/off switch and reset button should be easily extendable to allow mounting on the case. If the case is well defined they could remain on the PCB and positioned to match case cut-outs.

Steve

[Alan Cox]

On Mon, 18 Mar 2019 at 09:30, Steve Cousins <steve...@gmail.com> wrote:
>
> I've given quite a bit of thought to implementing look-ahead on the backplane or via flying leads and have not come up with a scheme I really like. If anyone has a good solution to this problem please post for discussion.

I have never seen one in a generic system. There were high end systems
that supported IM2 like the Altos 5 and the Cromemco but even the S100
based Cromemcos used a seaerate chain of little cables for the IM2
stuff.

> Actually, the whole IEI/IEO chain on the backplane seems to spoil the simplicity of what I think a backplane should be. It is very nice to be able to put the modules in any slot you fancy and not worry about interrupt order, breaking the chain by leaving gaps, or using a module that doesn't link IEI to IEO. With enough dedicated pins you can solve these problems and even have look-ahead on a separate card. This method was mentioned recently by Tom Storey here: https://groups.google.com/d/msg/rc2014-z80/oGw1MAQXfn0/JQ89M6LiCAAJ

S100 has a set of interrupt pins. If you had an 8080 you routed them
to an 8228 or similar and that generated multiple vectors in 8080
mode. If you had an 8085 you fed them to the multiple interrupt
vectors on the CPU. If you had a Z80 you could wire them to a PIO or
to any other logic you fancied to generate vectors or prioritize.
Other boards used whatever controller was appropriate for the CPU card
(8259 etc)

However it's 8 lines on the bus.

> 2 x SIOs giving 4 serial ports
> 1 x CTC to generate baud rates for some of the serial ports, plus provide tick interrupt*
> 2 x CTC to generate mode 2 interrupts for up to 8 non-Z80 devices
> 2 x PIO for anything else!
> So that's only 7 devices. Split across 3 modules, each with its own look-ahead, there is no need for additional off-card look-ahead.

So you can do the interrupts with a PIO channel and that takes you
down a CTC. You can fold the CTC, first SIO and first PIO into a KIO,
so that's down to 3 devices and you get some extra I/O lines in the
process.

I'm not sure I agree with you on the CTC being a bad timer for the
SIO. Nothing stops you using it to count external events off a
suitable crystal for the serial port clocks rather than internal time.

> There seems to be precious little software out there to make use of a proper Z80 mode 2 system. Trying to write such software when the hardware can be so diverse is quite possible, but not trivial. I've been considering making this part of SCM v2, with an API to install interrupt handlers for both mode 1 and mode 2 devices.

Fuzix supports IM2 on the Cromemco and on the Linc80 emulation. I've
never found it much of a win or anything to get excited about. On the
other hand being able to do 8085 style prioritized interrupts is a
huge win IMHO.

IM2 is great for real time process control in an RTOS, but I don't
think anyone (despite Uncle Clive's advert) is planning to use RC2014
to control a nuclear power station 8)

Alan

[Marten Feldtmann]

I build a board like this and hope to have time to test it out:

https://feldtmann.ddns.net/rc2014/doc/mks--irq-modeule.html

actually this card offers the possibility to get INT signals via D8 .. D15 - and these signals are connected to the CTC's. If not wanted there is a connector on the card for free wires  :-)

Marten

[Steve Cousins]

Hi Tom

Your description of the use of the CTC is spot on.

The interrupt edge can be set to match the device generating the interrupt. Normally this will be the falling edge.

You can only easily link one interrupting device to each CTC input. Being edge triggered you could miss an interrupt if two devices interrupt a CTC channel close together. This could be resolved in software but would not be a very efficient solution.

Alan makes good points about the PIO as an interrupt controller. The CTC would give one interrupt vector for each interrupt source which is fast, efficient, and elegant. However, the PIO solution's ability to use software to determine the source and set priorities is a plus. The CTC's internal priority is fixed, but jumpers could be used to map input source to CTC channel, giving priority control within those 4 interrupt sources.

Again I feel the optimum solution to all this interrupt stuff would depend on how many interrupts you wish to support. Setting a reasonable limit would help determine the best backplane design, look-ahead scheme and interrupt controller. Perhaps four mode 1 style devices interfaced through a CTC (or PIO), and 3 or 4 modules able to produce mode 2 interrupts would be a good compromise.

Steve

[Steve Cousins]

Alan

In answer to "I'm not sure I agree with you on the CTC being a bad timer for the SIO. Nothing stops you using it to count external events off a 

suitable crystal for the serial port clocks rather than internal time. "

What I found with the CTC is consistent with the data sheet. The input edge count can be delayed (or skipped) if it is not synchronous to the main system clock. If the frequency of the CTC input edge is low (less than half) of the bus clock there is no problem. However, this means you can't use the dual clock module to slow the process drastically. Even at a fixed bus clock you can end up unable to generate the higher baud rates you may want.

In practice, this issue leads to reliability problems as the CTC misses some counts.

Here is the description from the CTC data sheet:

In the Counter mode, the edge (rising edge is active in this example) from the external hardware connected to pin CLK/TRG, decrements the down counter in synchronization with the System Clock Φ. This CLK/TRG pulse must have a minimum width and the minimum period must not be less than twice the System clock period. Although there is no setup time requirement between the active edge of the CLK/TRG and the rising edge of Φ, if the CLK/TRG edge occurs closer than a specified minimum time, the decrement of the down-counter will be delayed one cycle of Φ. Immediately after the 1 to 0 decrement of the down-counter, the ZC/TO output is pulsed true.

In the Timer mode, a pulse trigger (user selectable as either active High or active Low) at the CLK/TRG pin enables the timing function on the second
succeeding rising edge of Φ. As in the Counter mode, the triggering pulse is detected asynchronously and must have a minimum width. The timing
function is initiated in synchronization with Φ. A minimum setup time is required between the active edge of the CLK/TRG and the rising edge of Φ.
If the CLK/TRG edge occurs closer than this, the initiation of the timer function will be delayed one cycle of Φ.  

[Steve Cousins]

Marten

Yes, that's exactly the kind of module I envisage. 

My SC102 CTC module has inputs which can be jumpered to USER pins to provide this function, and you can fit several in a system at once. However, a dedicated interrupt controller module as you have designed provides more channels on a single module. Also, the USER pins have multiple uses raising the problem of isolating sections of the backplane to support multiple uses, further complicating the bus and restricting the flexibility of module positioning.

Your solution has two Z80 I/O devices adding to your interrupt chain length. What are you doing about look-ahead?

Steve

[Tom Storey]

Excellent. Thanks for the confirmation.

I only need to cater for one non-family interrupt source (from an RTC), so I think using a CTC would be fine given I already have one in my design. From there I am only likely to use one or two more channels of the CTC.

Maybe a dumb question, but when you say you could miss interrupts "if two devices interrupt a CTC channel close together", do you mean that as two distinct CTC channels, or if two devices were trying to share the same CTC channel?

Thanks!

Tom

[Alan Cox]

> What I found with the CTC is consistent with the data sheet. The input edge count can be delayed (or skipped) if it is not synchronous to the main system clock. If the frequency of the CTC input edge is low (less than half) of the bus clock there is no problem. However, this means you can't use the dual clock module to slow the process drastically. Even at a fixed bus clock you can end up unable to generate the higher baud rates you may want.

You've got a 7.37MHz CPU and CTC and for 115200 baud you need the
classic IBM PC 1.843MHz crystal to generate the required baud rates at
x16. So you can go down to 4MHz happily. As you can drop to x64 mode
it's enough to get you all the bit rates you are likely to care about
unless you are doing 5bit baudot. (you can't quite get 110 baud).

(In fact you can go down to about 2MHz because you can then just use
the 1.843MHz clock for everything)

The other option if you have an RTC would be to time the CTC against
the RTC at boot and use that to compute the correct divider ranges.
I'd pondered doing that for the RC2014 Fuzix kernel and may do at some
point when an RTC is present.

Alan

[Marten Feldtmann]

Nothing really, I try to get rid of it by either:

have a Z180 - use it's own SIO channels, own Timer for system tick, two CTC's for other interrupts and perhaps 1-2 PIO's

have a Z80 - then I only consider to have ONE SIO, 2-3 CTC's and NO PIO.

I'm even not sure, if a KIO will solve this problem ... I think, that the documentation is not clear about this topic. They also mention a problem with 4 devices on the bus - but do they count one KIO as four devices or one KIO as one device ?!?!?!?!?!

Marten

[Steve Cousins]

I meant if you try to use a single CTC channel. 

I was tempted to add a single mode 1 style interrupt line to my system and hang on it whatever devices came alone, as you would on a 6502 system (for example). I'd then write the usual interrupt handler to poll the devices to determine the source of the interrupt.

The problem is the interrupt from the CTC is edge triggered so your interrupt routine will not fire again if there is an outstanding interrupt holding the input low. Such a thing easily could occur between the first interrupt and the handler clearing it.

I think a reasonably reliable fix would be to have the interrupt routine poll to determine the interrupting device, handle it, then jump back to the beginning of the polling list. The interrupt routine would only return if it got to the end of the list without finding anything. Another solution would be to monitor the mode 1 interrupt routine and only quite the polling loop when it is seen to have gone high.

None of this is elegant but it would allow multiple mode 1 style device to be connected to just one bus line, whilst still running mode 2 interrupts.

I'd really like one vector for each interrupt source as this allows the software support for each device to be isolated. This seems to be a big plus when installing interrupt handlers at run time, rather than compile time.

Steve

[Steve Cousins]

Alan

Yes, you are of course correct about the maths. 1.8432 MHz allows the common baud rates to be set in the range 150 to 115200. At least according to the notes I left myself when playing with this stuff.

There are two reasons why I was not happy with this solution though:

By using the divide 16 range setting in the SIO it becomes incompatible with standard RC2014 software distributions such as CP/M. If my ROM sets up the SIO for divide 16 and I run at 115200 baud, then launch the standard CP/M distribution, CP/M reprograms the SIO to divide 64 and the baud rate changes to 28800. As this is not a generally supported baud rate you can't even quickly switch the terminal baud rate to match. For my own system this would be fine as I'd simply create a CP/M BIOS which also uses divide 16. However, as I offer my boards on Tindie I did not want to create that compatibility problem.

The other reason, as previously mentioned, is the serial port would fail if you used the dual clock module to drastically lower the CPU clock or if you used a module like BusRaider which controls the CPU clock. This I consider a bigger issue than the software compatibility one above. There just isn't a fix for this one (unless I'm missing something important).

So while you are correct it is not an ideal solution for me.

I don't think the RTC idea would fix this as the CTC output becomes erratic (not predictable or repeatable) as the phase drifts between the two clocks when the CPU clock is not at least twice the CTC clock. If the CPU clock is already high enough there is no problem to fix. 

I like your idea of writing the software to calculate the required CTC and SIO settings from an RTC. This sounds worth exploring as a really nice way to avoid having to compile code to match the clock frequency. Brilliant when you don't know the user's clock speed :)  Reminds me of tuning RTC software when using a PIC's crude watchdog timer as clock tick for the RTC. Hours of fun.

Steve

[Alan Cox]

On Mon, 18 Mar 2019 at 12:57, Marten Feldtmann <m.fel...@dimap.de> wrote:
>
> Nothing really, I try to get rid of it by either:
>
> have a Z180 - use it's own SIO channels, own Timer for system tick, two CTC's for other interrupts and perhaps 1-2 PIO's
> have a Z80 - then I only consider to have ONE SIO, 2-3 CTC's and NO PIO.

If you have a Z180 you don't need anything else. You have the timers
onboard, you have the serial ports on board, you have the synchronous
serial to do SD card and most SPI devices at a nice speed.

Alan

[Tom Storey]

On Monday, March 18, 2019 at 12:58:23 PM UTC, Steve Cousins wrote:

I meant if you try to use a single CTC channel. 

Thanks Steve. 

Just to be absolutely sure that Im not getting things mixed up here, if two channels of a CTC cause an interrupt at the same time, the CTC will generate two interrupts in succession, with the higher priority channel being first, then the lower priority second? The datasheet seems to be suggesting this, but then I read some of the stuff you have said and I start to wonder if that isnt the case ... but maybe Im confusing some of the things youre talking about in relation to mode 1 style interrupts...

Thanks

Tom

[Mark T]

I like Karl's suggestion of the long vertical edge as the primary location for connectors, possibly also for indicators that would be useful to see from outside the case. Could we also include a suggestion for the mounting face of connectors as it would be best if this was common between modules. Perhaps 1.3 mm from the center of pin 40, slightly clear of the pcb edge.

For the IEI/IEO chain, the delay added by each Z80 peripheral is I think the limiting factor. This could be reduced by using an external AND gate to generate IEO from the IEI and the Z80 peripheral IEO.

I think the PIO, SIO and CTC were only available in 10 MHz, so it might be interesting to replicate them with CPLD some time.

I'd like to experiment with 16 bit data bus at some point so if I wanted extra pins on the bus I think I would use the higher address lines, A31..A24.

Mark

[Steve Cousins]

Tom

Probably just me not being clear.

If two mode 1 style interrupt signals are connected to two CTC channels (on the same CTC or different CTCs) and they both request an interrupt at the same time, the CTC will generate two separate mode 2 interrupts, highest priority first. The handler for the highest will complete and then the lowest will fire. Same will happen if the lower priority one is requested during the handling of the higher priority one.

If the lowest priority one occurs slightly before the higher priority one, the higher priority one can interrupt the lower priority one. So the handler for the lower priority one starts, then the higher priority one fires and its handler runs to completion, then the lower priority handler continues until completion.

This mechanism is controlled by the IEI and IEO daisy chain, with a device under interrupt service lowering its IEO (output) which holds off lower priority devices (further down the chain) from issuing and acknowledging interrupts. The IEO signal ripples down the IEI/IEO chain, and must stabilise within a predetermined time. A long chain takes longer to stabilise than is allowed, and thus the discussion about look-ahead logic.

Steve

[Tom Storey]

On Monday, March 18, 2019 at 2:29:34 PM UTC, Steve Cousins wrote:

Tom

Probably just me not being clear.

If two mode 1 style interrupt signals are connected to two CTC channels (on the same CTC or different CTCs) and they both request an interrupt at the same time, the CTC will generate two separate mode 2 interrupts, highest priority first. The handler for the highest will complete and then the lowest will fire. Same will happen if the lower priority one is requested during the handling of the higher priority one.

If the lowest priority one occurs slightly before the higher priority one, the higher priority one can interrupt the lower priority one. So the handler for the lower priority one starts, then the higher priority one fires and its handler runs to completion, then the lower priority handler continues until completion.

This mechanism is controlled by the IEI and IEO daisy chain, with a device under interrupt service lowering its IEO (output) which holds off lower priority devices (further down the chain) from issuing and acknowledging interrupts. The IEO signal ripples down the IEI/IEO chain, and must stabilise within a predetermined time. A long chain takes longer to stabilise than is allowed, and thus the discussion about look-ahead logic.

Steve

No probs Steve, thanks for taking the time to clarify. I guess its pretty much as I understood it should work.

I suppose you can use EI/DI to enable/disable maskable interrupts if you dont want higher priority interrupts interrupting lower priority ISRs.

This is my first time building a Z80 project, so just making sure I understand what Im working with (have done plenty of work with PIC microcontrollers though). Quite excited to try this out. :-)

Tom

[Marten Feldtmann]

Yes, the Z180 is quite nice at this - without any question - and the ez80 is even better. Actually for the whole

boards I have here (and waiting for testing) - they all would like to have interrupt lines. The I2C chip, the clock chip, the 8255 chips, the CH376 chips - they all are capable to trigger interrupts.

So even with the Z180 there would be a use case ... the ez80 should be able to handle this with its own io-pins.

But even then its also a matter of software to support it ...

Marten

[Marten Feldtmann]

Not much space for connectors :-(

[Marten Feldtmann]

on a 100x50 mm board

[Tom Szolyga]

Hi Alan,

Would you elaborate on using the Z180 synchronous serial to do SD Card interface?  I am interested in trying it but do not know how to start.

Thanks,

Tom 

[Alan Cox]

On Mon, 18 Mar 2019 at 17:21, Tom Szolyga <tszo...@pacbell.net> wrote:
>>
>> Hi Alan,
>

> Would you elaborate on using the Z180 synchronous serial to do SD Card interface? /

The N8VEM mark 4 is one that does this

https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:z180_mark_iv:z180_mark_iv

The CSI synchronous serial on the Z180 can generate the right signals
for SPI except that
- It can't do full duplex
- It sends the bits in reverse order
- SD cards are 3.3v

(and of course you need a gpio or similar for chip select)

The full duplex turns out to be a non-issue. Almost no SPI device on
the planet actually *needs* full duplex. The bit reverse is done in
software. The SD card protocol above SPI is done in software. I've got
a CP/M implementation of the core SD protocol if you need it and
ROMWBW supports SD over the Z180 CSIO card fully.

There's a lot more to doing SD 'properly' but the simple SPI mode on
an SD card is more than good enough for 8bit micros.

Alan

[Mark T]

It would only be the primary location for connectors. Secondary locations could be top edge and maybe tertiary would be short vertical edge. This would be similar to PC Cards, where other connectors on the board would connect via cables from the top edge of the board to a separate panel, or ide drive etc.

It might be best to avoid top edge on 75 or 100 mm high modules to avoid making the case too high.

Mark

[Marten Feldtmann]

Well, I build such a board (and again not fully tested :-)))). I bought a SD-card breakout board with 3.3V/5V level shifter:

https://www.sparkfun.com/products/13743

then I took a 82A55 and connected both PIO ports in such a way, that A7 is connected to B0 and so on. The port C was used to do the chip select (as output) and CD (as input).

The idea was to send the original byte to port A and then I read it again via port B. The value is then send via the CSIO port to the sd-card. Before that the CS signal is set ...

That was the idea :-)))

Marten

[Steve Cousins]

So far in this topic, we have considered two module sizes.

• Standard 50x100mm module extended for a 40-pin bus connector
• Plus size 75x100mm module 

I'll write a separate post about the Plus size module.

There wasn't much comment on the Standard size version, but there seemed to be a preference to just simply extending it by 0.1 inches (2.54mm). See the attached illustration. All other dimensions remain as defined on Spencer's website.

I propose we ask Spencer to give this his official approval as the suggested (or even recommended) way to support 40-pin bus connectors on a Standard'ish sized module.

Perhaps the two variants of the Standard size module could be referred to as "Standard 39-pin" (or just "Standard") and "Standard 40-pin".

Steve

[Spencer Owen]

On Tue, 19 Mar 2019 at 13:13, Steve Cousins <steve...@gmail.com> wrote:

I propose we ask Spencer to give this his official approval as the suggested (or even recommended) way to support 40-pin bus connectors on a Standard'ish sized module.

Perhaps the two variants of the Standard size module could be referred to as "Standard 39-pin" (or just "Standard") and "Standard 40-pin".

Anybody can do whatever they want* without my official approval :-) 

Currently I don't have any modules that need to use the 40th pin, so all of my modules will be sticking to the same dimensions.  If/when I need it, though, I guess "standard 40-pin" is as good a name as any.

If anyone wants to make a 40 pin by 50mm, 75mm and 100mm template (with cut off corner and mounting hole as mentioned earlier in this thread) in KiCad and/or Eagle, I'd be happy to host that on the RC2014 GitHub account and link to it from the rc2014.co.uk website.

Cheers

Spencer

* Only caveat is using the trademarked term "RC2014" to suggest it is an official RC2014 product

[Steve Cousins]

Now for the larger module size...

I've updated the illustration (attached) to include some of the feedback.

These are the points raised which have not been accounted for in the attached illustration:

• Mark T - Card guide or PC style bracket
• Peter W - Pull handles
• Karl B - Case considerations
• Mark T - Suggest a standard position of I/O connectors from PCB edge
• Mark T - Top and front edges as secondary connector and indicator areas

I've shown the large hole positioned the same distance from the front and bottom edge as specified on Spencer's standard module layout drawing. Spencer did suggest it could be positioned relative to the top edge. Both options have advantages!

As Spencer says, anyone is free to make modules any shape and size they like, but consistency is nice too :)

Thoughts?

Steve

[karlab]

Good work Steve

Why not make the four sizes into the standard.

At least when we talk about "Plus size" we do not refer to "double size", so there want be any confusion or misunderstaning.

I would also indicate the component side, and that the angled male connector go in on the front side, so we get uniform thickness/shape.

Karl

[Marten Feldtmann]

Are there any information about the hole size or where "Spencer's standard module layout drawing" can be seen ?

[karlab]

layout described here

http://rc2014.co.uk/1377/module-template/

[Marten Feldtmann]

Thanks, I added all that stuff to my documentation ...

Marten

[ZO...@gladucalled.com]

Does anyone remember this bus with the edge fingers?  =Steve.

https://en.wikipedia.org/wiki/STD_Bus 

Used a card cage, too.

On Sunday, March 17, 2019 at 6:36:50 AM UTC-4, Steve Cousins wrote:

I would like to make modules that are 40-pins long, rather than the usual 39-pins.

The attached illustration shows some possible board outlines.

The RED outline shows a module which has simply been extended by 0.1". In a backplane with 39-pin modules this would stick out a bit and spoil the consistent look.

o 

o

o