Stuff

VirtualDub 1.9.4 is out. This version contains only bug fixes and is the first stable release in the 1.9.x series.

Um, I guess that's it.

A mini-FAQ for this release:

Q: What happened to the "defer this job" checkbox in the save dialogs?A: I took it out because there were too many people who were checking it and then not realizing that it saved, and then thought the program was broken because it didn't do anything on a save operation. The batch commands have all been moved into a "Queue batch operation" submenu. Since this is less convenient than the previous location, 1.9.4 now allows you to configure keyboard shortcuts for any menu command in Options > Keyboard Shortcuts. This allows you to access the batch mode Save as AVI command directly.

Q: Does VirtualDub work under Windows 7?A: Yes, I have been testing VirtualDub under the current Windows 7 Release Candidate. In fact, all versions of VirtualDub work on both Vista and Windows 7 RC, although there are a few minor glitches that have been resolved in recent versions. Unless otherwise stated, you should assume that VirtualDub runs on any newer version of Windows. I don't target specific versions of Windows and try not to write code in a way that would break in the future.

Q: Does the AMD64 version work on Intel processors?A: Yes. It's called AMD64 because that was the original name of the platform before Intel adopted it as EM64-T, but the 64-bit version runs the same either way. Microsoft changed their platform description to x64 to be more politically correct, but it's the same thing.

Q: Is your program available in DLL/OCX form so I can embed it in my app?A: No, and I have no plans to do this. The embeddable interface is to invoke vdub.exe or VirtualDub.exe with command-line options.

I received an email from a user saying that a build of VirtualDub doesn't work under Windows NT 4.0. Well, not that NT 4.0 is in common use anymore, but current versions are supposed to support it, so I figured I'd take a look. Start Virtual PC, create a new VM, new virtual hard disk... heck, let's give it 8GB. XP's not workable in that, but hey, this is NT4. NT4 is compact compared to XP.

Suck!!!!!!

Turns out that the system drive has to be under 7.8GB for this build of NT4. Now that I think about it, didn't I have a 100MB drive when I ran NT4 Workstation? And something like a 486 with 20MB of RAM. I think nowadays I could boot NT4 in solely in L2 cache.

Installing NT4 was a real nostalgia trip. Oh right, you actually have to scroll down the entire EULA before you can press F8 because they think that ensures that you read it. Service Pack 1, hmm... well, at least it's not Service Pack 4. Ooh, I can actually choose not to install things. Phone dialer? Don't need that. Object Packager! No.

I have fond memories of NT4 because it was the first time I had a decently well protected 32-bit programming environment. When I mean protected, I mean the computer being protected from me, as in I couldn't accidentally memset() over the kernel database anymore. It took a bit of getting used to, because drivers were sometimes hard to find and install, and the only accelerated 3D game you could play was Quake. It didn't matter, because with NT4 you could write for Windows 95 without having to do it on Windows 95. That was golden.

(The reason VirtualDub 1.9.3 doesn't run under NT4.0, as it turns out, is that I accidentally snuck in a call to MonitorFromPoint. I'm SO going to put in import checking into the build.)

VirtualDub 1.9.3 is now up on SourceForge. This release primarily stabilizes functionality added in previous experimental releases and is intended to be a test candidate -- if all goes well 1.9.4 will be released as stable.

This version is also the first version with 3D acceleration support. 3D acceleration support requires filter support and is currently implemented in seven internal video filters. Because video acceleration quality and speed can vary based on video card and driver version, it is disabled by default unless enabled in Options > Preferences > 3D Accel and should be tested locally before use. I'm afraid that documentation for the VDXA interfaces on the filter side are not yet complete, so if you are a video filter author interested in implementing support, please contact me for details.

My 8-bit Atari computer emulator, Altirra, now has a home. You can find it at the bottom of the nav bar on the left. I finally got around to doing it since I don't frequent AtariAge enough to actually participate much there, so I needed somewhere else to put updates, and this blog isn't a good way to keep a permanent link to tip. I was going to do it via a second blog, but after running in circles trying to configure it, I gave up and just made it a static page. There's a reason I work on client-side software.

Anyway, while I was at it, I threw the release switch on the dev directory and posted a new version, Altirra 1.2. Most of the changes are nitpicky emulation fixes, and not too significant unless you have something that actually cares that changes to VSCROL are checked on cycles 108 and 0 of a scanline. A significant change, however, is that I added 65C816 support. The 6502 was first extended in the 65C02 by the addition of some useful opcodes, and the 65C816 was an even bigger upgrade to handle a 24-bit address space and 16-bit arithmetic. It was used in the SNES and in the Apple II GS, but Atari never released an 8-bit system with anything other than a good old fashioned 6502/6502C, making its addition is a bit whimsical. Apparently some accelerators with 65C816s were made, however, and there is a little bit of software out there. It's a bit buggy, but it can run at least one 65C816-based kernel ROM replacement. I think I can also say, after having implemented it, that the 65816 instruction set was a valiant attempt to make the x86 ISA look good. 8-bit emulation + 8/16-bit acc/mem mode + 8/16-bit indexing mode... what a mess. I think I actually prefer x86 real mode to banks and m/x bits.