playsoft

Here is the update containing the new RMT tunes that were very kindly donated. MaxFlash 8mbit cart version: ab_cart.zip Rambo 1088 versions: ab1088.xex SSSD.zip SSDD.zip ab1088_dsdd.atr

There was another one too, so I thought it best to set BOOT? rather than remove them in case there were any more. It does seem an odd change to make!

I don't know about this exactly, but I have seen the real time clock being checked before. I originally thought this must be copy protection from the original cart, but I just downloaded the image from atarimania and it does not access BOOT? In fact when the cart is running I think BOOT? would be 0 anyway. So now I wonder if this was something put into the RMT version?

And here is a xex file which will work with the Ultimate SD cart. What it comes down to is the BOOT? flag, the xex loader and some sneaky copy protection. The original cart uses BOOT? in a number places as a copy protection mechanism. It expects BOOT? to have a value of 1, any other value will result in problems (like rebounding off the ladders). When the xex file is loaded from the MaxFlash cart, BOOT? contains a value of 1. You can see the MaxFlash loader set it. When the xex file is loaded from the Ultimate SD cart, BOOT? contains a value of 3. I guess in most cases this won't cause a problem. All I have done in the attached xex is to add a new segment that sets the BOOT? location to $01, just before the run segment. The non-RMT version runs correctly from the Ultimate SD cart because it had all the BOOT? accesses replaced. DKRMT74_$09.xex

I see you are loading it from the Ultimate SD cart so I tried a couple of tests. From RespeQT it runs ok. From a MaxFlash workbook and flashed to a cart it runs ok. On the Ultimate SD cart you get your rebounding barrels. I then tried the original RMT version (i.e. without any of our changes) and that gave exactly the same results. Edited to add: If you add it to a MaxFlash workbook, export it to a .bin and turn it into a .car, that will run ok from the Ultimate SD cart. I have done that for you in the attached. dkrmt.zip

I am sure a lot of the code can be reused. It already contains some recycled code - the static display/sound for the level titles comes from one of my old A8 magazine games from 1986. The sprite multiplexer lends itself more to vertical games than horizontal ones, although I never explored single coloured sprites. Having spent a long time on this doing something different appeals more to me now, but in the future I'll probably want to try and do something else with it.

I did not have any luck using fcode.zip. I was trying to write to sector 12 and found that it erased but did not program. I noticed that setsec was storing the first bank number in cursec instead of the sector number and with that changed the sector now programmed. However I think I saw some other data changed that I was not expecting so I contacted Steve and he sent me the code he'd used on Ultima IV and said I should post it. example.s

There was much toing and froing with the music which ended up taking so much of my time that I'd just had enough. We received permission to use Flimbo's Quest, so it was either that or no music. At that point I should have asked publicly if anyone was interested in providing some music but I just wanted to move on with getting the rest of the game finished. Thank you so much for your offer but I have received a generous donation of a number of RMT files which are not original but are new to the A8. There will be a new release with those, see what you think then.

DLIs move with the vertical scroll so I would have had to factor that in when calculating which multiplexer slot to use. By using a POKEY timer the interrupts always occur on the same scan lines regardless of the vertical scroll which seemed like it would be a bit simpler. Also it was something I hadn't done before so that made it an interesting thing to do. I started off with 15kHz for scan line accuracy but I was having trouble with the sound effects. So I switched to 64kHz and configured the interrupts to occur as close as possible to the required scan lines. I was able to do this because the first two scan lines of each sprite are blank to give the interrupt time to set all the h/w registers, so I had a bit of flexibility. I posted the source code to the earlier demos here: http://atariage.com/forums/topic/234237-what-made-crownland-so-colorful/?p=3172380 When I find some time I'll post a simpler example of what I finally ended up with.

Thanks for reviewing the game, it was really nicely done.

You always covered the demo versions and I wanted to say thanks!

I should have done Bop It! codes

Random - so you can play on normal but you may have to do it a number of times to see them all.

Ah yes, there are only bosses on the vertical levels, none on the horizontal which makes them seem shorter (although they are different lengths anyway, the shortest is 23 screens, the longest 58). I was not going to have any bosses originally, they came about as a means to fully replenish your shields. This made it a lot easier to put the level attacks together since I could work on two levels at a time in isolation.

These are the blast codes for normal difficulty.

To all things an end... or 4.

Short vertical levels sounds like it might have got tricked into demo mode where only the first 6 screens are shown.

It is nice to hear it's working on these. I used a POKEY timer for the sprites which I expected might cause problems under emulation - no issues with Altirra, one in Atari800Win PLus which I got around with a better solution anyway (I was using a WSYNC to ensure that POKEY had latched, replacing it with code that took long enough solved the issue).

They are different routines but they reside at the same addresses on different ROM banks. Hence the main program (which resides in RAM) simply has to select the vertical or horizontal background bank and can then call the routines (initialise background, scroll background etc) blissfully unaware of what type of level it is. I never did any bank switching back in the day (I didn't make it to the XL) but feel I have made up for it now...

Just to be clear I have no issue with anyone not liking the game - there are things I don't like either. It's snide comments like "feeling sorry for the code" that I thought were completely unnecessary. One of the options with the music was to have my two teenage nieces who are both musical do something. I would have enjoyed it and I think they would have too, but I wasn't going to risk exposing them to any nasty comments.

It's just character animation. I used 8 characters in total to form two 2x2 squares. The same animation is used in both squares and a mesh is applied over the top of one of them. The source to an earlier demo (when it was disk based) is available here: http://atariage.com/forums/topic/234237-what-made-crownland-so-colorful/?p=3172380 The code was given for the multiplexer but it will include the rear character animations too (it's from a while back and I don't remember how readable it is - probably a lot better than it is now!).

No it won't be released on cart - it's a hobby and I don't want to commercialise it at all. I appreciate there may be people that don't want to have to flash a cart themselves but luckily this is the Atari community. I am sure if they ask there would be people willing to help. I would for anyone in the UK.

Thank you Fletch. It got a better reception here than I thought but I expected some people to be disappointed. I didn't expect insults though, a little hobby which is supposed to be fun...

Attached is Rambo 1088 memory expansion version - there's a xex file plus various disk sets for different format disks should anyone want to boot it from a real drive. I have only been able to test the SSSD set on real h/w. ab1088.xex ab1088_sssd.zip ab1088_ssdd.zip ab1088_dsdd.atr

Thanks Steve! It's just an image which is displayed for 1 frame in 3 instead of the normal game screen. The image has 4 frames with increasing gaps between scan lines to try and give a Jeff Minter type explosion (Mutant Camels was the first time I saw those split apart explosions). 5 seconds is suspiciously about how long it would take a byte to wrap around if you increment it every vertical blank. I have some flags that I inc and dec to set and clear. Perhaps there is a race condition which doesn't happen very often where I can miss one reaching 0 and then have to wait until it completely wraps around. I'll look at some robustness changes in this area and make a new cart version available with the Rambo 1088 version.