ol.sc

I don't know if it makes any sense to talk about technical details with you. Just trying... If you have one device requiring to be selected via $D1FF and being addressed via page $D1 and have another device "just" being addressed via page $D5 (?) than no software will out of the box work with both devices, will it? I certainly don't see an "absurd proprietary manner" in that. Apart from that I don't think your advice will work. E.g. several persons have shown interest in using an Ethernet device for playing http://8bit-slicks.com/- and I don't see if giving any hardware to "someone who knows the A8" will make that game automagically work with that hardware. But maybe I'm wrong - after all it's not that hard to grab my open source software and change it to work with another device. That's the difference between my software and other Reading the posts helps

So with one week since my posts http://atariage.com/forums/topic/287229-new-dragon-ethernet-cartridge-interest-check/?p=4206370, http://atariage.com/forums/topic/287229-new-dragon-ethernet-cartridge-interest-check/?p=4206372 and http://atariage.com/forums/topic/287229-new-dragon-ethernet-cartridge-interest-check/?p=4206458 without any reaction whatsoever I see that I'm asked to come to the conclusion that no coordination and/or collaboration in order to foster software interoperability are wanted. So I'm doing as I'm asked for: My upcoming releases will only support the Dracarys. Thanks for clarifying this before I actually invested effort to do otherwise )

It's in fact not that easy to find anymore these days. The Dragon Cart was built around the module "IP Dragon" from a very small company named "Invector Embedded Systems AB". Some traces: https://www.sparkfun.com/datasheets/IET/IET8900DOC_4.PDF https://web.archive.org/web/20060621205825/http://www.invector.se/iet8900.asp Some trivia: Glenn's Apple II Ethernet card "Uthernet" was built with the very same module. However, the module is mounted upside down on the base PCB. So what you read on the old page linked above... "Our production and design line is customized to be able to quickly adapt the production to meet your needs. We will customize the modules to whatever your needs are. Below is an example of a customer specified module with a slightly different connector layout." ...(and the picture below that text) was actually Glenn's Apple II project :-) Here's a picture of the complete Uthernet card showing the benefit of the unusual setup - which is to make it "flat" enough to not block the neighbor slot in the Apple II. BTW: I'm a bid proud to say that this setup was my idea...

Oops, I forgot one aspect about the software: In the lack of great alternatives programs tend to set the Ethernet MAC to just some fixed value. All my programs do so. I suggest to use the same fixed value for all programs following that approach. All my programs use 00:08:DC:11:11:11 with the first three bytes being the OUI of WIZnet. Using the same addr avoids unnecessary duplicates in the DHCP server database and in general simplifies things for users. Regards, Oliver PS: I'm fully aware of the downsides of fixed MAC addrs. No need to discuss them here.

Interesting thought. That would fall back on Glenn. He's following this thread so if he feels concerned he'll let me/us know...

First of all thanks for the interest in the device(s) announced here :-) I've followed the naming discussion with interest. However, the name "Dragon Cart II" wasn't born out of lack for ideas for other names - as I explained in both threads in question. So there actually was no need to find a new name for the two device(s). Rather they will be named Dracarys. In case you're interested in the background see e.g. https://www.elitedaily.com/entertainment/daenerys-dracarys-game-of-thrones/2037837

Given that we now know that Duddie's device is supposed to stay a cart device it's obviously too confusing to name the two non-cart devices "Dragon Cart II" I'll provide the new name for the PBI/ECI devices in the respective thread. Regarding Duddie's cart I'd personally ask to give it some name that's different from just "Dragon Cart" in one way or another in order to allow e.g. configuration programs to clearly differentiate between the original Dragon Cart and the new cart without having to resort to something like "Dragon Cart (2019)" or alike.

@ZuluGula: First of all thanks for you detailed posting ! If "someone else" refers to Glenn and me then this isn't the case. We started our project totally independently. The idea of Glenn's and my project goes back to mid 2015 - see: http://atariage.com/forums/topic/241526-tcpip-offloading-with-the-wiznet-w5100/ Do you happen to know if "existing programs" refers to anything I mention in http://atariage.com/forums/topic/287376-preannouncement-dragon-cart-ii/?p=4203077 ? Thanks for providing this relevant information here :-) So it seems we can put on record that: * Duddie's project stays a cart device (about to change into a pass through cart). * Glenn's and my project is a set of two pass through devices, one PBI, one ECI. * Both projects are supposed to be continued regardless of the other existing. Nope. What do you consider "working software"? Working on the Atari? About all my software works on the Atari. Working with the W510? All my software works with the W5100. Working with Duddie's prototype? Surely not without knowledge, how/where the W5100 is mapped. I asked you about that 4 days ago without any response - see: http://atariage.com/forums/topic/287376-preannouncement-dragon-cart-ii/?do=findComment&comment=4203122 What do you refer to with "share with us"? All my software is open source. Conclusion from my POV: The Atari community can be happy to very likely be able to choose from three Ethernet devices soon: * Pass through cart * Pass through PBI * Pass through ECI All three device use the same W5100 Ethernet chip. This asks of course for software interoperability. I'm willing to commit to support with my software all three devices if the same commitment comes from the people coding primarily for the cart. I presume that the cart maps the four W5100 registers to four successive addresses in the $D5 page. I presume that those addresses are fixed as it is supposed to be hard enough in the first place to find four addresses providing a high compatibility with carts plugged into the pass through port. The PBI and ECI devices will have DIP switches to select the PBI device ID. Being activated by writing that device ID to $D1FF they will map the four W5100 registers to $D1F0-$D1F3 (at least until we learn that these addresses are a bad idea for some reason). I guess the coders in question know that they should set $0248 just before setting $D1FF. So the software needs to know the PBI device ID to access the PBI and ECI devices. We could even go so far to agree on a common way to tell it so the user doesn't need to to it for every software again. E.g. I could see a file named W5100.CFG. It would contain just a single byte. This byte would be either binary $0-$8 or ATASCII '0'-'8'. $0 / '0' would mean the cart while $1-$8 / '1'-'8' would mean the PBI device ID. Furthermore I'd like to point to https://github.com/a2retrosystems/uthernet2/wiki/W5100-Shared-Access All my software follows the convention for "the program". If the programs primarily written for the cart would follow that convention too then it would become possible to create a RAM-based OS-driver/handler that e.g. provides access to a network drive by following the convention for "the system" - and have that driver/handler use the W5100 simultaneously to the the program using the W5100. On the Apple II I demoed a HTTP download program saving the data to a file - and that file being located on a network drive. The W5100 serves both the HTTP download program as well as the network drive handler. I hope you agree that there's great potential in cooperstion here...

So you want one of the two projects to stop? Which one? At least I do certainly know where the name came from. But with the artwork done on the shell of the original Dragon Cart this was already "abstracted away". So at least to me 'Dragon' has by now nothing to do anymore with the hardware used. I always felt that puppetmark didn't want to earn money, own the market or whatever. There are design files on the website inviting others to continue where he left off. My idea was to honor that attitude by carrying on with the name. I asked him before doing so. So much for the background. However, I understand that at the point we decided to go for a PBI/ECI device the name "Dragon Cart" wasn't exactly great anymore. But I still wanted to keep it for the reasons given above. By the time I noticed that there's another Ethernet project actually being a cart and - as far as I can tell - not having come up with any own name so far I of course knew it would cause confusion. So maybe it would be nice to get together. But I don't see the "other" producer represented here. Maybe he has a totally different naming idea. May he will decide to migrate from a cart to a PBI/ECI too. We don't know. And this brings me to an even more general aspect: Why is there no communication? Is it uncool, boring, old-school to talk to each other? I mean, from the translation of the http://www.atari.org.pl/thread I get that the decision for the W5100 was driven by the fact that there's W5100 support in Contiki and/or IP65. I've implemented that code. If I would have been him I'd contacted me long ago asking about adding "official" support for his upcoming device in my code. What will happen instead? Let me tell you: Users of 8bit-Slick will complain that the game isn't working with their nice new gadget. 8bit-Dude contacts me asking me to support it. I can't deny it because I like his work and want him to be successful. So I look up "somewhere" how the W5100 is mapped and implement "something". Me catching up with fulfilling expectations. Me the stupid guy nobody needs to talk to as I'll do whatever needs to be done anyhow? Do you have an idea how demotivated (aka fed up) I'm playing this game? Oliver

Thanks :-) I asked Atari8bitCarts for the file of the original Dragon Cart. It turned out that the "full dragon" was the original design that then was replaced by the dragon head. So I simply cleanup up and transformed his original design...

- "Dragon Bus" doesn't seem nice to me as the device isn't the bus, it uses the bus. - "Dragon Cart" (without any addition) doesn't seem a good idea for any W5100-based device as it's totally incompatible with the CS8900A-based 'Dragon Cart'. Thanks.

According to my experience all Ethernet solution in question work like a charm with any stock "wireless bridge".

I know And if I wouldn't I would have guessed )

Nobody said anything different - apart from you

Nope, the existing DHCP server in your network stops you from doing so! For sure, but only if they work. And BOOTP or DHCP doesn't work if there's an existing DHCP server that can't be configured!

As I wrote before: NFS is for sure the sweet spot of both being still feasible for the 6502 and being supported out-of-the-box elsewhere.

Sorry, but I'm afraid you're missing the point. We were talking about specific "file servers" of one or another kind when someone asked about "just" using a NAS. The obvious idea behind this proposal was to not have to add/install anything specific but re-use something already present. And at least I personally think this is a very obvious thought. Moving from SIO to Ethernet + TCP/IP asks for turning the Atari to a first-class citizen in your home network. Then I answered that this unfortunately isn't as easy as one would wish. I'm personally thinking about this very aspect since more than a decade by now... So you say something about BOOTP/TFTP. 1. TFTP: You write your own that Windows doesn't come with a TFTP server. You suggest installing Cygwin or MINGW. Then one needs to run a TFTP server inside that environment. How is that better for the average user than using something like an enhanced AspeQt already known to him? 2. BOOTP: I'd bet that nearly all users (not only the average ones already run a DHCP server on their DSL router. How do you successfully deploy an additional BOOTP server in such a network? Or how do you add option 66 and 67 to the DHCP server in your DSL router?

I hope it's okay if I answer although I'm not Dan... Those machines usually use the SMB2 protocol to share files. The SMB2 protocol is so complex that TCP/IP is nothing related to it. So you have three options: 1. Go for some simple proprietary protocol and implement your own server (e.g. by extending AspeQt). 2. Go for some as simple as possible protocol still somewhat popular. There come FTP and NFS into ones mind. However both are likely still too complex. 3. Go for some simple, well known, but not popular protocol. There you have TFTP. You see, after all you end up with 1.) as 2.) is no real option and 3.) has no real benefit. Just my two cents, Oliver

Sorry if I'm missing the point but ... Wouldn't it be most natural to just extend AspeQt to listen on some socket beside opening some serial port? To me it's one of the major benefits of TCP/IP that it's available on every modern machine without jump through loops like Serial2USB dongles etc. I mean, if you just want to connect a few Ataris together you don't need TCP/IP. You could as well use raw Ethernet frames. This would allow to just stay with the CS8900A (or use the W5100 in Raw Mode). Interacting with non-Ataris is the point in TCP/IP, isn't it?

In case you're interested in actively developing something for the W5100 I'd be happy to discuss details with you - either in another thread or 1:1, as you prefer. Just let me know...

The programs I provide all include DHCP and (where relevant) DNS. That's not the issue. I just wanted to comment on the common misconception of people reading the W5100 data sheet thinking they can create a network program by just hitting the W5100 registers. But at some point they usually notice that they didn't think about DHCP and DNS.

Are you aware that this is exactly one of the two variants I announced here?

You are right. Two different things.

I don't see software supporting both devices implicitly. Rather it needs to be explicitly implemented to do so.

I don't think so. I was sort of wondering why nobody commented on that so far... There's even a small power LED "in" the eye :-)