Jump to content

ol.sc's Photo


Member Since 6 Nov 2010
OFFLINE Last Active Yesterday, 12:30 PM

Topics I've Started

Preannouncement: Dragon Cart II

Mon Jan 21, 2019 5:17 PM



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- 8) 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.


Attached File  top.png   107.63KB   39 downloads

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.


Attached File  bottom.png   171.81KB   37 downloads

This is the bottom side of the XL device. All parts not relevant to the user have been moved here out of sight.


Attached File  3d.png   88.51KB   38 downloads

This is a 3D picture of the XL device. It gives a visual idea of the sockets.


So that's it for tonight,


ROMless PBI device to cooperate with other devices?

Sat Nov 24, 2018 6:13 PM



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,