playsoft

Yes, the current demo was released in the 5200 thread first - it's post #23 (is there anything I can do to stop people downloading the initial version in the first post?). The two 8-bit releases in this topic are identical to that version. I've got nothing else to show at the moment as I have been working on the midi converter. I am aiming for a new demo release every 6 months, so that there is enough new content to make it worthwhile.

When Kyle asked about supporting the RAMBO 1088K I said it sounded like a possibility but that I'd leave it until the end as I didn't really want to support another variant during development. However after finding out how RAMBO 1088K worked (thanks to the excellent Altirra h/w reference manual) by only using half the banks at $6000 I get the same layout as the 5200 version. So the 1088K version only exists now because I could do it for free (well it was a couple of hours work - selecting the 5200 bank layout with 8-bit code options, different macros for bank selection and turning the resulting cart image into a xex). I don't really know where we'll end up as it's not like any of this is planned in advance. If we end up using the entire 1MB of the MaxFlash then perhaps we will make two 5200 versions - they will be 512K so are possible candidates for what you suggest.

Yes all three versions build from the same source code... it's write one get two free.

Credit for the design and content of the backgrounds must go entirely to Harvey. I just wrote the display code and a tool for designing them. I was amazed when Harvey sent me the GTIA 9 robot design.

And here is the RAMBO 1088K version of the demo which should run on U1M when loaded from the FAT32 partition using the SIDE loader. Thank you Kyle22 for suggesting that I support it and for testing it. ab1088k.xex

I updated my path tool too - before and after:

Wow, a fantastic place to study and such a stunning building and grounds. I imagine the course itself was hard work though. I have not got around to trying to fix it yet, so thank you for the suggestion. If that is too complicated for me I'll try calculating the points as I do now but use them to determine the approximate length of the curve - I can then calculate the points again using this. I began this project to try 6502 programming again but I've probably done more ActionScript so far!

Well, we all have different tastes. I could not be more pleased with the graphics which Harvey has come up with - my favourite is GTIA 9!

One way I'm aiming to minimise flicker is in my path tool (for the sprites which follow a vector path) I've used the same multiplexer logic so I can see what it's going to look like before it gets anywhere near the 8-bit. You can see the tool here: http://www.playsoft.co.uk/path.swf You can click around and draw a path, grab a point to move it and press T to toggle test mode. The values on the right are step size, gap between sprites and number of sprites. I still have some work to do on this as the points are calculated using the straight line distance but the bezier curve can be significantly longer especially around tight turns - it makes it look like the sprites speed up when they go round corners.

I don't do anything with the rejected sprites - each frame the multiplexer processes the sprites in the order as specified in the next sequence in the random table. E.g. if sprites 5, 7 & 9 have the same y coord: frame 0: .byte 0,10,1,4,9,13,15,6,7,3,12,5,8,2,14,11,16 --- 9 and 7 are displayed frame 1: .byte 0,14,7,16,15,6,5,1,2,10,9,13,8,3,12,4,11 --- 7 and 5 are displayed frame 2: .byte 0,10,13,9,3,1,12,7,4,14,8,11,15,2,6,5,16 --- 9 and 7 are displayed frame 3: .byte 0,11,4,15,5,13,12,6,14,8,10,2,9,7,1,3,16 --- 5 and 9 are displayed etc... This seems to work ok and of course I am trying to avoid clashes wherever I can.

Thanks Jason. No it's too big now to run from a 1050. This was not an easy decision to make and we ummed and ahhed over it for a long time but eventually decided it would be more fun to go the big cartridge route.

José - I had to check the code... In GTIA 9 and ANTIC 2, the missiles use the fifth player colour only; the enemy missiles are not overlaid so there are two of them on screen simultaneously. I will try a different hue in GTIA 9. In GTIA 11 and ANTIC 4, the missiles alternate each frame between fifth player colour and sprite colours; the enemy missiles are overlaid to get the OR sprite colour so there is only one on screen at any one time. In GTIA 10, the missiles use the sprite colours only; both player and enemy missiles are overlaid to get the OR sprite colour so there is only one enemy missile and the player fires left/right.

Thanks Popmilo! Yes, you only ever get 2 multicolour sprites in the same horizontal space in any one frame. The multiplexer divides the screen up so that every 8 scan lines there are two multiplexer slots available - one for the player 0/1 sprite, the other for the player 2/3 sprite. When an attempt is made to draw a sprite it first looks at the player 0/1 slots - if all the slots it needs are free then it books them and updates the sprite data. If the player 0/1 slots weren't available it then tries the player 2/3 slots. The multiplexer interrupt is run from a POKEY timer and whenever it finds a booked slot it writes to the h/w registers. Everything is double buffered so that it can be preparing the next frame while displaying the current. The bullets are all missiles. The players are missiles 0 & 1 and are simply multiplexed as they never clash. The enemy bullets are the remaining missiles and are not currently multiplexed. In modes with good missile visibility (GTIA 9, ANTIC 2) they are used independently, in other modes they are overlaid to get the OR colour from the sprite colours. In poor visibility modes the missiles also alternate each frame between normal player colours and fifth player colour as that seemed to give better results.

Each frame I process the player ship first*** so that it is always drawn. The remaining 16 sprites I process in a random order so that it's not always the same ones missing out on the multiplexer slots when there are horizontal clashes. For my random order I just use a table of 10 order sequences: shuffles: .byte 0,10,1,4,9,13,15,6,7,3,12,5,8,2,14,11,16 .byte 0,14,7,16,15,6,5,1,2,10,9,13,8,3,12,4,11 ...<snip> .byte 0,6,2,12,1,10,16,15,14,7,5,13,3,8,4,9,11 *** Except in GTIA 10 where I can't modify the sprite colours as they are used in the playfield. If I always drew the player ship, the sprites using players 0 & 1 would always disappear when alongside the player ship.

Here are the files - it's now an Atarimax Maxflash 8Mbit cart image and in the zip you will find ab.bin (raw image), ab.car (image with CART header) and ab_atarimax_8mbit.atr (programming image). I have successfully tested on Maxflash 8Mbit, THE!CART, Altirra and Atari800WINPLus. Going the cart route means it now runs on a 16K machine. Renamed ATARI BLAST! because it contains ANTIC modes too, a couple of the levels you may recognise as reworked versions of Harvey's HawkQuest designs. On the programming side there are now sound effects, a couple more background tracks, some new attack patterns and enemy missiles. Still a lot to do... Keys 1..8 will jump to a level (at any time) and A will start auto-fire which you can cancel by pressing the fire button (this was added for the 5200 where fire buttons are not as robust as they are on the 8-bit joystick). Paul ab_070114.zip

Deal! For getting it running on the U1M - I've still got a lot to do before any work will begin on making it playable. I've looked up the RAMbo and CompyShop schemes (in the excellent Altirra h/w manual) and I think I can support this without any major changes. I've got a few other things to do first, but will message you when I have something to test. Cheers, Paul

Well this did start out as being disk based but when the decision was made to support the 5200 it became Atarimax Ultimate SD (5200) and Flashmax 8Mbit (8-bit) as I can build these from the same source code with minor differences. I am not familiar with how the U1M works but presume it must be bank switching in which case this is a possibility although I'd probably want to do it afterwards rather than develop 3 variants simultaneously.

Thank you. This version does not work on Altirra, but I will release an identical version for the 8-bit computers tomorrow which does.

Hi Chris, I don't think the emulator supports this format but I will be releasing an identical 8-bit version soon (tonight if I have time) which is in Atarimax 8Mbit Flashmax cart format. This runs on Altirra but I have not checked Atari800WinPLus but I think it should work - will check and let you know. Paul

Thanks Alan. It's all about getting the building blocks in place at the moment and there are still some major things to address, but it will get there eventually. Paul

Here is a new demo release of the project, now called ATARI BLAST! due to the inclusion of ANTIC modes. The filename extension has changed to .hyb but it still runs on the Atarimax Ultimate SD cartridge. It now uses hybrid mode which provides 8K bank switching instead of 32K, making it easier to align with the 8-bit version. Two of the new ANTIC 4 levels are reworkings of Harvey's graphics from HawkQuest, an excellent game he developed with Andrew Bradfield for the Atari 8-bit published by Red Rat Software in 1989. There is another new ANTIC 4 level and a new ANTIC 2 level. Harvey has also been busy refining all the original GTIA levels too. There are now sound effects, some varied music, some new sprite paths and enemy missiles. Controls are now: any fire button will fire 1..8 will jump to that level (at any time) * will start auto-fire which will remain active until you press a fire button ab5200.zip

pps was right - there are other Bee Gees fans in the world! My midi converter is extremely basic at the moment but this turned out well enough that I wanted to do something with it - hence the karaoke.

Thank you all for the positive feedback. No plans to make a cart, only intending to release it as a public domain bin for the SD cart. With 512K so much is possible but as a spare time project it has to be fun to develop with no deadlines or pressure. The intention is to work on it for another year and hopefully end up with something reasonably playable. Sound effects = planned Enemy patterns = currently being worked on Bosses = maybe Smart bomb = maybe Most of the border changes you see are in GTIA 9 - you can't have the border black and the screen a different hue unfortunately. The GTIA 10 screens have a green border which is also one of the playfield colour registers. I know we looked at making that black but I can't remember the reason why we didn't now. The current missiles toggle the fifth player enable bit each frame which results in varied colours and does help them stand out a little bit better than they otherwise would. The multi-coloured player bit is set for the sprites and this does lead to some strange blending of the missiles. It's not ideal, but just about acceptable. The missiles can be made fatter which does make them more visible, but they don't look right coming from the ship design. There are currently 2 rates of vertical scrolling, 60hz and 30hz which is selectable every screen (a screen being 24 lines of characters). The idea was to scroll at 60hz to show the power of the machine and 30hz when there was an interesting design to draw attention to. 2 player simultaneous = no plans but perhaps afterwards might consider a cut down version which could support this

I had shipping confirmation for my Ultimate SD cart last week and a reply explaining hybrid mode this week.

No plans for a cart, just files for the SD cart. I think if I ever did release a cart it would be GTIABlast! The old magazine games aren't good enough, they'd have to be significantly improved.