DigicoolThings Forum

With my first Minimalist Europe Card Bus CPU Card finally completed, to my satisfaction. Next up, was my Motorola based I/O Card, which will finally enable a complete modular 6809 based system.

In fact, my initial design had been completed, which also contributed a couple of recent posts / videos as I finalised the ACIA Baud Rate Generator, and the Interrupt Driver components of the design.

Join me, as I walk through the Schematic and PCB layout and then assemble and test my first card, here: Minimalist Europe Card Bus (MECB) – Motorola I/O Card + Sound

Subsequent Version Updates:

• v1.2 - Minor change to implement 3-way header for Audio Out (replacing original 2-way header), for consistency with other newer cards featuring an Audio Out header.

Just wondering - will there be a suggested I/O map for peripherals such as future MECB hardware that we might be planning, or would it be prudent to have a flexible map within our designated I/O space with jumpers or switches when designing these cards? Thinking about for example, creating a ps/2 keyboard and mouse port, and wondering how to resolve conflicts in a sane way with other peripheral cards?

There are other things I've toyed with way off in the future - say for example, things like an SDCard drive or Compact Flash drive where I wouldn't mind having two connected simultaneously to shuffle files back & forth between them, or having multiple joystick/controller ports, and maybe a way to identify if there's something using that I/O space, and what it might be in code?

bugeyedcreepy wrote: Sat Nov 25, 2023 1:16 pm Just wondering - will there be a suggested I/O map for peripherals such as future MECB hardware that we might be planning, or would it be prudent to have a flexible map within our designated I/O space with jumpers or switches when designing these cards?

My intention is that each card design provides flexibility to allow customising the address space allocation as desired. It’s one of the reasons for going with a standardised PLD glue logic solution. This enables each card to be configured for use in a large variety of address maps, which also allows configuring a system to mimic various other systems.

But, if you were building a newly defined system with your own standardised memory map, then it would certainly make sense to publish that memory map for others to replicate the same configuration.

The standardised PLD connections I went with allow for up to 32 I/O device allocations (with 8 byte resolution), and memory device allocation with 2KB resolution within the 16-bit 64KB address space.

With the ROM Expansion Card, where I/O space was not required, I added an extra memory address line input to the PLD (top 6 address lines), to allow for a 1KB resolution for the ROM space allocation.

So, overall there should be plenty of space / flexibility for whatever I/O devices, or memory space, you may want to allocate.

Editor wrote: Sat Nov 25, 2023 7:56 pm My intention is that each card design provides flexibility to allow customising the address space allocation as desired. It’s one of the reasons for going with a standardised PLD glue logic solution. This enables each card to be configured for use in a large variety of address maps, which also allows configuring a system to mimic various other systems.

Ahh, Right, now I understand - but I guess if I wanted to include a jumper option to select between two pre-programmed PLD address mappings, I could do that in the design easy enough? Like if I wanted to try running dual sound cards for my daughter's MIDI setup? Currently I'd be required to reprogram the PLD for each card - not a hard ask, I understand, but were I not in town and she wanted to substitute a card for something else, or another identical sound card because this one wasn't working, she would be able to jumper a replacement to suit in my absence, or with minimal support over the phone.

Editor wrote: Sat Nov 25, 2023 7:56 pm But, if you were building a newly defined system with your own standardised memory map, then it would certainly make sense to publish that memory map for others to replicate the same configuration.

Meh, I'm happy to stick to a standard, and I don't have the experience to be that meticulous about it anyway. Later on, I do intend to try my hand at creating an Atari 2600 cartridge system that would involve a matching MECB display card that suits that system to try my hand at such a system mimic you suggest above - one that could even take actual Atari 2600 cartridges...(?)

Editor wrote: Sat Nov 25, 2023 7:56 pm The standardised PLD connections I went with allow for up to 32 I/O device allocations (with 8 byte resolution), and memory device allocation with 2KB resolution within the 16-bit 64KB address space.

Hmmm, that second part I'm not sure I understand - what's with the memory device allocation? I've been searching all kinds of information on getting a CF/SDCard mass storage MECB underway, but right now, it defeats me how it works on the many other systems that have implemented it, I'm obviously not getting the whole story here... -_-

Editor wrote: Sat Nov 25, 2023 7:56 pm With the ROM Expansion Card, where I/O space was not required, I added an extra memory address line input to the PLD (top 6 address lines), to allow for a 1KB resolution for the ROM space allocation.

So, overall there should be plenty of space / flexibility for whatever I/O devices, or memory space, you may want to allocate.

....and one day, I might understand the memory device allocation thing...

bugeyedcreepy wrote: Sat Nov 25, 2023 11:39 pm Ahh, Right, now I understand - but I guess if I wanted to include a jumper option to select between two pre-programmed PLD address mappings, I could do that in the design easy enough? Like if I wanted to try running dual sound cards for my daughter's MIDI setup? Currently I'd be required to reprogram the PLD for each card - not a hard ask, I understand, but were I not in town and she wanted to substitute a card for something else, or another identical sound card because this one wasn't working, she would be able to jumper a replacement to suit in my absence, or with minimal support over the phone.

A jumper to select between two different PLD configured memory map options would require a PLD input of the jumper state.

What I would suggest instead, would be to instead simply install a 20-pin ZIF socket for the PLD. I specifically designed in enough PCB space to accomodate a ZIF socket for easy PLD change-outs.

Then, just ensure you label your programmed PLDs (as I have done on the PLDs I supply with Tindie orders).

It would then be very easy for anyone to simply pop-out an existing PLD from a levered ZIF socket, and swap it for another pre-programmed one.

bugeyedcreepy wrote: Sat Nov 25, 2023 11:39 pm Meh, I'm happy to stick to a standard, and I don't have the experience to be that meticulous about it anyway. Later on, I do intend to try my hand at creating an Atari 2600 cartridge system that would involve a matching MECB display card that suits that system to try my hand at such a system mimic you suggest above - one that could even take actual Atari 2600 cartridges...(?)

Sounds like a fun project to explore!

bugeyedcreepy wrote: Sat Nov 25, 2023 11:39 pm Hmmm, that second part I'm not sure I understand - what's with the memory device allocation? I've been searching all kinds of information on getting a CF/SDCard mass storage MECB underway, but right now, it defeats me how it works on the many other systems that have implemented it, I'm obviously not getting the whole story here... -_-

I think the easiest way to explain this is that if you consider the 6809 CPU Card has a 64KB SRAM chip on it. Clearly we are not using the full available 64K memory space just for SRAM. Instead, using the PLD logic equation we determine the address range that the RAM chip select output is asserted for.

So for example we can assert the CS_RAM output only for addresses $0000 to $7FFF (i.e. Simply address Line A15 low), to enable RAM in the bottom 32K half of the memory map.

Likewise, on a ROM EXpansion Card we could enable the ROM chip select for $8000 to $FFFF, for the selected ROM bank to fill the top 32K of the memory map (with the CPU Cards ROM chip select dissabled, or the ROM chip not even installed).

Slightly more complcated, to mimic a CreatiVision game console, the CPU Card would contain the BIOS ROM, perhaps this is located from $C000 to $FFFF (top 16KB). And the "Cartridge" ROM Expansion Card is enabled from $4000 to $BFFF (middle 32K), and the CPU Cards RAM is enabled for $0000 to $3FFF (bottom 16K).

Of course this is just an example, I'd have to have another look at the actual Creativision memory map to confirm. Also, to check on the Peripheral device address allcation etc.
But, it provides a useful example of using both RAM and ROM on the CPU Card, as well as Banked ROM on the ROM Expansion Card, all in the same 64K memory map.

Hope this helps clarify?
[/quote]

hello
can someone help me with the connection of the J6 , and witch and how to connect to FDI, i guess "rs232 tro usb" card
many thanks
cram51

cream51 wrote: Thu Dec 18, 2025 6:49 am can someone help me with the connection of the J6 , and witch and how to connect to FDI, i guess "rs232 tro usb" card

Hi. Hopefully a quick photo can help.

You simply need to connect TxD, RxD, and GND to your TxD, RxD, and GND of your TTL level USB Adapter.

Seperate to this, you'll need to GND the J6 RTS input, to allow serial traffic to flow (without hardware handshake).

Note: The interface is direct TTL level, so don't use a RS232 level adapter.

Hope this helps points you in the right direction.

hello sir
please can you look once at the pictures, to see if the µs and the jumpers are correct. there is no connection with the serial port
many thanks
cram51

cream51 wrote: Wed Dec 24, 2025 2:54 am please can you look once at the pictures, to see if the µs and the jumpers are correct. there is no connection with the serial port

Hi!

From the best that I can see, it appears you have the same USB Adapter as I have (as I pictured above), and it does appear to be connected correctly (assuming also that you have RTS grounded).

I see baud rate is set at 9600.

I do however have some questions / concerns with the 6809 CPU card pictured.

1. Is it a 6809P or a 6809E (Internal or External clock)?

You appear to have both the ’6800’ PCB Jumper installed, as well as U6 installed (74HCT73).
Only one of these should be installed at once.

The Jumper only (no U6), if 6809 (internal clock), or, U6 only (no Jumper) if 6809E (external clock).
The PCB notes U6 is for 6809E only.

2. The IORQ Bank Select switches appear incorrect.

As noted on the PCB, 1 = Off and 0 = On.
i.e. For the 48K + 16K memory map (indicated on the PLD label), you would typically have the IORQ at $C0xx.

This requires A15 & A14 high (1), and A13 - A8 low (0).

Therefore, I was expecting to see switches 1 & 2 OFF, and switches 3 - 8 ON.
This would then equate to I/O block $C0xx.

3. I also want to check the ASSIST09 ROM image you are using.

Is this ASSIST09 ROM configured for the 48K + 16K memory map?

The default (original) ASSIST09 ROM image was configured for a 56K + 8K memory map, with I/O at $E0xx.
Note this requires a 56K + 8K configured PLD, and also IORQ Bank select switches 1 - 3 OFF, and the rest ON (for $E0xx).

More recent Tindie Store 6809 CPU Card's have an option for either the 48K/16K or 56K/8K PLD, and also an option for either 'ASSIST09 56K/8K/C0', or 'ASSIST09 48K/16K/E0' (as shown on the supplied ROM label).

If you have one of the original ASSIST09 ROMs (as possibly indicated by the label), then note this was supplied for the original 56K/8K memory map.


I hope this all helps to isolate the issue.

hello sir
i tryed some changes on my cpu board, the processor is an EF68B09EP, so no oscillator on he chip
i removed the JP2, just connected on 1 side.
the JP1 is just connected to 1 pin
sw2 is A15 and A14 is off-------- A13,1A12,A11,A10,A9,A8 is ON
see pictures?