lgb, I think of the pic controlling the SD card just as the wd1772 controlling the disk access. There's no need to burden the CPU with the details, just get the data to where it needs to be!

Well, yes, but your example is not the very same as with disk access. WD1772 does know nothing about the file system itself of course, it only reads/writes blocks from/to the disk, the "higher level" operation (ie: file system, FAT12 in our case) is done by software (EXDOS) by the EP itself. I wanted to same with the ENC: it's capable of sending/receiving ethernet frames (well, even more, as far as I can remember, there are MAC filters, etc, maybe auto-ARP-request-reply as well, but I am not sure on the last one), so here the TCP/IP itself can be thought as the filesystem in case of EXDOS, that it's must be done by the EP (Z80). Well "must be" in the sense of "my feelings" of course it's not compulsory And it requires CPU power, memory etc, maybe even more than FAT handling for EXDOS As I've written: it's only a "bad" feeling inside me, nothing more.

I'll need to check the api for the tcp/ip stack and see how it all works, but in general I'm not a fan of polled access. But equally I know little of how the z80 handles interrupts, as I'm a 68000 guy, so if it's going to be a pain in the ass, we can stick with polled.

I am not sure, interrupts are useful (or can be), but if you can route your interrupt request via Dave, it's easy to enable/disable, like disable in case of polling only mode, but you still give the chance to be interrupt driven if somebody wanna use it later.

But anyway, if you want to use a more complex MCU for EP, there are some having Ethernet controller integrated as well, even without the ENC But I am not sure (never tried) if it still requires more external components than with the ENC solution.

0I think I'll look at using a flash EEPROM as well on this, so it can be reprogrammed in software from the Enterprise. Much nicer to have software upgrades.

I using Flash ROM. The best type which use 12 bit address for programing function for example x555h and x2AAh. MX or AMD 29F040 (or compatible) are right choice.
With this type you can program it when only one segment paged in.

I'm coming around to the idea of a hardware SPI interface as a solution to this problem after all! Mostly down to cost and complexity. There will be less components required for an SPI interface (and hence cheaper), all code will be running on the Z80, and it will be expandable.

Well, SD-card, the ENC28J60, but even there are SPI clock chips (yes, master Zozo has clock chip card or so, but maybe not too popular that everyone has it) besides I2C too, and many other even more "odd" devices (DAC and ADC chips, even mp3 playback capable chips!!!!!! - so in theory someone can digitalize audio with EP or playback, even mp3 playback ...) so quite unique features can be done only using SPI. That's why I always wrote too much about this topic, hopefully my writings are more or less survivable

For this purpose, for 65xx CPUs there is already a CPLD based solution (well, two versions):

The original version: http://sbc.rictor.org/io/65spi.html

The "B" version: http://www.6502.org/users/andre/spi65b/65SPI-B%20Datasheet.pdf

I've just inculded them here (and maybe I've already posted it) because there are somewhat detailed description which can be useful to create something similar for other CPU as well (I am not sure but I guess directly this 65SPI cannot be used because of the symmetric nature of a 65xx - also called motorola - bus that clock signal itself is symmetric and continuous but still controls the memory access as well, on Z80 they are different things), also it seems there are some things offered to be downloaded which can be useful (sorry I have no idea, I don't know anything on CPLD programming ...).

I should be able to offer several slave devices (4-8?), with the unused slave chip selects and SPI bus brought out to some headers for further user expansion.

Interesting, one of the 6502 forums topics exactly about this, and also the reason that the mentioned 65SPI CPLD solution has two variants ... Also do not forget that some devices are a bit odd (as far as I know!) for example SD card requires to go into SPI mode to pulse CLK about 74 times with select signal UNasserted. That sounds odd for me, as SPI defines that not selected devices shoudl not bother the MISO/MOSI/CLK at all! Also it seems some devices won't release (to high-Z) pins even when unasserted or need more time that you except ... One of the difficulties about SPI that it sounds great and logical but always there are devices which interprets the standard a bit more relaxed. That's OK if you interface only with one device. But if you want to do "shard SPI signals" (for MISO/MOSI/CLK at least, of course different select signals for devices!) you can meet quite "interesting" problems sometimes. But all I know about these are mainly from others' writing (as I was still lazy/etc to start my own project for real!) so please do not treat my words as-is, I can be wrong.

It's also interesting to think abotu SPI modes, I guess mode 0 is enough for most devices, implementing every SPI modes would attract some extra complexity into the design ...

Lots of potential...

Indeed!

I think I'll look at using a flash EEPROM as well on this, so it can be reprogrammed in software from the Enterprise. Much nicer to have software upgrades.

Yes, there are SPI and I2C based FLASH chips as well with quite great capacity and low price! A parallel bus version of the same are always more expensive ... And while some people blame SPI that it will be slow (because of the serial nature) at the other hand, think again: only 10MHz of SPI clock (which is supported by ENC28J60 as far as I can remember, or hmm even more?) allows 1.25 mbyte/sec. And I guess even a 4MHz Z80 can't even handle that transfer rate, so SPI is totally OK Modern SPI cards can even provide higher SPI clocks, etc etc.

But how can you use serial Flash as Z80 memory?

Not directly of course. But anyway, if you have SD card interface (or any other somewhat modern storage to be fast and always accessable), not so much difference, just mentioned.

I've done the SPI master interface Verilog code now. I had looked at the 65SPI stuff before, but I seem to remember it was a bit hard to understand the code (I think VHDL, which I'm not a fan of). Luckily Altera had some sample code which is an SPI master controller which interfaces to a standard bus with RD/WR/CE type interface and a bi-directional 8 bit data bus.

Ahaa, I see. The only problem I've heard is about the not-so standard SPI bus handling by some devices I've written in one of my previous messages (like SD card etc). So similar devices (maybe even 65SPI "B" version) has not only a separated select signal, but also MISO.

Unfortunately though, I don't have that many pins spare on the EPM3064, as I'm looking at the 44 pin version at the moment. So I can only manage 2 SPI slave devices and a 4 page ROM area with one page split into 8KB code and 8KB SPI interface. Is 8KB enough for the SD card driver do you think, Zozo? It may be a bit tight as it will need to be all Z80 code to control the SD card.

I don't think you need lots of code to handle an SD card. EXDOS will do all of higher level stuff (like FAT filesystem) you only need to supply SD card detect/initialization, block read/write, and such short piece of codes. I can tell after inspecting some AVR code, that even a little AVR MCU with as little as 4K (or 8?) flash can easily do it, and it also includes some FAT driver (which you don't need at all for EP, because it's task of EXDOS)!  As far as I can do a wild a guess, even about 2K Z80 code is enough in case of the Enterprise! Zozo is much more suitable person to answer this though Maybe his IDE card and its ROM can be checked out as a rough guess about needed amount of extra code. It's another question that people not having an EXDOS card itself (like me) would need the EXDOS too (maybe a bit modified version, Zozo told something about the need to remove some WD initialization code which can lead to long delays because of lack of a real WD in the system EXDOS was created originally for - fortunately EXDOS is also a great work having good "layered" design to easily adopt totally different storage hardware if it can support some basic functions like block read/write).

But for Ethernet, the situation is quite different especially if Z80 based TCP/IP stack must be created, but still I would not expect to have much more code than - let's say - some Kbytes (for the protocol itself, but there can be other parts unlike the more generic block level SD card interface for EXDOS ...).

It does mean there is a spare line for an ethernet controller, though.

Btw, what do you mean about "8K SPI interface"? Is it some kind of memory mapped stuff? At least my ideas was using simple some I/O ports, I am not really sure what you mean about 8K here. Or is it something I've also written about that some kind of DMA is done to a dedicated RAM (or RAM-like, from the point of view of the Z80 at least) area which can be accessed by the CPU as well, as it would be regural RAM?

Btw, can you suggest some resources (sorry, bit off-topic here maybe) to learn Verilog and/or VHDL? To be honest, I've already tried several times but always I felt lost after some minutes because of the "alien nature" of these hardware description languages compared to ones ("normal" program languages) I am used to.

One thing has crossed my mind though. As far as I know Atmel has FPGA (not CPLD do you can easily reprogram it, I guess) with integrated MCU on it. I don't know but maybe Microchip has something similar too (as far as I can sense you prefer PIC over AVRs, that's why I wrote about Microchip). So you can even save a discrete MCU, and lowering the chip count, if you want an MCU as well not just a CPLD/FPGA.

Btw, what do you mean about "8K SPI interface"? Is it some kind of memory mapped stuff? At least my ideas was using simple some I/O ports, I am not really sure what you mean about 8K here. Or is it something I've also written about that some kind of DMA is done to a dedicated RAM (or RAM-like, from the point of view of the Z80 at least) area which can be accessed by the CPU as well, as it would be regural RAM?

Btw, can you suggest some resources (sorry, bit off-topic here maybe) to learn Verilog and/or VHDL? To be honest, I've already tried several times but always I felt lost after some minutes because of the "alien nature" of these hardware description languages compared to ones ("normal" program languages) I am used to.

One thing has crossed my mind though. As far as I know Atmel has FPGA (not CPLD do you can easily reprogram it, I guess) with integrated MCU on it. I don't know but maybe Microchip has something similar too (as far as I can sense you prefer PIC over AVRs, that's why I wrote about Microchip). So you can even save a discrete MCU, and lowering the chip count, if you want an MCU as well not just a CPLD/FPGA.

I will be using memory mapped I/O for this interface, just because I don't have enough pins to include A0-A7 which hold the port address for the IORQ. Because I only use partial address decoding (A21-A12), I can only decode to 4KB pages (I've got an extra bit back by removing RFSH), so there will be a 4KB window where the SPI registers (4 of them) are shadowed.

The reason I need all the address lines is to decode the address for the on-board ROM as well. Another option would actually be to use a GAL for the address decoding of the ROM, as I do the SRAM expansion, and then use the CPLD just for SPI. This would free up a few pins for additional SPI slave selects, which may be a better idea. I'll have a think about that.

I found the best way to learn Verilog was to buy an FPGA development board (I bought an Altera DE1) and then just start playing around with it! The DE1 has a VGA out, so it's easy to write some simple Verilog code to output some colours and sync signals to get an image. This site has some nice simple examples: http://www.fpga4fun.com/. I'd recommend Verilog over VHDL, as its a friendlier language in terms of syntax if you are coming from a programming background.

In the cartridge version instead MREQ/RFSH, exist a CART signal which is valid when the cartridge memory area accessed, and only 16 address lines.

Yes, although I need a clock for the SPI interface. The choices are either an onboard oscillator, or use one of the clocks from the Enterprise (at the expansion port). Given the extra work and cost in the cartridge version (the cartridge body itself), I'm starting to think the expansion port version is looking better... and certainly cheaper.

In the cartridge version instead MREQ/RFSH, exist a CART signal which is valid when the cartridge memory area accessed, and only 16 address lines.

Some off-topic: for some very simple tasks (like trying to interface an AdLib/SoundBlaster OPL2 chip) it's even OK to "overlap" the basic ROM in the cartridge, as only write access to OPL2 is OK to be able use it, and it's not interpreted by the ROM anyway, so ROM area can be re-used for write access for extra hardware. I am not sure how dirty this idea will be treated as, by others though In theory an OPL2 can be wired in parallel to the BASIC ROM, shadowing its two registers throughout the whole BASIC ROM, but with only write access (so WR signal is needed too for example, not just the ones available on the ROM socket).

I'm not sure if this idea is useful for other puproses as well or not ...