ol.sc

Thanks :-) There's at least one bug to workaround - and TCP/IP neither includes DHCP nor DNS. Anyhow, at least from my perspective software development is already complete.

- The registration isn't open yet. - You won't need to register for one

Yes, you (and tf_hh) are right. Sorry for the noise.

Ah, thanks for pointing out :-) How / where will the 4 W5100 I/O ports be mapped into the 6502 addr space?

My understanding is that this thread is about a CS8900A based (cartridge) device, while the Dragon Cart II is about a W5100 based (PBI/ECI) device. According to my understanding is thread is about functionality-wise a Dragon Cart clone with the single addition to allow to move the 16 CS8900A registers inside the $D5 page via DIP switch. However, the network programs/libraries provided by me so far don't support the CS8900A on addresses different from $D500-$D50F. Regards, Oliver

No, there aren't any hardware requirements requiring a NewDevice. The reason for the decision was "only" that everybody I've been in contact with so far pushed us (actually pretty hard) in that direction. And reading through the Google translation of http://www.atari.org.pl/forum/viewtopic.php?id=14903 it seems that people consider there too the Dragon Cart being a CartDevice as a major issue (beside not allowing to offload the TCP/IP stack). Regards, Oliver

Hm, the only benefit of the Dragon Cart (clone) over the Dragon Cart II that I could see is that there might potentially be software supporting the Dragon Cart not being adapted to support the Dragon Cart II as well. There's no official announcement yet but my very personal guess is that it will be more expensive than the Uthernet II (http://a2retrosystems.com/products.htm) as it contains (a lot) more parts (incl. a CPLD which needs to be programmed) but that Glenn will try hard to keep it in the two-digit USD range. But again that's just my personal guess! The Dragon Cart II uses the W5100 chip instead of the CS8900A chip. Therefore no program supporting the (original) Dragon Cart will support the Dragon Cart II without adjustment. Let's define the term "my programs" as "programs provided by me" for the sake of simplicity here... I will certainly update them! They will work in the same way their Apple II and C64 siblings already do. This means in detail... Contiki (https://github.com/oliverschmidt/contiki): There will be a program ETHCONFI.COM allowing to select between the 'Dragon Cart' and the 'Dragon Cart II'. It needs to be run once before running IPCONFIG.COM. IP65 programs (https://github.com/cc65/ip65/wiki/Ready-to-run-TCP_IP-programs): - Date65, Telnet65 and Tweet65 will autodetect the 'Dragon Cart' and the 'Dragon Cart II'. - HFS65 will autodetect the 'Dragon Cart' and the 'Dragon Cart II' as soon as the program becomes available for the Atari (hopefully soon). - Wget65 will only support the 'Dragon Cart II'. IP65 C library (https://github.com/cc65/ip65/wiki/Library-for-C-programs): - All programs will autodetect the 'Dragon Cart' and the 'Dragon Cart II' simply be using the updated library. However, the updated library will be somewhat larger which might potentially cause RAM issues. IP65 asm library (https://github.com/cc65/ip65/wiki/Library-for-asm-programs) - There will be an additional library for the 'Dragon Cart II' beside the existing one for the 'Dragon Cart'. - There will be an additional library allowing programs to autodetect 'Dragon Cart' and the 'Dragon Cart II' which - again - will be somewhat larger than the device specific libraries. The only 3rd party program known to me to make use of an IP65 library is 8bit-Slicks (http://8bit-slicks.com/). It uses the IP65 C library. So what I wrote there applies here. Regards, Oliver

This was actually the first idea I won't pretend that I'm a regular Atari user but I tried hard to understand things (with the help of tfhh and others) and my current understanding is: - A cart is supposed to provide a program (or nowadays rather many programs to choose from). As the Atari isn't a multi tasking system there's no issue with having only one cart slot as there's always only one program to run. At least originally carts were supposed to be changed frequently, therefore the easy access to the cart slot on the XL. - In contrast a PBI device is supposed to provide a system extension. That extension is supposed to be re-usable by several/many/all programs. Therefore a PBI device is supposed to stay connected to the machine. And therefore there's the $D1FF device selection "protocol" allowing for up to 8 PBI devices being present at the same time - although there's no physical/mechanical daisy-chaining approach pre-defined by Atari. With that understanding the conclusion was that the 'Sys-Check 2' approach just isn't right for a "usual" PBI device supposed to stay connected to the machine: It doesn't allow to add another PBI device. It doesn't allow to add a cart on the XE. After all the decision against the 'Sys-Check 2' approach wasn't an easy one - producing two variants is at least as hard as (potentially) buying two variants Regards, Oliver

No! I just paged through the Google translation of http://www.atari.org.pl/forum/viewtopic.php?id=14903 and to me it seems that there was some discussion to replace the CS8900A with the W5100. But at least as far as I understand the actual device you can now show your interest in to buy one is a straight Dragon Cart clone, meaning: - Cart, no PBI - CS8900A, no W5100 - No PHI2 "shortening" Regards, Oliver

Yes.

Hi, I presume that some of you are interested to learn that there's a new Ethernet project. It's a cooperation between Glenn Jones, the manufacturer of Apple II Ethernet cards, and me. Here's the link to his current Ethernet card named 'Uthernet II': http://a2retrosystems.com/products.htm The original 'Uthernet' card was based on the Cirrus Logic CS8900A Ethernet chip (just like the Dragon Cart). After literally years of checking alternatives Glenn and I decided to migrate to the WIZnet W5100 Ethernet chip for the 'Uthernet II' card. We believe that the very same reasons for that migration hold true for the Atari too - and therefore we want to make a W5100-based Ethernet solution available for the Atari. Without going into all the details the W5100 combines from our perspective the best of two worlds: - It can be used in a pure Ethernet controller mode very similar to the CS8900A. This allows for easy migration of any CS8900A-based program to the W5100. On the Apple II there's not a single (published and therefore known) network program/framework/library today that doesn't support the W5100 beside the CS8900A. - It can be used in a TCP/IP offloading mode. This allows programs not caring about backward compatibility to the CS8900A to push all the TCP/IP handling to the W5100, e.g. to establish and maintain a TCP connection with just a few hundred bytes of code and no 6502 cycles at all. - It can be used in both modes at the same time. This allows a CS8900A-compatible user program to use the W5100 in Ethernet controller mode while at the same time some OS driver uses the W5100 in TCP/IP offloading mode to e.g. provide access a virtual disk drive hosted on some machine on the network. This isn't just some vision but actual reality on the Apple II. So after having moved from the 'Uthernet' with CS8900A to the 'Uthernet II' with W5100 on the Apple II it sort of seemed natural to move from the 'Dragon Cart' with CS8900A to a 'Dragon Cart II' with W5100 on the Atari. I asked @puppetmark about the idea to actually re-use the name 'Dragon Cart' and he liked it a lot, thanks! When I got in touch with my Atari contacts about the Dragon Cart II they all replied unanimously, that they really like the idea but that Glenn and I should pretty please go for a PBI device instead of a cart. And so we did! The Dragon Cart II isn't an actual Atari cart. It's a PBI device. There will be to variants. One for the XL PBI and one (a bit later) for the XE ECI. Both will have a pass-through design allowing to plug in another PBI/ECI device (or a cart on the XE). Please note that it won't be a "true" PBI device in that it won't contain a ROM holding a handler. It won't be detected by the OS as I/O device. Rather a user program and/or RAM-based driver has to directly access the W5100. While this may not be the approach preferred by everybody it's for sure the only approach delivering optimal performance. However, although the Dragon Cart won't come with a handler ROM it will be as compatible as possible with any other PBI device. It will fully adhere to the $D1FF PBI device activation "protocol". It will even come with DIP switches allowing the user to select the Device ID (1- to be used by the Dragon Cart II. The Dragon Cart II is supposed to become available in spring 2019. We'll be looking for a few beta testers sometime in February - details will follow. And finally as treat for all reading through this (too) lengthy post here are some design pictures. Please note that they're just a snapshot of the current design and are subject to change - in fact some things will change for sure. This is the top side of the XL device. On the left hand side there are the DIP switches. On the right hand side there's the RJ45 socket and a Micro-USB socket for providing power in case the XL doesn't. This is the bottom side of the XL device. All parts not relevant to the user have been moved here out of sight. This is a 3D picture of the XL device. It gives a visual idea of the sockets. So that's it for tonight, Oliver

Thanks for the link :-)

Hi, Your three questions show me that there's a major misconception :-( IP65 is a TCP/IP library talking to several Ethernet chips (incl. the W5100). That "Arduino Ethernet library" is a TCP/IP library talking to the Ethernet chip W5100. So there's of course no point in stacking both as they roughly do the same. If you want to use that "Arduino Ethernet library" then you'll do so from your game and drop IP65. This is by the way the very same thing you do when you want to use the ESP8266/ESP32. In both scenarios IP65 doesn't play any role aka I'm not involved in any way. So just in case you want to use IP65: As I wrote before, IP65 needs the registers of a CS8900A or W5100 or LAN91C96 mapped STRAIGHT into the 6502 address space. As soon as you modify that setup in any way you need to write your own Ethernet driver for IP65. Apart from that general aspect you need to know that all three Ethernet chips mentioned above support so-called auto-increment registers. That means when it comes to actually transfer data from/to the Ethernet chip RAM to/from the 6502 RAM one simply does successive reads/writes (e.g. LDA <register addr>/STA <register addr>). So even a read from the Ethernet chip register in question has a side effect! Therefore the hardware design needs to make ABSOLUTELY sure that there are no so-called phantom reads at any point in time. Regards, Oliver

Will do...

> I assume that once the hardware is mapping these registers to a continuous memory block, then it is a simple matter of giving the start address to IP65. That's exactly how it works. > Onto the next question then: Do you have a short list of those registers needed by IP65? This is something you usually get from the datasheets for the chips in question. However for your convenience: CS8900A: https://github.com/cc65/ip65/blob/master/drivers/cs8900a.s#L95-L101 W5100 (in indirect bus I/F mode): https://github.com/cc65/ip65/blob/master/drivers/w5100.s#L107-L110 LAN91C96: https://github.com/cc65/ip65/blob/master/drivers/lan91c96.s#L98-L132 Regards, Oliver

@8bit-Dude: A classic Ethernet chip "only" takes care of the Ethernet layer. This means that it's up to the 6502 to handle the TCP/IP layer. IP65 is such a TCP/IP layer for the 6502. Running the TCP/IP layer already takes away quite some resources from the 6502 not available to the "rest" of the running program. The Cirrus Logic CS8900A is such a chip - and the one usually used for 6502 based systems. However with the rise of embedded systems there were enough systems with limited resource that there was a market to develop chips with integrate the TCP/IP together with an Ethernet (or WiFi) layer. After several rather expensive chips the Espressif ESP8266 and ESP32 are by now THE solution. With the WIZnet W5100 Ethernet chip there's sort of a hybrid. It allows to be used both as pure Ethernet chip as well as TCP/IP+Ethernet chip. So what type of chip to go for on what machine? On the C64 there are quite some CS8900A-based programs. So RR-Net MK3 at the end stayed with the CS8900A used before although there was already a prototype with the W5100. On the Apple II and the ATARI there are less network programs to be compatible with. Most/all relevant programs are based on Contiki or IP65. And both Contiki and IP65 allow to easily switch between the CS8900A and the W5100 (with the W5100 used as pure Ethernet chip). Additionally the W5100 brings options to develop code using the ESP8622 TCP/IP layer. On other machines I personally would consider this: - On a machine with (nearly) 64kB RAM and reasonably well supported cc65 C library I tend towards the W5100. It allows to a) easily bring the existing Contiki/IP65 programs to the machine in question and b) make use of the W5100 TCP/IP layer for new programs. - On a machine with (much) less RAM and/or weak/no cc65 C library I'd rather think about an ESP8266/ESP32 approach. In contrast to the W5100 the Espressif chips don't contain only a TCP/IP layer but additionally a DHCP client, DNS client and HTTP(S) client. After these rather lengthy general remarks now for a more specific answer to "what would be the requirements in order to easily interface with IP65?": A CS8900A or W5100 or LAN91C96 with its registers mapped straight to some 6502 memory mapped I/O locations. Regards, Oliver

>> 8bit-Dude: Oli, I have a question: [...] > tschak909: Short answer, [...] I wasn't aware that you call yourself 'Oli'.

@flashjazzcat: Thanks for the link :-) @phaeron: Thanks for detailed feedback :-) I now see!

@flashjazzcat: Thanks for the detailed information :-) However, I'm unfortunately not able to determine from it if you see addresses generally unused.

Thanks for the recommendation (and the explanation) :-) Any different opinions?

@phaeron: Thanks for the hint :-) As you "only" comment on the IRQ aspect I presume the rest of my assumptions are okay from your perspective. I'll summarize what I believe to have understood. Please correct me where I'm wrong... The OS generally doesn't make assumptions on the content of $D1FF. When it wants to call a PBI handler it "just" writes the corresponding PBI index to $D1FF to have the corresponding ROM mapped. When an IRQ is asserted by a PBI device the OS needs to learn which one did so. Therefore the device in question makes a read from $D1FF retrieve its own PBI index. Therefore the OS IRQ handler can't save the $D1FF content in order to restore it prior to returning from the IRQ. Instead everybody writing to $D1FF needs to write the same value to SHPDVS. This allows the OS IRQ handler to read the "correct" value from there and write it to $D1FF prior to returning from the IRQ. In order to be really safe, writing a value to both $D1FF and SHPDVS should be made an atomic operation be masking IRQs while the two writes.

The specific scenario at hand is about 4 I/O ports. If there are 4 addresses available that can be assumed to be unused "no matter what" then this would certainly be the by far easiest solution.

Hi, I'm thinking about to create a device for the PBI without a ROM but only a few I/O ports at $D1xx. It won't be recognized by the OS but is only accessed by a specific program. My question is: Assume the device detects write access to $D1FF and only responds to I/O port access if $D1FF contains the right bit - which is as far as I understand what PBI devices are supposed to do. Is that enough to cooperate with other "proper" PBI devices? In other words: Is it reasonable to presume that the OS will set $D1FF before trying to access any recognized PBI device? And is it acceptable that some other part of the system (e.g. the specific program) writes to $D1FF (prior to accessing the device I/O ports)? Note: The device won't generate interrupts. The program won't access $D1FF and/or the device I/O ports from within an interrupt handler. Thanks for your help, Oliver

OpenSSL and OpenSSH heavily depend on an OS like Linux. I've been looking into these things quite a lot, it's VERY hard to get SSH (not to be mixed up with SSL) onto some micro-controller...

I'm for sure no Atari guy so maybe I'm wrong - but I think our 6502 machines tend to be powered on and off rather quickly / often. But any Linux SoC thingy takes ~30 secs to come up and usually wants to be shut down cleanly. So I'm with you that I prefer clean integrated solutions I have by now come to the point to see the Linux SoC as an optional add-on.