First of all thanks for joining in here and your detailed post !
Big thumbs up for your work, that's really awesome!
I appreciate your feedback :-)
You can do that via SIO, it even has 2 interrupt inputs ("Interrupt" and "Proceed"), so you don't have to use polling. AFAIK no other SIO devices are using these pins so there shouldn't be any conflicts. Using something like an Arduino plus ethernet shield (or some other micro with eth connectivity) would be a way to go. IIRC Sven on the ABBUC forum is experimenting with this.
As I already mentioned this seems to be the most popular approach nowadays: Use the given interface (Atari -> SIO, CBM -> IEC, Apple II -> SmartPort), implement it on an MCU and access an SD Card from the MCU.
Then one starts thinking about alternatives to exchanging the SD Card between a PC and "the device". So one adds WiFi. Finally one wants thinks about using WiFi not only for SD Card access but also for networking on the 6502 host. So one comes up with a clever pseudo-drive / virtual-channel / <you name it> allowing to open a (usually single) TCP (usually only client-) connection.
There might be a good reason why this is popular. It might just be the most useful solution for most users. Nevertheless it's not my solution. It's after all just a question of taste...
- Such approaches treats the 6502 host (more or less) as a black box as they aim for maximum compatibility with existing 6502 software. Almost all development is done on the MCU. But I want to make use of my experience in programming the 6502 host and create new 6502 software. I'm not really into MCU coding.
- Such approaches look to much like wag-the-dog to me. About every MCU offers a multitude of resources of the 6502 host. About every task coming up in the future would be solved quicker and better by offloading it to the MCU. Why go through the hassle of 6502 coding / optimizing at all?
One can of course use the W5100 in such a device (see http://www.retroswit...products/flyer/ or http://www.cometplus.net/ ) and drive it from the MCU. However that's not what I'm personally after...
Some thoughts on interrupts: Maybe they are important in the Atari for reasons beyond my knowledge but in general I see them as not necessary or even benficial. I think there are in general two reasons for having a communication device interrupt the 6502:
- The device has a small input buffer and one wants to grab the data before it's lost (think usual UART). The W5100 has input buffers larger than what one would usually want to spend in 6502 RAM. So the data is just fine in the W5100.
- The communication protocol requires to react in some way based on the data received. And may it be only to tell the communication peer to stop sending further data (think 6502 TCP/IP stack). The W5100 handles TCP flow control transparently. If the 6502 stops receiving, the W5100 input buffers fill upand if they are full the zero-sized receive window blocks the sending peer.
So conceptually I don't see why a 6502 program would want to read data from the W5100 (via interrupt) before it is actually at the point of processing it (in it's foreground code).
I presume that interrupts are interesting here to avoid the SIO overhead just for polling the W5100. However if the W5100 is directly accessible from the 6502 then polling is in the range of 20 instructions - very little in my opinion when taking into account that interrupt handling doesn't come for free either.
Another option is to create a PBI device. This hooks up to the 6502 address/data bus ("PBI" or "ECI+cart" connectors at the back of the Atari), supports IRQs as well and - if done correctly - can coexist both with other PBI devices and SIO devices.
Unfortunately I cannot really follow you. However maybe this isn't actually directed to me but rather towards somebody thinking about an Atari W5100 device...
The only thing I can/want add here is that it is from my personal perspective obligatory to allow the 6502 to directly access the W5100 (using its indirect bus interface). This allows to i.e. read data from the W5100 with a loop like
: lda w5100_data_reg
So there's no checking of some line to become high/low or alike. It's just reading (with auto-increment) as fast as possible - afaik only DMA could beat that.
The big plus of PBI devices is that they include the necessary device driver code in their own ROM and they are accessible via the standard Atari OS functions right after power up - quite similar to PCI cards with ROM on a PC. So you could put all the socket interface layer code into the ROM, people wouldn't have to load drivers and no precious RAM would be lost.
That sounds of course great !
Hardware wise PBI devices can bank in their own memory in the $D800-$DFFF area, the Atari OS controls the high level stuff of that (which of the up to 8 PBI device ROMs will be active). 2k isn't really a huge amount of memory, but with some clever bankswitching one can squeeze in quite a lot of code. If you need some scratch RAM for internal state/buffers/... you'll either have to bank it into the 2k area as well, eg by a 1k/1k or 0.5k/1.5k RAM/ROM memory split or use some of $D1xx for that (which you most likely will also use for the hardware and banking registers).
I must admit that I'm still almost totally lost when it comes to all the RAM/ROM config options on the Atari. What probably makes sense to add from my side:
As already mentioned the code to actually receive/send data from/to the W5100 can become pretty small - a few hundred bytes. I'd hope that this helps to makes it compatible with a wide range of software making its own use of specific RAM/ROM locations.
There's however the initialization / setup / login phase. There one would like want to have DHCP and DNS (which are not implemented in the W5100). Additionally there would be some interactive program (?). My gut feeling is that one 2kB bank would be sufficient.
The interactive part can be fully driven by the communication peer. Think of the 6502 machine just sending keystrokes and the peer sending full text screens (in the right format) the 6502 machine just copies as-is to its text video RAM. Very little code on the 6502 side and full flexibility regarding the UI. A simple LAN peer just presents a list of disks to mount. An Internet server with accounts (as described before) presents a login first.
Edited by ol.sc, Wed Aug 12, 2015 6:03 PM.