• Please review our updated Terms and Rules here

would anybody like to test this for me?

M

Mike Chambers

Veteran Member
Joined
Sep 2, 2006
Messages
2,621
i compiled what i have so far of my IRC client. it doesn't connect to servers yet but i got most of the user interface done... a couple more things i need to do with that and then i'll start working on the actual IRC routines, and connecting to servers.

the reason i compiled just what i have now is that i was wondering if somebody here who has a functional 8088 machine would test this for me, and let me know how fast it runs on it? i'm mostly wondering about the speed of the text being drawn during screen updates. i can't use my 8088 because i dont have an 8-bit floppy or hard drive controller for it.

it SHOULD be okay i would think, because i am using a routine from a QB library called cosmox that has a nice routine for copying data directly from one memory pointer to another. i am pretty sure this would be the fastest way to do screen writes.

i'm linking to a ZIP with the compiled binary(virus-free, i promise!) along with the source. if you wanna mess with the source you're going to need quickbasic 4.5

i also keep running into this one major bug that i can't seem to fix. if you run the program from inside of QB45 using the interpreter, the mouse works perfectly... for some reason, the mouse does not work in the compiled EXE. i'm sure it's something really obvious that i'm overlooking, but if anybody happens to figure out what the deal is with that please let me know. thanks!

(note: when you're running the program, you can use alt+q as a quick way to exit it)

http://rubbermallet.org/leetirc.zip
 
Does this need to have the packet driver and the WATTCP TSR running? If so, where do I find the WATTCP TSR?

On my PC XT it is slow, and it locks up the machine after pressing the space bar to get rid of the first diaglog. The lockup might be due to my not having the WATTCP TSR loaded.

Also, based on your previous thread, the top line with the menu options is missing. My screen started with '[STATUS]' or something similar to that.
 
mbbrutman said:
Does this need to have the packet driver and the WATTCP TSR running? If so, where do I find the WATTCP TSR?

On my PC XT it is slow, and it locks up the machine after pressing the space bar to get rid of the first diaglog. The lockup might be due to my not having the WATTCP TSR loaded.

Also, based on your previous thread, the top line with the menu options is missing. My screen started with '[STATUS]' or something similar to that.
Click to expand...

hmmm... no you shouldn't need the TSR actually running. if it is not active it just should say it's not detected.

and about the menu line, is the video card on that thing standard 80x25 in text mode? also, is it a color card or mono?

EDIT: here's a link to wattcp, just in case that is whats causing it to hang. http://rubbermallet.org/WATTCP.EXE
 
i actually think i know why it's locking up on your XT... it's not because of the absent wattcp tsr. that machine has a mono video card, correct?

after the initial dialog box is cleared, the program starts doing direct memory writes to the text mode memory segment @ &HB800

i never had an original mono card, but i am assuming it's text memory begins at a different segment? if so, i guess your computer didn't like data being written to that memory area.

i am going to have to write a card type detection routine so that it can check what the system has before writing directly to memory segments.

EDIT: is it the MDA video card standard?
 
Last edited:
Close, but no cigar ..

The machine has both monochrome (Hercules) and VGA. I tried on both. For your purposes the VGA looks exactly like a CGA.

When the machine locked up it responded to CTRL-ALT-DEL, but nothing else. Which is good, because on some lockups that combination doesn't even work.

The standard monochrome card maps it's memory at &HB000, which does not conflict with the CGA.
 
mbbrutman said:
Close, but no cigar ..

The machine has both monochrome (Hercules) and VGA. I tried on both. For your purposes the VGA looks exactly like a CGA.

When the machine locked up it responded to CTRL-ALT-DEL, but nothing else. Which is good, because on some lockups that combination doesn't even work.

The standard monochrome card maps it's memory at &HB000, which does not conflict with the CGA.
Click to expand...

yep... i already pulled up the tech specs on it. i'm writing a card detect function. i was doing it by using the quickbasic LOCATE command to position the cursor at 1, 1 (top left corner) and then the PRINT command to write a space(ascii 32) and an exclamation point(ascii 33)

then it'll check the first two bytes beginning at segment HB000 and also HB800 to determine card type. this should be reliable, i believe. if you can think of a better method to do it let me know, but i believe this should be a pretty reliable method.

btw, i don't think your system was actually locked up. it just wasnt showing you the text because it was writing to the wrong place. i would be willing to bet, if you hit alt+q and then Y at the part where it seems to hang, it would drop you back to DOS.

you really are helping me out here alot, thanks! i probably would never have known about that huge bug if you hadn't tried it. :)

EDIT: i just read this about the hercules card...

The Hercules card supported two graphic pages, one at address B0000h and one at address B8000h. The second page could be enabled or disabled by software; when it was disabled, the addresses used by the card did not overlap with those used by colour adaptors such as the CGA or VGA.
Click to expand...

so, if i do not disable the page at B8000 will writing to B0000 not work on it? i guess i can configure DOSbox to emulate a hercules card and mess with it.
 
Last edited:
Don't bother with a card detect function .. You'll have a problem on a machine like mine where both cards are present. Both will respond, but you won't know which one is considered 'active.'

A better solution is to use a command line switch, or try to detect which card is in use by DOS. DOS lets you switch between monochrome and CGA using the 'mode mono' or 'mode co80' commands. The information about which card is in use must be available somewhere, retreivable by a DOS or BIOS interrupt.

The Hercules card has two video pages, but only one will be active at a time. Generally assume that the Herc acts like a plain vanilla monochome card, and that the advanced features won't be active unless you start writing some code.

I'll try the Alt-Q and Y next time.
 
well it seems the "hercules emulation" in dosbox is pretty piss poor, at best... i can actually make it draw color just by using POKE to write to the attribute byte after any character i've written to the screen.

what i was trying to see is what the attribute byte should really be to have a character just display as plain old text.. i assume it's not zero? i'd imagine that'd make it black on black. should it just be a value of 1 for normal attribute? i can't seem to find any in depth documentation on google.
 
I wouldn't get too hung up on monochrome display adapter support, as most people who use a 5150 or a 5160 have a CGA or better as well. However, if you really want to subject yourself to this kind of pain, this should have what you need:

http://www.seasip.info/VintagePC/mda.html

Don't bother with Hercules specific support .. you just need straight monochrome, and the Herc will be happy.
 
hehe thanks for the link... i already found that page too actually. yeah, it's not like i'll have to spend alot of time working on this... all i'd really have to do is let my program know the correct memory segment to write to, and have it ignore any color statements i use.

almost done with it, actually...

well thanks for your help. i hope to have all the basics of this thing working sometime this week. i'll post it when it's ready.
 
ah.... i figured out why it's locking up for you.

i just compiled the program again, and transferred it over to my 286. i ran it, and it did exactly what you described on your XT. after the initial dialog box, it's locks up.

at first i was stumped, so i opened up the manual file for the cosmox library i was using for copying data directly to a memory segment and it said cosmox is written in 386 ASM lol. that would explain it.

i'm just going to go ahead and write my own ASM routine for memory copies. i'm far from an ASM expert, but i should be able to handle something that simple.
 
i'm sure it does, but i'll ask anyway....

for both of you guys, dongfeng and mbbrutman. when you try running it on newer machines, i.e. 386+ and a color-capable graphics card it works fine right?
 
sorry for postwhoring, lol..

just informing all that i'm actually re-writing all my TCP stack access routines from scratch. instead of working with WatTCP, i've switched over to NTCPDRV. i did this for two reasons actually.

first of all, the official programmer's reference for WatTCP costs a whopping $55!! the specs i've been working with are unofficial, and incomplete. NTCPDRV is completely free, including the programmer's reference!

the other huge reason is that NTCPDRV takes 68,704 bytes of memory, while WatTCP takes a whopping 90,128!!!! as you guys already know, ~22 KB of extra memory when you're dealing with old DOS machines can make a huge difference! :D

hell, i've seen motherboards before that don't even have that much TOTAL memory lol.

also, whenever i use a DOS program that makes use of WatTCP it always gets ridiculously slow download speeds. for example, when i use SSH2DOS's 386+ version executables like SFTP2D386 for example, i get at the most about 5-8 KB/s from the Pentium 3 linux system on my LAN. and this is on a 386 DX/40 MHz machine, so that is absolutely horrible. i also notice when my routines have to get large-ish amounts of data it is very sluggish, too.

to compare that with what this processor should be capable of, when i run mIRC v5.91 16-bit on the same system under WFW3.11 i receive DCC file transfers from another machine on my LAN at nearly 250 KB/s and that's even with windows' fairly big overhead on a system this old with 3 MB of RAM

hopefully NTCPDRV will greatly improve network performance.
 
Last edited:
I haven't tried it on any other machines, but I'll test it out on my 486 when I get home from work.

I'll have to try and find a network card for my XT now, it would be fun to use it for IRC and BBS' :D
 
Actually, I'd probably just fork over the $55. Here is why.

- Trumpet (NTCPDRV) doesn't come with source.
- WATTCP is better supported.

I doubt that WATTCP is slower than Trumpet. The only accurate way to measure the speed of a TCP/IP stack is to do it using sends and receives where there is very little overhead for disk, CPU, or I/O. For example, when I measure the speed of my TCP/IP code I don't read or write to file. On a send test I send the same 1K of memory repeatedly, and on a receive test I receive the packets and toss them. This accurately tests what the maximum throughput of the code, machine, and interface combination is.

SSH is CPU bound. Even on my 666Mhz Linux machine I can measure a large difference in CPU used between FTP and SSH file copy. It is encrypting the data before sending it. You can't get a good speed test that way - are you measuring the TCP/IP throughput or the speed of the (fairly heavy) encryption?

If Trumpet has a bug, you'll never get around it. That's one of the reasons that I started on my own.
 
dongfeng said:
I haven't tried it on any other machines, but I'll test it out on my 486 when I get home from work.

I'll have to try and find a network card for my XT now, it would be fun to use it for IRC and BBS' :D
Click to expand...

yeah, it is fun to see all the WTF's when you tell everybody what machine you're using to IRC with hehe

you don't really need to even get a network card for it... if you have a null-modem cable for serial or parallel you can use a SLIP or PLIP packet driver and connect it to another machine that already has a card.
 
mbbrutman said:
Actually, I'd probably just fork over the $55. Here is why.

- Trumpet (NTCPDRV) doesn't come with source.
- WATTCP is better supported.

I doubt that WATTCP is slower than Trumpet. The only accurate way to measure the speed of a TCP/IP stack is to do it using sends and receives where there is very little overhead for disk, CPU, or I/O. For example, when I measure the speed of my TCP/IP code I don't read or write to file. On a send test I send the same 1K of memory repeatedly, and on a receive test I receive the packets and toss them. This accurately tests what the maximum throughput of the code, machine, and interface combination is.

SSH is CPU bound. Even on my 666Mhz Linux machine I can measure a large difference in CPU used between FTP and SSH file copy. It is encrypting the data before sending it. You can't get a good speed test that way - are you measuring the TCP/IP throughput or the speed of the (fairly heavy) encryption?

If Trumpet has a bug, you'll never get around it. That's one of the reasons that I started on my own.
Click to expand...

well another thing about the incomplete wattcp unofficial docs(besides the fact that it's in german, and my knowledge of that language is kind of rusty since i haven't been to germany for about 7 years lol) i found is that it doesn't tell you how to open a port for listening. i might be able to figure it out by just messing with it. it's probably similar to trumpet's.

i'm guessing the guy who wrote that doc wasn't interesting in writing any kind of server apps.

i'll see how my trumpet interface code works... i'm almost done with it now. the documentation on it is great and easy to understand. i'll probably turn it into a .QLB library when it's ready :cool:

i really want to be able to open a socket for listening cuz after i finish this IRC client i really want to make a DOS TSR telnet server to access machines remotely, because i have a serious lack of monitor's for all the machines in my home hehe

i could buy a KVM switch, but between my smoking habit and gas prices i'd rather not spend the $20 :(

plus i only have one single ISA video card and i'm tired of moving it between all my old PC's.
 
Last edited:
Dunno how this relates to the current topic but, back in '92-or-so, when I got my first 'legit' internet account, I was using a local dial-up portal on Michnet to access my 'shell account' on the Detroit FreeNet. My friend in Detroit (about half-a-mile from the (physical) server, was successfully using his shell accnt for IRC, running a Tandy 1000 with a 2400-baud modem. When I tried to access the same server, the IRC connection was so slow as to be completely useless, and I was running w 14.4 modem hung off from a '386 machine, from about 90 miles away. (No telling how many timez it bounced me around the world to hit that server, I just know that it didn't work for sh!t).

--T
 
ALRIGHT! well i'm excited... i got my new quickbasic TCP interface routines all finished. the new one i was writing for TCPDRV, that is...

i did a speed test with the routines on my 386 DX/40 running MS-DOS 6.22 (clean boot. skipped config.sys and autoexec.bat load. all i loaded was a crynwr packet driver and ntcpdrv.exe). i know the NIC used can have a BIG impact on performance, as well. i am using a 3com Etherlink III (3c509) 16-bit ISA card with parallel tasking. it's a very solid card as far as ISA NICs go.

i wrote some software that simply connects to my athlon 64 (running a VB6 program i wrote) and just keeps pulling 4096 byte data packets. it sends back a one byte acknowledgement packet, which tells the amd64 to send the next 4 KB packet.

my qb test prog just discards each packet, so there is no disk access overhead. it updates the transfer rate every 1 second. (if it did it after every packet, being such a slow CPU it would likely affect the transfer rate due to screen writes)

anyway... when i run the code interpreted in QB45, i get a consistent 33.1 KB/s

when i compiled the code to an EXE, i got a consistent 37.4 KB/s

i guess thats decent considering it's quickbasic... the slowest of the slow when it comes to DOS programming.

anyway, i'm going to go through and see if there anything i can clean up in the routines that might be eating up CPU needlessly.
 
You must log in or register to reply here.
Back
Top