playsoft

For the 8-bit home computers a Joy2Bplus standard was proposed for 3-button joysticks: https://atariage.com/forums/topic/278884-2-button-joystick/?do=findComment&comment=4206381. It's probably fair to say it didn't set the world alight but there has been a decent amount of interest. There are now over 40 games which support it, mostly hacks but a couple of homebrews too. It sounds like you are aiming for more functionality than this, but perhaps it gives an idea of what sort of interest you'd get. With Joy2Bplus button 1 connects to the normal trigger line, buttons 2 and 3 to the paddle lines. It's not compatible with existing 7800 games because the trigger line is used to put the 7800 controllers in 2 button mode. However I have been able to use my Joy2Bplus joystick on the 7800 in my own code by clearing CTLSWB so all lines are inputs and reading INPT4/1/0 respectively for the 3 buttons (logic is the same for all buttons, the bit is 0 when pushed).

I received mine yesterday, really pleased with it. Thank you so much Rafal.

Obviously it's a bit odd with it working elsewhere, but Cybernoid2NtscPokey450.a78 crashed after ~5 minutes in A7800 for me. I ran it up with the debugger and it hits a brk instruction here: 193F: lda $1962 1942: cmp #$d4 1944: bne $18cb 1946: lda $1961 1949: cmp #$d8 194B: beq $195f 195F: rts 0001: brk Before it does the rts at $195F the stack pointer is $1FF so it's empty, hence where it ends up. I used dmsc's lzss-sap code on the 5200/A8 last year and I can't match that bit of code exactly but it does look a little like the test for the end of the song.

Thanks for making these available, the sound effects in the library sound excellent and are really useful.

Which you can, you don't need the programmer. You mount the .ATR programming image in D: (using something like APE or AspeQt), put a blank Atarimax 8mbit flash cart in your A8 and power up. The programming .ATR will boot and then proceed to flash the Atarimax cart. It does take quite a long time to flash an 8mbit cart this way. I used to set it flashing, go and have dinner (do the washing up, watch a bit of telly) and come back to it later. So when we were developing AtariBlast! the programmer sped things up. Nowadays we'd have used AVGCART or Ultimate Cart.

This looks great! Could you please add me to the list for one with Pokey Max and YM2151. Thanks, Paul

Yes that makes sense, thanks.

A quick question if anyone knows as it's just out of interest, but if graphics data is placed in RAM does Maria still require 3 cycles per byte or will it use 2 like the DLLs?

Thanks Jeff!

It was written specifically for ABBUC with the plan that it was made available to club members in issue 141, then made public on their website once issue 142 was published. I've just received issue 142, so when I find where it is on their website I will post a link. I think it would be nice if it was only downloadable from their website and not posted here or elsewhere, since they will get more footfall which might generate more interest in the club.

No, I think it's the seven year itch for me. Since 2013 I have written 6 games from scratch and must have ported over 20 titles from the A8 to the 5200. I want to do something different now. I got my original 400 back in 1983 and although I "upgraded" to a ST in 1986 I still tinkered with the A8 until 1990 (that's the last record I have of doing anything). So that was 7 years back then and 7 years again now, a nice symmetry. There was a 23 year sabbatical between those so maybe I'll get interested again in 2043...

It would have been too long for a type-in but it was on the issue disk which comes with the magazine (June this year).

This is the 5200 build of the game published in issue 141 of ABBUC magazine. Thanks to Darryl and Jaden for all their help and Dave Hughes who wrote the original ZX Spectrum version. Here is a video of it running on the A8, the 5200 is identical except it doesn't have the loading or credits screen. https://youtu.be/9p1SPeNkQso instructions.txt biscuits5200_32K.bin

Thanks but really all credit should go to the original programmer who did all the hard work; porting it to the 5200 was pretty simple.

Only tested in Altirra but seems OK. Start to begin, * for number of players, # for difficulty. star_island.bin

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.

@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 .endmacro To: .macro critical_enter php sei lda #$00 sta NMIEN .endmacro .macro critical_exit lda #$40 sta NMIEN plp .endmacro If 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 build.zip

It reminded me of Leggit, which looks very similar!

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

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... runner5200.bin notes.txt

@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. scroll.zip

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 miniature golf (5200).bin

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.

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.

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.