Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

8-bit ISA Bootable Ethernet Adapter with ATAoE

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Glad your on-board!

    Is there any reason we can't do both; I mean, start development against a common (any common) NIC, just keep the code nicely in layers so a direct media interface can be dropped in at some future point? I'm happy to prototype an ISA card of course, but there are others here much better equipped to do so than me.

    On the subject of cards, the 10 XT-CF-Lite boards I had made all sold within a week. So either the fine-pitched SMT or the need to program the CPLD seemed to put off buyers of the XT-CFv2 board (or maybe a combination).

    Comment


      #17
      Maybee a simple NIC and ROM supporting something like BOOTP?
      Reach me: vcfblackhole _at_ protonmail dot com.

      Comment


        #18
        Right now, on my XT clone, which has an XT-IDE and external CF fitted (photo here), I can get multiple boot environments by using multiple CF cards.

        From my viewpoint, this 'network boot for vintage computers' proposal is definitely 'a solution seeking demand' rather than 'demand seeking a solution' kind of scenario. But that's okay - this is not a commercial venture. Do it for the enjoyment/satisfaction (and brag rights). In fact, phase 2 could be the additional option of booting from a dedicated server on the Internet (just for the 'wow' factor).

        As long as contributors are aware that their efforts may be only be for a few.

        Comment


          #19
          Could always build around the Digi Connect ME modules:

          Wireless: $130
          http://store.digi.com/index.cfm?fuse...ategory_id=581

          Wired: $49
          http://store.digi.com/index.cfm?fuse...ategory_id=579

          A bit overkill, but you could also configure it remotely via web-browser. And if you're going for nerd factor, would be hard to beat running Linux on your 5150 NIC.
          "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

          Comment


            #20
            This would be a very awesome thing to see get made. I've been talking with pearce_jj about it a bit already. I don't have the kind of hardware expertise needed to help design the actual circuitry, but there are a lot of folks here who would be up to the task. I want to get involved on the software side of things, though. (ROM code, etc)

            The idea has already gotten me interested enough that I've started writing some assembly code for remote ethernet booting already. I'm just writing it to work with a regular packet driver on any existing NICs for now, but once everything is working it should be fairly easy to adapt it to ROM for a custom adapter like this. It's coming along really well, and I think I should have a basic proof-of-concept all functional in the next 2 or 3 days. It doesn't use DOS to load itself up, I wrote a custom floppy boot sector that loads up my code and the packet driver into the top of conventional memory and reserves it so that booting DOS won't interfere and break things.

            Getting packet drivers that are designed to run under DOS working without DOS required a bit of trickery, but was pretty easy. I'll give more details about all of this when I've got it the remote boot totally working and am ready to share. All that's left at this point is handling the actual int 13h calls, which really should be very easy. The memory footprint will be pretty small, the code compiles to about 6 KB right now and I'd be surprised if the whole thing ends up needed more than 8 KB when finished. So, that and the size of the packet drivers (crynwr ones are VERY small) will be all it needs.
            sigpic

            Comment


              #21
              Mike, thanks for posting this - it's phenominal to see this idea comming alive so quickly

              Great to hear that the packet driver model looks do-able. So building our own NIC seems somewhat needless, given the progress you're making and especially if the whole thing will fit into just 8K anyway.

              Comment


                #22
                That is good progress.

                So the plan is to adapt the open source Crynwr drivers to run from ROM, and then have the INT13 BIOS use them directly? Are you fixing the API so that you can just do a far call to the code to send packets instead of invoking a software interrupt? How are you planning on handling the server configuration - is it going to be a parameter "burned" in with ROM image or are you going to do something like DHCP to obtain an IP address and get the server IP address?


                Mike

                Comment


                  #23
                  No, what I do is hook int 21h and have my own handler support a tiny subset of the DOS functions. Just enough of it that the packet driver is able to run and set itself up. All of the packet drivers (including even the proprietary Xircom PE3 driver) I've seen so far only use a small handful of DOS functions, and then once they're installed and go TSR they never do any other int 21h calls again.

                  The complete list:
                  Code:
                  Int 21/AH=02h - DOS 1+ - WRITE CHARACTER TO STANDARD OUTPUT
                  Int 21/AH=09h - DOS 1+ - WRITE STRING TO STANDARD OUTPUT
                  Int 21/AH=25h - DOS 1+ - SET INTERRUPT VECTOR
                  Int 21/AH=31h - DOS 2+ - TERMINATE AND STAY RESIDENT
                  Int 21/AH=35h - DOS 2+ - GET INTERRUPT VECTOR
                  Int 21/AH=40h - DOS 2+ - WRITE - WRITE TO FILE OR DEVICE
                  Int 21/AH=49h - DOS 2+ - FREE MEMORY
                  Int 21/AH=4Ch - DOS 2+ - EXIT - TERMINATE WITH RETURN CODE
                  For server config, I'm actually just using my own ethertype in the packets which isn't used by anything else. It's just to keep things simple. When it's all working, I was considering using the UDP code from that asm TCP stack I wrote a while back. It would also need the ARP and IP code too though, and would eat up another 4 KB or so. I don't know if it's really necessary though, because I doubt anybody would be trying to use it outside of a LAN anyway. It's going to have it's own simple discovery protocol that just broadcasts a packet that any machine running the server software recognizes and sends a packet with info about itself to the client machine. A nice, clean, and simple way to do it.

                  Once it's working I'll probably just tinker with adding UDP to it. Maybe it will use less RAM than I'm thinking.
                  Last edited by Mike Chambers; January 5, 2013, 11:42 AM.
                  sigpic

                  Comment


                    #24
                    Nice!

                    ATAoE can handle the configuration automatically for us on the server side, by simply using a MAC address binding. So for example using Ubuntu and vblade we could create a blank 250MB disk image and then define an export based on the target machine thus:

                    dd if=/dev/zero of=5160-System-Disk.img bs=1M count=250
                    vbladed -m 00:01:2e:bd:2e:ac 1 1 eth0 5160-System-Disk.img


                    AoE itself is using three fields only - MAC addresses, 'shelf' and 'slot' in vblade terminology (major and minor in the spec, see wikipedia for frame format or the spec itself), but the discover option uses wildcards (FFFh, FFh) in those fields hence the only targets appearing will be those with a MAC address matching the request:

                    2.5. Major, Minor

                    Each AoE server possesses a major and minor address. Before
                    processing the header Command the server must validate its major and
                    minor address with the Major and Minor fields in the header. A
                    server will accept a command message for processing if the following
                    two tests are true:

                    The Major field in the header is the server major address or all
                    ones (0xffff).

                    The Minor field in the header is the server minor address or all
                    ones (0xff).

                    Any command messages failing either of these two tests must be
                    ignored by the server.

                    The server must supply its major and minor address in every response,
                    even if the corresponding request had all-ones values.


                    In that context, an AoE server is per disk image, so multiple "1 1" images can be shared (by MAC address) from a single vbladed host.

                    So no need to include any layer-3 code at all My suggestion would be to always use shelf/slot 1 1 for the first (boot) volume or something like that, so that multiple images could (in future perhaps) be supported too. But TBH, I think one disk image support would be absolutely fine.
                    Last edited by pearce_jj; January 6, 2013, 02:26 AM.

                    Comment


                      #25
                      Originally posted by Mike Chambers View Post
                      No, what I do is hook int 21h and have my own handler support a tiny subset of the DOS functions. Just enough of it that the packet driver is able to run and set itself up. All of the packet drivers (including even the proprietary Xircom PE3 driver) I've seen so far only use a small handful of DOS functions, and then once they're installed and go TSR they never do any other int 21h calls again.
                      That was clever, and it gets you around the requirement for the original source code.

                      (I'm still of the opinion that if the source code is available, use it. The packet driver interface requires a software interrupt for sending every packet two far calls to receive; it's a bit of a pig. But what you have takes care of the Xircom problem, and a lot of the later packet drivers too.)

                      Comment


                        #26
                        pearce_jj: i think the ATAoE stuff looks like it would work pretty well for this. i'm going to go with what I described first, just to verify everything works nicely then then I will definitely look into switching the protocol.
                        sigpic

                        Comment


                          #27
                          Originally posted by mbbrutman View Post
                          That was clever, and it gets you around the requirement for the original source code.

                          (I'm still of the opinion that if the source code is available, use it. The packet driver interface requires a software interrupt for sending every packet two far calls to receive; it's a bit of a pig. But what you have takes care of the Xircom problem, and a lot of the later packet drivers too.)
                          In most cases, you're right source code is the best to work with but I think there are many pros for just using the existing packet drivers as-is. It makes it easy for anybody to make any card work right out of the box. I don't think there's really a meaningful performance penalty from it is there? In any case, all of my code for this will be open-source. We can always tinker with it and see what we can do in the future.

                          I'm hoping to have something up for download before I go to bed tonight, or sometime tomorrow.
                          sigpic

                          Comment


                            #28
                            I haven't had as much time to work on it as I wanted, but now I've got the basics working and it can use a remote disk image as if were BIOS drive 80h. It doesn't do writes yet, only reads but I'm working on that right now. Here it is doing a boot, and it works fine on real hardware too. It worked the same on my XT. Should have something ready for people to download and play wiith pretty soon.



                            It's 100% hard-written assembly, and you can see there after reserving the RAM it needs there is still 624 KB free and that's with a packet driver that uses 8 KB.
                            Last edited by Mike Chambers; January 14, 2013, 01:15 PM.
                            sigpic

                            Comment


                              #29
                              Mike......

                              I love you.
                              "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

                              Comment


                                #30
                                Lol, thanks. I try!
                                sigpic

                                Comment

                                Working...
                                X