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

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]