jacobus

I'm currently bashing my head against a brick wall trying to debug some assembly code (at which I am totally hopeless). Hopefully I can get that fixed soon and the game will be available by: Canadian Thanksgiving US Thanksgiving Chanukah Christmas Chinese New Year

I like the sound of this - can you please provide a bit more detail? (my skill level floats somewhere above basic but below assembler)

It's actually a Rastaconverter image. The idea is to display the image (by running the executable) after the player has successfully completed the game. I would need to initiate a process that is completely separate from my code.

Is there a way of launching a disk based .EXE after wiping DOS from memory? I've tried reading the file into memory with the intention of calling its start location, but the load process overwrites the code that I am using to read it in.

OK, so predefined mini-map ... that would explain why the proportions don't quite line up. Rybags, Xuel - Thank you both very much for the insights! I've been playing with the idea of recreating the game (but with many more levels, extra hazards, etc) for some time, and I was having a heck of time figuring out the Navatron.

I’ve been trying to figure out how Steve Hales coded the Navatron in Fort Apocalypse. This is the little radar like display at the top of the screen the shows an extended view of the surrounding playfield. The Navatron consists of 3 rows by 12 columns of Antic mode 4 characters. It appears to give the player a preview of approximately six times the size of the screen (120 characters by 32) I first thought that it was a dynamic representation of the playfield – playfield data being compressed and displayed (perhaps 1 character on the actual PF being represented by a bit pair in the Navatron) – the fact that you can see the drones moving back and forth seems to bear this out. However, to do that requires an awful lot of operations – for a single refresh, 3840 characters would have to be read from the playfield, translated to the appropriate coloured bit and written to the character set representing the Navatron. If you look closely, you notice the Navatron jumps during horizonal movements instead of scrolling smoothly – vertical movement seems to be smooth. My second thought is that it is a predesigned mini-map that is drawn in the Navatron window and overlaid with the drone positions. However, I searched the Fort Apocalypse file for graphic data and did not find the map. Has anyone examined the code and been able to determine how it works?

thank you for the positive feedback! At this point the plan is to release it into the public domain without any personalization. We might consider a very limited cartridge release - still thinking about that one.

After more than 4 years, the sequel to 2014’s Dungeon Hunt is almost ready! Dungeon Hunt II is based on the original program but features a number of updates and improvements including: Updated and improved monsters and animation All new dungeon levels – 20 this time Wide open spaces within the dungeons Improved dungeon graphics and perspective views Ability to sneak through the dungeon without fighting Limits on the health and mana provided in each level Extended ranged weapon selection Combat menu – choose weapon, movement type, etc Up to 80 monsters per dungeon Ladders linking dungeons above and below – 3D mazes Autosave for each level Ability to go directly to an already solved level Overall DH2 is larger, more challenging and visually more appealing. Because of the new levels and difficulty settings I’m looking for a few play-testers to give the game a try and let me know how well balanced it is. If anyone is interested in receiving an advance copy and giving it a test drive, please contact me here asap. Thank you

RPG elements are all fairly basic - simply a metered quantity of each attribute - maximum quantities are limited in early levels to keep things balanced. Armour - Prevents or lessens damage from an attacking monster Weapon - Single weapon, becomes more effective with level (cannot be damaged) Health - self explanatory XP - Experience points - again they go up with level and help fighting effectiveness Mana - required for (single) magic spell Arrows - required for the single ranged weapon Torch (oil) - controls the amount of light around the player, also monsters are more deadly in the dark These attributes are incremented (randomly) after each successful battle or at select areas within the dungeon (wall / floor panels) There is a number that flashes in the bottom right corner during fights - this indicates the health of the attacking monster. Dungeons are all pre-set - the original Dungeon Hunt package came with a level editor but I have yet to see anyone create custom ones... No hidden doors or destructible walls, but I am playing with Up and Down ladders to allow the player to return to a previous level - this should allows some very nice 3-D mazes. Currently a key is needed to open doors - since the key is one use only it could be used to create some interlocking maze puzzles.

20K at $5000 for program/embedded data, 4K at $A000 for (I assume) the compiler's symbol table and another 4K at $B000 for program variables. Sadly the 20K is fixed and cannot be extended. Data can go pretty much anywhere else, I typically overwrite the compiler code and use $600 to $40FF and A000 to $AFFF which gives me almost another 20K in a 48K machine. I could avoid a disk based program by using a segmented XEX to load data separate from the actual program code - but for DH I need the disk for game saves anyway. I agree, using the XE's memory to compile in would be an incredible boost to the language's utility but the source code is not available. The compiler's author(s) were briefly online here around a year ago but were not interested in searching for the original disks (sounds like they are stored in an attic somewhere).

Although doing a boxed version of the original Dungeon Hunt was a lot of fun, it was also a colossal pain the a$$. I had intended to skip all that bother for this version but there seems to be more interest that I had expected. I will think about it - but no promises! :-)

The dungeon is rendered using Antic mode 4 and an entire character set. Some things bother me like the T (and upside-down T) shapes at the top and bottom of the side walls. With more characters I could change them to nice smooth angles. I am currently considering defining top and bottom character sets and switching with a DLI partway down. The monsters are rendered using all four Player Missile graphics to give 16 bits of horizontal resolution and three colours (by overlapping P0&P2 and P1&P3). Vertical and horizontal widths are doubled as the player approaches. Vertical changes are done in the animation itself, I currently have 8 frames (5 unique) in the cycle. I use a somewhat obscure Atari development language called Quick. Quick compiles directly into machine code, allows full access to the hardware (PMGs, VBI and DLI routines are easy) and yet has a very simple Basic like syntax that even moderately skilled programmers like me can handle. Where Quick falls down is that it only allows 20K for program code. I get around that limitation by offloading as much data to disk as possible and loading it into other areas of memory during runtime. The downside is that this in turn makes most of my games disk based rather than XEXs. The first version of DH left me with 7 bytes of program RAM remaining. I would have loved to include multiple weapons, more meaningful character development and other standard RPG elements in that version but there was absolutely no room. Instead I started work on Imp – a game with more classic RPG features (see link below). Imp is currently stalled because I’m sick of working on the maps (they are very large and complex and take a long time to complete) I’ll try to finish that someday. Back to DH2, with a lot of optimizing and offloading I have almost 2K left. So maybe I’ll try to upgrade the gameplay somewhat – I’ll have to see how long the new maps and graphics take. Imp Link:

Thank you! Still lots of work to do on maps and monsters... I'm planning to release this as freeware - more people can enjoy it this time.

Announcing Dungeon Hunt II Featuring Wide open spaces improved graphics new monsters new maps Multi level mazes completely re-written engine Available (hopefully) Fall/Winter 2018 https://youtu.be/o66g0Z1pw3Q

Interested!

and here is the manual DiskManager Manual.pdf

That makes sense, I suspect that DiskManager is simply a runtime version of FileManager with a few changes to read the directory sectors. Here is a .pro dump - please let me know what else I can provide. Synapse Disk Manager.PRO.atrSynapse Disk Manager.PROlog.txt

Synape - Disk Manager.ATRSynape - Disk Manager.LOG.txt OK here is a dump of the diskette along with the .log file from APE. Diskmanager requires an 800 with Basic - fails on an XL/XE. With Altirra it fails immediately with enhanced SIO enabled, and after a few seconds with it disabled. Sadly the copy protection is quite real and will need to be broken to go any further. I have included a screen shot of the title page for reference. I will try to find some time tomorrow to scan the manual.

Intec packaging and installation manual - The 400 adapter is original but the actual memory card is gone. MPC Packaging, warranty card and installation manual (someone went to town there) Unknown card. It is 32K, but was stuffed in the MPC box.

Not sure if there is any connection, but here is Diskmanager - a tool to catalog diskettes. Copyright 1981

For what it's worth, here a photos of all the versions I have: Filemanager 800, binder (may have had a slip cover - not sure), © 1981 Filemanager 800+, binder with slip cover, © 1981 The first SynFile version, comes in binder with slip cover case. © 1985 The second version of Synfile - uses extra 130XE memory. Much different packaging, copyright 1983,1985 And just for fun the PC version - package is still sealed but the outer box says © 1982

Great idea! I was involved with the HBO (Hamilton Burlington Oakville Atari Users Group) from 1982 to about the time it finally expired.

one of each please!

1 fully assembled with case please.

Thanks slx, this is awesome!