jacobus

First off, my apologies for asking this question again, but I was unable to solve the issue before and I’m hoping a better description (and a clean thread) may help. I need help launching a binary load file, specifically a Rasta-Converter self-executing image. I want to be able to execute the RC binary from within my (running) program – more or less duplicating the functionality of DOS’s Binary Load. My Environment Standard 64K XL and SD disk DOS 2.0 initially, overwritten by my program QUICK Development language No free memory in my host program – hence the need to call out to an separate executable Virtually zero assembly skills and a mediocre programmer at best If I understand the Binary load function properly, it would need follow these steps: Read first 2 bytes (FFFF) Read next 4 bytes – use these to determine start load address and length of segment (end-start) Read next X (segment length) bytes Call start address Read next two bytes – if FFFF assume new segment and start back at step 2 Thanks to FJC’s help I have managed to create a small assembler routine that can load a sequential series of sectors, placing them sequentially in memory and then call a specific address. The idea was to load the RC executable into RAM and then execute it. Unfortunately, it fails – no doubt due to a segmented executable not being handled correctly. Can someone please help by either: Suggest a method to adapt my existing code to follow the Binary load steps above Point me at an existing solution that would allow me to successfully launch this RC image. (preferred solution) Thank you! P.S. This request is part of the Dungeon Hunt II project - now massively overdue, but still alive!

xBoot is 384 bytes? That works - I thought it was around 6K. Question #2 - is it possible to load the xBIOS file into memory, execute it and then have access to the functions like "xBIOS_LOAD_BINARY_FILE" or do I need to boot from it?

Thank you for the examples! Unfortunately xBIOS would consume too much memory. I am trying to load and run an external executable file from within my program. As that I have already wiped out DOS, using a standard call is not an option. Is there a (relatively) simple way to run an executable from disk by either by filename or disk sector? I think I'd basically need to duplicate the functionality of the Binary Load function in the standard DUP.SYS

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! :-)