CPCWiki forum

Greetings! I recently bought a CPC 464 in fully working condition and i'm looking into some kind of simple Interface with the Floppy/Expansion port so that i can basically hook up any kind of 8 bit device (RAM, ROM, Character LCD, Serial Interface, etc)


I have a good understanding of Logic, Computers, and the Z80 itself so i should be able to build the circuit myself.


the problem i have though is that i barely know something about the CPC 464.


for example are there empty places in the Memory map where i could put ROM/RAM into, or any free IO Ports that could be used?


does the BASIC v1.0 even have commands to use the ROM/RAM/IO Devices? (so that i could for example load BASIC or ASM Programs from ROM or a Serial Connection). and if not how would i go about upgrading the ROM, i only got a few 8kB EEPROMs and 512kB FLASH chips lying around.


and lastly, is it even that easy to hook something up to it?
since the pinout on the wiki indicates that all important Pins from the Z80 are directly on the port (A0-A15,D0-D7,RD,WR,MREQ,IORQ,CLK)

Welcome!

Here some I/O port informations: http://www.cpcwiki.eu/index.php/I/O_Port_Summary (http://www.cpcwiki.eu/index.php/I/O_Port_Summary)
About ROM/RAM ... You should found informations into the wiki too.

yes i saw that page but I'm aparently not smart enough to actually understand it.


what confuses me is that they mostly use 16b addresses, as far as i know the Z80 uses 8b addresses (A0-A7) for IO Devices. so i cannot really tell which addresses are free to use.


and i didn't really find anything useful/understandable for RAM/ROM expansions.

Prox,

the Z80 uses 16Bit I/O address via register BC.

The use of the lower bits only was due to programmers and not a hardware limitation.

The BC register was issued to the I/O space where the B register was used as a counter with such instructions as OUTIR, INIR to make loops easier.

rpalmer

Exactly. The CPC has a 16bit I/O port and most of the MSB are used with partial decoding using only one line for the internal hardware (A15, A14, A13, A12).
About standard memory expansion, you have to locate RAM at #7Fxx (512KB) and ROM at #DFxx (and handle yourself the page banking) to be compatible.
Here the standard ports used: http://www.cpcwiki.eu/index.php/Default_I/O_Port_Summary

Quote from: Prox on 21:11, 04 March 19i'm looking into some kind of simple Interface with the Floppy/Expansion port so that i can basically hook up any kind of 8 bit device (RAM, ROM, Character LCD, Serial Interface, etc)

I think, the more easy to start is to build your own ROM board using your 512KB flash chip (Winbond or SST ?) and some logic gates ...

- 512KB (4Mb) flash IC
- 74*374 or 74*574 to store the bank config and generate the extra address lines (RA14 to RA18)
- some other IC logic gates
- 1 diode (4148) + 1 resistor (1k) for ROMDIS
- some decoupling capacitors

A13, /WR, /IORQ are required to set the bank number
A14, A15, /MREQ are required to select the external ROM (and disable the internal ROM)

Have fun!

Quote from: TotO on 22:22, 04 March 19I think, the more easy to start is to build your own ROM board using your 512KB flash chip (Winbond or SST ?) and some logic gates ...- 512KB (4Mb) flash IC- 74*374 or 74*574 to store the bank config and generate the extra address lines (RA14 to RA18)- some other IC logic gates- 1 diode (4148) + 1 resistor (1k) for ROMDIS- some decoupling capacitorsA13, /WR, /IORQ are required to set the bank numberA14, A15, /MREQ are required to select the external ROM (and disable the internal ROM)Have fun!

that was kind of the plan for a first little project. it should be easy enough


are those "74*374 or 74*574" Buffers or D-Flip flops?



i assume D-Flip flops so they can store the ROM Bank information.


that also answered one of my questions below.

Quote from: rpalmer on 21:56, 04 March 19
Prox,

the Z80 uses 16Bit I/O address via register BC.

The use of the lower bits only was due to programmers and not a hardware limitation.

The BC register was issued to the I/O space where the B register was used as a counter with such instructions as OUTIR, INIR to make loops easier.

rpalmer

ok so if i understand that correctly if i want to write to the gate array (0x7FXX) i would need to have C = 0x7F and B doesn't matter?

Quote from: TotO on 22:09, 04 March 19
Exactly. The CPC has a 16bit I/O port and most of the MSB are used with partial decoding using only one line for the internal hardware (A15, A14, A13, A12).
About standard memory expansion, you have to locate RAM at #7Fxx (512KB) and ROM at #DFxx (and handle yourself the page banking) to be compatible.
Here the standard ports used: http://www.cpcwiki.eu/index.php/Default_I/O_Port_Summary (http://www.cpcwiki.eu/index.php/Default_I/O_Port_Summary)

ok there is a lot of Space in the IO Range, so i could just use 00XX-7EXX without any problems in the standard CPC464? neat.
also a bit looking around on the wiki i found a memory map
(https://i.imgur.com/SECZd4F.png)
the manual itself mentions ROM Banking in detail (as far as i could understand it i need to use a FAR CALL if i want to run a program from any Expansion ROM? basiclaly RST 3 <Address> 0-251 to select ROM)
plus why did you say that ROM had to start somewhere from 0xDF00 to 0xDFFF? the memory map indicates that expansion ROMs can start from 0xC000.
also another thing that still confuses me is how the Computer selects ROM Banks, i don't really see any extra pins on the Expansion Port that would allow for banking. like how does the CPC know which of the ~251 External ROMs are actually there and how does it select between them?


I'm really sorry for my ignorance, it's just that i know barely anything about this Computer and i'm very bad and finding and reading Documentation. but i gotta start somehow.

.

on another note i'm not a fan of the formatting on this site. it's so easy to accidentally make everything tiny or make some text not be the same size as other text

Quote from: Prox on 22:50, 04 March 19
ok there is a lot of Space in the IO Range, so i could just use 00XX-7EXX without any problems in the standard CPC464? neat.
also a bit looking around on the wiki i found a memory map
(https://i.imgur.com/SECZd4F.png)
the manual itself mentions ROM Banking in detail (as far as i could understand it i need to use a FAR CALL if i want to run a program from any Expansion ROM? basiclaly RST 3 <Address> 0-251 to select ROM)
plus why did you say that ROM had to start somewhere from 0xDF00 to 0xDFFF? the memory map indicates that expansion ROMs can start from 0xC000.

Don't confuse I/O map (/IORQ) and memory map (/MREQ) ! ;)

Quote from: Prox on 21:11, 04 March 19
I have a good understanding of Logic, Computers, and the Z80 itself so i should be able to build the circuit myself.


the problem i have though is that i barely know something about the CPC 464.

Since you are German -

Mein Tipp - einmal

http://www.cpcwiki.eu/index.php/Das_Schneider_CPC_Systembuch (http://www.cpcwiki.eu/index.php/Das_Schneider_CPC_Systembuch)

durchblaettern, sparrte ne Menge (unnoetige) Diskussion hier ;)

Quote from: LambdaMikel on 23:14, 04 March 19


Since you are German -

Mein Tipp - einmal

http://www.cpcwiki.eu/index.php/Das_Schneider_CPC_Systembuch (http://www.cpcwiki.eu/index.php/Das_Schneider_CPC_Systembuch)

durchblaettern, sparrte ne Menge (unnoetige) Diskussion hier ;)

I'm already looking into this one: http://www.cpcwiki.eu/imgs/d/d3/CPC_464_intern.pdf (http://www.cpcwiki.eu/imgs/d/d3/CPC_464_intern.pdf)

Quote from: TotO on 23:03, 04 March 19
Don't confuse I/O map (/IORQ) and memory map (/MREQ) ! ;)

oh wow i'm an idiot. so i just write to IO Port DF and can ignore whatever the lower byte is, also which way around is it, is DF in Register B or C? since i would assume B-C <-> DF-XX



ok this makes a bit more sense now http://www.cpcwiki.eu/index.php/Upper_ROM_Bank_Number (http://www.cpcwiki.eu/index.php/Upper_ROM_Bank_Number)


still don't fully understand it but i'm getting there.


for example what still confuses me is that there are already 2 banked 16k sections there, the RAM and the BASIC ROM. i assume those are enabled via the ROMEN/DIS and RAMEN/DIS on the Expansion port? (except there only is a RAMRD and not RAMEN like ROM has the ROMEN, i assume any writes to ROM automatically go to RAM and unless RAMRD is used it would autoamtically read from ROM?)

https://k1.spdns.de/Vintage/Schneider%20CPC/Das%20Schneider%20CPC%20Systembuch/z52.htm (https://k1.spdns.de/Vintage/Schneider%20CPC/Das%20Schneider%20CPC%20Systembuch/z52.htm)
und
https://k1.spdns.de/Vintage/Schneider%20CPC/Das%20Schneider%20CPC%20Systembuch/z63.htm

Quote from: TotO on 22:22, 04 March 19
I think, the more easy to start is to build your own ROM board using your 512KB flash chip (Winbond or SST ?) and some logic gates ...

- 512KB (4Mb) flash IC
- 74*374 or 74*574 to store the bank config and generate the extra address lines (RA14 to RA18)
- some other IC logic gates
- 1 diode (4148) + 1 resistor (1k) for ROMDIS
- some decoupling capacitors

A13, /WR, /IORQ are required to set the bank number
A14, A15, /MREQ are required to select the external ROM (and disable the internal ROM)

Have fun!

btw it's SST


i got a very, very, very crude and quick circuit done. though i don't really know how to do the decoding to disable the internal ROM so i just used D7 of the D-FF to dsiable it. i'm also just checking for A13 = 0 for the ROM Selection (aka DFXX) PIC (https://i.imgur.com/1YE2hCF.jpg)
i forgot to draw the /OE of the D-FF. but it should probably just be grounded

Quotei forgot to draw the /OE of the D-FF. but it should probably just be grounded

edit: oh, you mean the flip flop. just ignore  ;D
what is the dip switch for in your drawing? to select bank?

This might also be interesting, because it shows all the involved signals for RAM / ROM

http://www.cpcwiki.eu/imgs/d/da/Schneiderware_SRAM_and_EPROM_Schematic.png (http://www.cpcwiki.eu/imgs/d/da/Schneiderware_SRAM_and_EPROM_Schematic.png)
http://www.cpcwiki.eu/index.php/Schneiderware_Pseudo_ROM (http://www.cpcwiki.eu/index.php/Schneiderware_Pseudo_ROM)
PS A couple people here besides ToTO also designed ROM / RAM expansion here (I didn't), so I guess you should get good feedback and help with your project. Best of luck!

Sure, I will.

About /OC, yes you can ground it.

ok, sadly this project is gonna be on ice for a while. because the Edge adapter i made crashes the CPC whenever i insert it.


PICTURE (https://i.imgur.com/nRoWgyq.jpg)


i've checked all connections with my multimeter and there is nothing missing and no wrong/unwanted connections, so i have no idea why it's doing this to my poor CPC.


either way i think i'll just order some custom PCB instead of doing it myself with protype boards, though i have no idea how to design and order PCBs but i'll figure it out someday.


I'm still very thankful for all the help i've gotten on here. as soon as i can continue to work on this i will update the thread

Have you done a continuity check between all pins?

Bryce.

Think about cleaning the edge port too!

I think he's saying that it crashes without any expansion connected to it, so edge dirt shouldn't make a difference, only a short could cause it.

Bryce.

Here is a link:
https://oshpark.com/shared_projects/3yA33GYO (https://oshpark.com/shared_projects/3yA33GYO)
And another one if you want to connect the CPC to a breadboard via a ribbon cable(that's like a RPi breakout header for the breaboard if you know what I mean):
https://oshpark.com/shared_projects/tGXq3u2F (https://oshpark.com/shared_projects/tGXq3u2F)

PS If you sent me 30 $ (USD), I can send you a kit consisting of the expansion port connector, a 50 pin ribbon cable, and the CPC breadboard breakout header such that you can directly work on the breadboard for your experiments (fully assembeled) This includes 17 $ USPS postage to Germany  ;) (I am paying 5 USD $ myself for the SCSI ribbon cable... and then there are the PCBs and IDC headers and edge connector ...) 

Quote from: Bryce on 13:37, 08 March 19
Have you done a continuity check between all pins?

Bryce.

Yes i did. i thought i said that in the post too. there was no unwanted connection between 2 pins. and all connections were working correctly

Quote from: Bryce on 14:59, 08 March 19
I think he's saying that it crashes without any expansion connected to it, so edge dirt shouldn't make a difference, only a short could cause it.

Bryce.

no i didn't mean it like that. only when i insert the self made Edge connector i showed in the pic does it instantly crash, without it it runs perfectly fine (though the internal speaker does some strange humming sound which isn't present on the TV sound)

Quote from: LambdaMikel on 17:14, 08 March 19
PS If you sent me 30 $ (USD), I can send you a kit consisting of the expansion port connector, a 50 pin ribbon cable, and the CPC breadboard breakout header such that you can directly work on the breadboard for your experiments (fully assembeled) This includes 17 $ USPS postage to Germany  ;) (I am paying 5 USD $ myself for the SCSI ribbon cable... and then there are the PCBs and IDC headers and edge connector ...) 

you mean something like this: https://www.youtube.com/watch?v=iQ-iDxdE5d0 ?


that would be really amazing actually. thanks for the offer! how would i send it though, IBAN? PayPal?

Quote from: Prox on 18:39, 08 March 19
you mean something like this: https://www.youtube.com/watch?v=iQ-iDxdE5d0 (https://www.youtube.com/watch?v=iQ-iDxdE5d0) ?


that would be really amazing actually. thanks for the offer! how would i send it though, IBAN? PayPal?

Right, that was my first "project" when I started CPC tinkering 2 years ago  :) 
I'll send you paypal in a PM.... check your messages.

That remember me when I have worked on the CTC-AY! ;D

Quote from: LambdaMikel on 18:55, 08 March 19

Right, that was my first "project" when I started CPC tinkering 2 years ago  :) 
I'll send you paypal in a PM.... check your messages.

hmm i never received any PM. strange

Quote from: TotO on 19:50, 08 March 19
That remember me when I have worked on the CTC-AY! ;D

say how do you people insert images that don't take up the entire screen? i cannot seem to find any resize feature for inserted images like you would find on some other forums


(https://i.imgur.com/nRoWgyq.jpg)
do you see this. i wish i could resize images on here so i wouldn't have to use external Links.
Damn you Modern Phone Cameras and your's +12MP

My pictures are only attached files and not inserted into the post.

Quote from: TotO on 19:50, 08 March 19
That remember me when I have worked on the CTC-AY! ;D

Yes, breadboard prototyping is fun... and necessary. Maybe some people are good enough by now that they no longer need to prototype and can do the PCB directly...  :)
I still use the breadboard, and then the PCB.

Your kit is assembled. Shipping on Monday - I am including a free LambdaBoard such that you can get started with MX4-compatible boards as well. Enjoy and happy prototyping / breadboarding!

Nice, because I'm currently out of MotherX4 and ribbon cable/connectors to help him.

It's in the mail by now. I really dislike USPS postages... 24 $ unregistered to Germany...  :(

Quote from: LambdaMikel on 06:08, 10 March 19
Your kit is assembled. Shipping on Monday - I am including a free LambdaBoard such that you can get started with MX4-compatible boards as well. Enjoy and happy prototyping / breadboarding!

Quote from: LambdaMikel on 06:08, 10 March 19Your kit is assembled. Shipping on Monday - I am including a free LambdaBoard such that you can get started with MX4-compatible boards as well. Enjoy and happy prototyping / breadboarding!

Thank you kind sir!


though what is the LambdaBoard/MX4? i assume MX4 is some kind of Expansion Card standard, and the LambdaBoard looks like a few Expansion slots..


does this basically mean you can have IBM PC like Expansion cards?

Quote from: Prox on 03:19, 12 March 19
though what is the LambdaBoard/MX4? i assume MX4 is some kind of Expansion Card standard, and the LambdaBoard looks like a few Expansion slots..

does this basically mean you can have IBM PC like Expansion cards?

Yes, but much better than IBM PC because it is for a computer with character and personality of course  ;)

Check out some expansion cards for the CPC here on the board:

   
• XMem from @TotO (http://www.cpcwiki.eu/forum/index.php?action=profile;u=290)
• M4 from @Duke (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1624)
• PlayCity from @TotO (http://www.cpcwiki.eu/forum/index.php?action=profile;u=290)
• EPROM board from @The Equalizor (http://www.cpcwiki.eu/forum/index.php?action=profile;u=2279)
• RAM / ROM expansions and a "CPC to RPi tube" from @revaldinho (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1776)
• SymbiFace III from @TMTLOGIC (http://www.cpcwiki.eu/forum/index.php?action=profile;u=2639) 
• USIfAC from @ikonsgr (http://www.cpcwiki.eu/forum/index.php?action=profile;u=541)
• LambdaSpeak from @LambdaMikel (http://www.cpcwiki.eu/forum/index.php?action=profile;u=2172)
• and and and... (apologies for to any non-mentioned card - @GUNHED (http://www.cpcwiki.eu/forum/index.php?action=profile;u=2029) will know more!)

They all plug in the "Mother 4X" expansion board originally from @TotO (http://www.cpcwiki.eu/forum/index.php?action=profile;u=290) 
It became a de-facto standard.

I see


but one thing i noticed, the MX4 slots seem to be 50 pin like the Expansion slot itself


that would mean that all Decoding has to be done by the card. which can be good and bad in some cases.


but i'll see how it works.

Quote from: Prox on 06:00, 12 March 19
I see


but one thing i noticed, the MX4 slots seem to be 50 pin like the Expansion slot itself


that would mean that all Decoding has to be done by the card. which can be good and bad in some cases.


but i'll see how it works.

Right, it is just the CPC expansion bus on a wire  :)

The MotherX4 had been able to hanle a primary decoding stage to redure the I/O port to 8bit in example, but it is not realy possible on CPC, because unlike others Z80 computers, 16bit I/O are used for all kind of usages.

ok so now i got an actual functional adapter to connect something from my breadboards to the CPC (thanks again to LambdaMikel)


i've been using the wiki to build the ROM Board and got down to the very basics


to write to the D Flip-Flop which stores the ROM Number i just need to check for A13, RD, and IORQ to be 0.


to read from ROM once it's selected i just need to check for A15 and A14 to be 1, and check for RD, MREQ and ROMEN to be 0. (which should also set ROMDIS to 1 which means it can just be hooked up to the inverted CS of the external ROM)


now the thing i don't really get is that the wiki says this:


"A14 doesn't need to be decoded since there is no ROM at 8000h..BFFFh, only at C000h..FFFFh."

which makes little sense, if you only check A15 to be 1 to enable your ROM that would mean that it would take up the upper 32kB of Address space instead of the 16kB it's meant for. so you have to check for both A14 and A15 to be 1.
or do you?

You got the answer... Because the CPC require 16K banks, you have to decode A14 AND A15 (#C000).

Quote from: Prox on 12:56, 08 March 19
ok, sadly this project is gonna be on ice for a while. because the Edge adapter i made crashes the CPC whenever i insert it.


PICTURE (https://i.imgur.com/nRoWgyq.jpg)


i've checked all connections with my multimeter and there is nothing missing and no wrong/unwanted connections, so i have no idea why it's doing this to my poor CPC.


either way i think i'll just order some custom PCB instead of doing it myself with protype boards, though i have no idea how to design and order PCBs but i'll figure it out someday.


I'm still very thankful for all the help i've gotten on here. as soon as i can continue to work on this i will update the thread

Just wondering if you could post a picture of the underside of your adapter board.

I did a hand made one (before I had PCBs made up) and it was very messy (but worked).Interested to see how yours looks?


Cheers,
Shane

it looks like this: https://i.imgur.com/LyAMBbq.jpg


basically i cut up a ~10mm² flexiable wire and used the indivitual strands to connect the Edge connector pins to the pin headers. after i was done with half of them i put a strip of electrical tape over them and did the second half.


as said before my multimeter says all of them are working perfectly fine, but the CPC doesn't think so

Hi Prox,

Thanks for the photo.

Plugging this in with nothing attached should not lock up the computer (I honestly think you must have a short).
A short is unlikely to show up on a basic continuity test, if you are just testing between two pins (one at each end).

I understand you indicated you continuity tested each connection, but testing for a short requires a slightly different approach.
I'm not calling myself an expert, and others may have a different technique.
So what I do is to test the connections to either side of the path I require.

So for example, If I was testing for shorts, I would hold one of the meter probes on a Pin at one end of the cable.
And at the other end of the cable move the second probe between the expected pin on the other end, and then move to the pins directly next to it (on each side).  I hope that makes sense.  It can take a bit of time to test on a 50 pin connector.

There is also another issue, but only if you intended to plug an existing 'MX4 standard' board on you adapter, or make boards in the future.
For your testing it would be OK, but this would not work as desired for any existing boards.

If I refer to the expansion numbering here,

http://www.cpcwiki.eu/index.php/File:ExpansionPortEdge.gif

If for example you plugged a current ROM board onto that adapter, the pins would not align.

Pin 1 would either go to pin 2 if the board was top of the board was facing the CPC or
pin 1 to 50 if the solder side of the board was facing the CPC.

I hope I made sense, it's been a long day and I'm ready for bed (in Australia).

If anybody else can explain better please do (or shoot me down in flames if they disagree  :D ).


Cheers,

Shane


EDIT:

Maybe a quick and dirty diagram will make more sense than my writing  ???

The black lines on the left are how I would test for a short (with the continuity tester).
The green and blue lines on the right indicate a correct connection for a standard interface board (using the MX4 standard).
The red lines are how you have it wired.

[attach=1,msg172211]

Quote from: TotO on 21:28, 20 March 19
You got the answer... Because the CPC require 16K banks, you have to decode A14 AND A15 (#C000).

well so the wiki is wrong since it says you don't need to decode A14? that was really just the only part that confused me.


oh well guess i now have a better plan on how to build this. gonna write again when i got something finished

Quote from: 00WReX on 11:06, 21 March 19
Hi Prox,

Thanks for the photo.

Plugging this in with nothing attached should not lock up the computer (I honestly think you must have a short).
A short is unlikely to show up on a basic continuity test, if you are just testing between two pins (one at each end).

I understand you indicated you continuity tested each connection, but testing for a short requires a slightly different approach.
I'm not calling myself an expert, and others may have a different technique.
So what I do is to test the connections to either side of the path I require.

So for example, If I was testing for shorts, I would hold one of the meter probes on a Pin at one end of the cable.
And at the other end of the cable move the second probe between the expected pin on the other end, and then move to the pins directly next to it (on each side).  I hope that makes sense.  It can take a bit of time to test on a 50 pin connector.

There is also another issue, but only if you intended to plug an existing 'MX4 standard' board on you adapter, or make boards in the future.
For your testing it would be OK, but this would not work as desired for any existing boards.

If I refer to the expansion numbering here,

http://www.cpcwiki.eu/index.php/File:ExpansionPortEdge.gif (http://www.cpcwiki.eu/index.php/File:ExpansionPortEdge.gif)

If for example you plugged a current ROM board onto that adapter, the pins would not align.

Pin 1 would either go to pin 2 if the board was top of the board was facing the CPC or
pin 1 to 50 if the solder side of the board was facing the CPC.

I hope I made sense, it's been a long day and I'm ready for bed (in Australia).

If anybody else can explain better please do (or shoot me down in flames if they disagree  :D ).


Cheers,

Shane


EDIT:

Maybe a quick and dirty diagram will make more sense than my writing  ???

The black lines on the left are how I would test for a short (with the continuity tester).
The green and blue lines on the right indicate a correct connection for a standard interface board (using the MX4 standard).
The red lines are how you have it wired.

 

the ironic thing is i did test like that, i connected one of my multimeter's probes to one pin and then moved it across all other pins with the second probe, it only beeped where the corresponding pin was.


but maybe i missed one.


i also only plan on not pulling out the current lamba card, because of 2 reasons


1. it's a passthrough so i can just stick cartridges onto the Lamba board
2. one of the Edge contacts on the CPC is somewhat loose and constantly plugging stuff in and out is just gonna break it off one day.

The CPC uses 16 bit I/O, so please everybody always decode all 16 bits. If not, one expansion is not compatible to others, in the worst case the CPC could crash.


Sure sometimes it's hard to do a fully decoding (missing pins, whatever), but in this case be very careful what you do.  :)

Quote from: GUNHED on 17:58, 21 March 19
The CPC uses 16 bit I/O, so please everybody always decode all 16 bits. If not, one expansion is not compatible to others, in the worst case the CPC could crash.
Sure sometimes it's hard to do a fully decoding (missing pins, whatever), but in this case be very careful what you do.  :)

When peoples use a CPLD and lack of I/O for doing the full decoding, it is easy to add something like a N-inputs NAND gates IC or a 688 magnitude decoder to save them.

Quote from: GUNHED on 17:58, 21 March 19
The CPC uses 16 bit I/O, so please everybody always decode all 16 bits. If not, one expansion is not compatible to others, in the worst case the CPC could crash.


Sure sometimes it's hard to do a fully decoding (missing pins, whatever), but in this case be very careful what you do.  :)

I mean you could just predecode Expansion Slots, that would allow you to have cards work perfectly fine even if they use the same IO Ports.


something like using the upper 4 bits of the IO Address would allow for 16 Expansion slots and still leave 16384 Ports per Slot. downside is that the Card that splits the expansion port into multiple slots would require some logic on it and probably a ROM Chip that hosts some routines or commands to access the correct card. this would also allow you to use multiple of the same card without them interfering with eachother.

Will not work, because A15-A12 are used for the CPC hardware. At less, they must be set to 1, so you got #Fxxx to be safe.
Next, you have to deal with exiting expansions on this addresses range... (except for ROM/RAM standard expansions)

oh i see, right. some IO Addresses are also used by the CPC itself. also only A12-A15? so A0-A11 is free for external devices? so theoretically, you could use up one IO Address for an 8 bit D Flip-Flop that stores the Address of the Expansion Slot to be accessed. so each slot can still use the same IO Addresses and you just need to write to an external Register to specify what card you want to access... kinda like selecting expansion ROMs except with IO Ports.


even if only the lower 8 bit IO Addresses were free to use that would still be 256 Ports per card. which should be more than enough for basically anything you could connect up to the CPC.

Prox,

Not all lower 8 bits are available (for example bit 7 on the disc interface is for floppy motor control).

see http://www.cpcwiki.eu/index.php/I/O_Port_Summary (http://www.cpcwiki.eu/index.php/I/O_Port_Summary) for more information about the I/O ports available.

rpalmer

Quote from: Prox on 21:05, 21 March 19even if only the lower 8 bit IO Addresses were free to use that would still be 256 Ports per card. which should be more than enough for basically anything you could connect up to the CPC.

Sure. i.e. the MSX interface board for CPC decode #FFxx, where xx are the 256 I/O from this computer.
Just, you can't use other expansions on the #FFxx range, but it is not a real problem... Each users have to know what they can use together.

Quote from: GUNHED on 17:58, 21 March 19
The CPC uses 16 bit I/O, so please everybody always decode all 16 bits. If not, one expansion is not compatible to others, in the worst case the CPC could crash.


Sure sometimes it's hard to do a fully decoding (missing pins, whatever), but in this case be very careful what you do.  :)

Indeed, I second that! It is considered very rude and egoistic if a card does partial encoding only and grabs a whole block of IO addresses that could be used potentially by other cards, only in order to save a couple of (CPLD) logic gates or lines in the design. 

Quote from: TotO on 23:25, 21 March 19
Sure. i.e. the MSX interface board for CPC decode #FFxx, where xx are the 256 I/O from this computer.
Just, you can't use other expansions on the #FFxx range, but it is not a real problem... Each users have to know what they can use together.

but there are still a lot of Io Ports free to use right? aren't all of those enough for a single expansion card/device?

Quote from: TotO on 23:25, 21 March 19
Sure. i.e. the MSX interface board for CPC decode #FFxx, where xx are the 256 I/O from this computer.
Just, you can't use other expansions on the #FFxx range, but it is not a real problem... Each users have to know what they can use together.

yes but that could "easily" be solved.


basically something like this:



I hope this gets the idea across better, you just write to a specific Port to select the Card you want to enabled, all the other ones will be blocked off. this allows you to connect multiple of the same card or cards that use the same IO Ports to your CPC without them interfering with eachother. I don't understand why this wouldn't be useful. only downside Cards cannot directly "talk" to eachother.
Data and Address are obvious, Misc is just the rest of the Lines from the Expansion port.

here are the Colors:

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.

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!  ;D
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!!!  ;)

Quote from: Bryce on 14:05, 22 March 19
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 (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.

Quote from: TotO on 14:57, 22 March 19
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!  ;D
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)

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?  ;D

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

Quote from: TotO on 21:41, 22 March 19
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?  ;D

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)

Quote from: Prox on 20:42, 22 March 19

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.

Quote from: Bryce on 16:18, 23 March 19
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.




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:


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.

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.

Quote from: Bryce on 17:16, 23 March 19
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.

Quote from: TotO on 17:27, 23 March 19
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)

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.

Quote from: Bryce on 18:12, 23 March 19
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

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)

Quote from: TotO on 18:37, 23 March 19
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.

Quote from: Prox on 19:17, 23 March 19
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.

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

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

Quote from: rpalmer on 21:23, 27 March 19
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.

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 (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 (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.

Quote from: LambdaMikel on 05:25, 28 March 19
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 (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 (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!

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.

Quote from: Prox on 07:25, 28 March 19

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  :P No kidding. I keep a virtual machine of Win XP just for that reason

Quote from: LambdaMikel on 09:08, 28 March 19
There is a legacy program called "WinCUPL"... that does only run on Windows XP  :P 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.

Quote from: Bryce on 09:18, 28 March 19
https://www.microchip.com/design-centers/programmable-logic/spld-cpld/tools/software/wincupl (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.

Quote from: LambdaMikel on 09:08, 28 March 19
There is a legacy program called "WinCUPL"... that does only run on Windows XP  :P 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.

Quote from: rpalmer on 11:55, 28 March 19
I run WinCUPL on my windows 7 machine with no problems.

Good to know. Curious to learn if anybody got it to run on Win 10. I contacted Microchip for that, and they said it's not supported on Win 10.

Not supported means they didn't try, it may work anyway.

Bryce.

Quote from: Bryce on 08:24, 29 March 19
Not supported means they didn't try, it may work anyway.

Bryce.

Well, I tried, and for me it didn't  ;)

Even in compatible mode?

Bryce.

Quote from: Bryce on 09:53, 29 March 19
Even in compatible mode?

Bryce.

Right, even then. It has something to do with how the access the file system - haven't tried in a while, but if I remember correctly, then the problem is that the "compiler" can't find the chip definition files / libraries on  disk. I mean, it starts up correctly and you can use the IDE, but the compiler fails. And I haven't tried burning / flashing directly from it ever. I just grab the BIN or JED file when it's done.

Quote from: LambdaMikel on 09:09, 29 March 19
Well, I tried, and for me it didn't  ;)

it works perfectly fine on my Win10 machine


i just have to run it as Admin.


also now i need to watch some Tutorials on this.


or you know, there is a way to convert a logic circuit to a GAL compatable .BIN file, that would also work.

Quote from: Prox on 17:50, 29 March 19

it works perfectly fine on my Win10 machine

Did you try to compile something yet? This is when the error shows up. Maybe they fixed it since then.
As I wrote, the IDE / UI and editor and all that shows up correctly, but the compiler fails. Let us know specifically if that works for you...

MIght be time to try again for me.


Here is a useful tutorial:


https://optics.csufresno.edu/~kriehn/teaching/ece85l/labs/WINCUPL_Tutorial.docx (https://optics.csufresno.edu/~kriehn/teaching/ece85l/labs/WINCUPL_Tutorial.docx)

PS Correct, Win 7 works... don't have Win 10 at hand currently.
It's easy to find out - you Open a file under "Atmel / Examples", and then hit the compile button.

Next to the clipboard - "Device Dependent Compile". That should give no warning and no errors for the examples.

Curious to try Windows 10 at home tonight... attached is a Win 7 screenshot, and that indeed worked well.
(I have Win 7 @ work and Win 10 @ home...)

Quote from: LambdaMikel on 19:42, 29 March 19
PS Correct, Win 7 works... don't have Win 10 at hand currently.
It's easy to find out - you Open a file under "Atmel / Examples", and then hit the compile button.

Next to the clipboard - "Device Dependent Compile". That should give no warning and no errors for the examples.

Curious to try Windows 10 at home tonight... attached is a Win 7 screenshot, and that indeed worked well.
(I have Win 7 @ work and Win 10 @ home...)

i already wrote some code(?) for a Z80 Computer. so i can replace all the Logic gate chips i use for it.
and it compiled perfectly fine (after serveral errors about missing semicolons)


also now that i was able to compile it... what now? can i somehow convert it into a format that the TL866 II Plus can use to program the chip?
nvm the Programer wants the .JED file which was compiled... problem solved

Good to know you got it working on Win 10!
Seems something has changed... or maybe the installation directory makes a difference.


Will try tonight on my Win 10.

Thanks for the hint to run it as admin on Win 10... indeed that makes a weird difference.
If I run it as normal user, I am getting an error message that it cannot find a file whereas that indeed goes away if admin runs it! Thanks @Prox (http://www.cpcwiki.eu/forum/index.php?action=profile;u=3031)

That has to do with the stupid permissions (or lack of) that Win10 assigns. Install it on a different drive (outside of C:\Program Files) and it should work as a normal user too.

Bryce.

Yes, but good to know that is work on Win 10 with some tweaks.
Given how inexpensive GALs are, they are a very good alternative to the more expensive CPLD for simpler projects. 

Quote from: LambdaMikel on 15:24, 30 March 19
Yes, but good to know that is work on Win 10 with some tweaks.
Given how inexpensive GALs are, they are a very good alternative to the more expensive CPLD for simpler projects.

yep i also had that error when it was in the program files, i moved it to my portable SSD and everything worked perfectly


well almost, it's quite obvious the program is really old. writing/editing text is kinda strange and glitchly but functional enough to write something.


i was able to test it by replacing th 3 Logic ICs on my Z80 test Computer with a single GAL. it still works perfectly well (after some problems with my 20 MHz Z80 which aparently has a minimum clock rate that if not met just locks up the CPU until reset)

alright i finished the actual ROM Board, now i just need something on the ROM to test it






the wiring is horrible but everything that needs to be connected is.

the way it should work is that if the Upper ROM Number is >0 it will disable the Internal ROM (aka BASIC) and enable the external ROM.

the upper 4 bits of the ROM Number also have a special use as they select what ROM Bank to use. so with values from $0x to $Fx it will select ROM Bank 0 to 15.

Quote from: Prox on 17:37, 02 April 19
the wiring is horrible but everything that needs to be connected is.

Looks neat enough to me from the wiring point of view!


Good progress.

hmm, bit confused but i almost expected this to happen


the ROM board itself either doesn't work or i overlooked something


i checked for shorts or anything, wrong wires, or similiar. but i found nothing


both the data and address bus show activity when i turn the CPC on. but i get no picture on the TV. and if i let it on long enough it changes the values of the external D-FF and then seems to freeze. not entire sure i don't want to damage anything so i quickly turn it off again each time i checked.


this would be a hell of a lot easier if i could use kicad correctly, i really need to watch some tutorials so i can just make a PCB design and let people who know what they're doing look over the circuit to confirm that it will work.

Make sure you are tri-stating the databus etc. correctly...


KiCAD is great, and a PCB is always a good idea. But, you could also just draw the schematics with KiCAD and share it here for "review" / discussion. Until you figured out how to make a PCB. I was in the same situation 2 years ago and was able to learn it from tutorials etc.


Wrt. PCB-advice, I would suggest to also consult the board Mikrocontroller.net. Especially since you are German-speaking - there is no better board / advice in all things electronics. The help you are getting on this board can also be useful, but one also needs to filter a bit... some advice (from people who are hobbyists themselves...) can also safely be ignored   ;)

Maybe start with something simpler... a first good test would be to figure out if you can "latch" a byte into the flip flop from the databus, at a specific address. You can verify with the LED segment bars.


I.e., program your decoder to decode &FFxx and then check if from BASIC out &FFxx,<byte> gives you byte in the flip flop reliably. 


Also, your LED segment bars have no resistors??
(And I hope you didn't connect the databus to the LEDs directly??)

Quote from: LambdaMikel on 21:21, 03 April 19
Maybe start with something simpler... a first good test would be to figure out if you can "latch" a byte into the flip flop from the databus, at a specific address. You can verify with the LED segment bars.


I.e., program your decoder to decode &FFxx and then check if from BASIC out &FFxx,<byte> gives you byte in the flip flop reliably. 


Also, your LED segment bars have no resistors??
(And I hope you didn't connect the databus to the LEDs directly??)

I always connect LED Bar graphs like this:


(https://i.imgur.com/uewtJ2k.png)
I know it's just 4 LEDs but imagine the same concept for the data and address bus. so before they connect to the LEDs they got some pull down resistor array (47k Ohm) and after the LEDs they also got a few of them (470 Ohm)
(http://robojax.com/products/images/ELE__518.jpg)
these things. so damn useful and more compact than single resistors.


also you could take a look at my Logic Circuit i wrote for the GAL i used, if that helps. https://pastebin.com/sCQan2fV (https://pastebin.com/sCQan2fV)

Quote from: Prox on 04:29, 04 April 19
I know it's just 4 LEDs but imagine the same concept for the data and address bus. so before they connect to the LEDs they got some pull down resistor array (47k Ohm) and after the LEDs they also got a few of them (470 Ohm)

Hang on - that means you have a 8 pull down resistors constantly connected to the databus?? Did you try running your circuit without pulldown resistors?

Yes, resistor arrays (especially with LED segment bars) are neat.

I would probably also try to remove the flip flop from the circuit altogether, and put that logic also into the GAL...

is there a problem with pull down reistors? i used the same design for my own Z80 Computer, and i also used it to test the connector. where i basically only had the LED Bars hook up without the Rest of the ROM Board. and that ran perfectly fine


i can try without though


EDIT: that didn't work but i removed everything and now the CPC works perfectly again and i'm back at square one.


also i didn't knew you could program D-FF into the GAL.... how?

Quote from: Prox on 05:41, 04 April 19
is there a problem with pull down reistors? i used the same design for my own Z80 Computer, and i also used it to test the connector. where i basically only had the LED Bars hook up without the Rest of the ROM Board. and that ran perfectly fine

I am not an expert - so don't take me too serious here...

I mean, the devices connected to the bus should be tri-state, right? It depends on the value of the resistor. Certainly, if the resistor value is too low, you always put 0 on the bus and it jams the bus. Just not sure why you want pull down resistors here.

There are flip flops modeled in the GAL / Atmel examples directory, you can use these. And, it is possible to make GAL outputs tristate as well! 

... the key towards tri-state with GAL is the ".oe" flag.

Check out this example and the last line:

https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/ls199/gal22v10/ls199-databus-multiplexer-U3.PLD (https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/ls199/gal22v10/ls199-databus-multiplexer-U3.PLD)
So, I would start simple... step by step. And only go to the next level of the circuit if the previous one did work, add functionality bit by bit, otherwise you have a hard time debugging.

For the LEDs, I would probably always try to use some line driver rather than connecting them directly to the buses.

Those pull down resistors are definitely messing things up. It's forcing 0's on the bus lines when they should be High-Z. This will work on dedicated buses, but not shared ones.


Bryce.

Am i too stupid for this?


I cannot even get a simple D-FF with the GAL....


here is the code: https://pastebin.com/tkQ0Nw7y


I don't understand. the circuit is connected as the inputs show. and the output is connected to an LED Bar Graph.


also yes i did remove the pull downs from the address and data bus.


the CPC itself starts up but trying to do "OUT (&FFFF), &0F" or any value results in nothing changing on the output.


for some reason the output LEDs are constantly on, like there is constantly some value being written to it. but the CPC itself never does writes to &FFFF, right? and if there is, what should i decode to isolate that one port, so nothing from the CPC itself ever writes to it?


also as might be seen on the pastebin i use .SP to store the data, and the CLK input is the WR signal. i checked the timing of the GAL and the Z80 and the GAL should be fast enough to grab the data from the bus when the WR goes high.


i might try to seperate that signal from WR and use the system clock for that or something.

... one thing I might add is - if you relied on the pin numbering on the breakout header PCB, then this might be wrong... please make sure you really have the right pins. The pin marked "1" on the breakout header might not be the "real CPC expansion port 1"... it might be anything from from { 1, 2, 49, 50 }.
I guess I should have said that earlier, I am just not sure if 1 is really 1. Please check.


Well, I would probably start by identifying  VCC and GND and put an LED (with resistor) to make sure we have the right pins...

Do you have a logic probe?? This is incredibly useful and inexpensive for debugging these kinds of situations.


https://www.amazon.de/Laser-5263-Logiktester-DC/dp/B006IRIP8I/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=logic+probe&qid=1554399584&s=gateway&sr=8-1 (https://www.amazon.de/Laser-5263-Logiktester-DC/dp/B006IRIP8I/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=logic+probe&qid=1554399584&s=gateway&sr=8-1)


Put it in pulse mode and check if you are correctly detecting the _IORQ & _WR (or _IORQ & _RD)

So, my suggestion is - buy that logic probe, define a WRITE and READ signal output in the GAL, that triggers when &FFxx is written or read, respectively, and then put the logic probe in PULSE mode and monitor your READ and WRITE GAL outputs.

Then write a BASIC program:

10 out &ffff,10
20 goto 10

10 a=inp(&ffff)
20 goto 10

and monitor READ and WRITE accordingly.

Quote from: LambdaMikel on 18:25, 04 April 19... one thing I might add is - if you relied on the pin numbering on the breakout header PCB, then this might be wrong... please make sure you really have the right pins. The pin marked "1" on the breakout header might not be the "real CPC expansion port 1"... it might be anything from from { 1, 2, 49, 50 }. I guess I should have said that earlier, I am just not sure if 1 is really 1. Please check. Well, I would probably start by identifying  VCC and GND and put an LED (with resistor) to make sure we have the right pins...

I used my Multimeter in continuity mode and put one probe on the +5V pin of the Power connector and went through each pin of the breakout board until i had it, from there it was obvious how the rest of the pins are layed out. and yes i got them all correct.

Quote from: LambdaMikel on 18:38, 04 April 19Do you have a logic probe?? This is incredibly useful and inexpensive for debugging these kinds of situations.


https://www.amazon.de/Laser-5263-Logiktester-DC/dp/B006IRIP8I/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=logic+probe&qid=1554399584&s=gateway&sr=8-1 (https://www.amazon.de/Laser-5263-Logiktester-DC/dp/B006IRIP8I/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=logic+probe&qid=1554399584&s=gateway&sr=8-1)


Put it in pulse mode and check if you are correctly detecting the _IORQ & _WR (or _IORQ & _RD) So, my suggestion is - buy that logic probe, define a WRITE and READ signal output in the GAL, that triggers when &FFxx is written or read, respectively, and then put the logic probe in PULSE mode and monitor your READ and WRITE GAL outputs. Then write a BASIC program:10 out &ffff,1020 goto 10 10 a=inp(&ffff)20 goto 10 and monitor READ and WRITE accordingly.

well i cannot really do reads from the flip flop. that is why that part of the code is commented out. i tried to do that and it only resulted in the CPC acting strange, i was unable to use the majority of the keys on the keyboard so i changed the code up to always output the data and just hooked it up to some LEDs


also this would be a lot easier if the simulation function of WinCUPL would actually work and not just give a "Simulation Errors encounter" with nothing else to go by. no error code or anything.


i will still get myself a probe, it overall seems like a good idea

EDIT: ok for some reason the text was tiny, whoever programmed the formating on this site should really reconsider all of their life choices

Quote from: Prox on 18:54, 04 April 19

well i cannot really do reads from the flip flop. that is why that part of the code is commented out. i tried to do that and it only resulted in the CPC acting strange, i was unable to use the majority of the keys on the keyboard so i changed the code up to always output the data and just hooked it up to some LEDs


i will still get myself a probe, it overall seems like a good idea

EDIT: ok for some reason the text was tiny, whoever programmed the formating on this site should really reconsider all of their life choices

yes i would get the combinational logic working first, and then work on doing the flip flop in the gal.
the latter is more difficult.


when you have READ and WRITE pulsing correclty, you can combine ADR & WRITE to trigger / load the external d flipflop you were using before. that is easier to debug.


when that is working, you can move the flipflop into the gal.

Quote from: Prox on 18:20, 04 April 19
for some reason the output LEDs are constantly on, like there is constantly some value being written to it. but the CPC itself never does writes to &FFFF, right? and if there is, what should i decode to isolate that one port, so nothing from the CPC itself ever writes to it?

But you aren't checking for &ffff, you are only checking for A15 & A14 being high, so basically anything on this page http://www.cpcwiki.eu/index.php/I/O_Port_Summary that start with %xx will be matched by your device. (The CPC generally has a simplified addressing scheme, the on-board devices only check for a single bit being low). So even the ROM page address &df00 (%xx0xxxxx) will match along with the writes to the 8255 for reading the keyboard.

Quote from: IanS on 23:53, 04 April 19
But you aren't checking for &ffff, you are only checking for A15 & A14 being high, so basically anything on this page http://www.cpcwiki.eu/index.php/I/O_Port_Summary (http://www.cpcwiki.eu/index.php/I/O_Port_Summary) that start with %xx will be matched by your device. (The CPC generally has a simplified addressing scheme, the on-board devices only check for a single bit being low). So even the ROM page address &df00 (%xx0xxxxx) will match along with the writes to the 8255 for reading the keyboard.

Right, partial decoding is dangerous...

Quote from: IanS on 23:53, 04 April 19
But you aren't checking for &ffff, you are only checking for A15 & A14 being high, so basically anything on this page http://www.cpcwiki.eu/index.php/I/O_Port_Summary (http://www.cpcwiki.eu/index.php/I/O_Port_Summary) that start with %xx will be matched by your device. (The CPC generally has a simplified addressing scheme, the on-board devices only check for a single bit being low). So even the ROM page address &df00 (%xx0xxxxx) will match along with the writes to the 8255 for reading the keyboard.

I don't really have a lot of pins free on the GAL so i would need 2 to to properly decode everything.


might do that though and just literally check everry single bit to be 0xFFFF


actually when i do the math the 24 pin GAL i use have a total of 22 usable pins. so when i got the entire address bus on that i still would have 6 pins left over, either i can then hook up 6 individual IO Devices, or i can also encode those 6 bits and hook up to 64 different IO Devices (though i would need more GALs to decode those 64 output lines into something usable).


obviously not gonna do all that right away, i will just hook up a single IO Device and just use a single output from the GAL. but the idea is still good for larger things.


i really wish i could use these ATF2500C's i got lying around, so many IO Pins... but my programmer doesn't support them.

... this is also where the logic probe would have already helped you... you would have seen that the "on" LEDs have a pulse, rather than a steady "1", due to picking up different addresses and IO activity.

alright probe arrives tomorrow.


doesn't mean i just have to sit around.


so i tried to compile this code for the GAL. i didn't use fields or anything just to make it simplier on the chip...


https://pastebin.com/zKqrzqVq (https://pastebin.com/zKqrzqVq)

and this doesn't compile... only error code i get is "CSIM Erros encountered", nothing more

and can i just say how i hate this program at times, it's quite clear this hasn't been updated since around Win 3.11.

it's functional, somewhat... but not comfortable. writing is strange and buggy, text colors only sometimes update, and the error codes are useless.

Can you try moving the negations (!'s) to the right sides of the equations?

Quote from: LambdaMikel on 15:14, 05 April 19
Can you try moving the negations (!'s) to the right sides of the equations?

i can, but would that change anything? i used the same way of doing logic with another program that is used in my stand-alone Z80 Computer and it works fine.


oh well, better to try everything, right?


ok so after doing that i got the "Excessive number of Product terms" erro for both outputs


because doing it like this:

IORD = RD # IORQ # !A0 # !A1 # !A2 # !A3 # !A4 # !A5 # !A6 # !A7 # !A8 # !A9 # !A10 # !A11 # !A12 # !A13 # !A14 # !A15;
IOWR = WR # IORQ # !A0 # !A1 # !A2 # !A3 # !A4 # !A5 # !A6 # !A7 # !A8 # !A9 # !A10 # !A11 # !A12 # !A13 # !A14 # !A15;

aparently takes up more logic/cells on the chip than doing this:

!IORD = !RD & !IORQ & (A0 & A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 & A10 & A11 & A12 & A13 & A14 & A15);
!IOWR = !WR & !IORQ & (A0 & A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 & A10 & A11 & A12 & A13 & A14 & A15);

which is strange.



can't i just use less inputs and only decode the upper 8 bits of the Address bus?

You could try an auxiliary variable:

Y = ....
X = ! Y

Internally, that should not make any difference anyhow, because of the minimization / optimization performed by the program.

For readability, I would always write it as a conjunction and use parantheses:

X = ! ( A & B & ... )

Did you look at this?

https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/ls195/gal22v10/ls195-address-decoder-U1.PLD
That does very similar things and fits and compiles...

Quote from: LambdaMikel on 15:50, 05 April 19
Did you look at this?

https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/ls195/gal22v10/ls195-address-decoder-U1.PLD (https://github.com/lambdamikel/LambdaSpeak/blob/master/firmware/ls195/gal22v10/ls195-address-decoder-U1.PLD)
That does very similar things and fits and compiles...

well if i rewrite it to something similar i still get the CSIM Error.



Name     CPC464 ;
PartNo   00 ;
Date     01.04.2019 ;
Revision 01 ;
Designer Engineer ;
Company  Team Rocket ;
Assembly None ;
Location None ;
Device   G22V10 ;

/**************** INPUT PINS *********************/
PIN 1  = A0;
PIN 2  = A1;
PIN 3  = A2;
PIN 4  = A3;
PIN 5  = A4;
PIN 6  = A5;
PIN 7  = A6;
PIN 8  = A7;
PIN 9  = A8;
PIN 10 = A9;
PIN 11 = A10;
PIN 13 = A11;
PIN 14 = A12;
PIN 15 = A13;
PIN 16 = A14;
PIN 17 = A15;

PIN 18 = WR;
PIN 19 = RD;
PIN 20 = IORQ;


/**************** OUTPUT PINS *********************/
PIN 22 = IORD;
PIN 23 = IOWR;


/**************** DECLARATIONS *********************/

ADDR = A0 & A1 & A2 & A3 & A4 & A5 & A6 & A7 & A8 & A9 & A10 & A11 & A12 & A13 & A14 & A15;

/**************** EQUATIONS *********************/

!IORD = !RD & !IORQ & ADDR;
!IOWR = !WR & !IORQ & ADDR;


and if i try to do the decoding like you did (without the ! infront of the output) i just get the same "Excessive number of Product terms" error.

otherwise that is basically identical as far as i can see.

even trying this doesn't work and gives a CSIM error


FIELD ADDR = [A0..15];
ACTIVE = ADDR:'h'FFFF;


/**************** EQUATIONS *********************/

!IORD = !RD & !IORQ & ACTIVE;
!IOWR = !WR & !IORQ & ACTIVE;





I must be missing something massive because the error message itself says "warnings: 0, errors: 0"
yet still it doesn't compile.


my other code compiles without issue

Maybe you have configured the project not for the GAL22V10, but for some smaller device?
Are you sure the project device settings are correct?

If my code doesn't compile in your setup, then there is something wrong with project setup or program installation.

Quote from: LambdaMikel on 16:46, 05 April 19
Maybe you have configured the project not for the GAL22V10, but for some smaller device?
Are you sure the project device settings are correct?

If my code doesn't compile in your setup, then there is something wrong with project setup or program installation.

wel i can close the project and reopen it. and the header is correct and works for the G22V10. (good way to test that was by setting one pin to be higher than 23, which causes an error)


and just using your code straight also gives the CSIM error.


it makes no sense since i can compile other programs.


and i just tried to copy the main part of the code into another project and it compiles perfectly fine


what the fuck is this, who wrote this program.

CSIM error makes no sense unless you are actually using the simulator?


Q. When I am compiling, I get CSIM errors, but I'm not trying to simulate it yet. [/size]A. Turn off simulation in the Compiler Options (https://class.ece.uw.edu/475/peckol/doc/cupl.html#compileoption) menu.


Well, there are alternatives to WinCUPL, but I never tried any of these.
Maybe somebody else can suggest an alternative for GALs.

Quote from: Prox on 15:21, 05 April 19

i can, but would that change anything?

Well, at least in a classical programming language, the left sides of an assignment are not expressions, but "lvalues", and I am surprised that you are saying it works I must say. I did not see any CUPL example that ever used negation on the left side... IMHO that should just be a single variable. But my knowledge of this stuff is limited as well.

This one you already read, right?
http://ee-classes.usc.edu/ee459/library/documents/CUPL_Reference.pdf (http://ee-classes.usc.edu/ee459/library/documents/CUPL_Reference.pdf)


https://class.ece.uw.edu/475/peckol/doc/cupl.html#programming (https://class.ece.uw.edu/475/peckol/doc/cupl.html#programming)



So, with all these references, a logic probe, trial and error and maintaining a calm attitude, I am sure you will figure it out!! Best of luck and keep us updated.  :)

Quote from: LambdaMikel on 17:39, 05 April 19
CSIM error makes no sense unless you are actually using the simulator?


Q. When I am compiling, I get CSIM errors, but I'm not trying to simulate it yet. A. Turn off simulation in the Compiler Options (https://class.ece.uw.edu/475/peckol/doc/cupl.html#compileoption) menu.


Well, there are alternatives to WinCUPL, but I never tried any of these.
Maybe somebody else can suggest an alternative for GALs.

ok i turned "simulate" off and it worked too!


amazing, also the circuit itself is working.








i forgot to cut out the audio of the video. so ignore the crackling.

Quote from: LambdaMikel on 18:13, 05 April 19

Well, at least in a classical programming language, the left sides of an assignment are not expressions, but "lvalues", and I am surprised that you are saying it works I must say. I did not see any CUPL example that ever used negation on the left side... IMHO that should just be a single variable. But my knowledge of this stuff is limited as well.

well the youtube tutorial i watched also did the negations on the left side as well.

you can also asign negative pins

something like:

PIN 1 = !IN
PIN 20 = !OUT

it should function in the same way.

and as said before, not doing the negation actually uses up more logical space on the chip and is therefore a lot more limiting

Quote from: Prox on 18:57, 05 April 19
you can also asign negative pins

something like:

PIN 1 = !IN
PIN 20 = !OUT

it should function in the same way.

Of course... but you were saying you used


!PIN 1 = IN


and that I never saw before. But anyhow  :D


Congrats to making it work!


Yes this program is a pain in the ****.