DigicoolThings Forum

Posted: **Sat May 31, 2025 5:14 am**

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

Posted: **Sun Jun 01, 2025 3:17 pm**

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;

Posted: **Sun Jun 01, 2025 10:43 pm**

djrm wrote: Sun Jun 01, 2025 3:17 pm 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...

Posted: **Mon Jun 02, 2025 9:44 am**

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.

Posted: **Tue Jun 03, 2025 4:41 am**

djrm wrote: Mon Jun 02, 2025 9:44 am 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];

DigicoolThings Forum

[v1.0] MECB Prototype 22V10 Card

[v1.0] MECB Prototype 22V10 Card

Re: [v1.0] MECB Prototype 22V10 Card

Re: [v1.0] MECB Prototype 22V10 Card

Re: [v1.0] MECB Prototype 22V10 Card

Re: [v1.0] MECB Prototype 22V10 Card