Shawn Jefferson

Thanks! I quickly switched the rnd functions to use the 16-bit version supplied by the C runtime, and it looks, at least so far that it's about three times quicker and still provides what the game requires. I'm going to tidy it up a bit more and remove the not required int32 variables. The game only ever tries to generate an int16 anyway. On the RANDOM front, I will add that into the project. I was going to put up a VBXE graphics title page anyway, so I'll wait for the user to press a key there and generate the seed after that! I figured it was something to do with power on state. Update: Wow, removing that routine and going with a 16-bit one without all the divisions has seriously sped up the generation of dungeons, on average it only takes 2-3 seconds now. I think I can remove the "Generating level..." message even! It also speeds up other parts of the game slightly too, which is also nice. I'll post another version when I have added joystick control.

Thanks! There are still a few bugs, found one today when you max out your inventory. That routine at $13xx is in the C runtime.... I'll check it out and see what I can do to optimize it a bit more. The random generator was never designed to run on a 1.79Mhz machine with only 64k. update: using the profiler in your great emulator, Altirra, with my debug symbols loaded, it was easy to see that the function is the cc65 runtime udiv32, called by the random number generator that moria uses. This is a 32-bit pseudo random number generator, and I didn't want to touch it too much, since important parts of the game rely on it (for instance in a single game the town always looks the same because the seed is saved and always generates the same random numbers.) It seems though that if I can replace this code with something faster on a 6502 it will really make a difference in the dungeon generator. Here's the code: PS. In the original Moria code, the random number generator is seeded from the clock, but since the Atari doesn't have a clock, I was using the RANDOM ($D20A). Is there any initialization that needs to be done first? I noticed that with Altirra at least, the code is not as random as I'd have thought (upon initially running the game... it's like it's generating the same seed from RANDOM deterministically, maybe due to power on state?)

I've got almost the entire Mines of Moria rogue-like game ported to the Atari, using VBXE and an Atarimax Flash 8Mbit cartridge. The only gameplay thing left to port is the "look" command. I will be adding joystick control, and a few other cosmetic things, and I will look into prerendering some levels and depacking from cartridge, as the random level generation is still around 30 seconds per level. I would appreciate any testing and bug reports though! Especially when it comes to the various spells, prayers, wands, staffs and potions and monsters. '?' brings up the help screen. CTRL-W enters wizard mode, which lets you cheat. CTRL-directions work in Altirra too, so you can use your direction keys (for up, down, right and left anyway.) A good page for Moria information: http://beej.us/moria/ The cart image is an Atarimax 8Mbit old style banking (cart 42 in Altirra). You need VBXE. The current colors are set for PAL. A couple of questions: What about colors of objects? I have some objects colored white and some blue. I couldn't decide whether to color all objects blue or white... monsters are currently red, which I think works fine. In some of the inventory screens there is a solid line below the inventory listing and in some there isn't. Which looks better? I restored some of the things I had initially changed (the history of messages are at 20 now), but monster recall/memories are currently not implemented. They will take a lot of memory and further cartridge banking, which may slow the game a bit. Are they important to the game play or not? (old moria players this question is for you.) Any questions or comments welcome. AtariMoria_55_alpha2.bin

Even a gr.8 port like Ultima IV would be awesome. It's the game itself that's important and not the graphics for these types of games, imo (says the guy who's porting Moria to the Atari 8-bit... with ascii graphics.)

I'd rather see Ultima V ported over to the Atari than a remastered U4. After all, we already have U4 and have played it to death on the Atari.

On the Atari 8-bit there is a club called ABBUC out of Germany that holds annual software contests, with cash prizes. This seems to really help spur on homebrew developers and several great games and other programs have been created specifically for the contest. Maybe a similar thing can be done here? We'd need someone "trusted" to keep the money (maybe Albert?), and have a well defined rule structure and voting system. Just brainstorming: - all games would have to be released in electronic (or physical) format to the "membership" (those that have paid into the prize fund) - all rights remain with the author - a public release can be done by the author if they so choose (after fulfilling rule #1 above.) - the game cannot be released in any form prior to the contest Things like that. The ABBUC rules may be a good starting place.

Yes, it's just work... and some games will be more difficult than others.

After adding the functions to write saved game and highscores, which have to sit in main memory, I'm officially out of memory. I will have to disable the OS and use the memory under the OS to complete porting the game. The good news is that I believe there will be enough memory and that it is possible to port the (almost; minus recall monster memories) complete Moria to the Atari with VBXE and Maxflash cart. Attached is the last version that works without using memory under the OS. Some things that have been added since the last playable demo: saving of highscores and game save (Ctrl-X). If using Altirra, remember to save the cartridge (Save Firmware in the File menu) to save the cartridge memory after your session. Also, some monsters can multiply (gets a little slow with a lot of monsters on the screen). You can gain spells now (can't cast them yet though!) A few of the bugs have been found and quashed, but some still remain.

How about displaying all symbols in the debugger for a particular address then? For now, let the user figure out what bank they are in and look at the appropriate symbol? At the moment, without doing that, or creating some banking compatible symbol format, the symbols for bank switched projects aren't very useful. The issue of the symbols starting with "__" from the cc65 suite wreaking havoc in the debugger, I can remove them from the symbol file myself of course... but that will always be an issue with cc65 suite symbols unfortunately.

Nice, looks like you got the "Ulrimare serue" working fine!

Phaeron, did you see this: http://atariage.com/forums/topic/235156-ca65-symbols-in-altirra-debugger/?p=3180016 Regarding debug symbols from the cc65 suite. A couple of (hopefully) simple changes that would make things better for Altirra and cc65 suite users. The other feature request is around banked projects. Displaying all the symbols would be preferable to only displaying one of them (is it the first read or the last?) Does Altirra support banked debug symbols with other compilers/assemblers? Maybe we can change cc65 to support the same method if so.

Without seeing the code, and I admit to not fully understanding your explanation of what's going on, maybe you are crossing a 4k boundary, or a bug in your code is trashing your display list? Also, and this might be because I don't understand what you are trying to do: If you have LMS lines each 256 bytes long, you are trying to scroll past 0 ? Wouldn't zero be the left edge of your screen memory, and the furthest left you can go, and 255-40 the right most edge of the screen memory? If that's the case, then I think what you need to do is load screen data in at the right edge of the screen (255-40) and then "jump" back to that location to give the impression of an endless horizontal scrolling. Could be totally wrong about what you're trying to do though!

In North America the Spectrum was not really a player, so we didn't have "isometric game envy". I just don't recall anyone wanting to play those types of games, or even missing them. The few I did see on the A8 didn't do much for me. Amaroute being the main one I remember.

Thanks for catching that typo... multiplied by 16 bytes, not the sector size.

Altirra automatically loads a file with the same filename and extension LBL as the image/file/cart you loaded (mentioned in the help file.)

I believe it's 16 bytes? 0000 0000 96 02 80 16 80 00 00 00 00 00 00 00 00 00 00 01 Yes, definitely 16. that's the ATR header there, 96 02 is the "magic number", and 80 16 is $1680, which multiplied by $80 (128) gives you the size of a regular 720 sector SD disk. I guess using paragraphs you could have an ATR that total size isn't a multiple of the sector size, but I wonder what the point of that would be?

I've been meaning to try this for a long time now, and your question gave me the initiative to try it out. It looks like the information from this thread seems to work: http://atariage.com/forums/topic/223360-altirra-debugger-powerful/?hl=%2Baltirra+%2Bcc65&do=findComment&comment=2953121 put -Ln filename.lbl on your linker command line and then load that symbol file into Altirra with .loadsym Don't worry about the leading dot, apparently that is no longer a problem. Bank switching really messes things up though, since the symbol file will have tons of overlapping symbols... I have this problem with my current project. I don't think source file level debugging works in Altirra with the cc65 suite either? @phaeron: If you read this, I think that cc65 suite symbols that end in "__" should be ignored. These are generally speaking all the segment definitions from the linker configuration, which really messes up the disassembly, especially all the *_SIZE__ ones. The _LOAD__ and _RUN__ might be useful for somebody I suppose, but just complicates things for loading the symbols. There are also some internal library symbols *_FILEOFFS__ that also are not useful, and a few others. "*__" should hit them all though. Banked projects are particularly horrible... I wonder if just displaying ALL the symbols for a particular address instead of just one (the first or last read currently?) would be more useful, then the programmer can just determine what bank they are in and pay attention to the appropriate symbol. Might make the disassembly sort of messy, but would make symbols at least useful for bank switched projects.

Yes handy! I was always running Altirra via a batch file that sends the cartridge type on the command line. Now I can put this into the make process instead.

oops duplicate post

The whole concept of "paragraphs", imo, is just weird. Why not just sector size and number of sectors? Also, what's with the "first (or typical) bad sector" field? That couldn't have possibly been of much use for copy protection emulation... Can't really change it now though I suppose, and why would you want to? Better to build a better format. A successor disk image format should probably also take into account copy protection information (like ATX), but also be extendable to larger disk sizes too.

A unix like find utility that has the -exec parameter would be nice.

Looking back, it would have been much nicer to have a smaller, leaner OS with more RAM available, and a larger BASIC cartridge that included all those routines that probably rarely got used by anyone but BASIC programmers anyway.

Most of the stuff built for the Maxflash cart uses Option to bypass the cart and boot from disk (note to self... ), but if it doesn't you can boot any Maxflash flasher ATR without a cart, and then "hot insert" the cart... I've done it before and it works, just a bit tricky and might need multiple tries. Some people swear by inserting at a angle, or quickly, etc... keep trying, it'll work eventually. Or you can flash it outside the computer with the USB programmer Atarimax sells.

Probably the driver is using null terminated strings ("C" style).

It sounds like you are rebuilding vbxe but with the RPi.