[v1.0] MECB Prototype 22V10 Card

[Editor]

When I started out with creating my MECB platform standard, for retro 8-bit experimentation, I spent some time deciding on the best retro friendly way to implement a flexible glue-logic solution.

At the time, I decided on the ATF16V8 for the standard glue logic PLD for all of my MECB needs, providing a 2K memory addressing resolution.

However, more recently, it was brought to my attention that some well known 8-bit retro systems (which somebody might want to re-create), required a finer than 2K address map granularity.

So, after careful consideration, I've now added the ATF22V10 as an alternative standard glue logic option.

This includes a new (second) KiCAD MECB PCB design Template, and also the addition of an alternative Prototype 22V10 Card to the lineup.

Read all about it here: Minimalist Europe Card Bus (MECB) - Expanding the Glue Logic versatility

[djrm]

Hi Greg, just back from a weekend camping and see your new video. I started something similar last week to rationalise my AIM-65 recreation. I happen to have some 20v8 PLDs and I used one of these for my memory map decoding. One difference is that I am using the address range syntax to make it clearer what addresses are in use. Attached is the PLD source, builds ok but not yet tested:

Code: Select all

name            MECB_AIM-65;
Partno          U1;
Date            05/2025;
Revision        01;
Designer        David;
Company         djrm;
Assembly        None;
Location        None;
Device          g20v8a;

/*
 *
 * Inputs: Inputs were assigned based on the ECB bus pin sequence (for ease of PCB routing).
 * Active low pins are inverted at the pin so all signals can be consistently treated as positive logic.
 *
 */

Pin  1 	= clk;
Pin [14, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 13, 23] = [a15..a3];
field memoffset = [a15..a3];

/*
 *
 * Outputs: Define outputs
 * Active low pins are inverted at the pin so all signals can be consistently treated as positive logic.
 *
 */

Pin 15 = !cs0;
Pin 16 = !cs1;
Pin 18 = !cs3;
Pin 22 = !cs4;
Pin 20 = !cs5;
pin 21 = !cs6;
pin 17 = !cs7;
pin 19 = !all;

/*
 *
 * Logic: AIM-65 recreation - I/O Address Allocations
 *
 */

cs0  = clk & memoffset:[A000..A00F]; // 6522 user
cs1  = clk & memoffset:[A400..A47f]; // 6532 memory
cs2  = clk & memoffset:[A480..A49f]; // 6532 keyboard
cs3  = cs1 # cs2;                    // 6532 CS
cs4  = clk & memoffset:[A800..A80f]; // 6522 via
cs5  = clk & memoffset:[AC00..AC03]; // 6520 display
cs6  = clk & memoffset:[A200..A203]; // 6551

cs7  = clk & memoffset:[A280..A283]; // spare
all = cs0 # cs1 # cs2  # cs4 # cs5 # cs6 # cs7;

[Editor]

Hi Greg, just back from a weekend camping and see your new video. I started something similar last week to rationalise my AIM-65 recreation. I happen to have some 20v8 PLDs and I used one of these for my memory map decoding. One difference is that I am using the address range syntax to make it clearer what addresses are in use.

Hi David. I like what you've done.

Interestingly, when I read through the WinCUPL User's Manual, I did note the more advanced syntax options, but as my mind still seems to think in binary (and I'm using very simple combinational logic for my glue-logic purpose), I just went with simple logic operator use.

I guess, in my mind, I had more confidence that the lower level declarations were doing exactly what I wanted.

In retrospect, I do like the list notation that you've used for defining the address pin inputs!

However, in regards to the FIELD statement. Although it looks tidy, it immediately raises a question (logical uncertainty?), in my mind.
e.g.
When you declare:

Code: Select all

field memoffset = [a15..a3];

and then state:

Code: Select all

memoffset:[A400..A47f];

I don't see how the address RANGE can be interpreted by WinCUPL, when memoffset isn't a0 based?
i.e. If this actually works, it isn't technically intuitive to me! (How does WinCUPL know that the reference a3 is the fourth significant bit?)

Whereas, if memoffset was = [a15..a0], then I'd certainly understand (be confident with), the [A400..A47f] RANGE reference, as the Hex address range is then directly comparing to an equivalent array of bits (from the MSB to the LSB).

But, perhaps that's just the way my mind works?

In the meantime, I might start using your suggested list notation for the address input pin definitions.

EDIT: I do note the WinCUPL manual's reference to Indexed Variables (variable names that end in a decimal number from 0 to 31), but I view that kind of language interpretation detail as not very intuitively apparent, when someone else is later reading the source.

Interesting...

[djrm]

Hi Greg, I agree that relying on the unstated assumption that the missing address bits is confusing but it does work and makes the PLD source very
clear and concise. I have used it already in other designs on the MECB. I found a useful tutorial on youtube by Dave Henry which uses this method: https://www.youtube.com/playlist?list=P ... NN6CYkrU3M

The sim file for the pld design I posted earlier is here and looks more familiar:

Code: Select all

%SIGNAL
PIN  23 =  a3 
PIN  13 =  a4 
PIN   2 =  a5 
PIN   3 =  a6 
PIN   4 =  a7 
PIN   5 =  a8 
PIN   6 =  a9 
PIN   7 =  a10 
PIN   8 =  a11 
PIN   9 =  a12 
PIN  10 =  a13 
PIN  11 =  a14 
PIN  14 =  a15 
PIN  19 = !all 
PIN   1 =  clk 
PIN  15 = !cs0 
PIN  16 = !cs1 
PIN  18 = !cs3 
PIN  22 = !cs4 
PIN  20 = !cs5 
PIN  21 = !cs6 
PIN  17 = !cs7 
%END

%FIELD
FIELD memoffset = a15,a14,a13,a12,a11,a10,a9,a8,a7,a6,a5,a4,a3
%END

%EQUATION
all =>
    !cs0
  # !cs1
  # !a5 & !a6 & a7 & !a8 & !a9 & a10 & !a11 & !a12 & a13 & !a14 & a15 & clk
  # !cs4
  # !cs5
  # !cs6
  # !cs7

cs0 =>
    !a4 & !a5 & !a6 & !a7 & !a8 & !a9 & !a10 & !a11 & !a12 & a13 & !a14 & a15 & clk

cs1 =>
    !a7 & !a8 & !a9 & a10 & !a11 & !a12 & a13 & !a14 & a15 & clk

cs2 =>
    !a5 & !a6 & a7 & !a8 & !a9 & a10 & !a11 & !a12 & a13 & !a14 & a15 & clk

cs3 =>
    !cs1
  # !a5 & !a6 & a7 & !a8 & !a9 & a10 & !a11 & !a12 & a13 & !a14 & a15 & clk

cs4 =>
    !a4 & !a5 & !a6 & !a7 & !a8 & !a9 & !a10 & a11 & !a12 & a13 & !a14 & a15 & clk

cs5 =>
    !a3 & !a4 & !a5 & !a6 & !a7 & !a8 & !a9 & a10 & a11 & !a12 & a13 & !a14 & a15 & clk

cs6 =>
    !a3 & !a4 & !a5 & !a6 & !a7 & !a8 & a9 & !a10 & !a11 & !a12 & a13 & !a14 & a15 & clk

cs7 =>
    !a3 & !a4 & !a5 & !a6 & a7 & !a8 & a9 & !a10 & !a11 & !a12 & a13 & !a14 & a15 & clk

%END

Note: the term cs2 is not assigned to a pin, it is only part of the combined output cs3

hth David.

[Editor]

Hi Greg, I agree that relying on the unstated assumption that the missing address bits is confusing but it does work and makes the PLD source very clear and concise. I have used it already in other designs on the MECB. I found a useful tutorial on youtube by Dave Henry which uses this method...

Thanks for the link, I'll definately watch his PLD playlist.

Thinking this through a little more, I do now realise that I need to stop being so analytical (try not to overthink things!).

Although it bothered me that this syntax is less technically intuative, you are indeed correct in stating that it makes the PLD source very readable and concise (for a user). So, most importantly, it benefits other users in terms of the ease of defining memory map allocations.

I will say though that it is still easy to get bitten with this higher level syntax.
For example, every bit declared in a field definition is significant.
i.e. Any declared bits in the field that aren't explicitly referenced, are equated to zero by the compiler (as opposed to being undefined).
e.g. if I defined a field [a15..a3] and then specified [E0..E7], the CUPL compiler takes this as being [00E0..00E7].
So, to get around this it is necessary to declare a second (sub) field [a7..a3] to correctly implement the 8-bit IORQ address range.

Anyway, I can live with these vagarities, in the interest of producing more user readable / editable PLD source!

So, thank you for again pointing me in the right direction. I live to learn something new every day!

Here's what I've ended up with for my updated Prototype 22V10 PLD source:

Code: Select all

Name            MECB_CHIPSELECT_PROTOTYPE_PLD_22V10;
Partno          U1;
Date            05/2025;
Revision        01;
Designer        Greg;
Company         Digicool Things;
Assembly        None;
Location        None;
Device          g22v10;

/****************************************************************/
/*                                                              */
/* Note: Device is an ATF22V10C                                 */
/*                                                              */
/****************************************************************/

/*
 *
 * Inputs: Inputs were assigned based on the ECB bus pin sequence (for ease of PCB routing).
 * Active low pins are inverted at the pin so all signals can be consistently treated as positive logic.
 *
 */
Pin 15	= clk;
Pin 10	= !iorq;
Pin 11 = !mreq;
Pin 8 	= !rd; 
Pin 19 = !wr;

Pin [16, 7, 14, 9, 6, 20, 13, 3, 5, 21, 4, 2, 1] = [a15..a3];
field iorq_addr = [a7..a3];
field mreq_addr = [a15..a3];

/*
 *
 * Outputs: Define outputs
 * Active low pins are inverted at the pin so all signals can be consistently treated as positive logic.
 *
 */

Pin 23 = !cs0;
Pin 22 = !cs1;
Pin 18 = !cs2;
Pin 17 = !cs3;


/*
 * Memory Map options follow (un-comment only one!)
 */


/*
 *
 * Logic: Prototype 22V10 Card - IORQ Address Allocations
 *
 * cs0 : iorq asserted for I/O address range 0xE0 - 0xE7
 * cs1 : iorq asserted for I/O address range 0xE8 - 0xEF
 * cs2 : iorq asserted for I/O address range 0xF0 - 0xF7
 * cs3 : iorq asserted for I/O address range 0xF8 - 0xFF
 *
 */
/*
cs0 = iorq & iorq_addr:[E0..E7];
cs1 = iorq & iorq_addr:[E8..EF];
cs2 = iorq & iorq_addr:[F0..F7];
cs3 = iorq & iorq_addr:[F8..FF];
*/

/*
 *
 * Logic: Prototype 22V10 Card - AIM-65 System I/O Space Allocations
 *
 * cs0 : mreq asserted for address range 0xA000 - 0xA3FF
 * cs1 : mreq asserted for address range 0xA400 - 0xA7FF
 * cs2 : mreq asserted for address range 0xA800 - 0xABFF
 * cs3 : mreq asserted for address range 0xAC00 - 0xAFFF
 *
 */

cs0 = mreq & mreq_addr:[A000..A3FF];
cs1 = mreq & mreq_addr:[A400..A7FF];
cs2 = mreq & mreq_addr:[A800..ABFF];
cs3 = mreq & mreq_addr:[AC00..AFFF];

[djrm]

Making progress and can now boot the unmodified AIM-65 roms using a new decoding scheme based on the 22v10 PLD, the photo shows a dev board with the 22v10 with four fly-leads going to the various cip select lines of the AIM-65 devices having removed their own 16v8 plds. Ram and rom are on the 6845 display board, this has its own 22v10 PLD for its own I/O decoding. It has various rom images including a sbcos for debugging the hardware. I found that o2 clock was not needed in the I/O PLD since this signal is fed into the i/o chips separately. My existing cards can be used by placing the ioreq page into gaps in the AIM-65 address space, the 6850 on the Motorola card is accessed this way.

Overall integration needs improving but the system now boots and I can make improvements with a way home if it goes wrong David.

[Editor]

Making progress and can now boot the unmodified AIM-65 roms using a new decoding scheme based on the 22v10 PLD...

Awesome update, and great to hear.

I've been recently looking again at some of my first built systems, and once again getting the "re-creation" bug.

I've also fished out my old Wire Wrap gear, thinking of possibly re-living my early Wire Wrap experience (although hard pushed when you consider how easy it is these days to design a PCB).

To this end, I'm thinking I might re-introduce the original "plain grid" MECB Prototype Card, but re-named as a MECB Wire Wrap Card.
I know at least one person (can't recall who?), commented that the original plain grid card was preferable for some projects.

Hmm...

[djrm]

I was surprised you didn't make the new card 22v10 prototype card plain grid. I think I mentioned a couple of times having to cut tracks on the triple grid cards to suit my purposes. When I ordered my initial boards I messed up thinking I was getting plain grid prototype cards. Looking forward to your next presentation. David.

[Editor]

I was surprised you didn't make the new card 22v10 prototype card plain grid. I think I mentioned a couple of times having to cut tracks on the triple grid cards to suit my purposes. When I ordered my initial boards I messed up thinking I was getting plain grid prototype cards. Looking forward to your next presentation. David.

Perhaps it was your feedback that had come to mind.

It has occurred to me that the first IC I'll need to wire-wrap will be a glue logic PLD. Therefore, your comment about making a plain grid 22V10 card certainly makes a lot of sense!

This is now leading me to think that I should perhaps go to a full family of six Prototype Cards choices.
i.e. Reintroduce the original plain grid card, but also make 16V8 and 22V10 versions, to mirror the existing triple grid cards.

I never had an original grid card with a PLD, as my first Prototype PLD Card was in the triple grid format, as someone had suggested as an improvement (and still seems a preferable option for a breadboard style point-to-point wired prototype).

Of course, now that I'm again thinking of my wire-wrap roots, having the three Prototype Card options in just a plain grid style (for dense wire-wrap), is also my preference.

Any final thoughts, before I dive back into KiCAD?