ivop Posted January 23, 2019 Share Posted January 23, 2019 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) Quote Link to comment Share on other sites More sharing options...
danwinslow Posted January 23, 2019 Share Posted January 23, 2019 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. Quote Link to comment Share on other sites More sharing options...
ol.sc Posted January 23, 2019 Share Posted January 23, 2019 (edited) 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 January 23, 2019 by ol.sc Quote Link to comment Share on other sites More sharing options...
Mathy Posted January 23, 2019 Share Posted January 23, 2019 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 Quote Link to comment Share on other sites More sharing options...
ol.sc Posted January 23, 2019 Share Posted January 23, 2019 (edited) 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 January 23, 2019 by ol.sc 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted January 23, 2019 Share Posted January 23, 2019 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). 4 Quote Link to comment Share on other sites More sharing options...
mono Posted January 23, 2019 Share Posted January 23, 2019 (edited) 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 January 23, 2019 by mono Quote Link to comment Share on other sites More sharing options...
ivop Posted January 23, 2019 Share Posted January 23, 2019 (edited) 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 January 23, 2019 by ivop 3 Quote Link to comment Share on other sites More sharing options...
sanny Posted January 24, 2019 Share Posted January 24, 2019 I'm using TFTP to boot one of my (PPC) Macs and a Motorola M8120 and a NCD X-Terminal. TFTP is good 1 Quote Link to comment Share on other sites More sharing options...
ol.sc Posted January 24, 2019 Share Posted January 24, 2019 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? Quote Link to comment Share on other sites More sharing options...
danwinslow Posted January 24, 2019 Share Posted January 24, 2019 (edited) 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 January 24, 2019 by danwinslow Quote Link to comment Share on other sites More sharing options...
leech Posted January 24, 2019 Share Posted January 24, 2019 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. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted January 24, 2019 Share Posted January 24, 2019 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 4 Quote Link to comment Share on other sites More sharing options...
ivop Posted January 24, 2019 Share Posted January 24, 2019 (edited) 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 January 24, 2019 by ivop Quote Link to comment Share on other sites More sharing options...
ivop Posted January 24, 2019 Share Posted January 24, 2019 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 Quote Link to comment Share on other sites More sharing options...
ol.sc Posted January 24, 2019 Share Posted January 24, 2019 (edited) 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 January 24, 2019 by ol.sc Quote Link to comment Share on other sites More sharing options...
ol.sc Posted January 24, 2019 Share Posted January 24, 2019 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! Quote Link to comment Share on other sites More sharing options...
sanny Posted January 24, 2019 Share Posted January 24, 2019 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 Quote Link to comment Share on other sites More sharing options...
ivop Posted January 24, 2019 Share Posted January 24, 2019 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 Quote Link to comment Share on other sites More sharing options...
ol.sc Posted January 24, 2019 Share Posted January 24, 2019 Nobody said anything different - apart from you Quote Link to comment Share on other sites More sharing options...
sanny Posted January 24, 2019 Share Posted January 24, 2019 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. Quote Link to comment Share on other sites More sharing options...
ol.sc Posted January 24, 2019 Share Posted January 24, 2019 (edited) Me not . I know And if I wouldn't I would have guessed ) Edited January 24, 2019 by ol.sc Quote Link to comment Share on other sites More sharing options...
leech Posted January 24, 2019 Share Posted January 24, 2019 1. davidcalgary29 - 1 cart2. xrbrevin - 1 cart3. skriegel - 2 carts4. Marius - 2 carts5. brenski - 1 cart6. AtariSociety - 1 cart7. Mathy - 2 carts8. Haightc - 1 cart9. Markk - 1 cart10. Sleepy - 2 carts11. Nezgar - 1 cart12. Gunstar - 1 cart13. Chaosfaktor - 1 cart14. Wadeford - 1 cart15. sanny - 1 cart16. DNA128k - 1 cart17. Senor Rossie - 3 carts18. KlasO - 2 carts19. NML32 - 1 cart20. CharlieChaplin - 1 cart.21. slx - 1 cart22. David_P - 1 cart23. Rainier - 1 cart24. AtariPortal - 2 carts25. patjomki - 1 cart26. Allan - 1 cart27. Toddtmw 1 cart28. TheNameOfTheGame 1 cart29. adam242 1 cart30. Dan Winslow - 2 carts31. Jinroh - 1 Cart32. Philsan - 1 Cart33. Lastic - 1 Cart34. invisible kid - 1 cart35. gozar- 1 Cart36. pixelmischief - 1 cart37. BigBen - 1 cart38. Soulbuster 1 Cart39. Ransom - 1 cart40. TemplarXB - 1 cart41. tuf - 1 cart42. mariusz - 1 cart43. leech - 1 cart44. Firedawg - 1 cart45. Quote Link to comment Share on other sites More sharing options...
HiassofT Posted January 24, 2019 Share Posted January 24, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
mani Posted January 24, 2019 Share Posted January 24, 2019 1. davidcalgary29 - 1 cart2. xrbrevin - 1 cart3. skriegel - 2 carts4. Marius - 2 carts5. brenski - 1 cart6. AtariSociety - 1 cart7. Mathy - 2 carts8. Haightc - 1 cart9. Markk - 1 cart10. Sleepy - 2 carts11. Nezgar - 1 cart12. Gunstar - 1 cart13. Chaosfaktor - 1 cart14. Wadeford - 1 cart15. sanny - 1 cart16. DNA128k - 1 cart17. Senor Rossie - 3 carts18. KlasO - 2 carts19. NML32 - 1 cart20. CharlieChaplin - 1 cart.21. slx - 1 cart22. David_P - 1 cart23. Rainier - 1 cart24. AtariPortal - 2 carts25. patjomki - 1 cart26. Allan - 1 cart27. Toddtmw 1 cart28. TheNameOfTheGame 1 cart29. adam242 1 cart30. Dan Winslow - 2 carts31. Jinroh - 1 Cart32. Philsan - 1 Cart33. Lastic - 1 Cart34. invisible kid - 1 cart35. gozar- 1 Cart36. pixelmischief - 1 cart37. BigBen - 1 cart38. Soulbuster 1 Cart39. Ransom - 1 cart40. TemplarXB - 1 cart41. tuf - 1 cart42. mariusz - 1 cart43. leech - 1 cart44. Firedawg - 1 cart45. mani - 2 carts 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.