31 Dec 2014 - Disqus added and Code Progress Update
Disqus now working, I think...
Holidays took a bit more of my time than planned, then had some 'issues' with getting disqus' comment counts to work right. Turns out they demand a full URI (which is stupid as HELL) to auto-process links on a page. I ended up using the span targeting with the data- attribute method. Not a fan, but it's just too damned stupid the other way around... so, now we have comments at least on the blog parts of the site. I'll be adding comments to some specific sub-pages as I'll likely start adding more article-like content to the site.
Site Back End additions
I've added a method of creating 'breakpoints' in my articles so I can manually set where the "read the rest of this article" link gets placed. Automating this usually sucks and is a headache, so simply having a 'comment' that says "stop here for the summary" seems a far, far better way of handling it.
When/if I turn this simple "poor man's CMS" into a real content management system, this may be a pretty big feature... though I will still likely require that articles be written in HTML simply because it is the only guaranteed way to have proper control over the output from an accessibility and SEO point of view.
8088/8086 DOS Game Engine Improvements
I've been working for, well... years -- mostly in my spare time -- on "upping my game" when it comes to writing games for DOS. My new approach uses a great deal more assembly language and is built towards building monolithic "single executable as the distribution" games instead of a "directory full of files".
I've made huge strides in terms of faster audio with a more 'modular' way of adding sound devices. I've been working towards adding new devices as well as fixing bugs. Likewise my video support is seeing some optimizations, bugfixes, and a whole new way of storing game data and buffering screen output.
New Sound Devices
- Innovation SSI-2001 -- basically a Commodore SID on a PC card. A bit tricky to implement as the input clock is slower than either tha PAL or NTSC versions of the Commodore 64... but for the most part implementing this was just a matter of porting my C and 6502 machine language code for the C64 version to Turbo Pascal and 8086 machine language. Working with "ports" instead of memory mapped hardware was actually the biggest hurdle resulting in the PC implementation taking a good deal more code.
- SoundBlaster "DSP" Midi -- Early Soundblasters -- pretty much every pre -16 version do NOT support MPU-401 compatible UART MIDI and instead have their own implementation through the DSP. Few programs support this, which is a shame because it's actually surprisingly simple to implement.
- PC Speaker using Arpeggio's -- My old speaker implementation was one-voice "priority based", which sounded... meh. Mind you, the internal speaker on a PC is rubbish and is ALWAYS "meh", but a 120hz 2 voice arpeggio is suprisingly fast, reliable, and not as foul sounding as I had expected.
- IBM PS/1 Audio -- The PS/1's actually had their own built in enhanced audio that for all intents and purposes is identical to the Tandy / PCJr implementation, just at a different I/O port.
- Sound Master+ OPL -- The Covox Sound Master Plus contained Yamaha OPL chips identical to those on the Adlib card that mapped by default to the same port -- 0x388 -- but they also let you configure it to 0x380 in case of conflict or so that you could put two SM+ in a system or put it next to an Adlib. As such I've added that as a valid port override to the Adlib code.
I was hoping to add support for the "IBM Music Feature" card, but lacking access to one, there being NO emulation of it that I'm aware of, piss poor documentation (some of the worst I've ever read), and just plain general headaches even the simplest of operations are with it means that for now at least that's been shelved.
Sound BugFixes and improvements
- All new sound subsystem -- the actual method of calling my sound support routines was rewritten from scratch. Instead of hard-coding a case/switch for each possible sound card, I've gone and made it use procedural variables which means I can just call the appropriate routines transparently. I've also built a structure of data that can be added to a pointered list to allow sound card detection and parameter checks to be "chained" together. This means adding new sound support is going to be as simple moving forward as just adding a new unit to whatever program I want that card added to.
- CMS / Game Blaster -- FINALLY fixed the compatibility issues. It turns out that if you have a recent knockoff "GAL" chip to let you use the SAA1099 chips my old codebase worked, but it failed to work with the real chips from Creative! That's why so many of you had problems getting it to play nice. This upcoming version should work with ALL versions of Game Blaster, Creative Music System, or Sound-blaster with the chips installed on it.
- Adlib -- Put together a bit better a patch for lead sounds. I'm still not wild about it, but to my ears FM synths sound like ass no matter what you do to them. I also resolved the issue where Adlib autodetection on some Soundblasters (2.0/pro) would prevent being able to choose any other type of audio.
- MPU-401 -- I've shrunk the code needed to support it greatly and made some reliability improvements while at it.
I am HOPING to very soon be adding support for the original Covox Sound Master which used a AY-3-8930 sound chip, but information on how it mapped said chip to the I/O ports is effectively nonexistent. I'm also playing with the idea of making something similar to the TANDY/Jr/CMS audio support for DAC devices like the Disney Sound Source or Covox Speech Thing for faster machines (there is NOT enough time at 4.77mhz to pull these types of stunts) but first I'll need to build one for testing and figure out where the 'cutoff' for a system being fast enough to support it during gameplay lies... much less maybe actually get such a device into my hands. I'll likely be tossing together a simple R2R ladder DAC "covox style" the coming week since it's not like I don't have the parts just lying around here. Those 0.001% tolerance 10k resistors I got out of a grab bag might just come in handy for that.
Paku Paku 2.0 coming soon
Since I have an all new sound and video codebase, the first thing to see the light of day using it is going to be Paku Paku 2.0. This is basically a complete rewrite from scratch now that I have some clue what I'm doing. It's kind of a laugh that I was programming blind on version 1.x given the result -- but now I'm using compiled sprites, custom data encoding, and a lot of lessons learned in making the C64 version to result in a far better build of the game. Right now it's around 60% complete, but the remaining bits should go fast since the original 1.0 release of Paku Paku took four days of development time. This may take a wee bit longer than that but I'm dotting every t and crossing every i... Wait, that's not right...
One of the biggest changes is the codebase is going to be WAY faster than the previous implementation. Sound, Video, control handling, game logic -- they all got a massive boost in speed and efficiency that I'm HOPING will be enough to make it run perfect on a non-expanded 128k PC Jr. The Junior's bottom 128k of memory is shared with the video controller, making it the slowest PC compatible ever released, to the tune of anywhere from half to two-thirds the speed of a real PC depending on the task. Squeezing that extra bit of juice out of the code didn't seem possible with my skill set two years ago, but today? I'm up for the challenge.
There is a LOT more assembly language going into this as I try to optimize certain bottlenecks. One of the most surprising choke points was actually redrawing the score on screen. Huge spikes in CPU use every time it happened because 1) Converting a long integer to a decimal ASCII string sucks, and 2) Converting a long integer to a decimal ASCII string sucks. I realize that is in fact only one thing, but it's such a colossal sticking point I feel it needs to be said more than once.
The solution was to use unpacked BCD, where each byte represents just one decimal digit. The 8088/8086 has some really good opcodes for handling it ASSUMING you can decipher the documentation; the laugh being almost NO books about x86 programming do anything more than mention it exists. While BCD addition to update the score is slow -- basically an ADC, AAA for each DIGIT! -- it's nowhere near as slow as turning a DWORD into a string -- 32 bit divide on each byte where you need to preserve the high word's result on each digit; which the 8088/8086 sucks at. This also let me use a more optimal way of calling compiled sprite versions of the decimal character draw routines.
No guarantees on when or if it will be completed as I'm mostly puttering around on it in my spare time; I'm HOPING to have a beta release sometime over the coming week or two, but that depends on how much it fights me and how I'm feeling. I've been sick on and off for a few MONTHS now -- laughably it's when I'm sick that I'm getting the most coding done.
