Sheddy

http://www.atarimax.com/flashcart/documentation/oldkit/chapter3.html To program using SIO2PC or APE cable, boot while holding down OPTION key.

Sorry to resurrect this thread, but anyone burning a new cart might want to use the version attached here - which contains a small optimize fix - we're talking about 40 cycles per VBI here, so it's not going to make any noticeable difference (except to me!). This does also include Steve's previous patch for the "bank zero" Maxflash carts. sharrier.zip

If you got to stage 9 you'll be able to select stage 1 or 6 to start from. Being able to select a stage is decided on whether you make it to a bonus stage or not. Once you've made it to a bonus stage you'll be able to start from that point on all the time the game is running. There's another bonus stage at 12, so you'll be able to start straight from stage 13 once you've managed to get there - you will have the choice of stage 1, 6 or 13 as starting points. Hope that makes it a bit more clear.

Glad you like it! It could have a checker board - as long as you didn't mind the game running quite a bit slower - colour bars are easy to do and don't use much processor time on the Atari 8-bit (compared to drawing stuff) ; there's a reason why you see them in nearly every game and demo

Thank you! I wouldn't have been able to do it without you though

This is terribly sad news ..just want to add my condolences

Well, the A8 + large cart can make possible some graphically and sonically intensive things that you wouldn't seriously consider otherwise. I don't know what projects might be particularly suited though - certainly other 3D style games - Anything that has a lot of graphic data, or large graphics and sound samples could benefit enormously. How about Street-Fighter? Because the player/missile system is relatively poor for a lot of game types, compared to say, the C64, we need to make the most of software sprites, which are slow at the best of times on 8-bits - to make them a bit faster requires a lot more memory than usual methods (as you know from your experiments of course). The major problem for the little Atari, as always, is the lack of colour depth with enough resolution. Maybe, just maybe, some of Jose's ideas (unfortunately quite often almost impossible to pull off in a real game with full freedom of movement) could be more easily realised by use of large carts and lots of kernel like routines. If it was a real, paid job, I would have been sacked a long time ago! I have no way of answering your question though, because that isn't how it happened and I have the answers now; I don't know how long some things would have taken to pop into my head on how to do things even if I worked at it full time. A game very similar to Space Harrier (say Space Harrier II) might only take six months or so with the help of a graphic artist, as it would mainly be about getting level data and pattern data in there. There were quite a few times when things weren't going well with the project and I was not finding it fun. Ideas that didn't pan out, difficult compromises and almost impossible to find bugs made me pretty depressed at times. But when things do eventually begin to come together, or you find that dreaded bug, the highs can really something, as I hope you know (or will know soon)! Of course, people's appreciation is also nice too! I remember seeing the games you mention, but they were never at the arcades we usually went to. Oh! Nearly forgot: Salamander! (and what a wonderful version the C64 has - it's a shame our 8-bit isn't quite as great at 2D shooters as the C64 - I still would've liked to see something similar on A8 though)

The way of drawing the software sprites went through many iterations before ending up where it is now, 256 byte wide screen layout, and taking advantage of the massive storage capacity and access speed of the 8Mbit cartridge. The game could fit in probably a 1/4 of the space, but the frame rate would have suffered. Although not part of the game, the conversion program for the software sprites was difficult and is very messy, mainly because of my attempts at making some size vs speed optimisations, using rule of thumb methods, as I lack the necessary mathematical analysis skills required. That said (in answer to your other question), I am relatively proud of the code it spits out to draw the sprites. The code that controls anything that flies around was probably the most complex - the pattern sequencer, decoder and handler (not really a "handler" in the strictest sense of the word - just needed to distinguish it from what I was already calling the sequencer). Although I tried to design it carefully, it had to be rewritten a couple of times as I kept finding things the arcade game was doing that my routines couldn't. It is the heart of the game, and I guess I'm quite pleased with the code. The data for all the movement patterns is quite minimal - under 4K. If I had to do it over, <shudder>again(!)</shudder>, maybe I would try to make the framework cleaner by using some of the state machine way of thinking about things, and I would have given more thought to disk versions for very large RAM systems (but that seemed even crazier to me than big carts back in 2003, when I ditched the 130XE only disk idea). Also, maybe to make better use of the Maxflash cart, for things like Marius1976 is suggesting. The code for the high score saving is sort of incomplete too - if someone improves their high scores gradually enough it could be possible for it to stop saving any more high scores until they are cleared - That will happen if you get onto the high score chart more than 744 times. I also wanted to include some missing graphics from the original, such as the huge explosions that happen sometimes when you blow up ground based stuff.

OK, at the risk of boring everyone else and overstaying my welcome by bumping the thread, I guess I can answer some of the questions I've learned quite a lot about programming the 8-bit over the years, but there's still a lot to learn from veteran developers and professionals in the best ways to approach big projects and being organised. For example, people look to create a state machine as a starting point for anything beyond simple games as it soon gets very messy otherwise. Any resemblance to a state machine in Space Harrier XL/XE is purely a co-incidence! I learnt most everything I know from doing this project and am self-taught, so while everyone can look at my source code, I couldn't necessarily recommend it as an template or a particularly good and clean way of doing or organising things. I still don't know how to use all the features of the Atari well! Most of what I learnt did come from trying to do this project. Things such as IRQ timers, I had no real clue about until about half-way through the project, and I still had some misconceptions about them until only a couple of years ago.

Thanks NRV - too kind. Some arcade favourites that spring to mind: Defender, Mad Planets, Exed Exes, Truxton, R-Type, PacLand... Now, was there something you need to be doing too? Please - don't take as long as me! And thanks to everyone for showing your appreciation (even if it is a bit over the top IMHO ) BTW I have no problems with the questions raised about the format chosen, and I hope I explained my reasoning clearly; but thanks for the support.

It was quite a few pages back, but this post explains a bit about stage select and continues

Yes

Thanks for the fix, Steve I needed to get some sleep before I was going to tackle it.

Just checked it on one of the carts that's going to get reprogrammed, works perfectly! :-) Steve No it doesn't. Sorry Chris. This version Crashes during stage 2 Every time. That's...curious. The hack looked OK on the face of it. It doesn't overwrite any code or data.

[Deleted]

Oops It hadn't occurred to me that there could be versions of the 8mbit carts that started in different banks. I'd assumed the jmp straight to bank 0 in bank 127 was just there to make it easier for the Maxflash Studio software to work with both the 8Mbit carts and the 1Mbit carts (which always start in bank 0). I'll see about getting a fix done that can work with both versions.

I made a tough decision about 7 years ago(!) that to bring about improvements I wanted, I had to move over to a cart only format http://sheddyshack.co.uk/2003/12/move-to-cartridge-only/ I'm happy for anyone else to give it a shot, but sorry, I don't want to re-develop the game myself - it's not a quick or simple task.

That is a crazy, crazy limitation to put on a game, the original of which has many, many megabytes of graphics (and can also scale them). I think C64 PowerDrift is exceptional considering these limitations and gives a good feel of the original Same problem, but worse with the C64 Space Harrier, which was such a shame. Imagine what he could have done with just some more time and a disk based version...

Ha ha! If only.

Most kudos to MAME single frame step though

Did play arcade version a lot, but didn't look at the code on any versions. Writing my own code from scratch was the fun bit for me.

Any reason why is it STY ? I bet Sheddy had a good reason, but what was it ? don't know myself actually! STAs and STXs, yes. Have a look if you want. (This would be useful for trying to convert to other storage formats too. You'll soon see why I'm not too keen.) Start at sh.asm. Apologies in advance for general messiness and not very many helpful comments. Attachment is .7z, but inside a .zip as AtariAge doesn't allow .7z - and it's too big as a .zip to post SH.zip

Bryan, that is so true! And thanks, that's good advice

Don't forget Maxflash carts only map in one 8K bank. Other 8K area is RAM and used as such...unlike XEGS

I tend to agree. The label looks really good though