Wrathchild

Think of each bank as a character slot on the disk, rather than a bank being a replacement for a single disk. Remember, if a bank is erased then you'd wipe off the other 3 characters . Unless of course you read them all in before hand, updated one of the characters and then erased the bank and write back to the cart. This however needs more unused RAM which wouldn't be available in a 48K machine as AR pretty much uses all of it. Regards, Mark

Yep, sorry - got my math wrong there An 8Mbit cart (1MByte - usually the caps state of the 'b' gives it away) has 16 banks of 64K. The 128 comes from the number of selectable banks. As the chosen bank resides between $A000 and $BFFF, this is 8K so 8*128 = 1024KB. So for AR:City - that would give 7 possible slots for characters. This may go down to 3 though. The writing to disk 2 side 1 may also have to be simulated, so each character requires 2 slots, one for the character and one for the d2s1. To be confirmed when my understanding of the requirement to actually do this d2s1 save is complete. Apologies for the confusion, Mark

I've stood back for a bit so I'll chip in a bit here... As it stands, the AR:City cart currently uses 1/2 of an 8Mbit cart. Therefore it could be feasible to make a 4Mb version which does no flash saving whatsoever. I could force it to require a disk drive. However, in doing some of these cart conversions I feel that the depency on having a disk drive should be removed if possible. Yes, most enthusiasts have them, but not all. When reworking the Infocom parser to cart - I thought how cool would it be to add a 'save to cassette' option as well. Haven't done it yet, but as I'll be putting in a 'save state to cart' option, the extra work isn't too great. However, with AR we don't have the luxury of being able to re-assemble the whole sources, at best hooks can be put into the existing code to launch routines in a ROM bank (which requires control as all RAM between $A000 and $BFFF is then unavailable) or where code is identified as redundant, e.g. some of the disk SIO routines, new code can be placed over this - however those areas are few and far between and not very large in size. So an 8Mb cart has 128 banks of 64K, a bank being your smallest erasable block size. So a character save state will occupy only a small part of that, but then it only occupies a small part of a disk so no loss there. So theroretically there are 63 slots (as one of the banks has my code in it) for character saves. I don't feel that a 1 character per cart option is good - other family members may want to play - you may want to rest a character whilst building up another one - so 4 or 8 slots would probably suffice. How about the Dungeon? We could still permit the user to export their City character and import this into the Dungeon. So a 'save slot to disk*' option would be good too. From what I gather Xebec, you're wishing to not have an (re)import feature in the City? This puts out people who have old chars on disk they'd like to resurrect and whilst I agree the cart version should be treated as an opportunity to take a char through the game from scratch, I do feel the 'option' to load a character from disk should be left in which does permit the 'cheating' for those inclined to use a char-editor on their disk. I'm not swayed by the 'comparing of chars' argument - just take such claims on faith, e.g. I could doctor a screenshot of any game and post it into the high-score charts. What would that gain me... zip. I'll be getting back into development mode soon (work keeping me busy) to see what is practically possible with regards to character saving/loading and will post up the options when I have them. Take care, Mark * a cassette save is not an option here as the O/S routines cannot be used

Another (the last I think) bitmap did not have a header. Therefore this can be patched with: c 9f9e 20 03 Now the game continues but, oddly, bits of land keep randomly adding themselves to the map?! So some other form of memory corruption is taking place - maybe by the droid I had set loose? It maybe worthwhile reverse engineering the C64 version for comparison - I haven't seen reports of that one crashing? Regards, Mark

Check the map @ http://mapy.atari8.info/s-z/universalhero.png You need the disk and take it to the Atari computer and use it (IIRC) You're then prompted to enter the password (from the ID card ) The bug stopped the correct response being accepted. Mark

Just checked your site, the title screen has Polish looking credits, the one we did left these as per the original game.

One of mine as well I believe. A patch I made during my uni days was sent to Jindroush who did the work integrating and validating it as an image - but I'm sure that a few others had fixed the problem too. The bug was that the computer did not accept any password so you couldn't proceed further into the game. You can get the ATR at: http://www.mkeates.force9.co.uk/uh_good.atr Back to Colony... even after patching up the bitmap sizes, a crash still occurs, so further debugging will be required. The effective monitor changes were: c 863A 10 02 c 865C 10 02 c 867E 10 02 c 86A0 10 02 c 86C2 10 02 c 86E4 10 02 c 8706 10 02 c 8728 10 02 c 874A 10 02 c 876C 10 02 c 878E 10 02 c 87B0 10 02 c 87D2 10 02 c 87F4 10 02 Therefore I think all of these images relate to the smaller inventory icons used in the 4 boxes top/centre. A patched com-file is attached. Regards, Mark Colony.zip

Hi, IIRC - the verdict on this one is that the game is crippled due to a bug in which the game crashes soon after some specific actions. I find this is done after ordering some batteries and once picked up, the top of the display corrupts and eventually the game locks up. I take it that Mastertronic also never released a 'fixed' version of this game? I've run through what's going on and here's the run-down. This is from my own cassette to disk conversion and the com-file found at AtariMania - both have this problem. The data loaded between addresses $8600 and $87FF is actual source code rather than the game data required. Luckily the data in this area should be the graphics images used for some items. Therefore if it can be worked out what they should be then an artist could supply these bitmaps. Also, a scan through the memory of another release of the game (e.g. C64 version) could result in finding the same data patterns and so lifting the correct 2 pages of data from that may work. The crash occurs simply because a request to draw a specific image is made, this image's X/Y dimensions aren't correct and so the resulting drawn bitmap can overrun and blat memory it shouldn't. I kinda enjoy this game - so it would be nice to have a working version. Anyone else agree? Regards, Mark

Nope, just busy(ish) - post #20 is great, maybe try leaving the gate's contents in too? By adding the stats, I meant take image #13 and just add a stats bar (taking from a screen dump or self-constructed one as you suggest) to the top of this, shuffling the texts down a little to accomodate this. I think putting the stats from the covershot wouldn't work due to its slant. Regards, Mark

Strange how the mind works... From working on AR:The City, I get to AR:The Dungeon... written by Dan Pinal and Ken Jordan... reminded me of a game the Atari didn't get by Jordan Mechner... Fired it up on a NES emulator and thought cool title screen let's see what G2F can make of this. All done bar some tidying up of the upper left sand dune colours. Enjoy, Mark pop_g2f.zip

Hi, Certainly check out the Compute's First & Second Book of Atari Graphics (The 1st one is on http://www.atariarchives.org/c1bag/ ) Although not heavily game orientated, they do give the groundings. Good luck, Mark

That makes sense, 's8' is used for that

Hi, the stats taken from an in-game screenshot, e.g. like this (but not such a wimpy guy!)

I like the post #13 image, but the post #14 is also interesting. Can you try it with a Stat's bar at the top taken from a screenshot, just closing up some of the horizontal gaps a bit? An alternative would be to put a 'watermark' of the gate behind the #14. (not sure how to describe that properly - basically the gate picture but so you harldy notice it ) Cheers, Mark PS: Ultimately I'd probably have 'Mark Keates' show instead of 'Wrathchild' but cross that bridge when we get there.

Hi all, A question regrading Stats. The FAQ refers to display and internal values. (Section 5.3.1 MANIPULATING THE CITY, Eobet's FAQ version 2.0 - beta) I've examined how these are calculated and here's my synopsis: Each stat (STR/CHR etc) has a base offset address - as given in the FAQ as the 'displayed' value. e.g. WIS = $8940 (btw - STR needs correcting from $892E to $895E) Starting with 'Displayed' as having an offset of zero (s0) then the calculation for displayed happens as follows: min(s2+s3, 255) -> s1 min(s4+s6+s7, 255) -> s0 max(s1-s0, 0) -> s1 min(s1+s5, 255) -> s0 Therefore I'm not sure whether the Natural & Effective values refer to s1 and s2 respectively? Looking at the Levelling Up code, s2 is the entry that can get incremented so I'd more say this is the 'Actual' and s1 is a working value? The only s1 value referenced elsewhere in the code is STAmina. However, I'm yet to examing the encounter code where it may be used more. I'll probably work out the uses for s3->s8 later but wonder if anyone else had any ideas? Probably mods for armour, drunkeness/poisons etc. A case of wait for something to happen to your character and then use the debugger to check the difference, (e.g. press F8 and then type 'm 8900' to show the page of memory containing the stats). Regards, Mark

http://serious-dial.atari.pl/makeATR/ Would be nice if this was updated to include picoDOS etc

Er, no. The menus require key presses to pick an option - it's certainly too much work to rewrite those routines. Needless to say I did think I was stuck inside the Bank until I read the instructions and realised that you have to use the joystick to walk out backwards.

They just promoted me from a technical project leader to technical manager Unfortuately a bit more responsibility with that Hopefully it won't interfere too much with the A8 development though Kind regards, Mark

Just back home after a holiday, will catch up on people ideas/comments and choose the next objectives for a release and get back to coding (also depends on what work has in store for me upon returning )

That would be Airball I think: http://www.atarimania.com/detail_soft.php?...&VERSION_ID=151

Hi Jaskier, Another request - can restore support for compiling under VC++6? I've tried with your sources and couldn't get this to work. Almost there though. The changes to using zlib.lib rather than zlib.dll and the new libpng cause me problems. IIRC one of the supplied lib refers to __ftoi2. As this is VC7 specific I replaced it with another VC6 lib I had. However with a VC7 zlib.lib I still get a linker error (undefined reference) errno so I need to look into that further. Also, can I PM you the diffs for the AtariMax cart support for inclusion? Regards, Mark

RE Carmel's subject - I think I recall Ian Bell telling me that an A8 version was never worked upon, but I can't find that email.

Effectively I do , I took a C64 memory snapshot and disassembled it. I just had to work out names for memory locations/functions/routines/tables etc After re-working the line drawing routines to the Atari screen layout things pretty much fell into place. I've mentioned it on other threads so please find and read those. But here's my memories/feelings on the subject: Primarily family issues at the time put paid to a lot of my A8 development. Secondly, David Braben got angered by some goings on with some release (PDA/gameboy type thing IIRC). This went so far as 'pulling' sources from previously 'OK' releases such as Christian Pinder's excellent Elite-TNG. I had been in contact with Christian and Ian Bell during the early days of development and both gave help (ship data structure details and more). Despite many attempted contacts with DB/Frontier over the years I have never had any response - but I believe this ties with his policy of not answering any questions regarding the original Elite. Hence I feel saddened enough not to continue but also as- Thirdly, development had got to a pivotal point. Having got a demo running with pretty much the same code as the C64, i.e. all the correct 'random' seeds working so that the Galaxy/Local maps & Planet names/prices have the original's values, the next stage would be to add a controlling 'game loop'. By this I mean a sort of state-engine, e.g. if in this state and this key is pressed go to another state. For this too occur two things need to happen. 1) I need to understand the use of a few more memory locations and code related to the game state in the C64 version and 2) An Atari key handler routine needs to be written to replace the C64's. It does 'keyboard-scan' resulting in an array [1 entry for each key] so that you can see what is pressed. The C64 therefore can support more than 1 key being pressed simultaneously as the keyboard is effectively broken into little blocks. The Atari keyboard works differently - one key at a time. So a new routine can be done for the Atari - I just hadn't gotten onto it. After getting the game-loop going, the next step would have been to add the ability to fly around outside of the space-station. Following on from that would be seeing the 'stars' and then doing 'hyperspacing'. Then actual 'logic' could be added, enemies, combat, sun-skimming and finally missions. So, as you see, still a fair amount of work. Yes, Elite is a holy-grail for us Atarians, but I can't see it happening for a long time yet. Perhaps you could all petition DB for me? Regards, Mark

From the FAQ it sounds like they should be closed off, so probably that.

With regards to these, would it be worthwhile fixing these (and any other) known issues? Regards, Mark PS: no progress this week as too [email protected] - resuming next Thursday (9th)