Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

114 Excellent

About ol.sc

  • Rank
    Chopper Commander

Profile Information

  • Gender

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm on the software side of things. The only thing I can say is that the (obviously 100% untested) drivers are available since May 2019: https://github.com/oliverschmidt/contiki/commit/c2a71ee62b3349141a94e72da685d6b839574259 https://github.com/cc65/ip65/commit/d970d4ae11bfa7618594ef47f1f6cbba640dad1e
  2. Both Dracarys variants (XE and XL) are pass-through PBI devices. They are both supposed to co-operate with other PBI devices (or carts in case of the XE).
  3. I thought this thread would be about a W5100-based cart. The W5100 offers TCP offloading for sure.
  4. @JoSch: There are several sources of information / sample code to get started. When the time has actually come and you have issues finding the relevant info let me know. @_The Doctor__: Even after reading your recent post several times carefully I still can't follow you :-( If you want feedback from my side you need to elaborate.
  5. Unfortunately it's not that simple. My statement "The question of implementing "PCLINK over Ethernet" is of course equally relevant to both upcoming Ethernet solutions." was a generic statement about a hypothetical software. IP65 isn't that software for (at least) two reasons: 1. The PCLINKoE software wants to be small by making use of the TCP/IP stack inside the W5100 chip. In contrast IP65 allows to use both the CS8900A chip of the existing Dragon Cart as well as the W5100 chip. The CS8900A doesn't have a TCP/IP stack so IP65 comes with its own TCP/IP stack (running in the ATARI RAM on the 6502). Even when actually working with a W5100 (in constrast to a CS8900A) IP65 doesn't make use of the TCP/IP stack inside the W5100 at all. Rather it uses the W5100 just as an Ethernet controller (like the CS8900A). 2. I don't see the IP65 that I provide support the Atari solution discussed in "the other" thread. You can read about the details in that thread. However to summarize: I asked about the technical details of "the other" solution necessary to support it several times and got no answer. I offered to commit to support "the other" solution with IP65 and Contiki if "they" commit to support the Dracarys with their software and got no answer. When adapting my W5100 driver code to the ATARI I had to make a choice to either have larger/slower code that could potentially support both W5100-based solutions or smaller/faster code only supporting the Dracarys. Guess which route I chose given my communication experience. By now my driver implementation is finalized so I'm by now not interested anymore in whatever whoever has to say about "the other" solution. Regards, Oliver
  6. Just to make sure there's no misunderstanding: The question of implementing "PCLINK over Ethernet" is of course equally relevant to both upcoming Ethernet solutions.
  7. You may want to check out http://atariage.com/forums/topic/287229-new-dragon-ethernet-cartridge-interest-check/?p=4204284 ff.
  8. To me the 8bit-Hub falls into a different category of network solutions. They offload the complete networking from the 6502 with their own micro controller. You can love them because they allow to do things otherwise simply impossible and because they make things way more easy. You you can hate them because they reduce your retro machine to a terminal (which you then can customize with e.g. a multiplayer game UI). Anyhow, the 8bit-Hub is for sure not the first solution of that kind: - The ESP-based "WiFi-modems". - For the C64: - The Coment (http://cometplus.net/) - The 1541 Ultimate (http://www.1541ultimate.net/) now that its network API was published (https://github.com/xlar54/ultimateii-dos-lib) Just my two cents, Oliver
  9. @flashjazzcat: Thanks for your detailed explanation - honestly! @Mr Robot: Thanks for trying to help, but there's no need for introduction - at least from my POV: flashjazzcat (Jon ?) has been there helping with answers in about every question thread I opened so far in this forum. I admire his work (been reading through the many pages of the thread on his GUI development) and appreciate his advice.
  10. Just deflecting responses like "Just give the hardware to someone who knows the A8 and isn't intent on making the hardware work in some absurd proprietary manner." What would you propose to do with insults like this instead?
  11. Yes, I'm indeed pissed off. Sorry if that wasn't obvious enough. And thanks in case you actually wanted to help.
  12. 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
  13. 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 )
  14. 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...
  15. 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.
  • Create New...