Wrathchild

True, in that case it may also be worthwhile adding a 'copy character from slot X to Y within the flash-mem' - instant resurrection. Though purists may disagree with the prinicple of this. Regards, Mark

Had an idea on this one, when booting up the machine I could detect if 'SELECT' is being held down. If so, a menu could be provided that allows the import and export of a character to and from disk/cart.

You are probably also going to want to 'break' execution at certain points so that you can being tracing. I'd advise going for the new A800WinPlus4 emulator. The debugger has some superb new options for breakpoints. In the monitor (F8) type "B ?" for a list of the options. Use "tron <filename>" and "troff" to log execution to a file. Regards, Mark

Indeed, but we're well past that point (see the Release 1 thread etc) I was already familiar with such routines after the LucasArt games. Those were pretty much lifted out of the OS, so understanding them wasn't too hard. Basically they're a state machine based on sending out and receiving single bytes on the SIO port. Once you've identified the code getting 1 sector of data all you need to do is replace this with your own code to copy the equivalent data from the ROM. The 'exe' versions floating around are for 128K machines as it uses the additional banks to simulate the bank switching in the original ROM - a good checkpoint for releases is www.atarimania.com BBSB has its own bank switching model, see http://www2.asw.cz/~kubecj/acarts.htm, it could be possible to make an XEGS/Megacart or Flash version of the cart - presumably the exe version of the game shows that memory can be copied in to position when required, no fast bank switching is actually required. Maybe one to do later. Aside - please don't use Wrathman Ironic really as this is currently referring to Philip Price. Regards, Mark

Indeed, I had to disable the loading, re-encoding and writing back to disk done during game start up. Looking a the sector counter on A800Win this was being done at the end of the disk. Therfore you've given me ideas to hunt down the related to accessing these sector and provide some substitute routines to use flash-mem instead. Might be tricky. I think I need to ignore developing and play the original for a while to become a bit more familiar with its workings. @densonj : Hopefully the timings are down to chosing PAL/NTSC. As far as I'm aware the emulators are pretty close on these days. I've run AR using the disk images and walk and turned a bit and took a screen shot, then repeated this with the cart image. As you mention, the mountains weren't the same, but also some doors were missing. This may explain the 'entering/leaving' problem - as although you can enter the door, triggering a load, the co-ordinates don't tie-up with anything? I'm assuming here that the map doesn't change between games, so I could be wrong? Thanks all for the encouragement so far! Regards, Mark

Hi, I was going to put up a disclaimer along the lines of 'as long as the copyright owners do not object', but I agree that would be a good idea to track them down and get a blessing. Can anyone from the AR Mailing list PM me an email address if its known (or just point Philip - is it one or two Ls? - to these threads). Remember too that credit also goes to 'Glenn the 5200 man' for originally cracking the game. I recently read the Byan's 5200 thread regarding the his new board and did think about this, but doesn't the 5200 have just 16K RAM which would not be enough to run the game without completely re-writing it (though not beyond doing)? Mark

A day earlier than expected Here is Stage 2. Remember the goal for this release was to permit a temporary character to roam around the city and do the sort of things any respectful (or disrespectful for that matter) AR character would want to do... Well you can now! The solution to avoiding the DLIs was to defer the data transfer from ROM to the disk I/O buffer to between certain scan lines. Just to be annoying I've added some code to set the background colour to the read byte value during copying. This will be taken out in the full release, though may remain as a single flashing line in the lower part of the screen, just to indicate that the system is busy. I anticipate some bug reports (use this thread), e.g. I have still had 'leaving' issues when entering some buildings (An Inn, maybe this happens if they're closed?). Still, enjoy this release and be patient whilst I try to now support either disk or flash loading and saving. Its early days, but the 'image' for the full version won't be released. As I've already freely put out the cart conversions of: The Eidolon, Koronis Rift and Gauntlet - I feel its time for some payback on the effort put in. So I'll most likely be working with [email protected] in having AR produced. As some people may already have 8Mb FlashCarts and may not want to part with hard-earned cash for another one. In that case it could be possible to setup something else, e.g. pay by PayPal and receive the image by email. Perhaps it could be free and people simply make volentary payments to me in recognition of my efforts? Undoubtedly, pirating will out itself and the image will be passed around for all to use, lessening my resolve to make more images in the future. Please post your thoughts on what to do with the final release. Best wishes, Mark Ar_cart_v2.zip

Thanks for the tip. AR doesn't use any of the OS and provides its own interrupt handler routines. So I have a high percentage good feeling that just the LDA $FF, STA $D301 will suffice in this case.

Yep, that icon was me with the hat on . So d) is fixed. (it wasn't a typo - that's what I had coded ) As a by product of working on b) I seem to have fixed a) :!: And if that's confirmed that the original game only played those 2 bars of music then I'll consider c) closed too. Therefore only b) to complete - you lucky people :!: I'm toying with redirecting the display list, so that the DLIs don't trigger. If I can't get that to work then turning off the display altogether maybe the only solution. This causes some flickering though when multiple little files are loaded but might be avoidable with some delays, e.g. wait until a certain scanline. Otherwise this may just be something we have to life with. From what I have seen already, we'd be losing out on the messages like 'Entering...', 'Leaving...' etc whilst the loading is done, but as this is much quicker now its not too much of a loss. So maybe it could be another Thursday night release again Take care, Mark

It was me getting that wrong... It was after midnight after all Cheers, Mark

Ah, forgot to add: d) Still to fix the 'Disable Basic' crashing on XL/XE machines. This is even after setting $D302 during the cart initialization and maybe down to something else. I need to debug this a bit further.

Stage 2 is almost upon there... Had a bit of a breakthough today... two more similar (but in different memory areas) loading routines were reworked in order to get the replacement 'get sector' routines working. Hopefully that's it for now. One thing I had to do was to take out a call which re-writes the read and decoded sector back to the disk after re-encoding it. Not sure of the purpose of this but it appears to be OK without it at the moment, though it may be linked with a) below. So, I can setup a temporary character and have them walk around the city and have encounters. However, the following is still to do: a) When entering buildings the system automatically leaves them. Identifying the cause of this may take some time to track down. b) The main game screen is using DLIs who's code is located in the cart area. Therefore during simulated disk (i.e. now cart) access the screen is temporarily corrupting. I've tried disabling interrupts but as the execution window for the copying is very small, 'off' before getting a sector and 'on' again when it's finished, the perceived display corruption is still there. Some more work is therefore needed to tidy this up. c) One thing I noticed in the cart and cracked versions, but I need to get my A8 out to test on real hardware, is that after pressing 't' for the temporary character, the gate screen appears and music starts, but when the P/M bars finish opening to reveal the gate and the force-field starts, the music stops? Seems odd to me. So, if a solution to b) can be made I could be in a position to release Stage 2 later this week, though it would be nice to get a) done as well. Hang in there! Regards, Mark

Silly me, as most development is done in A800WinPlus I had started using my normal 64K 800XL, but I switched to the 48K OS-B to develop against, therefore this wasn't an issue. I'll get that patched up for the next build. @eobet, yes indeed - and this game is quite worthy of this reputation! I'm now getting into the standard routines for loading game data from the last 3 sides, i.e those only taking 120 bytes of data from each sector, the others being part of the encryption. The aim is to leave these 'as-is' and let the existing code (albeit modified by Glenn) do the work. The thing I'm worried about is the reported occasional writes to one of the game disk, this may require a re-think... Regards, Mark

Thanks for the report. This seems odd behaviour as the OS would have already detected the presence of a cart during powerup and so basic should be in. It maybe a by product of some of the AR booting code - I'll check. Perhaps Steve can comment on if this is a 103XE specific thing? Regards, Mark

Great demos Michal! Kind-of an 'Aladdin'/'Prince of Persia' feel to it. My 2-cents on the main Cart models: XEGS : Maybe good for your size of game. With this you get the last bank of the cart always in the range $A000->$BFFF. I like this as it gives you a fixed base for all your core-routines. Bank access occurs by selecting your 8K bank to sit $8000 an $9FFF. So this can be used for copying out graphics etc, access music temporarily etc. Because you can fix code in the swapable banks, this frees up the memory (typically $0600->$7FFF, though you can go lower) for display memory, game variables etc. I think the advantage of this is that you can make large games that can run in 32K and even 16K, e.g. on a stock 400 or 600XL! Finally, this has an advantage in that you can re-use existing XEGS carts quite easily by replacing the (E)PROMs. Switchable XEGS: As above, but has the advantage of being disabled - freeing up the memory underneath. A bit more thought needed when developing on this but very nice. I don't think there are standard boards for these in existing commercial titles, the mod'd boards are done by Nir Dary. MultiCart: Similar to the Switchable XEGS except that a whole 16K is selected between the range $8000 and $BFFF. I find this slightly less easier to work with than the XEGS, but each to their own I guess. Typically I'd relocate a bank-selection or disable routine to the working RAM and then any code can access it safely. These boards are made by [email protected] and, though I haven't got one, have a professional look to them. FlashCarts: Made by Steve/Classics @ AtariMax - available in 128KB and 1MB sizes. These use a single 8K bank between $A000 and $BFFF and can be disabled to acces the RAM below. So, again, some thought is required when planning the swapping, but some more RAM is free'd up (on machines >32K) between $8000 and $9FFF. As pointed out elsewhere, these have the re-usability factor. Also, though yet to dive into this myself yet (soon though...), you can include code in your program to erase and write to banks (64K each in size) within the flash mem. Therefore high scores/game states/player data etc can be saved and recalled without the need for a tape/disk drive. Hope this summary helps people - feel free to correct any inaccuracies. Regards, Mark

Stage 1 has been reached!!! And its been painful getting there :!: If it wasn't for half the cracking already done by the mysterious 'Glenn' then this would have taken a lot longer I can tell you! There are so many replacement loading routines they'll be in the double figures before too long. OK - so what does this do? Using a real machine and an 8Mb flashcart - or an emulator supporting it: You can run the intro right through and press START at any time to continue loading. I was able to relocate the P/M memory used for the loading-tracker and so this still appears, albeit running a little faster. You then see the Character option screen. Ignore all the disk based stuff for now - press 'T' for a temporary character. Enter and verify your name and then select your stats at the Gate by pressing 'Space'. You will then be Joined... After which a crash occurs Don't worry about this, that's how far I wanted to get for this release. I'll be having a little break before commencing with the next release, wife not too happy at me coding 'til 2am and a short holiday coming up, so be happy with the great progress so far for now. (1 weeks work!) The aim of the next release will be to get the game working with the temporary character. The following release should then look at adding the disk or flashcart loading/saving support. I've gone back to favouring the flashcart as, because the disk I/O functions have been over-written, these would have to be re-replaced whilst the load/save to the character disk is done and then replacement ones replaced - confusing huh Also, the O/S disk I/O routines cannot be used as the memory areas they would use are no longer available. Again, we'll have to wait and see. Best wishes, Mark PS: I'm not 100% certain that my replacement Get-Sector-From-Rom routines are fully protected from interrupts occuring whilst a ROM bank is switched in, but it seems to be OK. Ar_cart_v1.zip ar_cart__maxflash_image_.zip

Interesting stuff, I'll look into this whilst doing the cart port. Maybe it could be possible to get the game to adjust itself if a PAL system is detected. Anyone have some common code for this? Certainly the intro music sounds better in NTSC mode! Regards, Mark

Objective almost complete, remaining is: After the intro, the loader uses PMs to display its countdown - an neat base 6 ticker. This is using the memory $BC00->$BFFF. Because the Flash cart swaps in and out whilst transfering memory blocks, this looks corrupted. The 2 solutions to this are 1) don't display anything, which isn't too bad a substitute and 2) Remap the PMs somewhere else. This should be OK as the loader doesn't use anything between $1C00 and $1FFF and so they can go here. Therefore I'll go for 2) and if it works out to hard I'll do 1). Next - after the main game code is kicked off - there are a few more sector accesses from Disk 1 - Side 1. haven't check what for yet, but they need to be reproduced. The pain in the ass is that once the game code has been loaded, the I/O routines are in a completely new place and so I must write a replacement for them. Question - does anyone know if D1S1 is ever accessed again? Regards, Mark

Hi, I've disassembled and gone through the intro and character creation code. This looks straight forward enough to simply lift the memory post its loading but just prior to its execution from within the emulator so that these can be loaded directly from flash and then jump'd to, rather than re-writing the disk-access routines for them. That will get me to the stage of then looking at the 'Insert disk X/side Y' code so that I can then formulate how that can be remapped to Cart. From what I've seen so far - AR uses replacement Disk I/O routines in a similar way to LucasArts 'Koronis Rift' and 'The Eidolon'. Therefore replacing these shouldn't be too tricky, except all RAM ($480->$BFFF) seems to be in use so it looks like the new routines will have to replace over the existing routines, i.e. be written at/over the same memory locations. Any other bits at pieces (like the copy protection) will hopefully fall out as I come across them, and I can explain them later. So the aim for next week will be to have the first cart image ready from which the intro will run and then allow a character to be created. With regards to the character disk - I think it maybe worthwhile keeping it disk based for the early work. The logic here is that there is quite a lot of menuing/code related to this that will be best left-alone for now. I tend to go for a temporary character at the moment anyway Regards, Mark Questions: The disk request routines appear to be able to ask for all of the 'other' titles, 'Dungeon', 'Arena', etc. Does anyone know if the game engines are identical/very similar and are the character disks interchangeable between the City and Dungeon?

I had already started work on a cart version of "Winter Olympiad 88" but seems like there's more call for these two games, so I can switch to work on these if it doesn't conflict with anyone else trying the same thing ? I have an original AR-City but no Dungeon - so with regards to the copy protection, I guess the basis for this work will be the cracked disk images included with the XLit emulator? The re-write should also permit the saving of characters to the flash cart - so the feasibility of this will also have to be investigated. City or Dungeon first? Well, let do them in order of appearence. Hopefully after doing one the other should follow easily. There may also be just enough space on an 8Mb flash cart for both games. Regards, Mark

Not the impression I got, but 'I cant get to see the file through atari dos' isn't too clear Carmel, can you post the related, binaries/atrs you are using and exact steps of what you are doing and what you expect to see but are not? All: Would it be worth trying to convert the PC util Exomizer for the C64 to produce A8 files? Regards, Mark

If you're using windows then there's the MakeATR program. You can transfer files in and out of an ATR image that's been formatted with DOS.

It's already been done with the 1Mb Flash cart by Steve. Check the Forums at www.atarimax.com

Hi, I'll be coming along to this event for the first time, so I'm interested to know if any other Atariage members are heading there too. Best wishes, Mark

Thanks alot, I was only using Vice 1.4, upgrading to 1.16 certainly helps!