2021.6.11 (IBM PC Suport)
The 8088 IBM PC 5150 support has been accomplished! Many things were learned a long the way. The IBM PC has an “interleaved” symbol/color arrangement, instead of separate buffer for content vs attributes (color, blink, intensity). And the real-mode nature of the 16-bit 8088 processor takes some getting used to — specifically the relationship between the segment pointers. The MDA (monochrome) equipment is actually 80×25 mode only, so I’ll have to do the “80 mode trick” like I did with the 80-mode version of the PET (just use the 40 columns on the left half). And I did study PC SPEAKER sound support, but hav en’t completed adding sound support (because the IBM PC is easier to adjust CPU clock speeds, with more modern versions at 8, 12, 20, etc. MHz beyond the stock/initial 4.77 MHz). This makes the sound programming a bit more difficult. For IBM PC version, translated all the text symbols and added color support.
2021.6.7 (IBM PC x86 Support – not yet, but getting closer!)
Big progress towards the x86 build. DH code is all compiling under the WATCOM C compiler and a 64K .COM binary executable is being produced. Have adapted the CORE code to do certain things like: poll keyboard, clear screen, enter 40×25 text mode. And I’ve worked out a more efficient process to get the built .COM file over into the target emulator (via WinImage). Still working on an efficient way to POKE to the text screen at 0xB800. The IBM PC has yet another slightly different arrangement of the video buffer: the symbol and attributes (color) are interleaved (on C64 they are two separate buffers). No show-stoppers, but will take time to resolve some of these final technical issues (for example, I may want to by-pass the BIOS and do my own “out” opcode cells; WATCOM C is also a little more strict about it’s inline assembly, I may need to POKE specific instructions manually). But very glad the WATCOM C compiler is working out, and don’t have to use Turbo C inside of a DOS box with 8.3 limited filenames.
2021.6.3 (TRS-80 Support)
Completed a TRS-80 build with sound support (based on SoundX assembly from a July 1980 Microcomputing article by Roxton Baker, used online assembler) using the z88dk C compiler. Ran Z-80 online disassembler to understand how arguments are passed to the BASIC USR function, but then borrowed the technique used in the Apple ][ version to avoid needing to use the USR function at all (i.e. POKE the argument directly into the code that loads the HL registers). Adjusted the string character codes to support the Model 3 character set.
Also added an PET80MODE build mode the PET build to support the 8032 business model (adjusted keypad codes and write only to the left 40-column half of the 80-column screen).
2021.6.1 (Apple ][ support)
Updated DH site links to be “raw” (otherwise they download github HTML content instead of the actual intended file; confusing since the browser provides the intended filename but is actually downloading the wrong thing– setting the links to “raw” solves that).
ALSO, lots of rain, so spent the day studying both the Apple ][ joystick/paddle support and sound support. The joystick support was fairly straightforward (Stefen Wessels in the cc65 mailing list sent me notes with a direct how-to link). I’m only using “digital” feedback of the joystick (so I am using a somewhat more streamlined assembly .s file rather than what is in the apple2.lib of cc65), but the joystick does support analog feeds.
Then spent a considerable amount of time understanding the Apple ][ sound support, which was a lot more effort than on the Commodore side. Then I found an interesting assembly example – which would be difficult to adapt into C, because the creation of the sound is sensitive to the literal cycle-count delays of the code used to create that sound! I POKEd the sample program, then you have to apply self-modifying code to write desired duration and pitch right into the assembly code. Insane, but it does work and am able to create a variety of sound in a “violin” sort of fashion (replicating the synth effect Captain Goodnight from 1985.
Also have a z88dk C compiler build for the TRS-80 Model 3 and 4. Studied the TRS-80s for quite awhile, didn’t realize they were not 40 column systems (64×16). That forced some re-thinking of how to port the C code, which I’ll describe in the next update.
2021.5.27 (Commodore FINAL-GOLD)
Improved the animation and map drawing speeds (using pointer increments rather than for-loops). Makes the game a lot more “crisp” and responsive.
2021.5.25 PM (FINAL-GOLD)
I made another minor update that adds a haiku to the end-game! For those who read through the DH lore, you will understand the meaning 🙂 This last update squeezes in the last available code-space available to the game (to fit this, I had to make the music notes all hard-coded rather than lookup from a table). The ZIP and PRGs have been updated, but the TAP file is not yet updated. I’ll update the TAP file as soon as I can – but this end-game text is the currently the only difference in the TAP version.
2021.5.25 AM (FINAL-GOLD)
Sound support has been added to the Commodore PET build! Be sure to get the 5/25/2021 or newer DHUNTERPET.PRG. The sound of your arrow firing changes with your remaining health! CHIMES has a sound, defeating CHALLENGES has a sound, entering REST has a sound. picking up items has a sound! The C64 sound is a bit more involved, so I will need a few more days to study the SID and get the sound working on the C64 build. Stay tuned, but the PET version is ready! (hope you enjoy the GAME OVER and END GAME “music”, I made them myself!). [ EDIT: I had this ready YESTERDAY, 5/24, but found an discrepancy between VICE and the physical PET handling of audio; correcting that required a rebuild — the issue was related to the real/physical PET requires the sound to be TURNED ON before the FREQUENCY is issued, whereas VICE allows either way ]. Also updated the TAP, MP3 files to correspond to this newest FINAL-GOLD release!
Big news! I freed up about 1200 bytes in the PET build (by removing some use of variable arguments and storing the “location to draw” buffer into the TAPE BUFFER #2). The gives room to add the full INTRO story (and a small special effect of inverting the bow when drawn on beach). PLUS – I think it free’s up the space I need to add sound!!! Hopefully can present something on that next weekend. Also fixed a bug in the time-counter (was querying the clock without clearing interrupts, potentially causing it become inaccurate). The “dhunter_final.zip” is updated with the INTRO added and various fixes included, but not-quite-yet with sound support – it’s coming!
Found issue in the Button A FIRE support for SNES GAMEPAD. Fixed and updated both PET and C64 builds. Also some slight changes: B=PERSISTENCY, Y=ORB (farthest and least used), X=FLIP. Also, received 2nd cassette port header from texelec.com to make it much easier to power the SNES GAMEPAD adapter, will update photo in Download section shortly.
Forgot to update the SAFE area in STAGE 8 after increasing the CHALLENGE attack area by 1. Made this adjustment and updated the “final.”
I’ve prepared a FINAL release, as I need to focus on some other projects over the summer. I did prepare a FINAL yesterday (5/17), but re-prepared it today with a few updates. The updates are:
- Collecting the GEM on the island in STAGE 3 now gifts some PERSISTENCY (1D3). I felt this was a cute addition, gives a motivation to getting to that island!
- The CHALLENGES have one extra space around them to perform an attack. I felt the game was a bit too easy. I tried THREE spaces, that felt it a bit too hard even on EASY. So I think two spaces is a good compromise. With this change, you really do need to keep your distance, manage your STAMINA, and stay on top of your PERSISTENCY to keep the health up (e.g. whenever defeating a CHALLENGE you get a few more PERSISTENCY, so be ready to use them). With this change, I haven’t actually yet beaten the game yet!
- Fix a bug where STAGE3 bird sometimes got stuck in the rocks.
- And with these 3 changes, the PET build is literally out of bytes! (for a cc65 built program with full optimization on)
I may add sound to the C64 build, to give a preview of what the sound might end up being in the PET version if I can ever find the extra 200-400 bytes to fit it. The C64 build essentially has another 29K, but I wanted to keep the two builds essentially identical (except for the addition of color) – but I understand C64 fans won’t appreciate that much, as the C64 does offer substantial more capability.
Also for fun I’m going to try to record a WAV file version of the cassette version of the game, I think I have all the equipment I need to do it.
Tested SNES.PRG sample provided by Joe Travis, adapted into C and integrated into DH – can’t test on VINE, but is working great on the physical PET 4016. Uplodated C64 version also to have the same gamepad support (and removed the native C64 joystick support — although the C64 has enough memory to really support both at the same time).
INVERSE on arrow over BEACH is gone again, no free memory space for luxury features at the moment. Closer to being able to load data into the spare cassette buffer space with linker segments (“cubbyhole”), but still couldn’t quite it working.
2021.5.14 (SNES GAMEPADS)
My SNES GAMEPADS showed up and I was able to verify how they work with the Commodore PET and the SNES ADAPTER. I did need to rig up an external 5v power source (as is warned about in the instructions, being necessary for only certain PETs). Luckily I had a 3-pin header wire laying around (and a variable power supply with alligator clips), but regular folks might need a turn-key solution (such as something that plugs into the 2nd Datasette port, as the closer 1st port is probably needed for the SD-card adapter). Anyhow, the adapter works very well, and I tested code to access it from within my own C code – now to make room for integrating that code into DH!
2021.5.13 (BETA4 update #2)
Fixed bug where ALYCONE was the only name showing at the End Game. Also slowed down FLIP SKILL slightly (moved to PRIORITY 2 keys), was hoping to fix “jittery” reaction of FLIP for C64 — doesn’t really seem to help, maybe have to add a PRIORITY 3.
Removed NEXT/PREV target cycle from CHALLENGES in C64 build (now matches “RANDOM” only of PET version). Prefer to keep the logic code identical between the builds. C64 just adds COLOR and JOYSTICK, is the goal.
INVERSE on arrow over BEACH is back!
2021.5.12 (BETA4 update)
More bugs on that darn STAGE3 bird spawn! Hopefully a final simpler approach that will put this to rest forever.
Had to remove INVERSE effect for when arrow was shot over BEACH. Out of memory for it (in PET build)!
2021.5.11 (BETA3 update)
Resolved additional bugs in the STAGE3 bird sometimes getting stuck.
Made updates to correct the C64 build (to clarify keyboard controls and add additional color). Found issue where the additional SLUAGHs in STAGE8 were causing a lock-up (but only in the C64 build!). It’s a mystery; doesn’t freeze in the PET version. Ended up just having to take them out of the C64 build for now.
2021.5.11 (BETA2 update)
Fixed a bug where FLIP SKILL could not be learned on reset of the game (e.g. after dying or playing another round after the end).
Fixed a bug in the STAGE3 animation of the bird (caused by using REVERSE symbol of the SPADE). Also found STAGE3 bird would sometimes spawn inside the rocks. Added logic that will “slide” the spawn point until a NON-BLOCK cell is found.
2021.5.10 (BETA1 update)
Removed the use of variable arguments to prepare the persona database. Free’d up over 600 bytes! Used this available space to now make the PET and C64 game mechanics completely identical (previously for the PET version I had to do things like remove the animation in STAGE 7, nixed spawn of a few CHALLENGES, etc.). So now about 200 bytes free, hoping to be able to add either audio or PET joystick support (but probably not both, TBD).
Will try to update on important development notes here. Taking a bit of a break since today is Mother’s Day!
NOTE: Development began mid-March, during Spring Break. Much of the initial work was understanding cc65, compiling, linking, and the PET system (graphic vs text mode, character sets, clock/time monitor, keyboard inputs). The next phase was coming up with a MapEditor, which was a whole separate project all on its own (and involved writing/reading files with the saved Map Data). Next was coming up with the strategy to animated CHALLENGES, and also the flicker-free animation approach. An initial DHUNTERDEMO was prepared to demonstrate all of these elements. From there, all the technical elements were complete, the rest was flushing out the story and icons of the CHALLENGES, and a set of “RPG rules” to try to keep everything balanced. In a way, DHUNTER represents a classic “board game,” except it does include real-time decision (as opposed to be turned based).