making DOS IRC client

[Mike Chambers]

i decided to completely rewrite the IRC client for DOS i've been working on from scratch, so that i can optimize it's performance as much as possible so it is not unbearable to use even on an original 8088 PC.

i am going to use interrupt calls for screen writes rather than the PRINT command. PRINT is definately fast enough for 386+ machines, but if it's older it can be so slow that you can literally watch it draw the characters.

i'm also going to add mouse support for the drop down menus and option screens. i am also going to have it use XMS memory for backbuffer scrolling since quickbasic on it's own is very memory-limited... 64 KB i believe? something like that...

i know most original PC's don't have any XMS memory, so in that case i will allow it to use a virtual memory file in case you still want to be able to scroll. you will also be able to disable scrolling if you want, because i know 8088 + constant disk reads and writes on an old MFM drive or floppy can be quite.... frustrating performance wise.

i should have it completed enough to release a beta version within a few days, or maybe by next weekend. i hope some of you could use a decent IRC client for DOS, because i know all the ones out there now are pretty much complete crap.

i also plan to add mirc color/bold support, and DCC file transfers. i'll update you all soon about this program.

don't ever let anybody tell you quickbasic is dead.

 

[fxg]

Good ideea; I'll give it a shot, just post the download link

 

[mbbrutman]

Before you go too nutty, put WATTCP and an old FTP program that works with it on an XT and try it. The point of the exercise is to figure out the maximum throughput rate on a bulk data transfer. If you want to be really fancy, read and write the files to a ram disk to avoid the overhead of the disk.

Once you know what the TCP/IP stack can do, then you can get a better idea of your maximum performance.

I think you are going to be sorely dissappointed with the BIOS interrupts to write the screen. If you disassemble your Quickbasic code you will probably see that it is using BIOS interrupts too. Try a simple benchmark doing it both ways to see if there is really a difference before rewriting things. The only way to really make an old machine scream is to start pounding things into B800 (CGA) or B000 (Mono) directly, which is bad for things that are not strictly CGA or Mono.

Most older machines are at least 512K, so you don't really need to use XMS or a file to store a backscroll buffer. 500 lines of backscroll is only 40KB at most, unless you start storing color and other attributes as well. Avoid disk access like the plague .. even on a hard disk.

Lastly, if you are going to think about making it fly on an 8088 here are some tips:

- Use small data types. If you can fit a loop counter in a single byte, use that instead of a 16 bit data type. 8088s only fetch a byte at a time anyway.

- If you use a 16 bit data type then get it aligned on a 16 bit boundary. The 8088 won't care, but 8086s, 286s, etc. will be happier.

- The TCP stack will do some buffering for you, but don't forget to check for incoming data. Dropping packets because you ran out of buffer space will crush your socket performance.

- Lastly, remember KISS: KEEP IT SIMPLE! (I leave the last word out to avoid insulting anyone ..)

 

[Mike Chambers]

Before you go too nutty, put WATTCP and an old FTP program that works with it on an XT and try it. The point of the exercise is to figure out the maximum throughput rate on a bulk data transfer. If you want to be really fancy, read and write the files to a ram disk to avoid the overhead of the disk.

Once you know what the TCP/IP stack can do, then you can get a better idea of your maximum performance.

I think you are going to be sorely dissappointed with the BIOS interrupts to write the screen. If you disassemble your Quickbasic code you will probably see that it is using BIOS interrupts too. Try a simple benchmark doing it both ways to see if there is really a difference before rewriting things. The only way to really make an old machine scream is to start pounding things into B800 (CGA) or B000 (Mono) directly, which is bad for things that are not strictly CGA or Mono.

Most older machines are at least 512K, so you don't really need to use XMS or a file to store a backscroll buffer. 500 lines of backscroll is only 40KB at most, unless you start storing color and other attributes as well. Avoid disk access like the plague .. even on a hard disk.

Lastly, if you are going to think about making it fly on an 8088 here are some tips:

- Use small data types. If you can fit a loop counter in a single byte, use that instead of a 16 bit data type. 8088s only fetch a byte at a time anyway.

- If you use a 16 bit data type then get it aligned on a 16 bit boundary. The 8088 won't care, but 8086s, 286s, etc. will be happier.

- The TCP stack will do some buffering for you, but don't forget to check for incoming data. Dropping packets because you ran out of buffer space will crush your socket performance.

- Lastly, remember KISS: KEEP IT SIMPLE! (I leave the last word out to avoid insulting anyone ..)

thanks for the tips. i really can't try anything out on my 8088 at the moment, because the only 8-bit ISA drive controller i had went bad somehow recently. it just no longer works in any computer i try it on.

on the 8088 system that i have, when it boots it gives you a list of all the cards you have in it and "Disk controller" no longer shows up

it still shows my other cards, it says "Network card" and "VGA card"

would you happen to know of a place that i can get a new drive controller dirt cheap? i've seen a few on ebay but they are ridiculously expensive... i can't afford to spend much more than $10 or so.

i'd really prefer an IDE controller if possible, but i know those are rare/expensive. MFM would work, as i do have a 48 MB Seagate MFM drive in my 386. I was going to take it out of there anyway as soon as my new 16-bit IDE multi-I/O controller comes in the mail. (should be any day now)

it would be great if i could find one with a 1.44 MB floppy controller on it. i could get a 360 KB controller really really cheap, but i don't have any compatible drives and i don't really want one. thats way too restrictive on capacity.

 

[mbbrutman]

What 8088 system do you have that tells you what's plugged in? Are you talking about the messages from each device that get printed after the initial portion of the boot is done but before it tries to go to floppy?

My 8088 class systems generally don't have hard drives, and I've given up trying. The problem is that if you get a classic MFM controller then you need to find a classic MFM hard drive. Given those drives are pushing 20 years old or more, getting something that you can use on a regular basis is unrealistic. The life expectancy for a hard disk was 5 years, not 20.

On my older systems if I need more storage than the floppies provide I use a parallel port-to-SCSI adapter and a more modern SCSI drive. Zip drives also work on old iron, and parallel port-to-IDE adapters should work fine as well. Very old standard parallel ports can be upgrade to be PS/2 bi-directional with just two trace cuts and a jumper wire, and that helps a lot on the parallel port attached devices.

You can try to find 8 bit IDE cards and 8 bit SCSI cards, but as you found out already they aint cheap. The 8 bit IDE cards are potentially problematic because not all IDE drives will work on them.

Do your development work on a better machine, and move the code over using a floppy when it comes time to test. Your code isn't more than 100K in size, right?

 

[Mike Chambers]

What 8088 system do you have that tells you what's plugged in? Are you talking about the messages from each device that get printed after the initial portion of the boot is done but before it tries to go to floppy?

My 8088 class systems generally don't have hard drives, and I've given up trying. The problem is that if you get a classic MFM controller then you need to find a classic MFM hard drive. Given those drives are pushing 20 years old or more, getting something that you can use on a regular basis is unrealistic. The life expectancy for a hard disk was 5 years, not 20.

On my older systems if I need more storage than the floppies provide I use a parallel port-to-SCSI adapter and a more modern SCSI drive. Zip drives also work on old iron, and parallel port-to-IDE adapters should work fine as well. Very old standard parallel ports can be upgrade to be PS/2 bi-directional with just two trace cuts and a jumper wire, and that helps a lot on the parallel port attached devices.

You can try to find 8 bit IDE cards and 8 bit SCSI cards, but as you found out already they aint cheap. The 8 bit IDE cards are potentially problematic because not all IDE drives will work on them.

Do your development work on a better machine, and move the code over using a floppy when it comes time to test. Your code isn't more than 100K in size, right?

yeah, that's exactly when it tells you whats plugged in.

you know, my grandfather has one of those iomega zip drives he used to use some years ago back when he still had a 486. used it for backup. i'm sure he would have no problem letting me use it, since its been sitting untouched in his closet for at least 5 years. i recall it had a parallel connector.

i suppose i could get one of those cheap 360 KB floppy controllers and a compatible drive couldn't cost too much i would think. i'm going to look into that. is it possible to modify a 1.2 MB 5-1/4" drive to work with a 360 KB controller? i still have a working one.

as for working on this program, yeah i've been developing it right here on my athlon 64 running XP x64. since microsoft's 64-bit OSes have no support for 16-bit code, i am working on this IRC client inside of a VMware guest OS where i installed DOS 6.22 and download crynwr's AMD PCnet packet driver.

sometimes when i'm not sure about the performance of some of my code on older systems, i'll compile what i have and run it on my 12 MHz 286.

 

[Mike Chambers]

i've not been working on it as much as i should.... but if you want to get a feel for what it will likely resemble, heres an old client i wrote last year

its for the DOS command prompt, but it only runs under windows sorry. you cant use this on your ancient machines.

but my new client will somewhat resemble this, but with WAY more features... and much more optimized code and a cleaner interface

i had written it because somebody i chatted with in IRC told me that i could not make a good IRC client for the command prompt. i dont think its fantastic, but i proved some random internet guy wrong becuase i had nothing better to do... i am a total winner.

http://retrobox.scieron.com/cpirc

 

[Mike Chambers]

just so show that i'm still alive and working on this... here's a screen shot from what i'm working on...

i plan to let you guys try a test release of this by monday :D

in case anybody is wondering why i have it say "DOS type detected" after it finds the wattcp tsr... you're probably thinking "well no crap it's DOS type"

the reason i have that is because i plan to integrate winsock access into it also, in case you want to use it under windows. if it can't detect wattcp i am going to have it search for a winsock layer... cool eh?