Dear All EPNET Fans!

I've exchanged some mails with Bruce meanwhile about the plans on project EPNET. I've already started to write a small "test program" which can be run (in theory ... without any hardware yet, I can't be sure, as I already write it by reading the specification from Wiznet) with the real EPNET and with my emulator Xep128 too (which will support _some_ features of the real hardware, the keyword here is "will", so it's in future tense).

The first problem of mine: where are the six I/O ports from viewpoint of EP. As Bruce told me, it's not a fixed I/O address, also Xep128 likely will use another - fixed - port. I proposed some kind of complicated way to find the I/O port (ie, scan segments to find EPNET ROM and then call a routine there which can tell). It's clear that Bruce has more experience with the Enterprise in general than me (hehe, no wonder ...) because he suggested to use an EXDOS-like method instead. That is: use an EXOS command with a probably impossible to type character in the command itself (like EXDOS\0xFD).

The idea basically: issue the EXOS command EPNET\0xFF (EXOS 26 call with DE set with that string, length of 6) and if command is returned with OK status (as far as I remember, A = 0), maybe register B contains the I/O port. Of course further functionalities can be provided by the EPNET ROM, ie, low level socket manipulation routines etc, and also EXOS integration, but the I/O port is the very basic thing to write the first apps which want to do all the I/O at their own and they only need the I/O address for this. I guess even SymbOS would use that, since - as far as I know - SymbOS loader uses some EXOS commands anyway, but does directly everything after that point by its own, when SymbOS is already running. Of course this "I/O port detection method" via EXOS will be supported by Xep128 too.

Any feedback, opinion, new ideas are welcome. Of course with proper EXOS integration (ie, devices like HTTP: etc) can make it possible later to even write network/internet capable software in IS-BASIC, now the I/O-port related problem is mainly about for the EP apps doing direct I/O anyway (probably including SymbOS!), because as far as I can see it can take more time to develop proper EP OS (EXOS) software support, but I can be wrong ...

Honestly, I don't know. You should ask Bruce, or Zozo. What I know that maybe with the bus bridge there was a nice idea to have some kind of "auto config" ability for cards, ie inserting even same type of cards but getting "private" resources (as for memory segments and I/O port ranges) based on (maybe) the card slot position. Or something like this ... The idea is quite "plug and play" like stuff, but ... I think it's not so well known method in Hungary for example and nobody cared on this later. Really, these are my best guesses, I am lame with this topic, just I tried to answer ...

My idea would be to do some kind of self modification on start-up for the I/O ports used inside the code (after the detection when you know what they would be modified to ...).

This is what I would do in any case. At least my W5100 driver for the Amstrad CPC (which would use indirect I/O as well) only has two routines, which really have to deal with the base I/O port: setup the address and return the data port; one for register memory access, one for RX/TX buffer access. The W5300 shouldn't be much more complex. So such an I/O port "relocator" is not a problem at all.

Of course in the case of RX/TX data transfer it's maybe slower to use OUT (0x??), A and similar constructs and self-modify code at init to set them at an altering reg, reg+1 numbers for ports, where reg = IOB + 4 is of course. And I meant about the unrolled loop to do data transfer for bigger data chunks, of course. Because IN/OUT with constant (rather than using register C) is faster (if I remember correctly) and then you can save the INC/DEC C opcodes as well.

lgb your description of the data transfer, and your code snippets,  agrees with my current understanding (perhaps not surprising as we have read the same datasheet!!) but I hope to be able to confirm for real very soon.

Well, with my misunderstanding ability, it would be no wonder to think about a completely different thing even by reading the same spec as you

It's a bit disappointing: at first glance of the datasheet with its auto-incrementing register I thought we'd be able to use INIR etc but on closer inspection it seems not.

Hmm, maybe I missed something, but I have no knowledge about any auto-incrementing stuff, or do you mean about the internal counter of FIFO registers maybe? I wouldn't say that not having INIR is a so big problem. INIR is kinda slow, something like 21 cycles (well, about cycles I can be wrong!). At the other hand, a plain IN A,(nn) - let's say we use constant ports, and unrolled loops for big chunks - is 11. So it's faster this way, but for sure, you need _store_ data too then, so maybe not If we optimize this to have EP-memory buffer at fixed 256 byte boundary, it can be eg an LD (BC), A - 7 cycles? - and  a plain INC C (if no 256 byte boundary crossed) - 4 cycles, thus we have 11+7+4 ... well, one cycle slower than INIR and having just too much "good" conditions for being fast. Well, better than nothing ... The other possibility would be using memory mapped I/O, thus not real Z80-like I/O, but using a memory area for that, as SD card does it too. In that case, a bigger area (even 16K, etc, but for real it's even OK to decode a smaller part of the EPNET ROM area for that, of course) can be used to address basically IMD_DR0 or IMD_DR1 based on the lowest bit of the address. The other stuffs can be on I/O port. This sounds insane, but consider this: w5300 seems to be indirect for FIFO TX/RX transfer even in direct mode. Register addressing still indirect and needs IDM_AR on I/O ports (and MR too, of course). But when it is set up, IDM_DR0 and DR1 can be accessed via "normal RAM" thus you can use LDIR (as it increases the source address the toogling A0 line in our "DR segment" would read IDM_DR0, IDM_DR1 sequence as we should!), etc for the actual transfer than! Only some extra decoding should be used. I am not sure if it worth anyway Sounds strange, but I've already started to like it What I see here, that from view point of w5300 even in indirect mode, those are just signals, nothing says we can't map w5300 address pins in an "insane" way

One other thing I felt the void before, but I haven't realized: there is no way on the w5300 to detect the link status, speed, etc If EPNET ROM would support something like doing DHCP it would only wait for timing out when even no cable plugged in. I don't like this. But what I have is an idea: w5300 has outputs to drive LEDs about some attributes we are interested in. What would happen if we also interpret those as logic levels, routing them onto a buffer IC which is enabled in case of reading of an I/O port after the w5300 IDM's ones? Then we would be able to "read the status of LEDs" basically, or so But we can see the link status, speed, etc, from software too!

All the code examples in the datasheet just have a loop which reads/writes the bytes from/to the data register.

All the code examples in the datasheet just have a loop which reads/writes the bytes from/to the data register.

Ah yes, those are the FIFO registers. Indeed they have auto-incremented (or decremented) _internal_ pointers pointing in the w5300's RAM, but only a "single" (*later on this) port from the viewpoint of the host. So that you need only read a single port to read RX buffer, and only write a single port to fill the TX buffer. Our problem is, that "the single port" is 16 bit wide, so for real (for a 8 bit system), it's reading/writing port, than port +1, then port, port +1, etc (if IDM_AR is set to the fifo register, it's IDM_DR0 and IDM_DR1 altering access then). Exactly that's why it came into my mind, to map _memory_ accesses for the w5300 as within a memory range any EP memory r/w op interpreted to access IDM_DR0 or IDM_DR1, based on the value of address bus bit0. Thus eg a simple LDIR would be able usable to read/write RX/TX memory, if IDM_AR is set up before, and you are very careful to start on even memory address (A0=0 -> accessing IDM_DR0 first) and doing even number of bytes strictly. You can question if it's sane then to use indirect mode, as we can use the direct one too with memory mapped I/O still using 8 bit. But as far as I can remember, the spec says that FIFO registers are some kind of similar and indirect stuff even in direct mode of w5300, so maybe it does not worth to do.

Unfortunately my proposal means some kind of tricky EP signal decoding can be "expensive" using discrete logic (eg with 74xx series of logic ICs) and would need some kind of GAL, PLD, and such. Then we can say that a given I/O port range for I/O request is forwarded towards the w5300, and a given _memory_ range op is forwarded as IDM bus address 4 or 5 based on the value of A0 from the EP. Then we would be able to use memory based ops to do the data transfer

Please don't do that.

ok, I won't, I hadn't read that example!