DigicoolThings Forum

djrm wrote: Sat May 03, 2025 9:31 pm I was disappointed to see that available address bus inputs to the prototype board included A15-A12 , these are not much use here and A11-A12 would have been more useful. but this had never been a problem before and probably will not be again.

All peripheral boards (including Prototype PLD), include A15-A11 (for minimum 2KB resolution MREQ addressing blocks), and A7-A3 (for minimum 8 byte IORQ resolution addressing blocks).

As the AIM-65 uses 4x 1KB pages in it's $Axxx I/O allocation, you'd only need to add A10 to the peripheral card's PLD input to be able to decode the AIM-65 I/O space allocation (using MREQ and A15-A10 to resolve each 1K I/O space).

Hence, my earlier thought that this could currently be achieved by disconnecting A7 from the PLD (pin 19), and jumpering across the A10 bus line.

This would give you your AIM-65 1KB I/O Chip Select allocation, whilst still retaining half of the existing IORQ bank space (256 bytes) for additional "user device" I/O allocations (half because A7 is no longer available to the PLD logic, so the bottom 128 bytes of IORQ space would be mirrored to the top 128 bytes. So only 16 possible 8 byte I/O spaces, instead of 32).

With the AIM-65's "expansion" address space (e.g. $1000-$9FFF), you could then presumably locate your extra "user" I/O space at $9Fxx
That is, by just stealing the top 256 bytes of the possible fully expanded 40K RAM space (or, alternatively use 256 bytes somewhere else in the RAM expansion space).

djrm wrote: Sat May 03, 2025 9:31 pm For sure the 22v10 would be more useful but I cant guarantee it would help. Some extra flexibility to jumpering the pld inputs instead of having to cut tracks would have useful too where I needed to give the IORQ bank more then 256 bytes.

Instead of jumpering PLD inputs, I think that moving to a 22V10 (so all of the Address lines A3-A15 are available to the PLD), would be a much tidier, easier to manage, and complete, solution.

Extending the IORQ bank to 4KB (instead of 256 bytes) I don't think is a good / viable solution. Although it could be done by leaving the A8-A11 switches open, jumpering across the same 4 bus address lines to the switch connections, and also (preferably) removing 4 of the IORQ comparator pull-ups (e.g. swapping the SIL9 pull-up for a SIL5 pull-up), it's definately not a pretty "hack".

djrm wrote: Sat May 03, 2025 9:31 pm On my present setup the ram and rom are on the additional display board, the memory sockets on the CPU board are now empty.

No problem, although I imagine you'd be running short of Chip Selects, without rolling some of your own additional glue logic?

Ideally, you could just map the existing CPU board's PLD for the on-board RAM and ROM to be in $0000-$9FFF (RAM), and $B000-$FFFF (ROM).

I think I'll proceed with implementing a 22V10 PLD standard MECB configuration option (for future peripheral MECB Card designs), as this will more tidily resolve the issue of trying to replicate, I imagine, any existing retro system's memory map (allowing MREQ address decoding down to 8 byte resolution addressing blocks).

To implement this, would just require me to implement another KiCAD template routed PCB (with a standard 22V10 pin usage), and then introduce a new Protoype 22V10 PLD Card (to suplement the existing 16V8 Prototype PLD Card).

From then, any new peripheral card designs could be designed around either the 16V8 or 22V10 PLD. Cards that only use the MECB IORQ space would only benefit from an additional (4th) Chip Select. But, Cards that choose to use MREQ based addressing in their PLD logic will then benefit from the full available 64K address range down-to an 8 byte addressing resolution.