playsoft

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

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!

Thank you - that was a good catch. 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. shades_wip_1_5_2020.zip

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... 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. SHADES_NTSC.BIN SHADES_PAL.BIN SHADES_PAL_60.BIN

A cut-down version of Crossniq+ looks like it should be possible.

It's not a WIP - it's an old abandoned project (OAP?). If a title screen had been added it would have done that.

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 CHANNEL To: 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 CHANNEL I'm not sure it affects timing, but it sounds cleaner to me, see what you think. strangerthings.s strangerthings.obx

Yes, attached is the PAL build. SHADES_PAL.BIN

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?

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

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.

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.

Seeing as no one else took up the reins I have worked on it over the past week. The final A8 version was supposed to have the last little bugs fixed but there were still a few in there. Probably the worst one can be seen towards the end of the video that BIGHMW posted; on levels where the shields rotate the shield characters often end up appearing on screen where they shouldn't be. There were half a dozen or so issues and I am confident I've fixed most of them, but there were a couple of one-offs where all I've been able to do is tentatively make a change that might help. The intro screen is the drawing from here yars_strike.bin

The explosions use player graphics and there are 2 players available in that portion of the screen. You don't want to be using software sprites for them, as that will consume more CPU time. As there are only 2 players available I kept the number of frames relatively small (5 frames) so they are unlikely to be cut off early. The way it works is that the first enemy you shoot uses one player for the explosion, the second enemy uses the other player; if you shoot a third enemy it will use the same player that was being used for the first one. So if the first enemy was still exploding it will be cut off short. Obviously more frames = more memory too. That said it may be that cutting the explosion short wouldn't happen that much and it might not look so bad if the frames were designed in a certain way.

Yes Konstantinos that's correct. If you want to play around with anything then extract the build folder and run build from the command line. The software sprites are in the .bmp file, the formation graphics in the .a4 and the PM graphics are all .apl. When drawing the software sprite frames I tried to use as many pixels as possible to make them look bigger on-screen than they really are! build.zip

I was happy with my multiplexer in AtariBlast and being an original game I was able to minimise the amount of flicker by designing the sprite paths around it, but even then there were complaints! Some of the paths in the challenging stages of Galaga have all 8 sprites in the same vertical space for a fair amount of time during which you'd only be able to display a single sprite once in every four frames if using multicolour sprites; once every other frame if single colour. I really don't think it would be greeted with much joy...

Also I think there is a difference between what is acceptable on the two systems. There would be significant savings in both memory and CPU time if you went the sprite multiplexer route instead of character sprites, but I don't think the flicker would be well received on the 5200/A8; the VCS has always had flickering sprites, so it's more acceptable there (although I remember when my Uncle brought VCS Pac-Man we thought we'd got a dud cart!).

It looks absolutely stunning 👍

Looks great, opens the door to using the 822 in games! (print maps etc...). Strange, my 822 seems to need the $4C in my test program; with Aux1 set to $00 there's no printer output at all, just farting noises; with it set to $4E I get normal text output, not bitmap. Paul

I don't know if this will help but I disassembled the code from the owner's manual to see what it was doing. Basically if you send a SIO Put with Aux1 set to $4C ('L' for Line perhaps) then instead of printing the 40 bytes as characters it prints a single line of 240 pixels (the last 10 bytes are not used - although you do seem to have to send them). The attached test.s continually prints lines of random data out on the 822: The code in the owner's manual prints the screen out sideways; I attach the disassembly for that which I've commented but haven't done anything else with. Paul test.s test.xex commented.s

Look forward to hearing them!