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

  • archeocomp
    replied
    Hi folks. Will 16bit ISA cards work as well ? Something like this ? I have no experience with network cards.
    http://www.xy100x.howto.cz/karty/05.JPG

    Leave a comment:


  • mbbrutman
    replied
    Originally posted by eeguru View Post
    Yes but soft-filtering every-frame on an XT makes me shudder - even at 10Mbps. With a single frame address, you could certainly filter on the image server address first - passing everything that doesn't match. However it would be nice to find a clever way of differentiating virtual drive frames from everything without having to peer too far into the payload. A multicast address works assuming the NIC has a hash based filter table. Without an IGMP join, it should be harmless enough on most networks with non-IGMP aware switches. Overloading one of the frame protocol enumerations works too.
    I'm not sure how compliant most of the hardware is with respect to multi-cast. We're talking about hardware that is 20 to 25 years old in some cases.

    Peeking at the payload is not a big deal. The packet driver interface that uses two interrupts for each packet received is the problem. (And one to send too!)

    Leave a comment:


  • Mike Chambers
    replied
    Originally posted by mbbrutman View Post
    A lot of the older NICs handle promiscuous mode just fine. There is usually a packet driver option to enable or disable it.

    One way to do it is to simply only call the INT13 packet receiver routine when an interesting packet arrives. (Presumably that would be done by the ethernet packet type.) This can be done by putting a "shim" receiver ahead of any other receiver, and let the shim decide how to forward it on.

    (A poor mans TCPDUMP that works transparently with any packet driver application would work like that. It would look like a shim, presenting a packet driver interface to the application code while filtering anything coming from the real packet driver.)
    Exactly, Mike.

    eeguru: you'd be surprised, there wouldn't really be any noticeable performance hit. I am already examining/comparing the ethertype of every single packet already and simply discarding the ones that don't match the one for NetDrive. The only difference would be passing it along to any user programs that ask for them.

    Leave a comment:


  • eeguru
    replied
    Originally posted by mbbrutman View Post
    A lot of the older NICs handle promiscuous mode just fine. There is usually a packet driver option to enable or disable it.
    Yes but soft-filtering every-frame on an XT makes me shudder - even at 10Mbps. With a single frame address, you could certainly filter on the image server address first - passing everything that doesn't match. However it would be nice to find a clever way of differentiating virtual drive frames from everything without having to peer too far into the payload. A multicast address works assuming the NIC has a hash based filter table. Without an IGMP join, it should be harmless enough on most networks with non-IGMP aware switches. Overloading one of the frame protocol enumerations works too.

    Leave a comment:


  • mbbrutman
    replied
    A lot of the older NICs handle promiscuous mode just fine. There is usually a packet driver option to enable or disable it.

    One way to do it is to simply only call the INT13 packet receiver routine when an interesting packet arrives. (Presumably that would be done by the ethernet packet type.) This can be done by putting a "shim" receiver ahead of any other receiver, and let the shim decide how to forward it on.

    (A poor mans TCPDUMP that works transparently with any packet driver application would work like that. It would look like a shim, presenting a packet driver interface to the application code while filtering anything coming from the real packet driver.)

    Leave a comment:


  • eeguru
    replied
    Originally posted by Mike Chambers View Post
    Yeah, I did it so fast because this is something I've been meaning to create for years anyway!

    If you guys go to the vintage programming subforum, I just created a new thread in there calling for NetDrive testers! And yes, eeguru network card sharing has been one of my goals from the beginning. It doesn't do it yet, but it will soon. Sharing the packet driver with other software tranparently should be straight-forward enough to do.
    What would be the best way to accomplish that? Two separate MAC addresses would be ideal - one for the virtual disk, one for user. However most NICs won't support that non-promiscuously unless you overloaded a multicast address or something. So how would you decide which frames are destined for the virtual drive code and which are for the user?

    Leave a comment:


  • Mike Chambers
    replied
    Cool, let me know how it works when you get a chance!

    I was thinking about using a ROM a little bit. It would still require reserving a bit of conventional memory, but yes that would be way more convenient. Problem is that the only EEPROM burning capability I have here at home is with some 8 KB chips. I don't even have a "proper" EEPROM writer. I do it full hobo-style. I took an old LBA BIOS extension card made by DTC, took it's ROM off since I didn't use it for anything, soldered a few connections on the bottom to connect the write enable pin on the ROM socket.

    I would need a way to work with larger ones. My resident driver is 6 KB on it's own, so it wouldn't leave nearly enough room for a packet driver to fit on there with it. Maybe somebody else out there in vintage computerland would be willing to mod it for ROM use. We should probably move further discussion over to my thread in the programming section.

    Leave a comment:


  • ibmapc
    replied
    Hey Mike,
    This looks AMAZING! I'll be testing it later today! Is there any way to make this work with a Boot Rom on a NIC so that the floppy would not be needed?

    Leave a comment:


  • Mike Chambers
    replied
    Yeah, I did it so fast because this is something I've been meaning to create for years anyway!

    If you guys go to the vintage programming subforum, I just created a new thread in there calling for NetDrive testers! And yes, eeguru network card sharing has been one of my goals from the beginning. It doesn't do it yet, but it will soon. Sharing the packet driver with other software tranparently should be straight-forward enough to do.

    Leave a comment:


  • eeguru
    replied
    Hatta,

    It allows you to take a well behaved DOS packet driver for the Ethernet card you have and create and burn a boot ROM image that will emulate a hard drive (C by reading and writing an image file over the network from a modern server. Initially you would not be able to use the network card for providing anything other than just the virtual drive C: (eg. you could not then run a Doom net game with your friends without a second NIC). However I suspect some sort of driver sharing could be worked out in the future even if it means encapsulating the payload of a second DOS loaded tunneling packet driver over the emulation protocol.

    The other caveat is it is a frame based protocol only. Thus it isn't routable at an IP level. Both the server and vintage PC must be on the same Ethernet segment.

    Leave a comment:


  • Hatta
    replied
    I didn't quite follow the entire thread, as it was very technical. Does this allow the ethernet card to be shared with other software?

    Very nice work either way.

    Leave a comment:


  • Tor
    replied
    So, in approximately two weeks since pearce_jj came out with the idea of ATAoE Mike already has a working solution? Now that is impressive! And I really like the concept of booting/using a remote 'virtual' disk, liked the idea from the start. I just didn't think it would happen so fast.

    -Tor

    Leave a comment:


  • tingo
    replied
    Impressive - and progress is too. Nice!

    Leave a comment:


  • pearce_jj
    replied
    Your 'workshop' looks as well organised as mine Seriously though, this is GREAT.

    Leave a comment:


  • Mike Chambers
    replied
    Just want to say I've got the write functionality working too. I will try to upload something tonight, I want to add a boot menu and polish up some rough edges first.

    Leave a comment:

Working...
X