• Please review our updated Terms and Rules here

IRCjr (Was: Another DOS IRC Client)

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,417
The other thread got too cluttered. I closed it so there will be no more replies, but it is still around for reference.

The name is now IRCjr - not terribly creative, but it will work. Here is the web page that describes the details:



Most of you have not seen it yet, so here is a screen shot:

IRCjr_screenshot2.gif


If anybody is interested in an IRC client for their older machines, give it a try. It is not as full featured as LeetIRC or other clients, but it is small, fast even on 8088 hardware, easy to setup, and it has the basics. It will also help me exercise the TCP/IP code, which I wrote entirely from scratch.

-Mike
 
Last edited:
yeah, i've tested all of mike b's releases as they come out and they are nice and sleek. will be fast on any computer, unlike the current v1.1 of leetIRC :)

wait until v1.2 which will be out very soon. it will be very useable on 8088's due to completely rewritten screen write routines!

IRCjr is nice though, he has a backscroll buffer and everything! highly reccommended.
 
mbbrutman said:
If anybody is interested in an IRC client for their older machines, give it a try. It is not as full featured as LeetIRC or other clients, but it is small, fast even on 8088 hardware, easy to setup, and it has the basics. It will also help me exercise the TCP/IP code, which I wrote entirely from scratch.
Click to expand...

New version works perfectly, btw.

However, docs say it requires 140KB free memory... it actually requires 152KB ;-) But why so much?

BTW you can add "Intel Etherexpress 8/16 (in 8-bit mode)" to the list of tested cards.
 
Trixter said:
New version works perfectly, btw.

However, docs say it requires 140KB free memory... it actually requires 152KB ;-) But why so much?

BTW you can add "Intel Etherexpress 8/16 (in 8-bit mode)" to the list of tested cards.
Click to expand...

that is a fantastic network card, i have one too. i keep that one my "XT-TURBO" box, and my other 8088 has a 3com 3C503 (the one that's currently running my IRC server). my 286 has a weird NE1000 compatible card that doesn't really have much identification on it. just says "EN-1000-10BT"

do you think there would be any performance gain from sticking the 8/16 in the 286, and putting the EN-1000-10BT (old ass 8-bit card, early/mid eighties) in the XT-TURBO? i mean as far as the 286 goes, actually putting a 16-bit card in it...

that said, mike i guess you can also put the 3C503 and EN-1000-10BT on the list of tested cards as well.
 
Jim - just curious, how did you measure? And how much of a backscroll buffer did you use? (The default is 200 lines if you didn't override it.)
 
mbbrutman said:
Jim - just curious, how did you measure? And how much of a backscroll buffer did you use? (The default is 200 lines if you didn't override it.)
Click to expand...

loadhi.com /gs ircjr, which we've covered in email. I used the default 200 lines, which is 32K. So 160-32=128KB, still a bit big for the program. Maybe Turbo C's linker isn't very good?
 
It was an estimate .. here is what I can account for with the default backscroll buffer.

[*] 76KB for the executable
[*] 30KB for incoming buffer space for Ethernet packets (probably overkill)
[*] 10KB for the TCP/IP socket buffer (probably overkill)
[*] 8KB for outgoing buffer space for Ethernet packets (probably overkill)
[*] 2KB for an internal buffer used to parse messages
[*] 35K for the backscroll buffer (it's actually 200 + 21 lines)

That adds up to 161K. There is some slop in there because the stack and some global vars are not accounted for.
 
mbbrutman said:
It was an estimate .. here is what I can account for with the default backscroll buffer.

[*] 76KB for the executable
[*] 30KB for incoming buffer space for Ethernet packets (probably overkill)
[*] 10KB for the TCP/IP socket buffer (probably overkill)
[*] 8KB for outgoing buffer space for Ethernet packets (probably overkill)
[*] 2KB for an internal buffer used to parse messages
[*] 35K for the backscroll buffer (it's actually 200 + 21 lines)

That adds up to 161K. There is some slop in there because the stack and some global vars are not accounted for.
Click to expand...

Everything in there I can totally understand except the 76K for the executable :)
 
Full ARP, IP, TCP, UDP, a DNS resolver, C runtime and a tracing facility in 76K. (The tracing facility is abou 11KB alone - you've seen the output from it, quality isn't cheap.)

Oh, and it's fast too. Not like the smaller TCP implementations which are minimal in size, but also are non-conformant to the RFC in many ways with terrible performance.

I'm still trying to recreate the 'Abnormal Termination Bug'. If I catch it with tcpdump and my logging, I'll be able to find what causes it.
 
I'm still trying to recreate the 'Abnormal Termination Bug'. If I catch it with tcpdump and my logging, I'll be able to find what causes it.
Click to expand...

Jim gets the first bug award ...

Found it, recreated it, and fixed it. It was in the screen handling code .. the right string of chars coming across the channel could cause it to bomb. A simple mistake on my part, but sometime it took hours for it to happen.

BTW, new memory consumption stats for this version:

Without backscroll buffer: 118KB.
With backscroll buffer: 152KB​

I put it on a little diet for you .. all of the same function is there though. :)
 
nice! if you can trim down the memory use just a little more i'll be able to run it on the toaster.
 
mbbrutman said:
Jim gets the first bug award ...

Found it, recreated it, and fixed it. It was in the screen handling code .. the right string of chars coming across the channel could cause it to bomb. A simple mistake on my part, but sometime it took hours for it to happen.

BTW, new memory consumption stats for this version:

Without backscroll buffer: 118KB.
With backscroll buffer: 152KB​

I put it on a little diet for you .. all of the same function is there though. :)
Click to expand...

Yay! I still think that's a bit high but I'm going to blame your compiler (actually, your linker and runtime libs). That's very very cool. The next time I drag the XT to a demoparty, I'll leave it running in the channel with this thing :)

BTW what are the numbers that your snow handling code takes, and what do they do? ie. how is snow-handling... handled?
 
If you want to play with the CGA snow settings set the optional IRC_SNOW environment variable to a number from 0 to 8. 0 is 'no snow', while 8 is 'blizzard'. 3 or 4 is a good setting.

If you really want to see something horrible, forget the IRC_SNOW environment variable and set IRC_USEBIOS to anything. That uses the BIOS of the machine instead of doing memory manipulation. It is horrible .. you can trace the cursor with your finger.

I still don't think that 76KB for ARP, IP, UDP, TCP, a DNS resolver, the string parsing required for IRC, the screen handling code, and an extensive trace facility is bad. I'm quite sure that the linker pulls in only referenced routines - the entire C runtime is definitely not in there. I also managed to skip the floating point libraries, because they bloat things quite a bit. The DNS resolver is a fairly heavy piece of code because of all of the parsing and pointer chasing it has to do in the response from the server.

If you want a really small TCP/IP stack, take a look at http://www.sics.se/~adam/uip/index.php/Main_Page . They've cut some corners, but they wedged it into a very small amount of code. They don't implement the sliding window, they don't automatically retransmit packets, etc.
 
linkers are for newbies. i connect a phone to the modem, scream into the receiver, and have it log to a .EXE file. pfft source code. pleeeease...:rolleyes:
 
I think I've got that bug nailed. Here is a screenshot of IRCjr running on DOSBox:

IRCjr_screenshot12.gif


Note the uptime: 2.4 days, and over 50,000 TCP/IP packets in an out. :)
 
mbbrutman said:
If you want to play with the CGA snow settings set the optional IRC_SNOW environment variable to a number from 0 to 8. 0 is 'no snow', while 8 is 'blizzard'. 3 or 4 is a good setting.
Click to expand...

Right, but how is it implemented? Is the number the size of the transfer while retrace is in progress or something?
 
The general algorithm is this:

- Check if in retrace. (I don't bother waiting for a new retrace interval to start.)
- Copy n number of lines (160 bytes each) while in retrace.

I could have done more, but this works well enough. I didn't implement it for backscrolling - only the normal scrolling of incoming messages is covered.
 
mbbrutman said:
The general algorithm is this:

- Check if in retrace. (I don't bother waiting for a new retrace interval to start.)
- Copy n number of lines (160 bytes each) while in retrace.
Click to expand...

You really should, because otherwise your code does not work as advertised. This explains why *no* value eliminates snow for me. You should be doing this:

Wait until retrace is not in progress
Wait until retrace *IS* in progress

Code is this:

Code: 
  mov   bl,8    {c_vertical_sync}
  MOV   DX,3DAh {m6845_status}
@WDR:           {wait during retrace, because we don't know where we are in the cycle}
  in    AL,DX
  test  AL,BL   {if our bit is 1, then we're in retrace}
  jnz   @WDR    {jump if 1 (not 0) = keep looping as long as we're retracing}
@WDD:           {wait for display to be over}
  in    AL,DX
  test  AL,BL
  jz    @WDD    {loop until we *are* retracing vertically}

...because otherwise there is no number I can use that completely eliminates snow. Even '0' shows snow.
 
I might go all the way in another version, but right now it's good enough. There are other things on the todo list that are higher priority.
 
You must log in or register to reply here.
Back
Top