Agreed. This is really cool stuff. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Sep 13, 2008, at 12:08 PM, bfranchuk at jetnet.ab.ca wrote: Nah, IP stacks have been done with FAR less than a PDP-8. -Dave -- Dave McGuire Port Charlotte, FL

Maybe a pic has more computing power than a PDP-8? :o)

On 14 Sep 2008 at 1:20, Dave McGuire wrote: The PIC in question is an 18F4550, pretty fast, not much RAM, Harvard architecture, so an apples-to-apples comparison is a little difficult. Cheers, Chuck

On Sep 14, 2008, at 3:37 AM, bfranchuk at jetnet.ab.ca wrote: Where are you getting "128 words of RAM"?? -Dave -- Dave McGuire Port Charlotte, FL

Dave McGuire wrote: Uhm. Clocked at 8MHz, about 4 clocks per instruction, you're already firing instructions through at four times the speed. Also, you've got registers, rather than just AC and (maybe) MQ. I could probably *emulate* a PDP8 on a PIC. I'd prefer to do it on an AVR though. Gordon

My TCP/IP stack isn't very small either .. people have done TCP/IP in a much smaller space. This particular application takes 68KB on disk and 132KB total, including heap allocations. There is no UDP or DNS support compiled in, but I do have about 9KB of trace code compiled in. In the 132KB of space I'm able to support 10 online clients, each with a 2KB output buffer, a 512 byte receive buffer, and a few buffers (20 to 30KB) floating around for incoming and outgoing TCP transmissions. General features I do support: - ARP including caching a few entries - TCP sliding window, automatic retransmit, zero window probes, MSS negotiation, listen support, etc. - Enough UDP to implement DNS resolving and DHCP - A nice tracing mechanism that I can turn on and off via an environment variable or run-time variable, with selectable levels of tracing Big things I know I'm missing: - ICMP - it's on the todo list. - IP fragments. I don't take them, and I don't do them. Too expensive for a little machine, and pretty rarely needed on a TCP socket. So the memory requirements and function put it above uIP, but it's still small enough to cram into a low end 8088 class machine. Many people have run TCP/IP on much less hardware. I haven't looked at the uIP code, but the fact that Adam can run in on a C64 is enough to amaze me .. It's not as full featured, but it's there! Mike

Sorry for the spam, but I'm back running again. The address is still the same: 97.86.233.68 . It will be up and running until I get sick of it, so please keep checking back and trying to break it. Here is what I think happened on this first crash: - New incoming connection send a SYN packet - PCjr sends SYN & ACK response - No response so SYN & ACK gets retransmited - Other side resends their SYN packet - PCjr incorrectly responds with an ACK to let the other side know what the correct sequence number is supposed to be. (The connection is not established yet.) The storage used to send the ACK packet is on the stack, and there is a BIG comment saying 'make sure this never gets queued anywhere, or you will have a dangling pointer into the stack'. I don't think it was queued anywhere (that path is good), but I did corrupt the stack because my code saw a socket in SYN_RECVD sending a new outgoing packet, and it went and politely filled in the TCP options in that packet. Which had no space to hold them, and thus corrupted the stack .. That's what I think at least. I put a little debug code to catch it if it happens again, and I'll try to simulate the same thing happening later on. It took about 72 connections and 40000 packets in and out to break it. Time to start again. :-( Thanks, Mike

Michael -- Great work, I just telnetted from my Atari ST with an Ethernec interface attached, so one old piece of technology connecting to another :-) Curt Philip Pemberton wrote:

I ran it in ANSI mode, so it shouldn't (I hope) come up as anything weird or oddball. Curt Michael B. Brutman wrote:

Jules Richardson wrote: Testing plug: the PCjr is still running at 97.86.233.68 Testing exercises what the test writer expects to break. I've tested quite extensively already, but every once in a while I need to get outside help to try to break things in new and exciting ways. Between the cctalk mailing list and the vintage-computer.com web forum, I've got quite a bit of variety. And just like a good testing effort should, I was caught by something I didn't expect and and plan for .. trouble with retransmits and sequence numbers while negotiating a connection. I've paid so much attention to the common case (established connections) that it seems to work pretty well. The three way handshake code gets executed far less and I have less ability to break it (being on a local network), so it makes sense that the first serious bug was found there. Btw, everybody must have testing fatigue .. We're only up to about 50 connections since I fixed the suspected bug and restarted things. Feel free to telnet back in again with whatever you've got handy ... The address again is: 97.86.233.68 I'm seeing lots of what look like Windows clients and Xterms (Linux or Putty probably). Raw connections like Netcat or Putty in raw mode should work too, although you might see double echoing. Oddball telnet clients and machines would be appreciated too. Mike

Michael B. Brutman wrote: Sure - I suppose I've just surprised that there isn't already something in the public domain that can't flood a system, generate bogus/corrupt packets etc. in order to test a stack out; it still wouldn't catch all bugs of course, but might give a faster response to most problems than asking the list. I'm recovering from Saturday night... :) Anyway, on the telnet interface side it'd be nice if the system kept track of nicks and didn't allow a nick that was already in use, and if messages could be sent to a nick rather than a session number (similarly if received messages showed the nick that sent them, rather than the session number). But that's all "UI stuff" rather than fundamental issues with the server itself... I did try breaking it by sending huge amounts of data or odd control sequences and so far it seems to be holding up well. Yeah, telnetting from a GUI shell in linux gives me a type of 'xterm', but telnetting outside of X just shows a type of 'linux'. Oh, what is the deal with backspace/delete? Backspace does nothing, whilst delete echos some form of control code to the screen. ctrl-H seems to work as the erase character, though (and genuinely does erase from the string that gets sent to the server upon <return>). Is the PCjr doing something non-standard with the handling of such keys, or is it just that other telnet servers generally hack such keypress processing to accommodate modern clients? cheers Jules

At 11:56 AM 9/14/2008, Jules Richardson wrote: I've used IP Stack Integrity Checker. http://www.packetfactory.net/Projects/ISIC/ -Rick

Part of the problem is that the specs for things like backspace are for *output*. Overloading them on input for things like line editing is somewhat outside the design envelope for them, so it's hardly surprising that the specs are silent. As far as I can tell, the only spec for what characters should do what in an input line editor is user expectations. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 14 Sep 2008 at 11:49, Michael B. Brutman wrote: Depends on the vintage of the implementation. BS originally was just that--move the current printing/display position one back, erasing nothing. 127 (Rubout/ASCII DEL) was used as a delete character because it punched all the holes in a tape and was ignored on printing as a fill character. (Many of us can still remember editing paper tape using rubouts to delete previously punched characters). The non-erasing interpretation of BS came as a surprise to me when writing early text CRT terminal firmware. To form various international characters, the client could send out the character for an ogonek, then a BS, then, say, an A. The firmware had to display the ogonek, move the cursor back a space, then combine the ogonek with the A and display the ogonek-inflected-A. The reverse sequence (A-BS-ogonek) also had to be honored. The purpose of this was to be compatible with earlier printing terminals. WikiP has the following on BS: "The ambiguity surrounding Backspace comes from mismatches between the intent of the human or software transmitting the Backspace and the interpretation by the software receiving it. If the transmitter expects Backspace to erase the previous character and the receiver expects Delete to be used to erase the previous character, many receivers will echo the Backspace as "^H", just as they would echo any other uninterpreted control character. (A similar mismatch in the other direction may yield Delete displayed as "^?".)" So, it's your posion. I've used telnet servers that insist on RO to erase characters and print ^H when backspace is received. OTOH, the current Linux telnet server treats BS and DEL identically--and if I were in your shoes, I'd do the same. Cheers, Chuck

On Sep 14, 2008, at 10:49 PM, Sean Conner wrote: That has nothing at all to do with the kernel; it's in the terminal driver. You can control all of those special character interpretations using stty. You can make the "erase" character anything you want, even a regular alpha character, like 'X': $ stty erase X -Dave -- Dave McGuire Port Charlotte, FL

On Sep 15, 2008, at 12:47 PM, der Mouse wrote: Hmm, now that you mention it, I suppose it is. [dave slinks away and goes back to sleep] -Dave -- Dave McGuire Port Charlotte, FL

After close to 3.5 days of run time I finally shut the PCjr down. Here are the raw stats: 685 sessions (of which about 370 were generated by a script) TCP packets sent: 93204 TCP packets received: 87367 TCP packets retransmitted: 414 TCP packets dropped due to low buffer space: None Raw packets sent: 93789 Raw packets received: 92458 Raw packets dropped due to low buffer space: 24 The first part of the test started Friday night, and the machine crashed early on Saturday afternoon. That was the stack corruption bug exposed by the failed connection attempt with the SYN packets being retransmitted. I had about 70 connections and 40 or 50,000 packets in and out before the crash. After a quick debug session and some new code I started the test again. The statistics reflect the activity after the restart. The rate of retransmitted packets is very low, which is good. About one half of one percent of packets (or 1 in 200) needed to be retransmitted. This often occurs when the remote connection drops - my code might try to send a packet, retransmit the packet because there is no response, and then eventually give up. It's also possible that packets were being dropped along the way depending on routers and traffic. The 'Raw packet' numbers refer to the packet driver. All 24 packets were lost in a 15 minute period while Chuck G. was on the machine experimenting with OS/2 Warp clients. I don't know what caused the hiccup, but it was brutal. Nothing crashed though, and no active sessions were prematurely lost as a result although a few of his sessions seemed to be hung. (I need to find the spot in the very large tcpdump trace where that happened.) Here are some of the gripes: - Backspace (ASCII 8 ) vs. DEL (ASCII 127) - I probably need to accept both - User interface issues - sorry, this is a test of my TCP code .. I put the bare minimum up to get it going. - Some lag time .. depending on your geographic location it could be very bad. Not much I can do here, except let the code negotiate line mode. Now on the other hand, I think that everybody who commented on it thought it was the coolest thing. Which really made me feel pretty good about my on and off again three year investment in the TCP/IP code. I even traded wisecracks with a certain collector who's name starts with an S who was completely blown away by the power and might of the Jr. He thought it was a Cray. I corrected him, and let him know that I use the Cray strictly as a firewall. ;-0 I'm going to be reading logs and looking for problems in the traces the next few weeks, and possibly fix a few bugs. I'm also still debating in my head whether the world needs a another Telnet BBS. It's a fun project and it might be worth doing on a small scale, but a big full featured Telnet BBS is a lot of work. If I do it, I've already started thinking about how to cluster a few Jrs to increase the total number of concurrent online users. Thanks for all of the help testing it. Regards, Mike

On Tue, 2008-09-16 at 22:42 -0700, Chuck Guzis wrote: I'd give it a go if I could find a copy. Where can I get it? Gordon

At 10:36 AM -0400 9/17/08, madodel wrote: I know Warp Connect only supports a *very* limited number of NIC's. Finding one that is supported was my biggest challenge, and I was pulling from a large pool of NIC's. Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh at aracnet.com (primary) | OpenVMS Enthusiast | | MONK::HEALYZH (DECnet) | Classic Computer Collector | +----------------------------------+----------------------------+ | Empire of the Petal Throne and Traveller Role Playing, | | PDP-10 Emulation and Zane's Computer Museum. | | http://www.aracnet.com/~healyzh/ |

Ethan> Back when NIC weren't $10 each, I remember the easiest to work Ethan> with (in terms of compatibility) were the NE2000 and clones Ethan> (NE1000 for 8-bit machines), the WD (later SMC) 8013, and the Ethan> 3C501, later displaced by the 3C509. ... Something to keep in mind is that the 3C501 is an extremely bad design. It is completely incapable of dealing with back to back packets -- even just two of them. And of course that's a perfectly normal situation in any plausible network. I remember working on DECnet when these toys came around, and the request came in to have a "go slow" feature in DECnet to support this single buffered design. The answer, of course, was "NFW". (Slowing down at the source wouldn't have helped because the network could easily cause clumping anyway...) paul

I assume you are talking about "Galactic Civilizations II." The company that made it still exists (Stardock), and has made newer verstions "Galactic Civilizations," "Galactic Civilizations: Altarian Conquest" and "Galactic Civilizations II", but you'll need Windows 2000 or later to run them.

My favorite two games are still the Macintosh versions of the original "Master of Orion" and "Warlords II". Unlike the PC versions, the Mac versions aren't limited to 640x480. They'll go up to something like 1024x768 or maybe a bit larger (they won't go up to 1280x1024). Still "Galactic Civilisations" is a close third. Zane

Actually it was just the original "Galactic Civilizations". I think it was Galactic Civilizations II I bought for my Core 2 Duo/WinXP Pro game machine last year, but found it to be horribly buggy. :^( Zane

Zane H. Healy wrote: Warp 4 is a bit better in that regard. Peace... Sridhar

Zane H. Healy schrieb: Provided the machine is not so old to have something like PCI, you can meanwhile use many modern ETH cards with OS/2. For 2.0 and 2.1, you need the separate TCP/IP product (including LAPS), and the normal ETH drivers for Warp Connect, Warp 4 and eComstation will usually still work. The mentioned "demo" version of Warp 4 can help to obtain the missing stuff. In the past when I worked on XFree86/OS2, I had more than once mixed drivers between different OS/2 versions - it was extremely compatible. -- Holger

Gordon J. C. Pearce (MM3YEQ) wrote: If you're just interested in tinkering, you can get an ISO of a LiveCD of Warp 4 here: http://www.ecomstation.com/demo.phtml I just tried it with an older HP P3 ePC box and it booted right up with network support without a hitch. Cheers, Chuck

On Sep 15, 2008, at 3:40 PM, Sean Conner wrote: Yeah, I was tired and hip-deep in pthreads code when I wrote that, trying to debug a process containing some ninety threads. My brain was fried. I set *everything* to use DEL by default...makes life much easier. -Dave -- Dave McGuire Port Charlotte, FL

Jules - There are lots of solutions for automating software testing out there. I built in a past life a system (Hammer Technologies' Hammer) for beating on voicemail systems over the telephone network so that these systems could be load tested without 150 humans calling in at one time (and believe me we did live tests in the early days on voicemail systems just like that!!!). Even patented a speech recognition approach to make sure the voicemail systems were responding properly. Similarly there are software systems that will duplicate any specified series of actions that a human (or computer) might take in order to simulate a user and (in most cases) record the results. This of course only measures the "outsiders'" view of what is going on, and doesn't look at the internals of the stack or anything else. But it does make for a useful tool to evaluate remotely whether something is still running. Many of the large financial services companies with complex financial software running for their customers use similar systems today to monitor their uptime and catch problems before they affect too many users. I've been out of it way too long to know who is current with the best solutions, but companies like Empirix.com (where my company Hammer Technologies eventually ended up) do similar things today. There have got to be some shareware systems somewhere that do this. Anyone running a UNIX box out there ought to be able to write a shell script to test Mike's setup and record the responses. It will be easier when a "pcjr>" response prompt is implemented so that there is a real response to check on the way back...otherwise the user is forced to just wait and then type a command that should return something like "help" or "nicks" John Kuenzig Jules Richardson wrote:

For free - Viewsonic 19" XVGA Color Monitor, Black - Model # E90fB http://www1.viewsonic.com/products/archive/e90fb.htm Barely used, bought it for a project that I never pursued, in the middle of Spring Cleaning and I would like to get it out of my office as its been sitting on the floor in the corner for quite sometime collecting dust. Anyone who wants it and is local and can pick it up, please contact me offlist to make arrangements. Curt