Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by playsoft


    Holy crap man! This game is HUGE! how big is that Atari Blast demo file?


    Well it is somewhere around 450K at the moment although there is some wasted space in there. It will require a MaxFlash 8Mbit cart for the 8-bit and a Ultimate SD cart on the 5200 where it runs as a 512K hybrid image.


    I like the soundtrack of this game. Its from the MSX game "Nemesis" or not ?


    There are 4 tracks - the Xevious jingle, two from Gradius and one from another game (I forget). I picked the midi files up from The Midi Shrine website which I converted to a format suitable for the 8-bit. The plan was for the music to be a homage to other shooters but now I hope to have some original music instead.

  2. Is any of the history behind Drelbs known? It was published by Synapse but was Kelly Jones employed by them to write it or had he already developed the program and they simply published it?

  3. I tried to play this through emulation and the emulator crashed. I'm using kat5200. I will try it using real hardware, though.


    I have tested on Altirra and on real h/w using the Ultimate SD cart, I've not tried kat5200 but here is a version with the cartridge header if it helps.


  4. Drelbs is one of my favourite 8-bit games but I couldn't find a 5200 version. This is a port of what I think must have been the cassette version as it ran in 16K. There was no title screen so I've added one with a speedy rendition of Wilder Reiter. I've changed nothing in the game itself other than to remap the keyboard controls:


    START - restart game (at any time)

    # - press this for difficulty selection, then press * repeatedly to select difficulty, then press START

    PAUSE - pause game, press RESET or 0..9 to resume


    • Like 8

  5. Thanks Steve. The original intent was for it to be a single load .xex file, GTIA 9 only with a couple of levels. Exactly where it will end up I don't know as it seems to have taken on a life of its own. As long as it continues to be fun to work on is the main thing - I'm not going to beat myself up saying it must do this or that - it has already exceeded what I was expecting to do.

  6. Steve kindly provided me with details of the hybrid 8K write/8K read mode supported by the Atarimax 5200 Ultimate SD cart. I have been using this mode primarily for the 8K read bank but now that I've experimented with the 8K write bank I thought I'd pass along the details in case they are useful.


    To use hybrid mode the image must be 512K in length with a ".hyb" extension. The cartridge is mapped:

    $4000..$7FFF banked area
    $8000..$BFFF fixed read area, top 16K of image

    The banked area can be either a 16K read bank or a 8K write/8K read bank.

    The cartridge has 512K of onboard SRAM and when you select an image it is copied into SRAM. The 8K write/8K read mode allows your 5200 program to write to the onboard SRAM.

    You select the bank by touching $BFC0..$BFFD where $BFC0 selects the bottom 8K of the image, $BFC1 selects the next 8K etc...

    When a 8K write/8K read bank is selected the following mapping applies in the banked area:

    $4000..$5FFF provides write only access
    $6000..$7FFF provides read only (and execute) access

    There is a significant restriction when writing, in that the way the cartridge write latching works means that 6502 dummy cycles can cause spurious writes elsewhere in the bank. For example, I find that sta (zp),y works ok when y is 0, but not when other values of y are used - I see additional spurious writes elsewhere in the bank.

    The attached demo program has 10 high resolution images stored in the first 10 banks accessible via the 0..9 keys. You can move the cursor around with the joystick and draw over them in white by pressing fire, or black with alternate fire. Start will fast cycle through all the images, any key will stop it. Rather than being anything useful (or particularly enjoyable) this is just to demonstrate use of the cart SRAM.

    The attached source code is ca65 - the bin directory is in my path and I use build.bat to assemble.



    • Like 2
    • Thanks 1

  7. Wow, I've just been playing this packed version and it is incredible in many ways. The size of it is beyond belief!


    I have some requests for it, but please feel free to ignore them as I am not a person who demands things and this is your work, not mine, I just want to suggest some ideas which may improve it further.... and I appreciate that this isn't a finished version....


    1) When the white noise screen comes up, make it that you can hit fire to continue rather than wait a few seconds. This will give people a small rest of the length of their choice before moving onto the next level.


    2) Can you make it so that the background colours are known and then the colours of the aliens / bullets are set to contrast to the background? It can sometimes be difficult to see what is going on.


    3) Can the transitions from one colour to another or another set of background tiles be done in a smooth way, i.e. perhaps have a screen with very little going on (less colours / backgrounds) and then do the transition there? That way it will appear smooth.


    4) I always feel a bit aggrieved when an alien approaches from the back and then hits you when you have no idea it is about to arrive. Is there some way that the user can be alerted that an alien approach is arriving from behind you (I am being so careful with my words here!)? Maybe a sound or a screen flash or something on the screen appears?


    5) And this one is just an idea that entered my head.... with some specific formations that arrive, the scrolling is stopped until they've all gone, that they will continue in their formation until they're all shot down.


    It appears to be a huge game and has so much going for it. This could I suspect go on to be one of the best Atari games that exists.


    1) I doubt the static display will remain in it's current form. I am all for not giving the player any respite at all and just go straight into the next level. It takes a few frames to set up the next level and without any intermission at all it looks like a glitch - ditto if the static display is not held long enough. The first 5200 demo held the static display for half a second or so (nothing written in it) and that seemed about right.


    My inclination is to keep the static display short and perhaps insert a code or message blipvert style. A code could be used in-game perhaps, a message would be something funny (hopefully).


    2) & 3) are more Harvey's area but it is difficult to maintain a good contrast between the two. There were some very nice ANTIC 2 optical illusion designs which we canned because we just couldn't get sprite visibility anywhere near acceptable.


    4) I suppose it should be possible to add something in the status area to indicate where the next attack will come from. Alternatively play it like squash and try and keep to the centre of the court.


    5) Yes that's a possibility. At the moment I'm concentrating on putting the main building blocks together and once I'm happy I have all of the main ones there, then I'll start trying to turn it into something playable.


    The main thing with any spare time project is for it to be fun to work on. The plan is to work on it for the rest of the year and hopefully end up with something reasonably playable.

    • Like 2

  8. Ok, so you're updating file on the 5200 thread? Wasn't sure.




    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.

  9. When looking at the data-segments I saw, that you mostly used $6000-7FFF or just 8k of the available 16k rambanks ($4000-7FFF), WHY ?!?


    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.

  10. The background themes just rock and build on each layer, I love it when a solid coder gets it together.


    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.


    I felt invincible, well er 'cause I was invincible!



  11. So I implemented it today and it works. I quickly modified "HitCEE" for a test. You see an NPC on a path over the screen. Alternating the "old" time-based parametrization and the "new" arc-length-based one. HINT: press "m" to mute music :)


    :thumbsup: I updated my path tool too - before and after:




    Uh.. that is (was) exactly my cup of tea :)

    I spent some time as student here: http://www.welfenlab.de/en/



    I have written a tool to use different kind of splines (Monom, Bezier, B-Splines, ...) to model 2d-pathes (about the same as you did in Flash)

    Of course I use it now to pre-calc pathes exactl yas you do :)


    So my question, do you know what you need to solve the speed problem but it takes some time ti implement, or do you have to search how to solve the problem?

    I guess what you need is the re-parametrization of your spline into arc length. Not sure on this though, as it was almost 10 years ago :(


    Wow, a fantastic place to study :thumbsup: 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!

  13. I make it short:


    Love the PMG-multiplexing

    Love the parallex background (even animated)

    However, not a fan of the GTIA modes as main background. Same as for TMR's game.


    Is this still test gfx? Maybe with better artwork the GTIA modes can be put to good use. I hope you surprise me :)


    For the first two points and the idea of using GTIA for background in a game: Great Work!


    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!

    • Like 1

  14. 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.

    • Like 6

  15. Paul, understood... but the interesting part is... the multiplexer checks that there are all slots used and sprites need to be rejected? and these rejected sprites... you need to mark them? or are you prior entering the multiplexer shuffling the sprites via your random table around so sometimes it checks sprite 10 sometimes 5 etc? but on your zone... maybe sprite 10 would be not in range anyway?


    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



    This seems to work ok and of course I am trying to avoid clashes wherever I can.

    • Like 3

  16. Looks great Paul :thumbsup:


    Will it eventually run from disk (1050!) or is it likely to be cartridge only due to size ?


    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.

  17. @Pop: All shots are Missiles in 5th Player Mode taking PF3 colour (then 4Missiles = 4shots).

    Our ship its two Missiles and that's why it sometimes has diferent lines colours, when the PF3 register changes (this happens in GR.12/ANTIC4, the only Mode that uses PF3 on the gfxs) and enemys takes the the other 2.

    The shots PF3 its always white less in some parts of the GR.12/ANTIC4 levels.

    At least is what I get at the first time I saw those videos and right now running the Emulator Monitor.

    The 5th Player is always enabled and how would you always have the enemys bullets as white also on the 4:1 GTIA and still have them moving in 2:1 ;) ?

    The only thing here done in software its the parallax scrolling.



    P.s.- The only thing I would suggest is on the 1:1 level that has gfxs/PF1 in white but maybe also on GTIA Mode9 colour0 black/grays/white set the bullets/shots PF3 in same luminance E but other colour to better distinguish the gfxs 'vs' shots.

    Just an idea...

    All the others are really AMAZING, OUTSTANDING,... !


    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.

  18. If I'm seeing it correctly: when you pause video on Youtube you can see that if two enemy sprites are in same line one of them disappears...

    Bullets are probably software sprites.


    No magic there imho, just a very good, high speed code ;)


    Great work Paul!


    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.

    • Like 2

  19. looking good... as I am still interesting in a simple sprite multiplexor... how did you realsied yours? not the vertical splits via DLI but when more than 4 players are per scanline?


    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:

      .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
      .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.

    • Like 1

  20. 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).





    • Like 8

  21. I volunteer to be a beta-tester :)


    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.




  22. How about a (NTSC) disk version that loads into extended RAM? All of us Incognito and U1M owners would love it :)


    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.

  23. Stuck this on the SD Cart, and I cannot believe this is a 5200 game! Granted it utilizes the Atarimax bank-switching, but still I'm flabbergasted. Amazing work! Screen scrolling/multiple background layers, music. Can't believe it.


    Did you say this worked on Altirra? What mapper/mode/settings are needed for that?


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

  • Create New...