Sun Oct 14, 2007 - 18:19:06

Oops. I feel silly. I had removed the code to add/remove my Caller*ID and Serial LCD/VFD programs from the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key due to the code being "broken" under Windows 2000. It would seem that the only reason it wasn't working was that I used a leading backslash (\) in the subkeyname (\SOFTWARE\... instead of SOFWTARE\...). With the leading backslash removed, the code works as it did under Win9x.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:06

Oops. SPoke too soon on the "bugs" in the Caller*ID code. With the additional code to fix the memory access violation, I forgot to advance the pointer to the end of the strings that are auto-loaded in place of the CID data. So, when a no name or no number packet came in, the fields were filled and then the first character of the string was cleared. Problem fixed.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:06

Just completed another revision of the PHP script generating the "news" page. Not sure if this will be the final product or if I will play with it more. I'm sure someone will let me know if they think this is hideous.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:06

Last night, I participated in what turned out to be a rather lame online chat session involving 2 members of NVidia. The "chat" was held at eVGA and was run through a some sort of Java based chat program on their web server. The NVidia guys found time to reply to questions with "we cannot comment on that" answers. They also answered some other questions, but nothing ground breaking. Only 1 of the questions I sent was answered while other participants somehow managed to get several questions answered. It seemed to me that I was being ignored because I was trying to ask the questions that the real end-users wanted to know answers to. When the "chat" ended, I was left with the feeling that it was a joke. Perhaps I was simply not important enough, since I wasn't running a major news site or producing NVidia based products. No, instead I represented the consumer. While I still believe NVidia has the best products for my graphics use, I am rather unhappy with their public relations. Whether or not this will change is anyone's guess. Until the next time, I'm done.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

I'm still in the freezing lands of the north. :) Ok, so it's really not that cold. My computer seems to like it though. That is, I'm an overclocker, and the CPU/case temperatures are cooler than they would be if I was "home". Anyway, I did a little bit of work today on my serial LCD display program. Previous versions either limited the number of display data to 255 or 1023 (depending on how far back you go). As of today, that limit is gone. I never reached either limit, myself, but I figured I'd better put something in place to allow for future expaqnsion. Welcome the linked list alternative. I intend to design some sort of script language at some point and needed a way to ensure support was in there for whatever size script was tossed it's way. On another note, I've been playing with the 2.6c source for the Atari800Win project. As I had some minor add-in features on my old 130XE, I thought it'd be cool to code them into the emulator. My end goal is to also add TCP/IP interfacing through the use of the R: device and 65c816 CPU emulation. I know the 65c816 isn't really needed, but it'd make for a good development tool. The TCP/IP support, however, would be sweet for running an old Atari BBS on the internet without actually needing to hook up an Atari and interface it with a PC. At this time, I'm trying to debug my 1088k code modifications (though a 1MB RAM disk in that emulator isn't needed, so I may just pull it back down to the 320k). As soon as I have some sort of stable code changes, I'll make them available on here.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

Thought I'd died? Perhaps you thought I'd forgotten about my own news area? Not at all. I simply didn't have anything worth adding. That is, until now. Playing with a 2x40 LCD display on my laptop, I decided to port my serial interface code back to the parallel interface. It was easy to do as I'd simply written serial I/O routines in place of the parallel I/O routines that I had been using. Anyway, that's not the important part. I discovered that my Athlon system, under Windows 2000, was somehow hiding a couple minor bugs that had been in the code. My K6-3 laptop, running Windows 98SE, promptly showed me the issues. I believe that I have squashed the remaining bugs in the code. They resided in the variable processing and token expansion functions. All is well, on both parallel and serial versions, at this time. I may still have an issue with the Caller*ID pop-up, but the shared memory code seems to be working perfectly. In any case, enjoy the fruits of my labor.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

After having had a major filesystem crash, I'm almost done with rebuilding mysystem. Having never made backups of things (like my own web site), I havebeen forced to use data recovery software to get as much as I could. The newsfiles, fortunately, had the dates of the entries as the filenames. Thetimestamps, however, were on the file entries, thus they've all been reset.Lesson learned, though, is that I will make backups after everything is backup where it needs to be. I won't have a 6 week down time again.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

Caller*ID code updates continue. Most recent changes are in the shared memory handling and window size/position calculation. As I use WindowBlinds to change the look of Windows, I discovered a few quirks with how it effects window sizes. I'm still trying to compensate for the problems that have surfaced. It's funny that some software companies still blame others for the problems that show up in their software. As a programmer for the past 15 years, maybe I've just learned that what works for one (or several) doesn't mean that it works for all. Some of my own code would work perfect for me and couple others, but have troubles for some. I took responsibility for the issues and fixed them in my code. I didn't send them elsewhere.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

A long time ago, I'd say a minimum of 10 years, I was addicted to a game called Alternate Reality. I played both The City and The Dungeon on my trusty Atari 130XE. Recently, I found a site that had the disk images of The City and The Dungeon for the various systems that they were available for. After trying and finding that the Atari emulator doesn't quite display things properly (a bug in the video emulation, I assume), I downloaded the Amiga version of The City. Having been so long since I last played, I basically forgot the layout of the map and where everything was. So, I went looking for a map. I found a few, but none of them gave the level of detail that I was looking for. I did, however, get an AmigaBASIC program with one of the maps I found. This program was used as the base for what I wrote. Still, that program only looked at the wall definitions. It then added location markers based on it's own data. Following the same principles, I wrote a Windows program that did the same thing. I wasn't satisfied with that and kept adding to it. I had added code to tell you the name of each map coordinate as you moved the mouse over it. Still, that just wasn't good enough. After hand coding map coordinates for everything, I should have been happy. I mean, move the mouse over coordinates 30,40 and the titlebar reads "Tail of the Dog Tavern" which is what is there. But, without actually sitting down in the game and making sure I walk into every single coordinate location, my map just wasn't going to be 100% accurate to what the game sees. Thus, in my boredom on the weekend before I head home, I decided to have a look at the raw data for the map and see if there's anything I missed (especialy since there are whole sections of the map that we simply can't reach). I discovered that the author of that AmigaBASIC program may have done a good thing, but he was also in error. The map is made up in a grid of 64 by 64. Each cell in the grid is 4 bytes. The AmigaBASIC program was written on the assumption that the walls were defined in the 3rd and 4th bytes of each cell. This was wrong. After looking more carefully at the raw data and going on my actual knowledge of the map from game play, I discovered that the AmigaBASIC program was based 2 bytes off on the map array. Instead of the 3rd and 4th bytes defining the walls, it is actually the 1st and 2nd bytes. The 3rd byte is an index into an array of names. The 4th byte is split into separate nybbles (as is the 1st and 2nd bytes) with the lower nybble being the location type. The high nybble seems to be some sort of secondary type value, but it's exact use if still unclear to me (except if it's a value of 2, which happens to be a "dead" area of the map). The resulting program is here. Source for this map viewer is available upon request. Please forgive the legend window. I should generate a bitmap of what is actually displayed and use that. Instead, I have a somewhat sloppy text display that probably relies too much on the system metrics (in other words, it may not look right on your system).

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

Found a slight bug in the Delayed Startup code. While it worked fine for me under Windows 2000, it wasn't too happy with Windows XP. Of course, I had reports that it wasn't working well for another user under Windows 2000, so maybe this will fix it up for everyone.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

Split the "news" off to it's own page and started using a PHP3 script to generate the new style/page. The script is not yet in it's finished state, so expect changes to occur over a period of time.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:07

Serial LCD program updated a bit. Some basic script functionality is in there now. Download it and check the documentation for the details.

Submitted by: MageX

Sun Oct 14, 2007 - 18:19:08

Just finished another update for my Caller*ID program. I finally took the time to compile up a debug version and find where I was getting the memory access violation at address 0x00000000. Turns out, I wasn't initializing a pointer when the no name and no number packets were being processed. That's now fixed, and I hope that means the program is now fully stable (but I'm not going to make any promises on that). Also, while I was in the coding mood (trying to keep my mind off of the World Trade Center incident), I added the ability to select one of 5 different display colors (red, green, blue, yellow, and cyan). I may, in the future, add a 6th choice for user defined. As of now, all the color modes use a black background. However, since the full source is being distributed here, anyone with Visual Studio (version 6 or later, I assume) can customize the colors as they see fit. I don't wish to create a monster of a program (it's currently a 60K executable), I most likely won't add anything else. If there are any bugs remaining, I'll do my best to fix them. As to features, however, I don't see any reason to add anything else. If this is being used in a commercial environment and more than 4 ports need to be monitored, the code should be easily modified to accomodate the situation. The "Run at StartUp" option will, eventually, have code behind it. It used to work properly, but I still need to write Windows 2000 compatible routines to add/remove entried from the HKLM\Software\Microsoft\Windows\CurrentVersion\Run registry key. The method I'd been using wasn't the right way, I guess, as it simply didn't work except in a Win9x system.

Submitted by: MageX