wave17.html

There aren't any big visual differences with this release, but there are numerous "behind the scenes" improvements and fixes. This release is perhaps the first real smooth version we've had since this project began.

It's beginning to feel real solid and stable now. The HTML interpreter in the browser is improving and so is the VT100/ANSI interpreter in the terminal.
The biggest improvement was finding a bug that's existed for several releases. It was causing goofy things to occur in the browser.

More work was done with the browser as it's being readied for the Internet. You can now have a whole web site copied to a native partition on your CMD device and it will move around and through the subdirectories just like it would if the site was on the Internet. For instance, if a link on one page points to an html file that's located in another subdirectory, it will find it and display it.

I'm going to create an installer program that will copy the files to your working directory for you. This will help to simplify things because it will also check the files to make sure you have all the current ones required. If you're missing anything, it will let you know.

This installer will be a stand alone utility for the tme being, but eventually,it will become a built-in function in The Wave. The idea is that you'll be able to access my web site and get automatic updates. In fact, you won't actually have to go through the motions of going to my web site, the installer/updater will do it for you. A simple menu selection will invoke it.

You'll get a dialogue box that will then pop up with something like the following:

If you click on OK, my web site will get accessed and files on the site will be compared to the ones you're currently using. If new files are found, you'll get another dialogue box asking if you want to install the new files.
A simple click on OK will do the job.

It looks like it's time to get the browser onto the net. A little bit of multitasking is going to be required so that the browser and the terminal can be running at the same time. Technically speaking, I need to add more code to allow for TCP/IP packets going to multiple locations internally. Even though this will allow both the browser and terminal to have their own connections to sites, it will also allow the browser to have multiple connections running which is very important.

After all, as it's rendering a page, it might be fetching one image from one site while fetching another from another site. So, an improvement to the TCP/IP routines is needed to get the browser connected. The terminal wasn't a problem. It could function with just one TCP/IP connection at a time. But the browser is a whole nother story.

A new section started Wave Browser Plans with various text moved around, as this page was getting very large!!

The backslash, tilde, and underscore characters can be entered just like you would if you were using geoWrite. In fact, the CMDR/i for the TAB is used in geoWrite also since the 64 has no TAB key.

Copy all the files in this archive into your Wave directory. This has a new Wave128 and System128 file. Keep all the other files from the B1.5 release that are not included in this archive.

This one fixes several bugs. Some font handling issues were taken care of and a couple of problems with connecting to certain remote hosts.

 
    Term128.tall
    Term128.short

The Term128.tall font is identical to the font that was included with B1.5, it has only been renamed. There is also a new FontList128 file included to accomodate the new font. Load the file into geoWrite and change the location of the semi-colon depending on which font you want to use. Remember, a semi-colon in front of a line of text in the FontList file makes that line into a comment and is ignored when the font handler reads through the file.

The biggest change in the terminal is the font handling. This release comes with a new terminal font. The old Terminal128 font will no longer work.

This font is special in that it allows about 5 different combinations of character sets in the terminal. Between the various character sets contained in the font file along with the translation tables in the terminal, different combinations of characters can be accessed depending on the commands coming from the remote connection.

There is also a new DB that is accessed from the options menu, called "terminal display". This DB lets you turn VT/ANSI mode on and off And if on, you can also turn ANSI colors on and off. You can also choose to force the terminal to use ANSI characters or the normal VT-102 characters. When browsing the web with Lynx, you'll want to select the VT-102 characters since this is the common 8859 character set recognized generally by most web pages. But for those telnet sites that use ANSI graphics, you'll want to use the ANSI set.

Even though you've chosen one or the other charaacter sets, the terminal might still switch on its own if it gets a command to do so from the remote site.

Be sure to copy each of these files included here into your Wave directory. You must use all of these for The Wave to work properly. Keep the rest of the files that came with the B1.4 set. This B1.5 upgrade includes the following:

11/05/2000...
Some Wave Font news..
Nate Dannenberg has added some additional characters to the terminal fonts. Most of the characters in the font that Geoff Sullivan has created have been retained, but with a slight modification to the height of some of the characters.

Anyway, the font is almost double in size and now includes characters that are more compatible when using something such as the Lynx browser. The terminal attempts to determine which character set is needed but can't always figure it out correctly if the remote host doesn't send certain commands. So, if you feel the extra character set is needed, you can force it to be used with a new dialogue box that is available from the "options" menu. You have a choice of the ANSI character set which is now being used and the VT10x character set, which is also known as a 8859-1 set. These same characters are also used in the browser fonts, so they are more appropriate when browsing.

If you're telnetting to a site that requires ANSI characters such as "bbs.docsplace.org", then you want to stick with the ANSI set.

I will fix it soon so that you can set defaults for each site that is in the history buffer, as well as defaults for the ISP and BBS directories. The history buffer settings would override the ISP directory settings.

We've got the 128 font ready but not the 64 one yet. As soon as that's ready and tested, this next version will go out.

Note: If you use the SuperRAM for the OS to use and you set up a ramdisk in it, don't make the ramdisk as big as you can. If you make a 15+ meg ramdisk, there won't be any ram left for The Wave to use. Be sure to reserve 4 megs or more for The Wave. The Wave is ram hungry, like Microsoft products. :)

You'll notice that Wave128 is somewhat smaller this time. I've broken the file up into two pieces. That's what the System128 file is all about. I won't go into details, except to say that I did this for technical reasons. System128 must be in thesame directory with Wave128 or it won't let you start it up.

FontList128 is different because the Terminal128 font is now listed in that file. In B1.3, the Terminal128 font would get loaded everytime you switched into the terminal. Now, the font handler includes it in the same database as the browser fonts. This means that the first time the font is needed, it gets loaded into memory. From that point on, it will stay in memory unless the browser uses so many fonts that it needs to kick it out to make room. If that happens, it will simply get reloaded from disk the next time you enter the terminal.

The Terminal128 font is different because it's now an 8 point font instead of 7 point. (thanks to Geoff Sullivan for updating the font)

We use an 8 point font now because the terminal has been changed. The menu is no longer visible unless you move the mouse to the top of the screen. This allows us to use the entire height of the screen for text. With the characters falling on even 8 pixel boundaries, I've been able to add color to the terminal. Therefore, ANSI colors are now implemented and we still have an 80x25 terminal screen.

 
CMDR/v - this still toggles VTxxx/ANSI mode on and off. By default,
    ANSI colors are enabled. If you toggle VTxxx/ANSI off, all VT
    and ANSI commands are ignored and the screen changes to
    monochrome mode. The VT/ANSI commands are still parsed so
    that they don't show up on the screen like "[1;1H[37;40m". This
    allows you to see only the actual ASCII text that you want to see.
 
CMDR/a - This toggles ANSI colors on and off. This key combination
    is only effective while VT/ANSI mode is on. If you toggle ANSI
    colors off, VT/ANSI mode is still on, but in monochrome mode.
    There might be some screens where monochrome mode shows
    up clearer, or maybe you simply prefer not to have color mode.
    Also, keep in mind that you'll only see color changes on sites that
    actually have color commands in them.

In this B1.4 release, you'll be forced to once again create new BBS and ISP directories. In the future, I'll come up with a method that will automatically upgrade the directories when something is changed in them, but for now you'll have to do it yourself.

The reason for the change is that some more settings are being placed in the directories. Mainly the ANSI color settings. There's no way yet o change the ANSI setting for each directory listing, so for now you'll have to live with the default settings of having VT/ANSI mode on and ANSI colors on. Soon, I'll add more to the setup dialogue boxes so that you can set your own defaults.

The WaveHistory file remains the same, so you can reuse your existing one if you like. If you don't have one, it will automatically be created the first time you log oto the Internet.

Play around with this release and see if it works even better than the last one. There's more VTxxx compatibility in this one than the last, so you might see some telnet sites that work better than they did before.

17/04/2000...
I've decided to make a change to the terminal in The Wave. Up through version B1.3, the terminal has had a menu at the top and the text lines begin below the menu. The text area consists of 26 lines of text. Each line is 7 pixels high.
The problem with this layout is that I can't display colors properly. Most of the characters on the screen overlap more than one color card. The color cards fall on even 8 pixel boundaries. This is the main drawback of our Commodore video display. I wish we didn't have the 8 pixel boundaries, but we're stuck with it and we must make do.
So, what I've done today is to make a disappearing menu. And now we're using the whole screen for text display. Each line is now 8 pixels high and we've got 25 lines total. What I'm getting ready to do is to provide us with ANSI colors in our display.

To activate the menu, you move the mouse pointer to the top of the screen. When the pointer hits the top, the menu appears. If you move off the menu, it goes away. It works pretty slick this way.

Wave B1.3
Here's the next release of The Wave for the 128. The browser still isn't online yet, but I'm getting the PPP negotiations a little more perfected. I've managed to get one particularly troublesome ISP to work with this release. Hopefully, the work I've put in it will help the other troublesome ones and not hurt the ones that are already working good.

There's a lot of little improvements here and there. I can't even name all of them. Many of them aren't really visible to the user. Overall, the terminal display is faster, the keyboard handler in the telnet mode is improved, YModem is added but you can only select one file when sending. I need to make a multi-file selector yet.

There is now a history file that gets generated so you no longer need to type in your telnet destinations after the first time.

(128 mode)
When exiting the terminal back to the browser, the links are no longer active. You must reload the file. The terminal will sometimes trash the appearance of a large HTML file in the browser. Again, reloading fixes it.
Sometimes, the "wheels" menu will look funny. The "exit" item might be superimposed over it in the browser.

29/03/2000...
I fixed another bug. This one only seemed to appear on my system while using a USR modem. Not sure why the modem made a difference, but it did. Most of the time, it would take 10-15 seconds for the modem to hang up after pressing CMDR/h or clicking on "hang up" in the menu.

I found where the code was going into a loop and repeatedly trying to disconnect from the ISP until a timeout finally occured. Then the signal would be sent to the modem to hang up.

Anyway, I fixed that problem and it hangs up fine now. Of course, there is still about a 2-3 second delay before you see the modem actually disconnect. During that time, the TCP routines are making sure to remote TCP connection is closed and then the PPP routines are letting the ISP know we are going off the network. If the ISP doesn't respond within 3 seconds, then the modem will get disconnected anyway. So, fast ISPs will see a fast disconnect, while sluggish ones will see about a 3 second delay in hanging up.

I've been checking out "cereal.mv.com" by trying to telnet to it and noticed that it makes for a very messy screen. I checked into it and for some strange reason, whoever put that site together is using code in an odd manner.

Telnet has its own escape character, a 255. When this character appears, special code follows it. The telnet application has the job of deciphering this code and acting on it. The Wave does this, however, while deciphering VT-102 and ANSI codes, it was ignoring any instance of anything but what belonged within an ANSI or VT-102 string.

If a 241 follows a 255, this is a "no operation" code. This pair of bytes simply gets ignored. Well, this particular site has these pairs of bytes stuck within each and every ANSI code. Also, where a CR/LF pair appears, it puts these bytes in between the CR and LF also. I don't understand why they chose to do that, but they did. It just seems sloppy to me.

Anyway, I added some code into the VT/ANSI routines to watch for the telnet escape. And now, cereal.mv.com displays correctly.

I'm still curious as to what the logic is behind putting those bytes within every ANSI code and between every CR and LF pair. Maybe a strange text editor that they use?

Also, cereal.mv.com doesn't translate the telnet backspace correctly. A combination 255/247 is supposed to be interpreted as a command to erase the character to the left of the cursor. This site only recognizes an 8 for this purpose. So, anytime anyone runs across a site that doesn't translate the "erase character" sequence correctly, just use CTRL/h and it will send an 8, instead of using the delete key.

When I get Wave B1.3 ready to send, it will have the fix in it for cereal.mv.com.

Also, I made an improvement in the telnet keyboard handler. There were times when I noticed that a keypress wouldn't go through until I pressed another key. Most of the time, I noticed this happening as I was entering a password while logging into Delphi. My typing would get ahead of Delphi (not too hard to do) and then the ending carriage return wouldn't get sent.

I found out it was recognized by the system but still waiting in a buffer to be sent. If I hit RETURN again, then it would get sent. Only problem is, so would the second carriage return. Anyway, I fixed this problem and now every character gets sent when the remote host is ready for it. I don't have to hit another key to trigger the send anymore.

The biggest improvement is in Wave 64, but only because Wave64 needed this. At work, I have a V1 SuperCPU. These early units had a problem with NMI interrupts. At least once a day, the machine would lock up on me while running Wave64. It works fine otherwise.

But The Wave uses NMI interrupts to capture incoming data and the SCPU processor is really stressed out at 20mhz. What happens is instead of an NMI interrupt occuring every time, and occasionaly NMI actually occurs as an IRQ interrupt instead. No big deal normally, except that it only happens while IRQ interrupts are disabled.

And they are disabled for a reason, so that another IRQ interrupt can't occur until the current one is finished running. In addition to this, the NMI routine doesn't get called during this particular interrupt. This causes the NMI line to be held low until something is done to release it.

If no data is going out currently, then the line will remain held and also no more data will come in. Therefore, with no data coming in and an IRQ interrupt overlapping another one, conflicts occur and data is lost and the machine basically goes to junk. The only way out is to reset and reboot.

I spent about a whole week researching this problem and I believe I've come up with a software solution incorporated into The Wave. For 3 days, the machine hasn't locked up a single time at work. At home this is never a problem, because I use two SuperCPU V2 units there. CMD corrected the problem in the V2 machines. This only happens with the V1 machines.

For you 128 users, I'm telling you all this also, because just for the heck of it, I put the same "fix-it" code into Wave 128. I suspect the problem might occur on a very rare occasion with the SCPU V2, but haven't been able to tell for sure. In any case, having the code in there doesn't hurt a thing.

If I had intended to make this into commercial software, you wouldn't see any of what you're seeing right now. You'd have to wait until the product was finished. But that would take awhile and I didn't want to wait that long to get this into people's hands so they can begin using it.

As for features, they will be plenty. There's already a 64K capture buffer in the terminal, but we don't have any way of viewing it yet. :) I'll probably make it so you can use a larger capture buffer also. Its size will be in increments of 64K.

The CMDR key is now the PAUSE key in the terminal. You can enter your own DNS addresses in the ISP directory now for those ISPs that don't provide them during login. In the telnet DB, you can alternatively enter the real Internet address instead of the name, if you know the address. This is faster because the DNS server doesn't need to be accessed. For instance, instead of entering "delphi.com", I can now enter either "199.93.4.65" or "199.93.4.67" and I'll still get telnetted into Delphi. Delphi uses either of those addresses. This is the info the DNS servers looks up and sends back to The Wave.

XMODEM, XMODEM-CRC, and XMODEM-1K are now functional for both uploads and downloads. Currently, it's set for "automatic" protocol detection. It tries to determine which XModem variation the other end is trying to use. This will work with most online systems. Eventually, there will be a config DB that will let you look in the method you want to use. For now, it should work fairly well. YMODEM is coming real soon, it's in progress right now.

If you're telnetting to various sites, and bouncing from one to the other, you'll get the telnet DB automatically as soon as you log out from a telnet site as long as the site has properly terminated the connection. If not, then you'll have to click on the "open" menu and then "Internet session" again in order to get the DB to come up. When you do this, there might be as much as a 4 second delay before the DB appears. During this time, The Wave is attempting to properly close the previous telnet connection. If the other end responds right away, the DB will pop right up. If it doesn't respond correctly, then the 4 seconds is used to give it time to respond. After 4 seconds, we give up and you're allowed to telnet somewhere else.

When you click on the "hang up" menu selection or press CMDR/h to disconnect, there might be a small delay in hanging up the modem. It will likely happen immediately though. The Wave is first atempting to do a proper closing of the PPP link with your ISP now. Prior to this version, it just hung up the modem and the ISP had to end up timing out after no activity. The ISP will know right away that you are disconnecting. The ISP's machines will appeciate this.

Nate Dannenburg has been connecting up his system to a Linux box and running The Wave with a null modem cable from the SwiftLink to the Linux box. But, there's no dialing out, so this has given him a little trouble. By ignoring the carrier detect, The Wave will work in this fashion. In the meantime, he can get around it by somehow unhooking the carrier detect wire and reconnecting it to simulate a connection just being made. At least, The Wave will think this is happening.

When I get email implemented, we'll be using geoWrite as the email editor. The Wave will launch geoWrite whenever you want to compose and email message or reply to one. When you exit geoWrite, you'll return back to the email function in The Wave and be able to send the email message. Likewise, when you grab your email, you can read it in geoWrite or you can read it right in the browser. You would use the browser if the email contains HTML code, or save it to geoWrite files if you want to keep the messages. The browser will take care of converting the HTML to geoWrite format.

You can upload and download to your shell accounts or a BBS, and you can even transfer files through a telnet connection as long as the host you're connected to can also do the same. Currently, XModem, XModem-CRC, and XModem-1K is supported.

You're going to love this version of The Wave that will be ready within the next day or two. I've been testing XModem, XModem-CRC, and XModem-1K uploads and downloads here on Delphi during the last two days. I've also been testing it with my BBS. YModem should be ready shortly, possibly by tommorow night.

I'm pleased to announce that The Wave's terminal with telnet has been working flawlessly lately. I've really made some nice improvements to the TCP/IP and PPP code to make this work good. Plus, I've added considerably to the VT-102 routines. I've tested it by accessing videocam.net.au and delphi.com's version of Lynx, and it works great. The VT-102 stuff is also working great with Pine and other utilities that require this sort of thing.

By getting the terminal/telnet aspect working good, I've been able to debug the TCP/IP routines properly, since I can interact with what I see on the screen. In other words, I know that when I press a key on the keyboard, if I don't get the proper response, I know where to look for the problem. If I had worked on the HTTP protocol first, I would be debugging a little more blindly, and it would have been more difficult.

I've been comparing the performance of the telnet terminal with one I have running on my laptop (with Windows 95) and don't see any difference in speed or performance between the two. In fact, the 64's screen display is a little faster than the laptop, while the 128's screen display is just a little slower. My laptop is a 100mhz Pentium.

I'm leaving this message while telnetting in with my 64. I'm using an 80 column font that displays quite well on the 64's 40 column screen.This is actually working pretty good except for the keyboard still needs some work. But it's 10 times better than it was yesterday.

I've actually been able to telnet into Delphi now. I've been successful at least 4 times now. However, I've got a few problems to iron out. Each time, after about a minute of being logged in here, I would experience a problem of not being able to type a character. This prevented me from entering any further commands to navigate about Delphi.

Typing was very sluggish also. I'm fixing that right now. I'm rearranging the code so that interrupts are running more. This will allow the keyboard to be read more often. This problem is only occuring during a telnet session and not at any other time. But it will be fixed shortly.

The best part is that I was actually able to telnet into here. Earlier today, I gotin and even was able to read the 4 email messages that were waiting for me. I then went to the forum to see if I could leave a message stating that I was in here "live with a 64", but then the keyboard problem came along. I'm in here with my laptop right now.

I also telnetted to "bbs.docsplace.org". That site seemed to give me less trouble than Delphi. Something about the way Delphi's telnet software is programmed makes it kinda goofy to get logged in. If I send information to Delphi's telnet port too fast, it seems to miss about half of it and I have to repeat it. This is something you can't see on the screen, but I can tell it's going on because I'm capturing a log file of every byte that goes back and forth in order to debug the system.

This software is pretty simple to use. I just clicked on the "open" menu and then clicked on "Internet session". From the dialogue box that appeared, I chose "Telnet". Another dialogue box opened up asking me to enter a telnet site. I typed "delphi.com" and hit return. Then a dialogue box opened asking me to select an ISP to dial. I chose the only one that was in the list and the system proceeded to dialout. Within a matter of about 25 seconds, I had the Delphi "USERNAME:" prompt showing on the screen. This was the total time to dial out to the ISP, access the DNS server for Delphi's address, and then telnet to Delphi. This even included the time it took the modem to get a carrier detect with the ISP's modem. Not too bad.

Actually 3 tests were wrapped up into one. In order to test the TCP protocol as well as the IP protocol, I had to have something to send and something to receive. So, I implemented the DNS routines for the test. I sent out a request to a domain name server requesting the host address for "delphi.com" and received a response back from the server with the correct address for accessing Delphi.

06/02/2000...
Taken from the Geos Fido Echoes.
I haven't done anything concerning a User Agent yet, but will put it on the list. So, if the OS gets set as COMMODORE, does this mean they'll have to do a new version of the RFC for Assigned Numbers? Amiga is listed in there, but COMMDORE or CBM is not.

The real test will be coming very soon. PPP has passed the test... It looks like the TCP/IP code is ready (but untested). The DNS code is being worked on and then I'll throw the telnet and http code together and surfing we will go.

The key to how The Wave's browser works is in the fonts. The 40 column fonts are sized just right, but not too small. All the content of the page fits in the width of the 64's screen.

Now, if you compare the display to a Netscape screen (or that other widely used browser) you'll see that the text might wrap to more lines. This is because Netscape can use smaller characters. In my opinion, though, the characters that these Windows browsers use get too small. But that's also the fault of the author of the web page.

The 128's screen will look very similar to the 64's except for the fact that it has more horizontal resolution. This allows for less word wrap. And the 128 uses different character sets from the 64. They are about 50%-80% wider so they don't look scrunched up.

As for the browser, you would use that just like any Netscape user would. Just click on the ISP in the directory and it dials out and logs into the Internet for you. The Wave is not a large file, it's currently only about 30K. (How huge is Netscape and Internet Explorer?) The Wave is small because it's written in good assembler code, unlike the other browsers on other machines that are written in C.

The terminal will be able to telnet without the use of the shell account. So, you'll never see any menus on your ISP, you'll just telnet to wherever, such as Delphi, using the terminal.

I haven't been very productve the past few weeks due to the holidays and having to work extra in my shop for needed income and to get caught up on having too many customer's cars sitting around.

12/12/99...
The PPP is pretty much finished but untested yet since I haven't performed my first logon test. This is because the TCP/IP is not ready to go yet. It should be ready very soon though. And then we will get our very first internet access with The Wave.

10/12/99...
The Wave has a graphical browser built in, plus a VT100/ANSI terminal including a telnet mode. It's still in its early stages of development, but the first public release version should be ready within a few weeks. It will be limited to some degree, but development will continue and new versions will be released as they are ready.

The Wave is a free application and will be available for downloading from my web site (http://people.delphi.com/arca83) or from my BBS (5173222386) when it's ready.
Once this gets going good, I'll have a built in routine for automatic upgrading to make it easy to keep up with the new releases that might come out every other week or so. You'll just go to my web site and click on a link and you'll be prompted if you want to upgrade The Wave. Click on YES and the process will be handled for you.

The Wave installs itself as the default desktop until you exit it. While its running, you can launch other applications like geoWrite or any other app. There will also be new Wave modules that will run right within the browser. Call them "plug-ins" if you'd like.

The latest news is the browser is now capable of handling most any html tag except for those dealing with frames and images. That stuff will come after I get finished with getting this thing ready for its first login session. I'm trying desperately to get something ready for everyone to play with before Christmas.

Actually, part of the frame work is done. In a sense, the current method of displaying the html document in the entire screen is no different than displaying it in a portion of the screen, which would be a frame. The code for displaying on the screen is the same as that which will be used for displaying within individual frames. The scrollbar routines are adjustable to work a scrollbar at any position on the screen and at any height, with any amount of content. So, we can have the ability to scroll any part of the screen. The scrollbar routines I've got now are better than the ones I created for the Dashboard. These new routines will eventually find their way into a new version of the Dashboard.