very simple Expansion Interface (new to CPC)

[Bryce]

But what signal are you using to enable/disable each card? And what about cards that contain Flash/EPROM/ROMs that need to be accessed directly?

Btw, there's a list here of most hardware expansions, what port they use and how much of the address bus they decode: http://www.cpcwiki.eu/index.php/I/O_Port_Summary


Bryce.

[TotO]

The CPC had potentially 65536 I/O ports (4096 for the users, because #Fxxx) ... All others Z80 computers only 256. And usually, an expansion board require 1, 2 or 4 ports to work.
So, why not simply using free ports or ranges for your expansion like everybody does? You have 16 times more the choice! 
On MSX, many expansions exist, and nobody looks to have problems to deal with them.


Your idea is nice, but... Hey, return 30 years ago to do a standard because today it is late... All the I/O range is fragmented. 
Do you really require so much I/O to redo the wheel for your incomming expansions?


By the way, you are free to allow 16x 256 I/O slots (as well as 256x16 I/O) into your decoding system. Just think that will be not compatible with the existing.
Obviously, it is not a problem if you are only using your own expansion boards!!! 

[Prox]

But what signal are you using to enable/disable each card? And what about cards that contain Flash/EPROM/ROMs that need to be accessed directly?

Btw, there's a list here of most hardware expansions, what port they use and how much of the address bus they decode: http://www.cpcwiki.eu/index.php/I/O_Port_Summary


Bryce.

like on the pseudo-diagram, it uses a single External Register to select the card you want to access. it's the automated equivalent of plugging in/out cards while the CPC is running, only difference you don't actually need to pull anything out/in and the disabled cards remain powered.


also i don't see any problem with ROM/RAM cards as they still have access to the full 50 pin expansion connector. so they would work perfectly find, but only if they are the selected card, as soon as you select another one the RAM/ROM would seeming disapear from the address range.

The CPC had potentially 65536 I/O ports (4096 for the users, because #Fxxx) ... All others Z80 computers only 256. And usually, an expansion board require 1, 2 or 4 ports to work.
So, why not simply using free ports or ranges for your expansion like everybody does? You have 16 times more the choice! 
On MSX, many expansions exist, and nobody looks to have problems to deal with them.


Your idea is nice, but... Hey, return 30 years ago to do a standard because today it is late... All the I/O range is fragmented. 
Do you really require so much I/O to redo the wheel for your incomming expansions?


By the way, you are free to allow 16x 256 I/O slots (as well as 256x16 I/O) into your decoding system. Just think that will be not compatible with the existing.
Obviously, it is not a problem if you are only using your own expansion boards!!! 

the point was not really because i or anyone needs that many ports, but because this prevents port clashing of already existing and potential future expansion cards. and it would still be compatible with existing MX4 cards, because all of the decoding and logic is done on the splitting card, not the expansion cards


also, why does the wiki have a list of used ports, but not a list or diagram of free ports. (like a memory map, but with IO)

[TotO]

Your way to do is something like a bank manager for expansion slots... To allow to have all the boards at the same address range to not require to decode them.
It is interresting, but if I understand well, you have to set the port and the slot each time you want to access it. And you can't use the expansions without the slots expansion board.


This to save something like 50cts per expansion? 

By the way, I'm curious to see the final result.

[Prox]

Your way to do is something like a bank manager for expansion slots... To allow to have all the boards at the same address range to not require to decode them.
It is interresting, but if I understand well, you have to set the port and the slot each time you want to access it. And you can't use the expansions without the slots expansion board.


This to save something like 50cts per expansion? 

By the way, I'm curious to see the final result.

well the card you access is stored in a register on the board itself, once it's set the card on the selected slot will permanently be enabled until the value in the External Register is changed.

so if you were to move data from one RAM card to another RAM card it would probably go like this:


* Set Slot number of the first RAM Card in the External Register
* Move as much data as needed (or as much as can fit) from the RAM Card to the CPC RAM
* Set Slot number of the second RAM Card in the External Register
* Move the data from Internal RAM to the RAM Card
* Repeat until done

also if i had the knowledge about designing PCBs i would probably make this right away, i do have all the chips required. (though i don't have 2x25 pin connectors for MX4 cards)

[Bryce]

like on the pseudo-diagram, it uses a single External Register to select the card you want to access. it's the automated equivalent of plugging in/out cards while the CPC is running, only difference you don't actually need to pull anything out/in and the disabled cards remain powered.


also i don't see any problem with ROM/RAM cards as they still have access to the full 50 pin expansion connector. so they would work perfectly find, but only if they are the selected card, as soon as you select another one the RAM/ROM would seeming disapear from the address range.

But that's exactly my point, expansion cards don't have an enable pin. How do you intend enabling/disabling a card? How is it selecting the card?

The problem with ROMs is that they all need to be present when the computer boots. This is when the port and RSX's get assigned in RAM, you would need to completely re-write the ROM handling routines in the Firmware to get around this. The RSX is just expecting the card to always be there, it doesn't know how to select a card. That also brings up a further issue: What if the LowerROM is on an expansion card?

Bryce.

[Prox]

But that's exactly my point, expansion cards don't have an enable pin. How do you intend enabling/disabling a card? How is it selecting the card?

The problem with ROMs is that they all need to be present when the computer boots. This is when the port and RSX's get assigned in RAM, you would need to completely re-write the ROM handling routines in the Firmware to get around this. The RSX is just expecting the card to always be there, it doesn't know how to select a card. That also brings up a further issue: What if the LowerROM is on an expansion card?

Bryce.

ok first i need to clarify some terms, otherwise it's gonna be a bit harder to explain because everything can be called an Expansion card.

Spoiler: ShowHide

ok now. the expansion cards don't need an enable pin because all the decoding, enabling/disabling is done by the Splitter card.
so it's the Splitter card's job to take the value from the register (which is also on the card) and decode that to enable one of the Slots.
I thought the pseudo-diagram i made showed the buffers and everything being before the actual slot where you plug cards into, that way the cards themself don't need to change to fit into it.

next up, RSX. to be honest i had no idea this existed, and i'm not entirely sure what it is... so i never accounted for that. but just reading the wiki it seems to allow the CPC to add additional commands and routines to itself via external ROM.

but then again couldn't that feature be used to fix itself? like, what if there was a ROm Chip on the Splitter card? RSX would only read that in and add any commands/routines that are on there, right? so couldn't those routines add the ability to search for more ROM Cards by selecting different slots and checking of they're ROM card, etc?

lastly, LowerROM Cards would be like switching the OS of the Computer, right? so they really need to be enabled from the very start, otherwise it couldn't really start.

so, my idea was to just have a Jumper which can permanently enable Slot 0. (or maybe even any slot)

just to clearify, if the card were to be real and you would hold it, here is how i thought about the Slots:

Spoiler: ShowHide

as you can see, Slot 0 is the Edge connector at the end of the Card so if that was set to be permanently enabled you could plug anything into there like the Splitter card didn't even exist. this would allow you to use lowerROM (or any) Expansion Card without it needing to be enabled, if the card requires that to be completely functional.

then again if you think about it. since the Splitter card will just decode whatever is inside the D-FF, and the default value when powering on is 0, this would mean that when powered on, the first slot that would be enabled from the start is Slot 0. which can be used to something that can be used from startup.



I'm sorry if this is getting really complex or off-topic this was just a random idea i had that i just kept on expanding.

[Bryce]

It does seem to be a definition of terms issue. You refer to "enabling" a card. Can you explain what enabling would entail? Is this a single signal to the card, is it passing the entire bus through to the correct card? Define how (electronically) a crad would be disabled, which signals would not get to the card so that it doesn'T start putting data on the bus.

Regarding RSX's, many cards come with their own commands, for example, the DKTronics speech synthesiser adds commands such as |Speak. This command is saved in the CPC's RAM with a pointer to the ROM slot where the command code can be found. How would the (no longer very simple) Interface know which card to enable when I type: |Speak "Why doesn't this interface work?"

Bryce.

[TotO]

What I have previously understood is:
- The full addr, data, cmd lines are disabled using some 245 IC if the slot is not set
- You select a slot to set by writing its value into a buffer through a dedicated I/O port
- The Slot 0 is always connected and you expect to not use the same address than slot1-sot4 to not conflict the board

At end, all the custom expansions going to this slot interface do not require any decoding because all at the same port but never set at the same time.

[Prox]

It does seem to be a definition of terms issue. You refer to "enabling" a card. Can you explain what enabling would entail? Is this a single signal to the card, is it passing the entire bus through to the correct card? Define how (electronically) a crad would be disabled, which signals would not get to the card so that it doesn'T start putting data on the bus.

Regarding RSX's, many cards come with their own commands, for example, the DKTronics speech synthesiser adds commands such as |Speak. This command is saved in the CPC's RAM with a pointer to the ROM slot where the command code can be found. How would the (no longer very simple) Interface know which card to enable when I type: |Speak "Why doesn't this interface work?"

Bryce.

What I have previously understood is:
- The full addr, data, cmd lines are disabled using some 245 IC if the slot is not set
- You select a slot to set by writing its value into a buffer through a dedicated I/O port
- The Slot 0 is always connected and you expect to not use the same address than slot1-sot4 to not conflict the board

At end, all the custom expansions going to this slot interface do not require any decoding because all at the same port but never set at the same time.

what TotO says is basically correct, 48 out of the 50 pins would be completely cut off from the Cards (except +5V and GND) by using Transceivers and Buffers.


also Slot 0 can be disabled like any other slot. it's just that when you power the CPC on (or have a jumper set) SLot 0 will be enabled by default because the D-FF will contain 0x00 after a cold reset.


lastly, i think i see what you mean. even if all commands and routines could be loaded into the CPC by using an additional routine it still doesn't replace the Firmware's way of trying to execute them.
because the Firmware has no idea that there are multiple cards it cannot set the correct slot before trying to execute something.
and to be honest i have no idea how that could be solved, other than to require a Lower ROM board or ROM chip on the Splitter card that replaces the default routines that handle expanion devices. (like RSX)

[Bryce]

Ok, ignoring the RSX issue... 48 bidirectional low-latency tri-state buffers!!! That's not one or two chips like in your diagram, that's one massive PCB with a pile of chips and probably not very cheap either.

Bryce.

[Prox]

Ok, ignoring the RSX issue... 48 bidirectional low-latency tri-state buffers!!! That's not one or two chips like in your diagram, that's one massive PCB with a pile of chips and probably not very cheap either.

Bryce.

i mean not all are bidirectional.


only the data bus is actually bi-directional. the rest can technically just be done with Buffers.
so that would be 1x 8 bit Transceiver and 5x 8 bit Buffers (or 3x 16 bit Buffers) (or 2x 20 bit Buffers)

sure it can be done easier by having the cards handle the Enable Signal from the Splitter, but part of the idea was to expand on the MX4 standard without requiring cards to change to be compatible.

sure this would also work by just cutting the power off the cards, but that will be a problem as RAM cards loose their content, and all kinds of Video and sound cards will cease to function until they are selected again.

overall i cannot think of a better way of disabling cards without changing the cards themself

[TotO]

Hum... As I know, you wished to start with simple expansions as a ROM board... And it will not be friendly with your labyrinthine system.   
Next, about RAM boards, if you use SRAM ICs you will not lose anything. (and if you plan to use D-RAM, you will make it more complex because you will have to do the refrest by yourself)

[Prox]

Hum... As I know, you wished to start with simple expansions as a ROM board... And it will not be friendly with your labyrinthine system.   
Next, about RAM boards, if you use SRAM ICs you will not lose anything. (and if you plan to use D-RAM, you will make it more complex because you will have to do the refrest by yourself)

yea it kinda spiraled out of control. sorry


also doesn't the Z80 have build in DRAM Refresh? then again SRAM is just easier to work with and i have some 512kB SRAM chips lying around.

[TotO]

also doesn't the Z80 have build in DRAM Refresh? then again SRAM is just easier to work with and i have some 512kB SRAM chips lying around.

On CPC, the refresh is done with the CRTC addressing for internal memory only. (64K + 64K for 6128)
About the /REFH signal, I think that it will not do the job on the hidden pages ... and over 64K.

[Prox]

ok so I almost got the board finished (finally), just need a few more logic gates and the decoding


decoding the ROM Number is a bit strange but doable, as i want to use bit 0-4 for Bank Switching for multiple ROM Banks. it should be easy as i only need to connect bit 0-4 to a pyramid of OR gates so that the output is only 0 when all inputs are 0. that will be hooked up to the ROMDIS pin so that when the ROM Number is larger than 0x00 but smaller than 0x20 it will disable the Internal ROM.
bit 0-4 of the ROM Number will then also be hooked up to A14-18 of the ROM to select the Banks.
speaking of ROM, the wiki says that ROMEN will be 1 when A14 and A15 = 1. but also when they are both zero? which one is it by default? if the first one is true i can just connect ROMEN + RD + MREQ (+ some OR gates) to the OE (Output Enable) of the ROM, and ROMEN itself to the CE (Chip Enable).





but i'm also wondering about decoding specific adresses. how would i go about doing that?


am i just supposed to use a lot of OR and NOT gates (or NAND and NOT)? or is there an easier way to decode things properly? without wasting too much space and without wastin gaddress space.


.


again, thanks for all the help. I get distracted easily on the long run, so actually finishing something would be really amazing

[rpalmer]

Prox,

Think about using a PAL chip (example 16V8, 22V10) to handle any decoding as it reducing the chip count plus you can always check the PAL program to see if it matches what you want it to do.

rpalmer

[Prox]

Prox,

Think about using a PAL chip (example 16V8, 22V10) to handle any decoding as it reducing the chip count plus you can always check the PAL program to see if it matches what you want it to do.

rpalmer

I thought about getting myself some CPLD (since PAL/GAL is basically completely discontinued nowerdays). i know my Universal programmer supports some PLDs/GALs/CPLDs mostly just atmel chips (ATF16 - ATF22) and some older GAL chips.

if i were to get some CPLD i wouldn't know how to program them without spending even more money on another Universal  programmer.

[LambdaMikel]

I guess if I ever were to develop something for the CPC again, then I would probably use STM32 (like Duke). I believe with that thing and its > 90 Mhz clock rates, you can even do the address decoding and everything in software.

Good thing about old GALs is - they are very cheap (pulled from old devices, and most still work):

https://www.ebay.com/itm/10PCS-IC-GAL22V10D-DIP-24-LATTICE-NEW-GAL22V10D-15LP/281757770102?epid=625482547&hash=item419a126176:g:Q6MAAOSwLVZVszh2
And who cares if the parts are obsolete - so is the CPC 
Xilinx USB platform cable does not have to be that expensive:
https://www.ebay.de/itm/Xilinx-Platform-USB-Download-Cable-Jtag-Programmer-for-FPGA-CPLD-C-Mod-NEW/171008779562?hash=item27d0eae52a:g:nzsAAMXQ01tRRSeo&frcectupt=true
That's the one I have (cheap China clone), and it is working just fine for the old XC95... CPLDs... pretty obsolete as well btw.

[Prox]

I guess if I ever were to develop something for the CPC again, then I would probably use STM32 (like Duke). I believe with that thing and its > 90 Mhz clock rates, you can even do the address decoding and everything in software.

Good thing about old GALs is - they are very cheap (pulled from old devices, and most still work):

https://www.ebay.com/itm/10PCS-IC-GAL22V10D-DIP-24-LATTICE-NEW-GAL22V10D-15LP/281757770102?epid=625482547&hash=item419a126176:g:Q6MAAOSwLVZVszh2
And who cares if the parts are obsolete - so is the CPC 
Xilinx USB platform cable does not have to be that expensive:
https://www.ebay.de/itm/Xilinx-Platform-USB-Download-Cable-Jtag-Programmer-for-FPGA-CPLD-C-Mod-NEW/171008779562?hash=item27d0eae52a:g:nzsAAMXQ01tRRSeo&frcectupt=true
That's the one I have (cheap China clone), and it is working just fine for the old XC95... CPLDs... pretty obsolete as well btw.

the GAL22V10D is actually supported by my TL866ii plus. still no idea what kind of software you use to write the program but as long as it can output a BIN file i will be able to load it into the GAL.
thanks!

[Bryce]

GAL's and PAL's are programmed in HDL and the source file is a called a JED file. If you've no idea what that sentence means, take a look at the code here for the RAM Banking PAL used in the 6128 as a starter: http://www.cpcwiki.eu/index.php/PAL16L8
It's quite an easy language to learn.

Bryce.

[LambdaMikel]

the GAL22V10D is actually supported by my TL866ii plus. still no idea what kind of software you use to write the program but as long as it can output a BIN file i will be able to load it into the GAL.
thanks!

There is a legacy program called "WinCUPL"... that does only run on Windows XP  No kidding. I keep a virtual machine of Win XP just for that reason

[Bryce]

There is a legacy program called "WinCUPL"... that does only run on Windows XP  No kidding. I keep a virtual machine of Win XP just for that reason

https://www.microchip.com/design-centers/programmable-logic/spld-cpld/tools/software/wincupl

If it's this one, I have got this working on Windows 7 in the past. Never tried Win10.


Bryce.

[LambdaMikel]

https://www.microchip.com/design-centers/programmable-logic/spld-cpld/tools/software/wincupl

If it's this one, I have got this working on Windows 7 in the past. Never tried Win10.

That's good to know! I have only tried this on Windows 10. No Windows 7 here.

[rpalmer]

There is a legacy program called "WinCUPL"... that does only run on Windows XP  No kidding. I keep a virtual machine of Win XP just for that reason

I run WinCUPL on my windows 7 machine with no problems.