Jump to content
ZuluGula

New Dragon Ethernet cartridge interest check

Recommended Posts

 

Unless you've got some way to have more than one cart installed at a time, you'll need the PBI/ECI version.

 

Or boot over the network ;)

 

 

 

(Note that this is a joke and such a thing does not exist. Yet. It would be possible to create an OS ROM that boots over BOOTP/TFTP)

Share this post


Link to post
Share on other sites

Yes, I think so, for DOS loads especially. I've thought about this. What's needed is a 'shared disk' over the network. One atari acts as a disk server and contains disk images for bootable environments and a server program that accepts incoming disk requests. The client atari would have a hook in DOS init that loaded the handler (from ROM or something on the cart or PBI/ECI) and would hack the startup such that all low level disk calls that go to the disk drive D1: instead get vectored out through the handler to the server as just get/put disk sectors and stuff. As far as the client atari would know it would have a boot disk locally as per normal.

 

Doing an OS load would be harder because you'd need an active handler of some sort on the client machine. Maybe a small mini-OS could boot from the PBI or something and load a real OS from the handler.

Share this post


Link to post
Share on other sites

What's needed is a 'shared disk' over the network. One atari acts as a disk server and contains disk images for bootable environments and a server program that accepts incoming disk requests.

 

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?

Edited by ol.sc

Share this post


Link to post
Share on other sites

Hello Dan

 

What's needed is a 'shared disk' over the network. One atari acts as a disk server and contains disk images for bootable environments and a server program that accepts incoming disk requests. 

 

Why not use a NAS?  Or maybe even a Mac or PC (kinda like SIO2PC, but over ethernet via a router and/or switch)?

 

Sincerely

 

Mathy

Share this post


Link to post
Share on other sites

Why not use a NAS?  Or maybe even a Mac or PC (kinda like SIO2PC, but over ethernet via a router and/or switch)?

 

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

Edited by ol.sc

Share this post


Link to post
Share on other sites

SpartaDOS X would probably be well positioned to play a role in a shared resource environment, since file system drivers can abstract file system operations to interact with (for example) a file server on a remote machine. The PCLINK (PCL:) driver is a good example of this: it implements a bi-directional file system protocol between the Atari and the PC's host file system (via SIO2BSD or the PCLINK implementation built into RespeQt).

Share this post


Link to post
Share on other sites

I think that boot through internet is possible when NewDevice option is chosen. Remote resource (disk image) could be provided by low level SIO protocol (read/write sectors) and supported by NewDev-ROM. The problem is to implement desired network communications directly in NewDev-ROM. But advantage we can get this way is to have many remote disks over internet without any modification of existing software.

Cartridge device will never do this. The only option with CartDev is to use specialized driver (e.g. for SDX) to get data from remote resource.

 

Edit: Maybe UDP protocol could be enough for this purpose (I'm sorry, I don't know if it's supported by Dragon Cart, so it's just thought).

Edited by mono

Share this post


Link to post
Share on other sites

You are making it way too difficult. BOOTP/TFTP was specifically created for this scenario. A very small boot ROM (like 1-2kB) and everything else is done by the code that's loaded over the network. So no difficult protocols like http/ftp/smb/nfs or whatever. Trivial File Transfer Protocol. Just to boot, like reading sequential sectors of a boot disk, it reads of a network stream. And BOOTP is your poor man's DHCP.

 

Regards,

Graybeard Ivo ;)

 

Edit: about popularity, it might not be that popular anymore to boot over a network (used to be "thin" clients and diskless workstations, etc..) but it's still easily available on current OSes. MacOS and Linux distros have it by default and on win32/64 you can install cygwin or MINGW and have the same daemons for bootp and tftpd.

Edited by ivop

Share this post


Link to post
Share on other sites

You are making it way too difficult. BOOTP/TFTP was specifically created for this scenario. A very small boot ROM (like 1-2kB) and everything else is done by the code that's loaded over the network. So no difficult protocols like http/ftp/smb/nfs or whatever. Trivial File Transfer Protocol. Just to boot, like reading sequential sectors of a boot disk, it reads of a network stream. And BOOTP is your poor man's DHCP.

 

Regards,

Graybeard Ivo ;)

 

Edit: about popularity, it might not be that popular anymore to boot over a network (used to be "thin" clients and diskless workstations, etc..) but it's still easily available on current OSes. MacOS and Linux distros have it by default and on win32/64 you can install cygwin or MINGW and have the same daemons for bootp and tftpd.

 

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?

Share this post


Link to post
Share on other sites

 

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?

 

I am pretty sure BOOTP is UDP, but I agree with Oliver, the point would be to use the LAN. I have no idea how AspectQt could arrange to boot an OS from a remote disk, but if it's possible that would be pretty cool too.

 

Hello Dan

 

 

Why not use a NAS?  Or maybe even a Mac or PC (kinda like SIO2PC, but over ethernet via a router and/or switch)?

 

Sincerely

 

Mathy

 

Hi, Mathy. Sure, I think that would be fine too, I just think the idea of a remote disk system between two ataris would be cool. Like NFS, but based on low level sector calls that get mapped across the LAN.

 

You are making it way too difficult. BOOTP/TFTP was specifically created for this scenario. A very small boot ROM (like 1-2kB) and everything else is done by the code that's loaded over the network. So no difficult protocols like http/ftp/smb/nfs or whatever. Trivial File Transfer Protocol. Just to boot, like reading sequential sectors of a boot disk, it reads of a network stream. And BOOTP is your poor man's DHCP.

 

Regards,

Graybeard Ivo ;)

 

Edit: about popularity, it might not be that popular anymore to boot over a network (used to be "thin" clients and diskless workstations, etc..) but it's still easily available on current OSes. MacOS and Linux distros have it by default and on win32/64 you can install cygwin or MINGW and have the same daemons for bootp and tftpd.

 

Yeah, that's the essence, you would need some kind of small bootstrapper on the client atari, just enough to get the stack active and support fetches and loads (either bootp or custom, whatever). No matter the transport mechanism, you'd need this small bootstrapping OS, and it would need to be somewhere that wouldn't get overwritten by the real OS.

 

Anyways, kind of getting ahead of ourselves here. I was totally just blue-sky imagining possibilities. The actual machine OS is the hard part, just DOS boots from remote machines would be easier.

 

*EDIT*

Hmm, after reading up a bit, BOOTP is just an earlier version of DHCP, all it does is get an IP. There's a 'netboot' protocol that does what we're talking about, but it seems like it doesn't define an actual transport mechanism, just says "most implementations use TFTP"

https://en.wikipedia.org/wiki/Network_booting

Edited by danwinslow

Share this post


Link to post
Share on other sites
Not sure where the gaps are, but would like to be added to the list. May as well get both variants too, if there is going to be a cartridge and ECI/PBI one.

Share this post


Link to post
Share on other sites

SpartaDOS X would probably be well positioned to play a role in a shared resource environment, since file system drivers can abstract file system operations to interact with (for example) a file server on a remote machine. The PCLINK (PCL:) driver is a good example of this: it implements a bi-directional file system protocol between the Atari and the PC's host file system (via SIO2BSD or the PCLINK implementation built into RespeQt).

Hmmm, do I hear someone volunteering to give it a try? :-)

IMO It'd be very interesting to explore if a NFS client implementation would be feasible. SMB is a mess, so better avoid that, and TFTP isn't really suitable for random access (which is a feature we'd might want to have). NFS server software is available for a wide range of platforms (yes, even Windows :-) and basically every NAS has built in support for that.

If NFS is doable then it would be interesting to make the Dragon "cart" V3 a real PBI device with flash ROM and RAM and whatever fancy bank-switching scheme is needed to make the code workable in the 2k pinhole (the hardware and PLD logic for that is no problem at all, software is the crucial and very time consuming part).

Instead of tying the file access code to DOS the device could register a, let's say, 'N:' CIO handler to give you access to eg "N1:>GAMES>PACMAN.COM".

With NFS client support in the PBI ROM the device could also intercept Dx: SIO calls and redirect them to (ATR) file access on the NFS server. And/or provide some simple game loader that lets you browse through your library on Nx: and start things.

Configuration could either be performed on the server side (BOOTP/TFTP or some DHCP options) or on the client (Atari) side. Maybe with a simple (external) configuration tool or (later) built into the flash ROM as well (like on the Black Box). Add a 3V lithium cell for RAM backup - like we did on the Turbo Freezer - and you have plenty of easily accessible non-volatile storage space.

so long,

Hias

Share this post


Link to post
Share on other sites

Nothing stops you from adding BOOTP (or full blown DHCP) and TFTP support to RespeQT. The basic idea is to put your bootstrapping code somewhere in the OS (Int. charset, 1kB, selftest or PBI ROM) and load support for other protocols over the network. After that, you can access higher level network protocols or, say, PC-LINK over TCP/IP.

 

Or invent something entirely new if you want. My main point is to utilize existing solutions that have been working for 30-40 years and save yourself a lot of work.

 

 

Edit: just seeing Hias's post, this is what I mean, but he phrases it better :)  Of course, if you can put NFS support in your boot ROM, you can skip TFTP if you hardcode a boot filename at the client.

Edited by ivop

Share this post


Link to post
Share on other sites

I'm using TFTP to boot one of my (PPC) Macs and a Motorola M8120 and a NCD X-Terminal. TFTP is good  :)

 

NCD X-Terminal, now that's a blast from the past! Wish I had taken one home when my former employer got rid of a ton of them. 8MB RAM IIRC, a small boot ROM, Network connector, keyboard, mouse and display. That was it :)

Share this post


Link to post
Share on other sites

IMO It'd be very interesting to explore if a NFS client implementation would be feasible. SMB is a mess, so better avoid that, and TFTP isn't really suitable for random access (which is a feature we'd might want to have). NFS server software is available for a wide range of platforms (yes, even Windows :-) and basically every NAS has built in support for that.

 

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.

Edited by ol.sc

Share this post


Link to post
Share on other sites

Nothing stops you from adding BOOTP (or full blown DHCP) and TFTP support to RespeQT.

 

Nope, the existing DHCP server in your network stops you from doing so!

 

My main point is to utilize existing solutions that have been working for 30-40 years and save yourself a lot of work

 

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!

Share this post


Link to post
Share on other sites

 

NCD X-Terminal, now that's a blast from the past! Wish I had taken one home when my former employer got rid of a ton of them. 8MB RAM IIRC, a small boot ROM, Network connector, keyboard, mouse and display. That was it :)

 

And, most important, "no fan", so silent :)

Share this post


Link to post
Share on other sites

 

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!

 

In that case, why not utilize the DHCP server in the first place? If you're going the PBI ROM route, this should be feasible. A DHCP request can be done in ~300 lines of C, so a reasonably sized ROM could handle that easily. Now NFS is another story. Luckily, if I googled it right, most NASes still support NFSv2 (RFC1094, 1989), which looks doable if you don't implement all the unnecessary functionality.

 

The boot process would be like this: ...., PBI ROM get initialized, does DHCP, boot hardcoded file (ATR) over NFS, run :)

Share this post


Link to post
Share on other sites
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?

 

Me not :).

I'm granting myself the luxury of a home server running 24/7. And this is not just some small NAS thing. It runs the DHCP server (ISC DHCPD) and it can be configured to what I want, not restricting me to the things that the DSL-router GUI allows.

Share this post


Link to post
Share on other sites

1. davidcalgary29 - 1 cart
2. xrbrevin - 1 cart
3. skriegel - 2 carts
4. Marius - 2 carts
5. brenski - 1 cart
6. AtariSociety - 1 cart
7. Mathy - 2 carts
8. Haightc - 1 cart
9. Markk - 1 cart
10. Sleepy - 2 carts
11. Nezgar - 1 cart
12. Gunstar - 1 cart
13. Chaosfaktor - 1 cart
14. Wadeford - 1 cart
15. sanny - 1 cart
16. DNA128k - 1 cart
17. Senor Rossie - 3 carts
18. KlasO - 2 carts
19. NML32 - 1 cart
20. CharlieChaplin - 1 cart.
21. slx - 1 cart
22. David_P - 1 cart
23. Rainier - 1 cart
24. AtariPortal - 2 carts
25. patjomki - 1 cart
26. Allan - 1 cart
27. Toddtmw 1 cart
28. TheNameOfTheGame 1 cart
29. adam242 1 cart
30. Dan Winslow - 2 carts
31. Jinroh - 1 Cart
32. Philsan - 1 Cart
33. Lastic   - 1 Cart
34. invisible kid - 1 cart
35. gozar- 1 Cart
36. pixelmischief - 1 cart
37. BigBen  -  1 cart
38. Soulbuster 1 Cart
39. Ransom - 1 cart
40. TemplarXB - 1 cart
41. tuf - 1 cart
42. mariusz - 1 cart
43. leech - 1 cart
44. Firedawg - 1 cart
45.

Share this post


Link to post
Share on other sites

In that case, why not utilize the DHCP server in the first place?

On a second thought that may not be too viable, people may want/need to use the router from their provider which typically has terribly crippled DHCP configuration options (sometimes none at all). Better use DHCP only to obtain a IP and DNS information, these things should work with all DHCP servers/routers.

TFTP could be used to retrieve client configuration but that requires people to install, configure and run a TFTPD server somewhere and managing configurations isn't too easy.

So I think it's probably best to keep the configuration on the client side, then people can change them rather easily, directly on their Ataris.

so long,

Hias

Share this post


Link to post
Share on other sites

1. davidcalgary29 - 1 cart
2. xrbrevin - 1 cart
3. skriegel - 2 carts
4. Marius - 2 carts
5. brenski - 1 cart
6. AtariSociety - 1 cart
7. Mathy - 2 carts
8. Haightc - 1 cart
9. Markk - 1 cart
10. Sleepy - 2 carts
11. Nezgar - 1 cart
12. Gunstar - 1 cart
13. Chaosfaktor - 1 cart
14. Wadeford - 1 cart
15. sanny - 1 cart
16. DNA128k - 1 cart
17. Senor Rossie - 3 carts
18. KlasO - 2 carts
19. NML32 - 1 cart
20. CharlieChaplin - 1 cart.
21. slx - 1 cart
22. David_P - 1 cart
23. Rainier - 1 cart
24. AtariPortal - 2 carts
25. patjomki - 1 cart
26. Allan - 1 cart
27. Toddtmw 1 cart
28. TheNameOfTheGame 1 cart
29. adam242 1 cart
30. Dan Winslow - 2 carts
31. Jinroh - 1 Cart
32. Philsan - 1 Cart
33. Lastic   - 1 Cart
34. invisible kid - 1 cart
35. gozar- 1 Cart
36. pixelmischief - 1 cart
37. BigBen  -  1 cart
38. Soulbuster 1 Cart
39. Ransom - 1 cart
40. TemplarXB - 1 cart
41. tuf - 1 cart
42. mariusz - 1 cart
43. leech - 1 cart
44. Firedawg - 1 cart
45. mani - 2 carts

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...