playsoft
-
Posts
658 -
Joined
-
Days Won
3
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by playsoft
-
-
On 8/17/2020 at 7:24 AM, Bobo Cujo said:
@kiwilove @playsoft And now, a big one: a beta release of Hawkquest Joy2B!
(based on @playsoft's NTSC-compatible Atarimax Cartridge version; specifically "hq_blank.bin")
Old controls (in the overhead shooter stages):
Fire button: Shoot
Fire button + UP or Fire Button + Down: Drop Bomb
New controls:
Button 1: Shoot
Button 2: Bomb
This should now make lining up bomb shots considerably easier (especially given the sheer amount of flak to dodge).
Note that the game allows you to have up to two projectiles onscreen at once, where one of those is allowed to be a bomb.
Tested on level 1 (played all the way through until I got to the base).
As for why I'm declaring this a beta release rather than a full release:
As far as I can tell, the new button code appears to be stable, but it did involve having to branch out to other parts of the rom since the new code took up more space.
In particular:
- This is a very big game (!) and I haven't had the opportunity to play all the levels yet (but two-button firing makes me far more inclined to do so :-))
- The button 2 handler takes up $98D2-$98EB. I don't know if I clobbered an important lookup table/bitmap/etc. in the process; I didn't know of a better place to put this code ?
- I had to add some extra code to the game's custom VBI handler so that it got the POT value and called STA POTGO; this takes up $F2E0 - $F2EC (there's JMPs to and from the existing handler).
- This also meant changing the bootstrap loader code params to account for these extra bytes; hopefully this doesn't clobber other data someplace... (A01A: LDA #$EB now becomes LDA #$FB)
- I don't know if the on-foot sections need the Joy2B treatment as well. Other than moving and shooting, I don't actually know the controls for it (I don't even know how to get out of the upper-left quadrant of Mycea's base... is there a bomb somewhere?)
- I recall that this game is a bit on the tight side re: per-frame cycle count for NTSC compatibility - how much buffer is there?
@kiwilove and @playsoft, please let me know if any of that code should be relocated to other places, or if there are any other unintentional bugs I added...
@Bobo Cujo great work on this. Harvey asked me to do this previously and I put together a version for him to test (in July) but I don't know if he's got around to trying it. One thing I did find when I added Joy2B support was a (terrible!) existing bug that meant the game more often than not didn't boot on real hardware. The issue was I'd tried to read NMIEN in order to maintain it's status around critical sections.
So I changed:
.macro critical_enter php sei lda NMIEN pha lda #$00 sta NMIEN .endmacro .macro critical_exit pla sta NMIEN plp .endmacroTo:
.macro critical_enter php sei lda #$00 sta NMIEN .endmacro .macro critical_exit lda #$40 sta NMIEN plp .endmacroIf you want to hack the fix into your version maybe change lda NMIEN/pha to lda #$40/pha/nop. There should be 4 occurrences of this.
To port the game to cart I used the RAM under the OS for the replacement OS and all the new code that was added. So that is where I put my 2 button handler. I'm not the original programmer so I don't know what's at $98D2-$98EB (I only hacked it, I haven't done a disassembly). In the replacement VBI I also check the POT value and do a POTGO, so your change there should be fine. I opened up a lot of loops to get it running in NTSC but I can't say how much leeway there is now (but adding a little to the VBI is fine).
I don't think I've ever completed a fortress, so mine's also a beta.
If it's of any use attached is my work directory. The resulting builds are in carts/bin and carts/car and there are 4 different versions:
hq – for use with a normal joystick, nothing saved
hq_f – for use with a normal joystick, a different fortress on each save position
hq_joy2b+ – for use with a joy2b+ joystick, nothing saved
hq_f_joy2b+ – for use with a joy2b+ joystick, a different fortress on each save position
-
1
-
-
On 6/22/2020 at 12:33 PM, snicklin said:
This game reminds me somewhat of the first game that I ever played on the Atari 8 bits,
Leaper
It reminded me of Leggit, which looks very similar!
-
2
-
-
I'm really please to see that people have enjoyed the game, thank you all.
I'd been meaning to contribute to ABBUC as I've been a member for a long time, but never got around to doing anything. When I saw the post at the beginning of the year asking for submissions for the issue disk, I decided I must do something. I watched a lot of youtube videos of games from other systems and this was the one that grabbed my attention. I liked the humour, it looked well suited to the A8 and something I could (just about) get done in time (and I can't resist a biscuit).
On 6/23/2020 at 7:14 PM, skr said:The game is not property of the ABBUC, @playsoft has every right to publish it in any form he wishes as it is his work. Thankfully, he gave the other members some benefit to being a member, by releasing it through the ABBUC first. If he doesn´t want to release it to the general public himself, we could release it to the public (there is a free download area on the website) when we publish the next magazine, making it an ABBUC exclusive for three months. We don´t want to hide stuff from non-members, but we love to have some exclusive stuff making a membership even more worthwhile.
I wrote it specifically for ABBUC so I like that idea. I have a 5200 build too, which is identical apart from it not having the loading or credits screen. I don't know if you would want to put that on the free download area at the same time?
On 6/23/2020 at 7:14 PM, skr said:And with Biscuits being a really great software, he will get a little reward from ABBUC.
Thanks, but that's really unnecessary. Talking of rewards, when the Spectrum game was originally released the first three (I think) people to complete it got a reward - a packet of biscuits.
-
6
-
-
I only wanted to write a little endless runner game, not a full blown platform game. Maybe using Bentley was a mistake since it has drawn comparisons with the 7800 game.
I have used all the space in a 32K ROM and can't add anything else. The game does have a change of scenery but the player in that video didn't get that far. In this version I have made it happen more often, so it's more like day/night now. The death jingle has been changed to a Darryl original! The invincible jingle you will all probably hate, but it is from my favourite band and very apt for the scenario.
I know bigger ROMs are available, I took that route with AtariBlast! but decided I would limit myself to 32K after that. I have grown to really hate designing screens anyway, so I would not add any more even if there was space.
So on that terrible disappointment...
-
5
-
4
-
-
On 6/19/2020 at 1:31 AM, Fred Toronto said:
Does anyone have any technical notes on the programming of Runner Bear? Ways to contact the developers? I thought I knew the hardware pretty well, having written some machine language games myself, but the parallax effect here is excellent and I have no idea how they could have achieved it. Display List Interrupts and fine scrolling registers of course... but there has to be something else.
@pps is correct, it uses character mode, the screen is scrolled left and the background characters are updated to scroll right (at a lesser rate). The hardware features it uses are horizontal scrolling, screen flipping (so that one screen can be displayed while the other is computed) and character set flipping (to scroll the background characters).
When you scroll a background character right it scrolls into the adjacent character. Say you have a row of characters containing AB (with spaces before and after). There are 3 different pairs of characters; (space, A), (A,B) & (B, space). To scroll them right you will need a scrolled character for each, XYZ, where X is space scrolling into A, Y is A scrolling into B, Z is B scrolling into space. Where the same pairs of characters are repeated in the background you can replace them with the same scrolled characters. In the attached example the (48x24 character) background contains 27 unique characters; after it has been converted for scrolling it contains 63 characters.
4 character sets are used. In character set #1 the background characters aren't scrolled right at all, in #2 by 1 pixel, in #3 by 2 pixels and in #4 by 3 pixels. In the attached example the screen scrolls left 1 pixel per frame and the character sets are swapped every other frame. Once the background characters have fully scrolled right and you want to reset back to character set #1, you need to recompute the screen. That takes a lot of CPU cycles because for every character in the screen buffer you need to look at the character in the foreground, if it is non-zero write it otherwise write the character from the background. That is where the screen flipping comes in, you break this down into small steps and work on the inactive screen so that it is ready for when you need to reset. In the attached example you have 8 frames before you need to reset, so it splits it down into a number of screen columns each frame.
I think that is everything. For simplicity I generate the scrolled background and character set data on the PC but this could be done on the A8 which would reduce the amount of data held in the XEX file. The main limitation is that the foreground designs need to use whole characters, if you leave bits of foreground characters blank it breaks the illusion.
-
4
-
-
The controls are mapped to the following 5200 keys:
start = begin game
1 = 1 player game
2 = 2 player game
0 = toggle colour/monochrome
* = left difficulty switch
# = right difficulty switch
-
3
-
-
9 hours ago, Wrathchild said:
there's no code there so maybe these are just some graphic changes?
D = 11 01 or colours 3 & 1
F = 11 11 or colours 3 & 3
But (just speculating) could also be a value written to h/w register where the value of the changed bit (here = bit 5) actually makes no difference or perhaps makes a 4 port behave the same as a 2 port
[Edit] also wouldn't be hard t use Altirra to stick a breakpoint on read of one of the addresses and then step through to see how it is used.
With a read breakpoint on the first byte which is different, using the first image posted it stopped here:
(2409: 26, 88) A=00 X=59 Y=00 S=FB P=36 ( IZ ) 67EE: 31 72 AND ($72),Y [$9581] = $DC (2409: 26, 89) A=00 X=59 Y=00 S=FB P=36 ( IZ ) 67F0: 11 76 ORA ($76),Y [$89DB] = $03 (2409: 26, 94) A=03 X=59 Y=00 S=FB P=34 ( I ) 67F2: 91 74 STA ($74),Y [$2EFF]The byte is a mask. It looks like it is trying to set the two bottom bits (i.e. one pixel) leaving the rest of the byte unchanged, but the $DC mask results in a bit being cleared in the upper nibble. The mask value should be $FC, which it is in the second image.
So it looks like someone altered it to correct the masks. I think it will only make a difference when things overlap on-screen and even then you may need a young man's eyesight to notice it.
-
1
-
-
Thanks for posting the video, it was really nice to see someone making good progress in the game.
Runner Bear was developed for both the A8 and 5200. It is an endless runner with characters from Crystal Castles. The A8 version was released on the 2020 New Year Disk and almost immediately a cracked version appeared with infinite fire power and continues together with a comment that the game was too hard. So rather than release the 5200 game straight away I started making some changes, adding more fire power and continues and making some of the jumps and enemies a little easier. It has taken a back seat while I do something else, but I'd made most of the changes I wanted to so it shouldn't take too long when I get back to it.
-
2
-
-
That is identical to the PAL version, so it is not seeing the HZ_60 or NTSC flags.
I define them on the command line (the -Wa means pass to the assembler, -DHZ_60=1 means define label HZ_60 with value 1):
bin\cl65 -t atari -C bin\memory.cfg -Wa-DHZ_60=1 -Wa-DNTSC=1 main.s -o SHADES_NTSC.BINIn the code it uses these labels to select timer values and colours:
.ifdef HZ_60 VBLANK_TIME = 50 OVERSCAN_TIME = 26 .else VBLANK_TIME = 83 OVERSCAN_TIME = 52 .endif .ifdef NTSC YELLOW = $10 BLUE = $90 GREEN = $C0 .else YELLOW = $30 BLUE = $B0 GREEN = $50 .endif block_colours: .ifdef NTSC .byte $AE,$BA,$C6,$C2,$D0,$90 .byte $3E,$3A,$36,$32,$30,$F0 .byte $5E,$5A,$56,$52,$50,$B0 .byte $9E,$9A,$96,$92,$90,$40 .byte $AE,$BA,$C6,$C2,$D0,$90 ; repeat of first .else .byte $5E,$58,$54,$52,$50,$B0 .byte $4E,$48,$44,$42,$40,$80 .byte $AE,$A8,$A4,$A2,$A0,$60 .byte $DE,$D8,$D4,$D2,$D0,$50 .byte $5E,$58,$54,$52,$50,$B0 ; repeat of first .endif .ifdef HZ_60 ldx #$03 .else ldx #$19 .endif :
So for whatever reason it seems they are not getting passed down. -
About the only thing I can think of which is open to some interpretation by the assembler is when it decides to do zp or absolute addressing. My guess would be the Mac code takes a little longer and there was enough leeway in the 50Hz builds for it to have no effect, but not the 60Hz ones. I wouldn't mind seeing a Mac build, not to do a full analysis but just to see what the first difference is.
-
1 hour ago, Karl G said:
Has anyone else had luck assembling this? I was able to, but the 60Hz versions have unstable screens. I'm on a mac though, so I built my own version of cc65 instead of using the included version.
Were the .bin files in the .zip stable? Assembling should have generated identical files, so would be interesting to see if they match.
-
Thanks Phil, this was originally going to be an A8 game and my contribution to the 2017 New Year Disk. But when I started coding it seemed it could be done just as well on the VCS. Perhaps an A8 version for the 2021 NYD!
-
1
-
-
On 4/29/2020 at 9:23 PM, Thomas Jentzsch said:
/signed
Found a small bug: The sound is not stopped when you leave a game early.
Thank you - that was a good catch.
On 4/29/2020 at 11:18 PM, Karl G said:Having switchable color schemes might be a nice future feature as well. Here's one possibility that I was playing around with:
I have created a topic for the game here. I have added some additional palettes with placeholder colour values. The source is included so hopefully you would be able to try them out or just post the values and I will include them, thank you.
-
A few years ago I started a port of the iOS game Shades by UOVO which is a Tetris type game where you have to try and drop a block on another of the same shade so they merge to a darker shade:
That it used luminance made it well suited to the 2600 but it was frustratingly hard to tell them apart and I abandoned it. However recently @Thomas Jentzsch hacked it to use different (but similar) hues to give more variance.
Attached is the current WIP.
@Karl G I've added 3 additional colour palettes and for testing you can step through them by pressing the trigger during the game. The colours are just placeholders for now, if you fancy playing around with these you will find them in build\colours.s. Each palette comprises 6 colours values, the 5 block colours (ordered bright to dark) plus the background colour. I use the ca65 assembler which is included so you should be able to rebuild by running build.bat in the build directory from the command prompt. Perhaps the colours could switch each time the speed increases?
Currently there are 4 speeds; NOVICE starts at speed 1, NORMAL at speed 3 and EXPERT at speed 4. I thought the fastest speed was difficult enough but I'm getting better at playing it now and it needs to go faster and present more of a challenge once you get to around 3,000 points.
-
10
-
1
-
-
On 4/27/2020 at 11:10 AM, Thomas Jentzsch said:
Attached is an NTSC version with hacked colors. That one should work better, I hope.
Thanks, I hadn't tried using different hue values. Initially I wasn't sure as it doesn't look quite as nice, but I got used to it after playing a while. It definitely helps distinguishing the blocks, which was my reason for not finishing it off, so...
On 4/27/2020 at 11:37 PM, ZeroPage Homebrew said:This is great Thomas! It makes the colours a LOT easier to distinguish without taking too much away from the difficulty of matching and correctly stacking. All that's left is to be able to reset the game without power cycling.
- James
I've added a title screen and 3 difficulty modes which select the initial speed of the blocks. I didn't think the game needed to be any harder, so EXPERT mode plays as before, NORMAL is a little slower and EASY a lot slower (those two speed up after a while). You can abort a game by pressing Reset which takes you back to the title screen. The NTSC build uses the hacked colours, the PAL colours aren't changed.
-
7
-
2
-
-
On 4/23/2020 at 6:36 AM, PitfallHarry77 said:
Wow!! Thanks playsoft - that is awesome!! I have been playing Shades on my phone after your recommendation. I will really enjoy it on the Atari so thank you. I have found another good one that might work on Atari on the Nintendo Switch called Crossniq+. You can play two player and it is addictive and fans of the genre will enjoy it. Possibly too many colours going in different directions but would be good if it works. It is also a little like Multicross which I enjoy on the phone.
A cut-down version of Crossniq+ looks like it should be possible.
-
6 hours ago, ZeroPage Homebrew said:
It's not a WIP - it's an old abandoned project (OAP?).
5 hours ago, bluswimmer said:This shades game is pretty neat! Would like to play an Atari version with better RNG (as it stands the seed appears to be the same each time with no manipulation of the seed).
If a title screen had been added it would have done that.
-
1
-
-
One thing I noticed is that the volume is not protected against decrementing below 0.
I changed:
DEC FREQCNT,X ;REDUCE THE NUMBER OF FRAMES UNTIL NEXT DECAY BNE TUNNEXT ;IF WE AREN'T AT ZERO YET, DON'T DECAY LDA DCYSTOR,X ;RESET THE DECAY FOR THE NEXT COUNT STA FREQCNT,X DEC CTLVOL,X ;DECREMENT THE VOLUME LDA CTLVOL,X LDY TUNCHANNEL AND MUTEMASK,Y STA AUDC0,Y JMP TUNNEXT ;GO TO NEXT CHANNELTo:
DEC FREQCNT,X ;REDUCE THE NUMBER OF FRAMES UNTIL NEXT DECAY BEQ DEC_VOLUME JMP TUNNEXT ;IF WE AREN'T AT ZERO YET, DON'T DECAY DEC_VOLUME LDA DCYSTOR,X ;RESET THE DECAY FOR THE NEXT COUNT STA FREQCNT,X LDA CTLVOL,X ;IF VOLUME ALREADY 0 DO NOT DECREMENT AND #$0F BEQ TUNNEXT DEC CTLVOL,X ;DECREMENT THE VOLUME LDA CTLVOL,X LDY TUNCHANNEL AND MUTEMASK,Y STA AUDC0,Y JMP TUNNEXT ;GO TO NEXT CHANNELI'm not sure it affects timing, but it sounds cleaner to me, see what you think.
-
1
-
-
12 hours ago, PitfallHarry77 said:
Shades looks awesome and I would love to try it out. You don’t have a PAL version by any chance.
Yes, attached is the PAL build.
-
4
-
1
-
-
17 hours ago, devwebcl said:
Cool !, I always thought that was a very feasible game for 2600
It's interesting that Shades by UOVO is no longer available in the AppStore but Mega Shades by Marstin is. The two games are extremely similar but not 100% identical; in Mega Shades the next block indicator does not morph into the block like it does in Shades. I think they are different developers as UOVO are (were) Danish but Marstin appears to be UK. Maybe UOVO sold the rights on?
-
1
-
-
I did start programming the mobile game Shades by UOVO which is a Tetris type game where you have to try and drop a block on another of the same shade so they merge to a darker shade:
Having colour shades makes it well suited to the VCS, but I did find it hard to distinguish them which is why I never finished it off.
-
3
-
-
That was about as much as I could improve the program as a port. Writing from scratch you would be looking at multi coloured sprites, the shield moving up and down (like the VCS) and some nice explosion effects. It would be an ideal game for the demo coders that make all those nice swirly effects.
-
1
-
-
Look forward to it but there's no rush! I took a look at your Stranger Things and the muting code looked fine to me. I thought it sounded great and it wasn't obvious to me there was a timing issue?
-
They look great Konstantinos but currently only the formation graphics can be animated though.
For each software sprite, although there are only 2 frames for each design in the .bmp (upright and diagonal) they are rotated to make frames for all directions. These 8 frames are then pre-shifted for all 4 horizontal offsets. So you end up with 32 frames for each design @ 27 bytes each = 864 bytes.
I have allocated RAM to allow 5 designs to be present on-screen at any one time: bee, butterfly, boss, captured player and one other. The extra one is used for the transforms - I call them all that although I think only half of them are actually transforms, the others just appear in the challenging stages. The code which rotates and pre-shifts the frames is split into steps that allow a transform to be loaded up seamlessly between waves.
So currently 4320 bytes of RAM are used for the software sprite frames. I don't have enough free RAM (on the 5200) to double up all the frames; there is enough to double up just the diagonals but that won't leave much free and at this stage you want to keep a bit in reserve.
There aren't any explosions for the player ships yet. Really the big unknown for me is the expanding formation and that is what I will look at when I get back to it later in the year.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
2 button joystick ?
in Atari 8-Bit Computers
Posted
When I originally did the disk to cart conversion I was using an Ultimate Cart too and I can't have seen the boot failures or I would have investigated. Alas my Ultimate Cart stopped working, so when I added Joy2B support I used a real Atarimax cart and the boot failures were a surprise! Another possible factor is that I have 2 NTSC machines, a 1200XL and a 130XE and I've no idea if I used the same machine on both occasions. When I next have a machine set up I will try the original version on an Atarimax cart and see how that behaves.