wave2.html

I'll be releasing a new release of The Wave soon. I finally took some time to fix a cosmetic problem that has been in the 128 version in terminal mode. Occasionally, you would see some corruption on the screen that appeared similar to a bar code. I figured out where this problem was and fixed it.

I've also fixed a couple of other bugs (also in 64 version). I'm going to take a look at the HTTP downloading routine to see why it might not download an entire file sometimes.
Also, with the new release of Donald Zerbe's graphical fonts combined with Geoff Sullivan's button fonts,
we need more storage in memory for fonts. The Wave currently uses a 64K buffer to store font data, but
this isn't enough with these new fonts. This change will be in the next release.

If possible, I might get some more work done on the email program and turn that function on so we can
do some simple emailing with The Wave. Maybe I can fix up the forms editor for the browser as well.

These can be handy when you're connected to somethinglike another terminal through a null-modem connection.BBS's will generally echo your keypresses back so theterminal can display them to the screen, but other terminal programs usually do not echo back. By default, they usually don't add linefeeds to a carriage return either.

Port Numbers added:
Also, you can add port numbers to your URLs now. You do this by adding a colon after the server name followed by the port number.... Let's look at an imaginary example in the browser:

Instead of trying to connect to the default port 80 on an http connection, the browser will try to connect to port 64 at commodoreheadquarters.com. Or in the telnet terminal, you can try to log into:

If you add port numbers in the browser, and if you also will be adding additional text for the path, the port number always goes after the server name and before the rest of the path. For instance, the following two examples will get you to the same web page:

http://www.cmdweb.com/cbm/index.htm
http://www.cmdweb.com:80/cbm/index.htm

Of course, you don't have to add the port numbers in most cases. This feature is only for those people that have special servers they need to connect to that use port numbers other than the default ones.

Email support is in the works but I had to disable it in this release since the user interface still isn't ready for public use. However, I felt that other improvements in the browser warranted getting this release out for everyone to use.

The browser can also display borders around tables now for those sites that use Borders.
Font handling is improved. There was a bug that prevented the correct fonts from being used in many web pages. The same bug also kept the correct font sizes from being used in some cases.

The SYSTEM64 and SYSTEM128 files have now been eliminated.
The new Concept+ programming package that I'm using to code The Wave with allows me to more easily create larger and more complex application files. So, I've been able to put all the code into one file for each version. You only need Wave64 or Wave128 now. Of course, you still need all the other support files such as the fonts.

(More B2.9 info taken from various Emails between myself and Maurice)
Maurice writes:
I've got tables looking much better. No more narrow columns showing up on some pages. The Cocos sight even displays now. That's a goofy site to deal with. They are describing some of the tables as being one pixel wide and then putting a lot of content in these narrow tables. I wonder who codes like this?
For that reason, I have to ignore the pixel width attribute.

Also, the Homestead site was giving me fits. The center column contains a table that sits in the cell of another table. That cell is defined as being 100% wide which means it should be the full width of the table it's in. But the table contains a total of 5 cells. So, I have come up with some code to try to figure out how to deal with stuff like this.

That particular table describes the leftmost cell as being 150 pixelswide the second one is undefined but contains two space characters that is supposed to define the width. The third is the 100 percent wide one,
then another two character width cell, followed by the rightmost column which has an undefined width. The browser is supposed to figure out how wide the undefined cells are supposed to be. It would sure be much simpler if they were all defined by percentages and the total of the percentages would be 100% or less. I'm sure this is not the fault of Rod or Gaelyne, but more likely the fact that the page is being generated by software that
someone else wrote.
That same page also contains many font tags without closing font tags. The search form sits inside a cell that is missing a closing TD tag. I've already had code to watch for errors like these.

Note:
You can see some new Screenshots of B2.9 and the vast improvements in the Table display, with Borders now rendered, in my

You will also see there is a new option in the menu's "edit" which will allow text to be cut 'n' pasted in future releases..

CTRL-V problem solved
I had changed the way some routines test for the STOP key. In fact, I've eliminated all the hard coded checks that are made directly to the CIA chip. The check is now made with the kernal doing it all. And that's where a problem can happen.
The value for CTRL-V just so happens to be the same value that is given if the STOP key is pressed. So, now, when testing for a STOP key, I first check to see if the CTRL key is being held down. If so, then the STOP key check is skipped. This fixes the problem in Pico now.

The packet size is still 1024 bytes like in YModem, but where ZModem picks up speed is in its ability to send more than one packet at a time without waiting for confirmation on each packet. This is all negotiated at the start of the ZModem session.

For instance, it might be agreed that each side can handle a 6K buffer. So six packets are sent and then the receiver will tell the sender that it got each packet OK. Meanwhile packets are still moving. If the receiver can't handle this much all at once, this is determined at the start. Also, the receiver might not be able to keep receiving incoming packets while it writes its already received data to disk. It will let the sender know this also and the sender will wait until the receiver is ready for more data.

So, if the receiver can only handle a single 1024 byte packet at a time and needs to write it to disk before it can receive another packet, then ZModem won't be any faster than YModem, it might even be slower. But if both sides can handle multiple packets and work with the disk drive at the same time, then ZModem can be much faster than YModem.

ZModem is made flexible so that it can be used by fast computer systems that can handle overlapping disk and I/O and it can also be used by slow systems that can only do one thing at a time.
The Wave's implementation of ZModem will be somewhere in between the slow and fast system, perhaps closer to the fast system except for when it needs to access the disk drive.
By the way, I've been making improvements to YModem and XModem. YModem does a better job of getting the receiving host in sync at the start of a file transfer now. Previously, uploads on a telnet connection failed too often due to the other end losing incoming data at the start.
Also, the terminal is slightly faster at decoding ANSI/VT100 codes which makes the display a little faster.

There's also a few other little improvements here and there throughout the software. Email isn't ready yet, but I'll probably go ahead and release this current version as B2.8 on my web site soon. Email should be showing up in either B2.9 or B3.0 along with some added features in the browser.

Maurice writes:
I've discovered that your recent problems with the junk characters showing up when you type is primarily a problem on your ISP's end, but it can be covered up at our end with a minor bit of work. I'll try to describe in simple terms what is happening.

When you type in a character, that character is packed up into a TCP packet, stuffed into an IP packet, and then further stuffed into a PPP packet. This PPP packet heads off to your ISP. In this particular case, you are typing in your password to log into your shell account through a telnet connection. So, your ISP which is handling the PPP connection, is also the destination for any data that is generated as you type away on the keyboard.

The character hasn't appeared on your screen yet. Your ISP receives the PPP packet, pulls out the IP packet, removes the TCP packet from that, and lo and behold, there's this single character. It processes the character and sends it back the same way through a stack of packets.

It comes back to your computer and gets all upwrapped and the terminal can finally put it on the screen. But, somewhere along the way, some extra characters get thrown in and they also get put on the screen. This repeats for each character you type as you type in your username "sunfish". You'll notice that every character in "sunfish" is in there, but there are some extra junk characters added in between each valid character.

At your ISP's end, either their IP software is adding some extra unwanted bytes to the packet as it passes it along to the PPP software, or the PPP software is adding the extra bytes into the packet. Either way, the extra bytes are coming from your ISP. The actual TCP packet identifies that only one character is in the packet, but there may be 3 or more extra characters added afterwards. My guess is they have some sort of memory allocation problem or a bug in their software code that is adding extra data into the packets. Perhaps they have two function routines mistakingly using the same area of memory.

Now, I can fix the problem at our end. This has made me discover a slight flaw in my TCP routines. The extra data from your buggy ISP will still be coming, but it will be ignored once the packets get unwrapped on our end and you won't even know the bad data is in there. One bad thing is this extra unwanted data results in slightly slower performance. You might notice it in your typing response, but you won't see the junk characters once I fix it.

START of PPP Packet
IP Header
TCP Header
TCP Data
End of PPP Packet

We're pulling the TCP data from this mess and know where the data ends because it's right where the PPP packet ends. But in the case of your ISP, we've now got some junk in between the end of the TCP data and the end of the PPP packet. So, my fix will be to change where we stop grabbing TCP data. We'll stop where the TCP data really ends and anything between there and the end of the PPP packet will get ignored.

Tweaks for Uploading and a few changes in the Browser
I've found a better way to get the protocol back in sync when a packet gets lost during an upload. It appears to be working without failing at all now.

When a packet gets lost, you might notice a 5-second delay while the re-syncing is going on. Once things are back in sync, the uploading will proceed quickly again.

On my system, I've tested with a null-modem cable attached to my laptop running Linux. I've noticed that packets tend to get lost on even 32K boundaries. This is usually when Linux is writing the buffered data to disk. The Linux disk routines are trying to write to disk while the Linux PPP routines are trying to accept incoming data from the 64. Obviously the disk routines take priority and the PPP routines miss some bytes which in turn mess up a whole packet of data.

The YModem functions never see this particular packet and just keep on waiting. Meanwhile, the lost packet is silently ignored. This is where things get out of whack and we must get it working again from our end, because it doesn't appear like the other end is doing much to fix it. YModem on the Linux end will eventually time out and the upload fails. The new routines I've made prevent this from happening and the upload will work now.

Another fix I've made has to do with the date when the upload occurs. This isn't completely finished yet, but for the time being, the remote host will set the file date to the current time when the file is uploaded. This is how it will work with files that do not have time stamps. GEOS files will get sent with the actual time stamp when this function is finished. Of course, that will only work when I get the auto-convert routine installed.

Tweaks to the Browser
The browser has a little improvement on how it handles filenames. The other day, I donwloaded a document that was comprised of about 20 different HTML files. This was something I wanted to be able to view from The Wave. But pointing and clicking on different links in the files would fail because these files originated on a Linux system and some of the files had filenames that were longer than 16 characters. When the files were downloaded to the Commodore drive, the filenames naturally get truncated to a maximum of 16 characters. When clicking on a link to access a particular file, the file wouldn't be found since the original filename no longer existed. So, I fixed the parsing routines to truncate the filename that is being searched for and it works now.

For instance, a link might be referencing a file called "a_big_long_filename". That filename has 19 characters in it. On our disk, the file is stored with the name "a_big_long_filen". The browser will find the correct file now. Doing this prevented me from having to manually edit all the links in all of those files.

The Wave can handle 115,200bps no problem. I tested it using a 33.6 modem and also while using a null-modem connection to my laptop. (I don't have anything fast enough here to try 230,400 with)

This really woke up the USR 33.6 modem. Apparently the modem is using some compression that's compatible with the modem used by my ISP. The browser now reports the "avg. bytes per second" while data is coming in. I was seeing speeds as high as 5300 bytes per second with this 33.6 modem.

The real smoker was the null-modem connection to my laptop. I've got the Apache web server running on there so I can do some browser testing without having to actually log into the Internet. You have to watch carefully in order to see the speed readings while the data is coming in since it happens so fast. I saw a reading as high as 10,400 bytes per second.

From the terminal, I logged into a shell on my laptop through a telnet connection. Then I did a YModem download. Even with the telnet and PPP packet overhead, along with the YModem overhead and including writing the incoming data to a ramdisk, I was getting a steady 5500-5600 bytes per second.

This speed is calculated on the number of file bytes written to disk, not the actual number of bytes coming in. If I were to base it on the total bytes, the speed would look even better because of all the added packet bytes that are not part of the file data.

I did another download to the HD to see how much slower that would be. This was through a parallel connection between the RL and the HD and I was still getting a little over 2900 bytes per second. That includes the time it takes to write the data to the HD. Uploading is much faster since reading is faster than writing.

As for the Internet, this same 33.6 modem operates almost exactly twice as fast when the port speed is set to 115,200 as compared to before when I was setting it at 38,400. At 38,400 I was getting about 2600 bytes per second coming into the browser. Data coming in at 5600 bytes per second is actually more than twice as fast. Web pages really burn their way onto the screen.

Some null-modem connections should perform even better than my own testing here. My testing is based on using a 100mhz Pentium. I would imagine that someone connected to a faster PC would get somewhat better performance yet.

06/09/2000...
The Wave B2.7 is released.
As always, this latest release includes numerous little "behind the scenes" improvements and enhancements that may or may not be readily apparent. The big addition to this release is the long-awaited URL bar editor. We can now manually type in a web address into the URL bar instead of only being able to point and click our way around. These same routines will be used for the forms editor as well as the terminal's "chat mode".

The URL editor isn't 100 percent finished, but it's very functional as it is. It's basically a one-line text editor and is normally turned off. To activate it, simply click anywhere on the URL bar. When the cursor is blinking, the editor is running and will accept your input. The editor will accept up to 255 characters and can scroll left and right when there are more characters than can fit in the URL bar. Doing other things such as scrolling the page up or down or clicking on other parts of the page will turn the editor off.

The editor is always in "insert" mode which means as you type a character, all the characters to the right of the cursor will move to the right to make room for the new character.

The Wave B2.7 also has a user-agent..
Maurice added a "User-agent:" string to the http request when accessing a web site.
We are now identified as using The Wave,
either as a Commodore64/CMD_SuperCPU or a Commodore128/CMD_SuperCPU whenever we access a web site.

Here is what it looks like when the logs are viewed:
TheWave128/B2.7 Commodore128/CMD_SuperCPU

05/09/2000...
Wave B2.7 update
Just wanted to update everyone on the B2.7 progress. I've had too much going on over the weekend and wasn't able to spend much time on The Wave. However, today I was able to type a web address into the URL bar and it worked fine.

I've got to add some more functions to the URL editor and then it should be ready to go. Currently, you can click anywhere within the text to place the cursor where you want it. Typing characters is in "insert" mode.

The HOME key will put the cursor at the start of the text and SHIFT/CLR will clear all the text.

I've got to add the DELETE key and the CURSOR keys yet. In the meantime, I'm able to use SHIFT/CLR to clear it all out and type in a complete address. When I get the DELETE key working, then I'll be able to edit an existing address. I can add text anywhere within an existing address, I just can't remove characters yet without the DELETE key.

Once I get those finished, B2.7 will be ready to go. Other capabilities such as being able to highlight a portion of the text to delete or alter will come later.

These same routines used for the URL bar can now be incorporated into the forms editor.

This release is getting closer and closer to being ready for the public. I think we'll get just one more beta release after this one and then V1.0 will be released to the public. (the URL bar editor is still not ready, it's coming in the next release)

Here's how I'll be doing it from that point on... V1.0 will be made available for free downloading from my web site and my BBS. Plus if anyone wants to make it available for free elsewhere such as on club disks, BBS's, cover disks, etc., that's OK too.

There will STILL be beta test versions after V1.0 is released. For instance, this current release is B2.6. We'll get B2.7 and then V1.0 will be released to the public. Shortly after that, B2.8 will be ready. It will contain new features that may not be fully tested. This will also be available for downloading. The beta test versions will no longer be sent through email. The Wave can download files from the Internet, so anybody with current versions from B2.6 and later can download the latest files after V1.0 appears.

Anyway, once enough feedback confirms that the latest beta release is good enough, then it will become the next public release, such as V1.1. In between public releases, there could be several new beta releases. Chances are good that the beta releases will be fairly good when I make them available if you are familiar with how I work.

Why do it this way? The public release version should be very stable and bug-free. Someone that likes to use proven software will use only the public release versions. Those that like to keep up with the absolute latest and most current features and goodies might want to try out the beta versions. For instance, when we get email working, we might go through 6-10 beta releases before I'm satisfied enough to make a public release out of it. So, if you want to be the first on the block to have email working from your Commodore, then you'll want to try out the beta releases when that happens.

In this B2.6 release, I spent a lot of time improving what we already have plus I added another new feature. The browser can now download files straight to disk instead of bringing them to the screen first.

To do so, put your mouse pointer on a link, but don't click the mouse button. Instead, press the 'd' key to start the download. You'll be asked for a filename and a destination directory. Following this, the downloading will begin. The current web page will remain on the screen.

I worked on XModem and YModem a little bit more. I found a potential problem with uploading files through a telnet connection. Downloading works fine because we don't seem to miss any incoming packets. But when uploading, there seems to be an occasional outgoing packet that gets lost somehow. Maybe the remote host misses the incoming data, I'm not sure. But when it thinks it's lost a packet, it will send a request to resend the packet.

Here's the problem: The TCP routines send a request to resend the last packet, plus the X or YModem software running on the remote system will also send a NAK byte indicating it wants the previous packet resent. What happened in the previous versions is that two packets would get sent and everything would get out of sync. Now, the XYModem routines in The Wave work closer with the TCP routines to watch for this occurence and when it happens, it will send out the one packet that is supposed to be sent and it will contain the TCP sequence number that the TCP software is watching for along with the XYModem packet number that is also expected. You might see a slight pause when this occurs. Previously you would have seen a longer pause and maybe even a complete lack of activity.

So, uploads using XModem and YModem should work better now. This problem didn't seem to occur when using plain XModem with 128 byte packets. Maybe the other end has a hard time taking in 1024 byte packets when it's too busy doing other things. ???

I haven't seen the shooting bar lately. Maybe that problem is gone with this new release. Also, it's very rare that I have to click on the reload icon to get a web page to load. We appear to be having much better success at making the initial connection to the remote hosts.

In the browser's file menu, there's a new menu item "view header". This is the header information that the remote host sends along with the web page that is currently displayed. The Wave uses the info in this header to know what to do with the incoming data. Most people won't have any need to view this info, but it's there for those that find it interesting.

16/08/2000...
HTTP downloading now workingI've not got the HTTP downloading working in the browser now. What this does is it allows you to download a file straight to disk instead of capturing it to the browser's screen first.

To do this, you simply place the mouse pointer on a link so that it's highlighted, then press "d". A DB will pop up asking for a filename and a destination directory. Once you finish this and click on OK, the downloading will begin. The original web page remains on the screen so you can select another file or continue reading the page, etc.

I'll have V1.0 ready to go and will email it first to all the beta testers. If V1.0 meets with approval from the majority of the beta testers and no major problems are encountered, then it will be released to the public on my web site and my BBS.

Following this, I plan to take a short break and work on PP2 to get it ready for the Chicago EXPO. After the EXPO, Wave development will continue and I'll also work on getting the source code ready for release to anyone interested in checking it out.

I want to thank everyone in advance. This project has really advanced in a hurry to the point it's at. All the testing and feedback has really helped to make it a very good product. It's amazing that it's as far along as it is in less than one year of development. It's actually been about 10 months.
This couldn't have been done if it were not for the SuperCPU.

07/08/2000...
The Wave B2.5 is released
Most of this info was taken from the Readme file that came with B2.5.
Edited, converted, viewed and Uploaded using Wheels, The Wave and PPI.

I spent a lot of time on the XModem and YModem routines in this release. Several problems were found and corrected.

Sometimes the protocols had a hard time getting started, and other times, they would work just fine. This made the problem hard to track down, but I finally realized that the SwiftLink/T232 was causing the problem. If the user was slow in getting a directory selected, a byte might come in from the other end during the initial protocol handshaking. Not a problem, we can ignore several of these bytes and the other end will wait for us to respond. However, this incoming byte makes the SL/T232 bring the NMI interrupt line low and will hold it low until it's released. When this happens, we won't get signalled when the next byte comes in. So, it appears that nothing is happening and we end up aborting the file transfer.

Other problems occured at the end of an XModem file transfer as well as in between files on multi-file YModem file transfers. Some protocol implementations aren't handling this portion of the protocol correctly. I had to add code to watch for this problem. This mostly occured while doing XModem and YModem over a telnet connection. It's amazing that these even work at all over a telnet connection.

These protocols are designed to be the most efficient when using during a direct dial session such as when dialing in direct to a shell account or BBS. They are much slower when used during a telnet session. This is why the browser transfers data much faster, it's designed for Internet data transfers. Also, when FTP is working, you'll notice how much faster it will be than what XModem and YModem is. I imagine ZModem should also be faster due to the way it works.

A few new features are included in the browser. There is a new "file" menu. You can save the current page to disk now. Just click on "save source" and the current HTML document will be saved to the directory of your choice.

***NOTE***
See the "New in the Wave B2.5" for more on these new features further down this page.

Since we can save the current HTML file to disk, this also means that we can grab any kind of file into the browser's memory and save it to disk, even if the file isn't really HTML code or viewable text. You can click on a binary file such as a ".wr3" or ".zip" file and it will be downloaded into memory. The browser will still try to render it as viewable text, but it will mostly look like nonsense on the screen. Just click on "save source" and the file will be saved to disk.

Be careful with very large files. The browser will use approximately 6-8 times as much memory as the file size to render the file. So, if you download a real big file, you might run out of memory as the browser does its rendering. Just hit the STOP key when the "Loading page" box clears the the render bar starts climbing up on the right. You don't need to render the whole file if you only intend to save it to disk.
If you download a 2 meg file, it might take 12-16 megs to render it. So, be ready to hit the STOP key after the whole file is in memory.

Small files are not a problem. If you download a 100K file, it will only eat up about 600k-800k when rendered. If you only have 1meg though, you'll be in trouble. The Wave eats up about 700K of memory just to get started. 1 meg machines will just barely be able to use the browser, and only with small web pages.

"save source" allows you to save the file that is currently displayed on the screen to disk.
"view source" can be used to view the actual HTML code instead of seeing it in its rendered form.
"render source" can be used to redisplay the page after viewing the source.

This can also be used to force the browser to 'attempt' to provide an HTML display for pages that are missing opening html and body tags. Selecting "save source" has some interesting side benefits. You can edit an HTML document in geoWrite and then exit back to the browser to reload the document to view it as you are working on it. When finished, just save it to disk and it will become a plain ascii file ready to be uploaded to your web site.

Until actual HTTP downloading is ready to go, you can click on binary files that you might find on a web site and load them into the browser even though they won't display anything but garbage. Then you can save the file to disk. The only drawback is that to get back to the same site, you'll have to point and click your way back to it again. When HTTP downloading is fully implemented, the download will go straight to disk instead of to memory and the current web page will remain on the screen.

Another new feature is for web pages that are missing html and body tags. If the HTTP header has a line that says:

I just tested grabbing a file from the Internet, and it was technically from an FTP site. Using the browser, I went to "ftp.videocam.net.au/cbm/" and a directory of files was displayed to the browser's screen. I clicked on a subdirectory to move into a directory containing some GEOS files and found a game with a filename camlled "scoreup.cvt". I clicked on this file and it quickly loaded into the browser. Since I was done with that part, I went ahead and logged off, although I could have stayed online.

Then I saved what was in the browser, to disk. While still in the browser, I ran Convert 2.5 and selected this new file to convert. Then I exited back to the browser and ran the new file and the game called "ScoreUp" appeared on my screen.

This new function will be very handy. No longer are we limited to viewing everything while still logged on. Our pages and text can be saved to disk and viewed later. Plus we can now grab binary files like I just described.

As always, there are numerous little improvements and 'tweaks' to various parts of The Wave. I can never remember all the little things I do. The big improvement to this release is with null-modem connections when used with some Linux implementations. It works nice and quickly now.

In B2.3, I made some improvements to the PPP software. This in turn caused some failed connections for some users. I have corrected those problems and have tested them with two different users that were having problems. If you also had problems getting connected, see if this B2.4 release solves those problems. If not, then be sure to let me know.

I can't think of all the "little" changes that have been made just since B2.3 was sent out, but to give you an idea, The Wave is created currently from 31 different source code files. Changes have been made to 13 of those files.

30/07/2000...
Null-modem works good now
For those interested in connecting The Wave up to a PC running Linux or any other OS that is capable of acting as a server, it's now working much nicer. I'll try to describe why it was acting so sluggish previously.

When we connect to another machine with a null-modem cable, we are doing basically the same thing as if we were to dial out to an ISP through a real modem. The only difference is that a null-modem cable (also known as a file-transfer cable) is used to connect our SwiftLink or T232 to the PC's serial port. The PC acts as an ISP in this case. On my machine I have Linux running and can log into it just like logging into an ISP that provides a shell account. I have access to every file on the PC and all the devices connected to it, including the CD-ROM. By the way, null-modem cables can be found at many computer and office supply stores. I bought one from "Computer Warehouse" and on the package it was labelled as a "file transfer cable" for connecting two PC's together.

I can upload and download files to/from any directory on the PC. I can also run some of the software that can be run from within a terminal window. Almost anything that can be controlled from a command-line prompt on the Linux PC can also be controlled from the terminal in The Wave. I can even have an MS-DOS disk in the floppy on the Linux machine and move files between it and any device running in Wheels. The same goes for the CD-ROM.

Now for the explanation as to why it works good now and why it wasn't working good before. All the communication is handled through PPP packets. This includes the data that is transferred when sending and receiving files and also when a single character is typed. That single character is sent within the data portion of a PPP packet. Every PPP packet begins and ends with a flag byte. A flag byte has a hex value of $7e. A single packet would look like this:

$7e ... packet data ... $7e

The packet data in our case, consists of an IP packet. Yes, one packet is being carried by another packet. In fact, within that IP packet, there is a TCP packet. Within that TCP packet will be the actual data that eventually reaches its destination. So, if I type the command "dir" to view a directory, my typing will be slow enough that the first character, a "d" will go out immediately way before I strike the key to produce the "i" character. Then the "I" will get sent and finally the "r" will get sent. On the PC, the PPP software is receiving the packets and removing the TCP/IP packet(s) and sending them through the system to their destination. Eventually, the first packet carrying the "d" is checked in and the "d" is sent to whatever software on the PC is waiting for it. Soon, the "I" will arrive and then the "r" will arrive. And of course, there will be a carriage return coming in to the PC soon afterwards once I've hit the RETURN key.

After the first character was sent to the PC, the PPP software running in The Wave waits for an acknowledgement packet so that we know it reached its destination OK. This ack packet might be just the acknowledgement, but it can also contain data. It might contain a copy of the "d" character for The Wave to display on its own terminal screen. Or, the "d" character for the screen might be coming in the next packet that the PC sends.

Now, remember when I said a PPP packet begins and ends with a $7e flag byte? Well, the ending flag byte for one packet can also be the beginning flag byte for the next packet. The PPP documentation states that this is not a recommended practice as it could result in lost packets, and in our case that's exactly what was happening. The Linux machine would send an ack packet after receiving the packet carrying the "d" character and then it would send another packet carrying a "d" to be displayed on our screen. To illustrate this, let's look at how The Wave used to expect to see its incoming packets:

That illustrates the whole sequence of sending a "d" character and receiving a copy of it back to display it to the screen. Now, here's how Linux is doing it and you'll see why it was failing for us:

Linux sent two packets one after the other with a single flag byte separating them. On our end, we saw the acknowledgement packet and then waited for the next flag byte. The next flag byte we saw came at the end of the echo packet. So, we completely missed or ignored the packet carrying the echoed "d" character. Linux would sit and wait for us to acknowledge receiving the echoed "d" packet, but we would never send the ack since we never thought the echoed "d" packet had arrived. Eventually, Linux would repeat the packet and then we would see it and things would continue on. But of course, this would repeat itself with the next character. So, communication was very, very slow.

Now, why doesn't this problem happen when connected through a real modem to an ISP? I can only guess that it's because the ISP is communicating with many more computers than just ours. The ISP will send us a packet with a beginning and ending flag byte and then it will go handle sending a packet to another user that is logged in. When it's ready to send us another packet, it will begin with another flag byte. And The Wave sees the whole incoming packet correctly. Now, if we were the only user logged into the ISP at any one particular time, this big slowdown might occur since the ISP's machine can devote all of its time to just our connection. Strange how a smaller load can result in poorer performance. But that's how software works. If one end or the other isn't working right, something's gonna suffer. In this case, the fault is at our end. But not anymore.

The Wave B2.4 has a correction to its PPP software for this to work correctly. It now treats all ending flag bytes as the beginning flag byte for the next incoming packet and doesn't miss a single packet now. I've tested it and notice even better performance on my Telnet connections as well as my HTTP connections. This improves any incoming data that has successive packets coming in that are missing extra beginning flag bytes as described.

28 Jul 2000 12:58:19 +0930
Blank screens an quick render Bars
I might know what is causing some of you to see blank screens and quickly shooting render bars now.There's a new timeout function that occurs if opening a TCP connection to a remote host fails. It makes an attempt to open the connection every two seconds. If after 10 attempts and the remote server still fails to respond, The Wave aborts the attempt.

So, you're going to see this happen when the remote system is either down or way overloaded. Eventually, I'll fix it so you can adjust this timeout, but for now we're locked into how I've got it set.

Also, if your primary DNS server is down, you'll also see this attempt to open a connection to the server. After about 20 seconds, it will switch to your secondary DNS server and use that one for the remainder of the session.

So, if for the very first connection you make after getting dialed in, it seems to be very slow, give it about 20 seconds and then see if it starts working. This is when it kicks over to the secondary server. From that point on, you won't see this big delay.

27/07/2000...
Wave B2.3 released.
You might want to keep a copy of your current Wave128 and System128 files in case this version fails to work properly for you. However, I don't think it will be a problem. This is the first version since this project began that I believe we finally have a good set of PPP negotiatiion routines in it. This version is working great during this phase, and it has always been a problem especially for certain ISP's. There is not really anything new feature-wise in this release. This is just a good clean-up of B2.1 and B2.2. I think we have a good stable system once again here.
I've concentrated primarily on just fixing what we already have and making it better.In the terminal, YModem batch downloads is working correctly now. With some remote hosts, it would only download the first file and abort on the rest of them. Works good now.

Logging into the Internet should be noticeably faster and should work correctly every time. If it doesn't, let me know. I believe I've fixed the lockup problems some users were reporting. If not, post a message in COPS.

There is one new feature in this release worth mentioning. This feature is for those that would like to experiment with null-modem connections to other computers. You can now set up a dialing directory entry to make the connection through a null-modem cable instead of using a real modem. Just add a new entry to either one of the dialing directories, the BBS directory or the PPP directory depending on the type of connection you wish to make. You'll get a prompt asking if this entry should use a real modem or a null modem. It's easy to set it up on our end. Not so easy on the PC.

25/07/2000...
Hangup problems fixed?
I've managed to find a spot in my code that could "possibly" cause a lockup to occur depending on how the ISP terminates the PPP connection. If my thinking is correct, this would explain why some users have lockup problems and other do not. We will find out for sure as soon as B2.3 goes out.

I also made another very important discovery concerning the PPP negotiation phase. When PAP logins are being used, we've always had a problem that would confuse the software running on the ISP's end. Both our end and the ISP end exchange configure request packets and acknowledge each others requests. During these requests, certain options are agreed upon. One of those options has to do with the PAP protocol. The Wave was always including PAP in its request. And so was the ISP. When the ISP requested CHAP, The Wave would send a NAK packet telling it to use PAP instead.

That part was OK, but by putting a PAP request in our own request packet, the ISPs (many of them) would get confused and think we wanted them to log into our own machine! By simply removing PAP from our request packet, this has completely eliminated this problem that would cause negotiations to go back and forth and back and forth over and over until either timing out and hanging up or the user giving up, or one end or the other trying something different to get back in sync.

Login times are vastly improved now. The software that is used on Terry Raymond's ISP has been the most troublesome of all. Some of the other beta testers have ISPs using the same software. You'll see a reference to "Hiper" in the login screen for this software. Terry's ISP is working real good now with this little change.

You'd think that the software on the ISP end would know that it's not supposed to log into our machine and just ignore stuff like that. I think the problem lies with the fact that ISPs use software that is capable of going either way, to be a server or a client.

I've yet to run across any mention in the PPP documentation about the client not wanting to include the PAP request in its own configure request packets. I guess I just stumbled onto this by trying different things.

24/07/2000...
More PPP problems solved
As you all know, Terry Raymond has been having problems logging into his ISP using a PAP login. He has solved his AUTO and MANUAL login method by entering the secondary DNS address as the primary one. Why does this work for him? Because his ISP has been giving out the WRONG primary DNS address! It's not Terry's fault, he's been using what he's been told to use by the "tech" people at his ISP.

In previous messages, I've explained that my DNS resolver wasn't switching over to the secondary DNS server when it discovered that the primary one wasn't working. I've fixed that problem now and if I had fixed it earlier, we would not have discvered that Terry had the wrong DNS address, because the secondary one would have worked as the switch was made.
This is why Terry had no problem logging in with a Windows machine. Windows found the primary address to be bad and switched to the secondary one.
Now for Terry's problem logging in with the PAP method. For those that don't yet understand what PAP is, it stands for something like "Password Authorization Protocol". This is where your username and password are sent during the PPP negotiations. If successful, then your ISP will authorize you to have access to the network (Internet).
I had Terry send me a copy of his ISP directory file so I could test his ISP from here. I discovered that it wasn't the PAP part that was failing for him. The failure was once again related to the DNS numbers. Terry had chosen in this ISP entry to have the ISP assign the DNS numbers instead of entering them into the entry himself. During the PPP negotiations, the ISP was sending the wrong primary DNS address!
I think Terry needs to call his ISP and give them some technical advice.
OK, there's still another reason why this was failing for Terry, and this part is my fault. The PPP negotiations were only requesting the primary DNS address and not the secondary one. Of course, even if the secondary address was requested, it would have failed anyway due to the previously mentioned address switching problems we had.
So, why aren't we requesting the secondary address? Early on in the development of this software, I was requesting both primary and secondary addresses, but it wasn't working for me with my ISP. The PPP negotiations kept on failing. I had discovered that my own ISP would reject the request for the secondary address. When this happens, a new request is supposed to be sent and the rejected item is supposed to be removed from the next request.

So, some more coding was needed to handle this instance. Instead, I worked on other things and just removed the secondary request from the coding altogether. So, all this time, only the primary address has been reqested. It worked for my ISP, but Terry's ISP gives the wrong primary address. The secondary address was never being requested.

So, I finally worked on that part of the code that handles option rejections and re-requests and now it works just like it's supposed to. This particular request begins with asking for three items, an IP address for out system to use while on the Internet, a primary DNS address and a secondary address. My ISP will return a rejection packet stating that it won't send a secondary address. A new request is made for just the IP address and a primary DNS address and the ISP responds with both.

Back when I first discovered this problem with my ISP not sending a secondary address, I called them to let them know about it. Their answer was "Just enter them into the dialogue box yourself, that's why we provide them to you on our flyer". Typical response.
I truly believe these problems have been hindering us all along with some of the failed logins. I think we're getting closer and closer to having a good solid system here.

22/07/2000...
General hints for the Wave and "Logon" problems..
When you do a manual login, you yourself are watching for a "login:" prompt at which point you will enter your username. Then you watch for a "password:" prompt and you enter your password. When you choose the AUTO method, The Wave's login routines are watching for these prompts for you and automatically typing in your username and password instead of you doing it.

Now, if it fails to find these prompts, it assumes the ISP doesn't allow manual logins and will switch to the PAP method. But this is where our current problem lies. For some reason, the software isn't switching properly to the PAP method and getting the PPP negotiations going.

Now, if the ISP supports manual logins, then AUTO is working correctly. It's just not switching to PAP for those ISP's thgat don't work with manual logins.

So, until I get this fixed, if you're having problems getting a PPP connection working, try PAP and try manual. One of those two should work. PAP is the preferred method. If it works for you, don't even bother with manual or AUTO, there's no point in it. But if PAP doesn't work, try manual. If that works, then AUTO should also work.

If neither PAP nor MANUAL work, then you are out of luck, because there's no way that AUTO will work. AUTO is only supposed to work if either PAP or MANUAL works. AUTO is mainly intended to be used so that you don't have to manually type in your username and password each time. Some ISP's support both manual and PAP. And there could be times when manual logins could have a glitch or two. This is why I want AUTO to be able to switch to PAP, to give you another chance to get logged in.

1. Always try the PAP login method first. If it works, use it.
2. If PAP doesn't work, try MANUAL.
3. If MANUAL works, try AUTO.
4. If AUTO works, great. Use it.
5. If AUTO doesn't work, but MANUAL did, use MANUAL only.
6. If neither PAP nor MANUAL works, AUTO will not work either.
7. Change ISPs.

YModem bug fix
I fixed a bug in my YModem routines that I didn't reaalize was there until recently. The problem never showed up when I would download files from my workspace on Delphi, but I was downloading some files from my BBS and discovered there was a problem.

The bug would only occur with certain remote hosts and was only really a problem when downloading multiple files. It depended on if the remote host sent the exact filesize or not.

Anyway, what the user would see is that YModem would abort after the first file was received.

And The Wave will download all of the GIF files from the specified directory. Previously, it would only download the first file and then quit.

18/07/2000...
Wave B2.2 released..
I found a bug in the routines that has been there for quite some time because it was in a routine that I haven't changed for 4 or 5 months. Even though my ISP hasn't failed me, this bug looks like one that could cause confusion for the ISP's PPP negotiation routines. I really don't know for sure until the rest of you try it out for me. I'm hoping that this fix will take care of the ISP's that have been giving us problems with failed PPP negotiations. It looks like something that could possibly cause the ISP's end to try starting the negotiations all over again, and then still failing and either starting over once again or just hanging up.

Wave B2.1 released..
This archive includes 3 files, Wave128, System128, and Headline128. The headline font had a bad zero character in one of the point sizes.

Visually, this version is the same. Rather than adding goodies, I've been concentrating on improving what we already have. The biggest improvement is with the speed of imcoming data from the internet. Web pages load at least twice as fast as long as the remote server isn't too busy. Many web pages that we couldn't load with B2.0 will now load, such as the C=Links page on CMD's site. In the terminal there is less color flicker when the screen is scrolling. There are a number of small fixes and improvements throughout and a few bug fixes.

Some of those sites that you've encountered that won't load or display nothing, or maybe display just a header that says "Connection: close" in one of the lines, will load in now.
One example is geocities home page. I think the programmers of some servers are lazy or something. Anyway, we can accomodate them now.

Here's what's been happening. The browser needs to know how much data to keep watching for as the web page is being loaded in from the 'net. It's like loading in a file from disk. There's eventually going to be an end of file indication. Knowing where the end of the file is on a web page can be tricky. Some web pages are static and have a definite file size. Then there are sites that have pages that can change from one minute to the next. These pages are generated by software. They might also be composed of several files and pieced together to make one file to be sent to the browser. For this method, the server has no idea ahead of time how big the file will be unless it assembles the entire file on memory and holds it until it's sent. But if it sends each piece out one at a time as it creates the page, it won't know the size of the page until it has sent all of the data. Therefore, it can't tell the browser ahead of time how much data to expect.

For those pages that the size is known ahead of time, the server will send the info in the "header" that is sent before the actual page data is sent. The header contains pieces of information that tell the browser if the page was found, how big it is, if it needs to be redirected to another file, etc, etc.

If the server doesn't know the size of the file ahead of time, like I already described, then it will send the data in chunks. At the start of each chunk, there is information on how big this chunk is. The browser takes this chunk and stores it. Then another chunk comes in and it gets added to the data that is already in memory. This continues until the final chunk arrives and the server knows it's not sending any more data. The entire page is now in loaded in memory.

In B2.0, both of these methods were in use and worked fine. But another method which is really kinda simple but a lazy way of doing it wasn't in use because I didn't realize that some sites did it this way. They wouldn't send the size of the data in the header and they also wouldn't inform within the header that they were going to use the chunked method. They would just keep sending data without conforming to the standard. When all of the data has been sent, they would then just close the connection, rather than doing the calculations for the size or the slightly more complex method of handling chunked data.

The browser will now automatically dial out to get an Internet connection when you click on a link if you're not already dialed out.
Within the next day or two, I should be ready to try my first http download. This is where you can download files from web sites. Most of the stuff is ready, I just have to work on a couple more routines. The downloading part is actually ready, but saving to disk isn't. In a sense it is, but the internal communication is the part I have to work on.
What's happening is that the http routines are taking care of getting the data from the Internet into the computer memory. Then the data will be passed over to the same routines that take care of saving downloaded files for the YModem and XModem protocols. It's the passing of the data to these routines that still needs to be dealt with. Plus I've got to add a little more code to make sure we've got all the incoming packets before writing to disk. After the disk access is finished, then we let the remote server know it's OK to send another groups of packets, etc, etc.
There's no limit on how big a file can be that we download. Well, actually there is a limit... 4 gigabytes. I guess that's not really a limit. :)

Our "real" limitation is our storage capacity, currently just under 16 megabytes in a partition. But plans are to incorporate some new disk drivers into The Wave. One of these drivers will allow big foreign partitions to be utilized on the HD. For instance, we could make use of a whole 100mb partition on a Zip disk. Or a 500 meg partition on a 4gb HD. The only drawback is that these partitions will only be usable while The Wave is up and running. But you'll be able to copy files to/from other drives.

First of all, if you've been to GO64's site and clicking on "links" near the top of the page, you'll notice that there's a problem loading this links page. This has been driving me crazy trying to figure this out. I don't think the whole problem was in the way The Wave was getting the data in, but some of it had to do with the way data was handled on the server's end too. In any case, some fixes on our end has taken care of the problem.

I traced this down to the server (at least this is what it looks like to me, I might be wrong) only dealing with 64K of data at a time. This includes the approx 62K file size of the page plus the extra bytes needed to wrap up each packet into TCP/IP packets.

Near the end of the file we would always get a RST signal from the server. I tried all kinds of things to figure out what the server was wanting to do. The only thing I could come up with was that the server wanted a new connection and to fetch the remainder of the file in another session. "Back to the drawing board".

I started studying my SwiftLink code because I also noticed that there were a lot of discarded packets being received. Any time a packet is received that has errors it gets thrown away and a replacement packet comes in to take its place. I've noticed this problem in a lot of data transfers.

I had already spent a great deal of work on the interrupt handling of the SCPU. I've fixed the NMI lockup problem that exists in the V1 SCPU with some software routines. But for some reason we were still getting lost incoming bytes. Anyway, without going into too much technical details, I found a spot in the SwiftLink driver where we had the possibility of losing a byte whenever a false IRQ occured. I fixed it and lost bytes are now a thing of the past.

This change along with the interrupt fix in the SL driver not only speeded up data transfers over the Internet, but it also fixed the problem I was having with the server handling the GO64 links file!

08/07/2000...
COCOS and the Wave Browser
I checked out the "COCOS" site and sure enough, it's a site that makes the browser crash. I downloaded the page to have a look at it. This uses a table layout with embedded tables, which is OK, but there's some stuff that the browser doesn't deal with very well yet.

What's really messing up the browser is the heavy use of "WIDTH=1" when defining the width of a table cell. This is OK where they are only using a cell as padding. Quite frequently they put a 1-pixel wide gif image in to fill the cell and the alt tag specifies just one space character. That's OK...

But they also define some cells a 1 pixels wide and then try to stuff other things in like text and even complete tables containing other text. I've seen coding like this on other sites. I wonder why they don't define the table cell more accurately? Could it be laziness?

I'm guessing that they feel as long as the browser can determine the width of the cell, then it's OK to define it as 1 pixel wide. If that's the logic used, then they shouldn't define a width at all. The way I see HTML coding is that if the web page author defines a cell width, this is the width that he wants it to be, period.

I've been avoiding making the browser do two passes through the tables to render them, but it looks like it's going to be necessary in order to figure out the correct size of each cell. Strange how we can't get away with poor BASIC programming, but we can make bad HTML code and get away with it.

If anyone has browsed on over to Ismael Cordiero's site, you'll find that it contains one of the largest collection of links on the planet. This is the only site I've found so far that maxes out the memory allocated for the link database.
When the browser renders a page, it creates a database of hyperlinks in memory. The database includes the href string and the coordinates of the location on the display where the link is located so that the browser knows if the mouse is passing over a link and it also uses this info to highlight the link.

Currently, up to 64K of memory is used to hold this database. Ismael's page is big enough, with so many links, that it requires more than 64K to hold all the info. So, I'm going to fix it so that the database can use more memory when needed for sites like this.

In the meantime, there a workaround. When the page renders (and it takes a bit of time, be patient), it will keep building the database until it fills up this 64K and then it will start filling from the beginning again. So, only the links from about 1/3 of the way down the page till the end will be correct. The first 1/3 or so will be wrong. If you want to click on one of the links in the first 1/3, reload the page and while it's rendering, hit the STOP key before it finishes. The page will stop rendering and all the links up to that point should be correct.

04/07/2000...
Date: Tue, 04 Jul 2000 14:37:48 -0400 (EDT)
I finally found a bug that's existed for awhile now. You'll notice it happening only if you have a real big web page loaded into the browser.

What triggers it is when you then go into the terminal and do some telnetting. When you exit back to the browser, scroll down about 5 screens (10-11 on the 64) and you'll see some trash on the screen.

It appears to only be a cosmetic bug, so I wasn't too concerned about it. I found the problem to be in the TCP code. After closing a TCP connection, I didn't fully deallocate the memory that was used by that connection. The web page would end up using this memory when displayed. Then the next TCP connection in the terminal would reuse the same memory which was now being occupied by image data for the currently displayed web page. The result is that the image data would bet trashed.

Both the 64 and 128 versions of The Wave B2.0 went out this morning.
It seemed like one thing after another getting this release ready to go. Everytime I fixed something and tested again I'd find something else that needed attention. I thought this would go out Saturday night, but you know how that goes. :)

There are still a few troublesome web sites, but not too many. I still can't get Centsible Software's home page to display correctly. The 64 page there comes out OK, but not the beginning index page. Maybe we can get Scott to fix it for us.

Loadstar displays quite nicely now. The Videocam site works great and navigates well. CMD's site works good, except that the C=Links page won't come up. Apparently, that page is looking for something that I'm not sending. I haven't taken the time to figure it out yet.

Any web site that follows good rules and is properly coded will display correctly in the browser. Sites that have messed up code might still display OK if the errors are something that the browser is trying to detect. You might run across sites that have errors that the browser can't deal with. This is really not a bug, but rather bad HTML code. Somehow we have to deal with this stuff and the browser will get smarter and smarter as it develops further.

Even AOL's home page comes up looking halfway decent considering how congested it is on our 320x200 screen! And the same for Delphi's home page. It's congested as all get out, but it displays on these low resolution screens much better than you would expect.

On the browser screen, you'll see some new icons. Only one of them is functional at this time. The one that looks like a little "Wave" logo will bring up your START64.HTML or START128.HTML file at any time by simply clicking on it. This is handy for getting your favorite links back on the screen.

LEFT ARROW icon: This will redisplay the previous HTML page. RIGHT ARROW icon: If the back icon was pressed to display the previous HTML page, this will go forward in the list of pages. TWO CURLED ARROWS icon: This is the reload icon and will reload the current HTML page. Use this if you pressed the STOP key to halt an incoming page and wish to reload it. HISTORY icon: This is to the left of the URL bar. Clicking on this will display a list of your most recent HTML pages. They will be displayed as hyperlinks to click on. URL SCROLL icons: To the right of the URL bar are two arrow icons. Clicking on these will scroll the URL bar left and right. This is handy for when the URL is too long to fit and you wish to read the remainder of it. When you pass the mouse over a long link, the cursor keys will serve the same purpose.

-Maurice

I forgot to mention about another reason some pages aren't being rendered at all. An HTML page is supposed to begin with an HTML tag. Otherwise, it's just a text file. There are some pages like this. Bo Zimmerman's site begins with a page that doesn't have the html tag starting out. Funny though, it ends with a closing html tag. Jim Caldwell also has a page like this that I found. In Jim's code, the http header states that the page was created by www.homestead.com (this has nothing to do with our own Homestead mailing list). So, commercial sites that will generate a page for you may not do a very good job of it.

Currently, we've all seen the dialogue box that comes up that tells you this is not an html file, would you like to view it anyway? This is handy for displaying any text file, even petascii files. But what I'm going to do is change this DB to give you the option of displaying the file as-is, or attempting to display it as html. This way, you'll know when you've encountered a site that isn't written correctly.

You are probably all wondering how B2.0 is going. It's coming along nicely. I had hoped to get it packed up and emailed out to everyone at least by last night (Saturday), but I'm finding things that need fixing.

Then I found that even though anchor references such as those links that begin with # were working, they weren't working if the reference immediately followed a domain name. For instance, one of the links on Randy Harris' site looks like this:

I had to add code that broke that line up correctly and now it works fine. It will go to the start page on the videocam site and once loaded, it will look for an anchor that matches "Videocam Home Page", although it appears this anchor doesn't exist, but the page comes up anyway.

The biggest problem I'm having is with sites that have syntactical erros in them. Errors in tables are crashing the browser. Centsible Software's site crashes the browser because it's table layout is bad. From what I gather by looking at the page's code, it looks like the intention was to put a narrow empty column on the left side. But it's missing a closing cell tag and then the next table begins within this cell. But the table is supposed to be wider than this cell, so it scrunches it way down in width. This page displays OK in Netscape, so apparently Netscape watches for bad code and accomodates it. I need to add some code to better watch for errors also. Then with the rest of the table code in Centsible's page, the browser ends up crashing.

Another page that crashes the browser also has to do with tables, but was not created by Front Page. The CBM LINKS page on the videocam site has what is supposed to be a table at the bottom of the page, but it's missing a starting table tag and then missing a row tag. Then the browser encounters a table cell and since a table hasn't really begun, it crashes due to a stack error.

The browser ignores closing tags if a matching starting tag wasn't in use, but I didn't think about opening cell (td) tags being encountered when there wasn't an opening table tag or row (tr) tag yet.

Then there are some pages that just don't render at all. Of course, they may not have errors in them. For instance, I'm not done with supporting the FRAMESET tag yet. So, any site that uses frames won't render yet. Instead, you'll just get a display of the actual HTML code.

Sites that require the browser to send info explaining what the browser is may not display because the server may not send the page at all. The Wave currently isn't sending any info on who it is yet.

23/06/2000...
I've been working on the DNS resolver some more. I've discovered that even though the telnet app worked fairly good with it, the browser needed the resolver to be much more functional. The work I've done should also fix the problem that Bruce Thomas has had in accessing edmc.net.

Today, I was able to click around Loadstar's site, plus I've accessed Randy Harris' pages (SWRAP club) on AOL and clicked on some links from there.
With a little more work, I might be satisfied enough to turn B1.9 loose to all the beta testers. Maybe I should call it B2.0 since it will be the first version where the browser can get online.
After this release, I'll see about getting a null modem connection going here to get that aspect of this thing working good. Then I'll finish up a couple of things the VT100 routines need. And finally, I will make a simple installation program to supply with The Wave and I'll get the very first public release out for everyone to enjoy.
All you beta testers will end up being the "technical" experts on The Wave. There's going to be a lot of new users soon. I'm sure we'll get bombarded with questions.

16/06/2000...
June 15, 2000 at 9:20 PM EST..
Wave64 grabs its very first web page from the Internet.
I visited Rod and Gaelyne's videocam.net.au site and pointed and clicked my way around for a few minutes. I even found a link there to Colin Thomson's site and checked out some news about The Wave!