Vinyl Goddess on YouTube
May 12, 2008
I have written about DOSBox in the past and I have nothing but good things to say about it. It’s a great project whose people continue to push for greater compatibility, speed and functionality. Over the weekend, I tried to use DOSBox as a development environment for compiling DOS applications using the DJGPP 32-bit compiler and associated development suite such as RHIDE, Allegro, GRX libraries, etc.
Sadly, it didn’t work out so well since a number of common tools simply didn’t function that well in v0.72. I’m not terribly disappointed, since the emulator takes forever to compile a project in its environment, and wouldn’t be suiteable for long term development. I’m raising the issues here in case anyone tries to use DOSBox in the same way.
First, let’s talk about what did work. DJGPP for starters. It works just fine; albeit, the compilation and linking process does take a while. Some might argue that this is all you need to develop a project, and while that might technically be true, it certainly doesn’t work out for anyone trying build something more than a “Hello World!” application.
So, what didn’t work? Well, I tried four different editors: edit (the one which ships with your MS-DOS operating system), TDE (Thomson-Davis Editor – one of my favourites), MEL (Multi-Edit Lite – another great little editor), and RHIDE (the development environment which you can install alongside DJGPP). I didn’t try VI/VIM, but I might sometime later just because I’m curious.
First out of the gates, Edit simply wasn’t suitable in an environment where tab characters are important. It simply replaces them with spaces and continues on its way. Too bad since the editor is simple and to the point. Although, it really isn’t a good solution since it lacks one of the most basic development features like syntax highlighting.
DJGPP makefiles will not tolerate spaces when there should be tab characters. No, it’s not being quirky, it’s in the POSIX standard after all but it doesn’t make it any less annoying. So, the solution is to switch to an editor which respects tab characters and does not try to convert them to nasty spaces. So I jumped to a more sophisticated editor: TDE. Sadly, I was let down again, due to a bug (could be within TDE or DOSBox) where the cursor was not visible while using the editor. It was a little like fumbling in the dark trying to find that blasted light switch.
After some research I found MEL, so I installed it and tried it out. The editor was well laid out, the cursor showed up, and it respected my tab characters. Super, finally something I can use! Alas, I soon discovered that our relationship would never last. You see, MEL doesn’t use tab characters out of the box, you need to turn it on through one of the configuration dialogs. No problem, right? Well, it doesn’t seem to remember the setting once you save it, so you need to set it every… single… time you load the editor. Hrrmph.
“Well, it’s time to bring out the big guns!” I thought. I had used RHIDE in previous development projects and found the environment quite enjoyable for the larger ones. I typed in the command to fire it up and… whammo! Congratulations, it’s a bouncing baby SEGFAULT. Sigh. I don’t know about you, but four editors is enough experimentation for one day. If you find an editor which works well and meets my humble requirements, please post it in the comments.
Anything missing which should be added? Well, you’ll certainly want to add in some basic DOS utilities such as XCOPY, DELTREE, ATTRIB, and what not. It will make your life much easier. It would also be great for DOSBox to incorporate a configuration reload command, so you don’t need to exit the emulator in order to reload the preferences file. For now, I’m going to use one of my older development boxes for this software project, and stick with DOSBox to run my games.
PGP: Source Code and Internals
April 28, 2008
My copy finally arrived the other day and I am elated. Now, before you make another hasty buying decision based solely on my opinion, and on a single line of text, there are a couple of things worth mentioning about the book. First and foremost, the book does lack a few structural elements like plot and little things like paragraphs. Having read about the history of Philip Zimmerman and his toil with the U.S. government, I already knew this before I purchased the book.
It does contain source code. Lots of code. The entire PGP program, in fact, including the project files. The book was sent to print because the digital privacy laws the government was attempting to enact at the time, did not cover the printed page. If all you want is the source code, you can simply find it on the Internet. Looking for a specific version, especially an older version, is more difficult and may be fraught with export restrictions.
The story behind the printing of the book is a fascinating history lesson and one we should all be concerned about, even if you live in another country, since we all know governments are not terribly adept at learning from their mistakes.
TheDraw for DOS
March 10, 2008There are two ways to display graphics in DOS. The first involves getting out of text mode and setting the desired graphics mode and then drawing pixels on the screen via the BIOS or writing directly to video memory; the second method involves drawing with the set of ASCII or extended ASCII characters. You can also make use of ANSI escape sequences to control the cursor, display coloured or blinking text, etc. DOS requires an ANSI driver in order to translate these escape sequences. These character codes are non-intuitive and look something like this: ESC[=5;7h. I swear my cat coughed up a fur ball which looked exactly like that the other day.
The set of extended ASCII characters provides an easy way to draw connected lines within the grid of displayable characters. This grid changes in size depending on the video mode set. With the default video mode in DOS, the dimensions of this grid is usually 80 characters wide by 25 characters high and covers the entire screen. Naturally, these characters can be connected to form anything from boxes to mazes. It’s how all those menus and dialogs are drawn when using a program like QBasic.
TheDRAW is a program which allows you to paint a picture using a variety of special characters. It’s not like painting individual pixels, you are limited by the set of characters available. However, this hasn’t stopped ASCII artists from creating fantastic content. The most stunning examples I found were on Bulletin Board Systems which used them to attract new and repeat visitors alike. The ANSI art found on those systems were often themed according to design of the on-line system or the whim of the system operator. Using TheDRAW, these pictures could be exported as ANSI-compliant or ASCII text files, or as header files to be used in other programming languages. There are a number of small tools available for translating these files into other formats used by other programming languages.
Many of my programs in QuickBasic took on a more professional and uniform look because of this spectacular drawing tool. I still find it the best tool available for doing this sort of work in DOS, although I’m sure many of you may prefer other programs.
When I began to write software using The C Programming Language, I used TheDRAW to create a title screen in a number of small programs (the concept of a splash screen hadn’t been introduced yet). Although most dialogs and windows I used were crafted in code using a custom built user interface library, the more complex dialogs were created using this application. To allow for input or interaction, the fields were marked by a special character, followed by a small series of alpha-numeric characters. These markers would be found by the interface library and the characters following the marker would correspond to a header file which linked the “names” to constants and then to user interface controls and data structures.
The output from TheDRAW was compressed and archived in a separate resource file to keep them from being easily pillaged by unworthy scavengers. I’m not an artist so it may have been overkill.
Portable Computer Console
March 9, 2008
Computers like the Atari 800, Commodore 64, or Amiga 500 share a special place on my gaming mantle. The specialized sound and video hardware can make all the difference when experiencing old and new games alike. However, there are times when they really begin to show their age. Of course, being old is never a problem here, but it is when you’re trying to mesh the old with the new. Take the Atari 2600 console, for example. I just recently installed a nice little hardware upgrade which provides the console with the technology to output a composite or s-video signal. The composite signal looks good on a normal television; the colours are clear and sharp and the signal is strong and healthy. When IÂ plug the cable into my high-definition television, suddenly things start to go very wrong.This doesn’t necessairily mean it’s the console’s fault or a poorly installed hardware mod. In this case, it’s probably something the television is doing. Most high-definition televisions have electronics which pre-process the video signal before it is sent to the display. These processes, or filters, can help clean up the signal or enhance it to make it look good on your high-definition screen. The hardware is normally tuned to your specific display, so the number and quality of the filters can vary from television to television. One of the downsides to this technology can be increased blurring, shifting, or muted color when you’re trying to view a low-definition signal, or a signal that the hardware deems to be unclean or poorly formed. The filters kick in to help fix the problem but it really only serves to exacerbate the situation. Some of the filters seem to designed for higher resolutions, and only serve to degrade the visual quality of the lower-definition signal coming from your console.
Wouldn’t it be nice to have crisp, clean, beautiful colours shown on your high-definition television? Of course it would, and there are options available to you. One option is to support the services which provide these games to you on your high-definition console. The Nintendo Wii and Microsoft’s Xbox 360 both provide on-line shops for you to buy these titles. However, when compared to the sheer number of classic games available, the companies simply do not have the money, desire, or the ability to offer anything more than the most popular titles for the most popular consoles. Sometimes I like to play games which will never be discussed in the forums, and I would bet one of my cats that these titles will never see the light of day through these services. It’s not a case of simply choosing one over the other; I support these services whenever I see a title I would enjoy playing, but the release cycles are too few to satisfy my gaming needs.
The solution for me was the personal computer and hardware emulation. I had specific requirements for the physical size, number of available ports, and driver compatibility. Those were the three biggies. I could ramble on about the time I spent searching and testing different machines, but I won’t bore you with that. No, you’re reading this blog for results. The machine I chose to go with is the AcerPower 1000 computer. It’s smaller than your average DvD player, performs well using under low power consumption, and runs very quietly. It also has oodles of USB ports for lot’s of expansion possibilities. I needed the machine to support at least two joysticks (along with the USB keyboard and mouse), and I wanted those ports easily accessible. The AcerPower has four high-speed ports right in the front of the machine which was perfect for my needs. It also has 3D support using an nVidia GeForce 6150 chipset and full environmental audio; I tested the graphics chipset with the Ion Storm’s Deus Ex and it ran very well at 1024×768. So long as the software can support one of your television’s video modes, everything should work out alright.
Wii Hardware Hacks
February 7, 2008Atari 2600 4-port S-video and Composite Mod
January 22, 2008Eternal Sonata
December 19, 2007Too Much for a Blanket?
December 13, 2007QBasic
December 5, 2007
When I mention QBasic to some people, they immediately think I’m talking about Quick BASIC. The two products, however, are a little different. They were both created by Microsoft but Quick BASIC is basically a super set of QBasic. QBasic has an interpreter and an editor built as one package; I hesitate to call it an IDE since your projects could only use one module at a time. It was also limited in the amount of memory available to the program and the amount of memory available to the editor. I experienced the latter problem only once while creating a game involving viruses and robots (I didn’t get around to naming it); the editor just started losing lines of code I had written and was behaving eradically. Eventually, I became frustrated and moved on to other and presumably smaller projects.
QBasic made its first appearance with MS-DOS 5.0. It came with a few example programs and games. One of these games was called Nibble. I love this simple game, even to this day. It’s a little similar to games like Centipede, although the game itself is far too simple to make a reasonable comparison. The goal for each level is to gobble up the numbers that appear in random locations. Each time one of those numbers gets consumed, your “snake” grows a little longer. You have to avoid running into the walls of the level, which get more complicated as you progress, and you must not run into yourself. As you attain higher levels, your snake becomes faster and faster. This game was never synchronized with the system clock, so if you play the game on a machine made today, it would move around so quickly as to render the game unplayable.
I have often thought a game like Nibbles would make an excellent game to practice your porting skills on other platforms. It is sufficiently interesting to make the project worthwhile and could be adapted to play well using almost any input device. It could also be rendered using a simple text mode, just like the QBasic version, or you could enhance it in a graphics mode using imagery, vector graphics, etc.
QBasic also introduced the concept of functions and other forms of structured programming. GW-BASIC could only remember and execute your program if each line was prefixed by a number, or right away if you are using instructions in immediate mode. As you added and removed lines from your code, there were a couple of functions to reorder or renumber your line numbers when you ran out of room.
The concept of a function didn’t really exist in GW-BASIC; instead, it allowed you to jump to a particular line number using commands like GOTO or GOSUB. The latter was more like a function since you could jump to a specific region of code and then return from that function when the code had finished. GW-BASIC also supported one line functions which were handy for calculations. Although QBasic could still use line numbers, it encouraged the use of named labels for functions instead. Despite my work with Amiga’s BASIC, I still preferred the old way since I had been doing it for so long. It took me a while to adjust to the new program structure at first, so I purchased a new QBasic book after upgrading and essentially dove in head first.
Interrupts would become increasingly important for me in the future, but at this time I knew little about them. QBasic had no direct interface for handling interrupts, but it could handle interrupts used by the system’s timer:
ON TIMER(n) GOSUB MySubRoutine
Having no functionality to manipulate interrupts meant there were no functions to gather information about input devices like the mouse. Despite this seemingly major failing, all was not lost. While it could not handle input from the mouse directly, you could make use of a machine code sub-routine which could get the information you needed, like position and button states. You could use techniques like this to gather information from other devices.
QBasic also introduced me to one of the greatest time saving features ever created: the debugger. A debugger can be a separate program or feature within an IDE which allows you to trace through your program and examine variables and addressable data as the software executes. One of the core features of a debugger would be the ability to set a break-point at a specific addressable location that corresponds to a precise line within your source code. Before debugging, I was tracing through my program by hand and using PRINT commands to dump the contents of a variable. Even today, there are professional programmers who don’t use a debugger, either by choice or lack thereof, and choose to examine how there software operates by sending information to a log file or an output stream of some sort.
