Arlasoft

Some GFX I did dig out, might provide some inspiration Berzerk Binary Land Dr Mario Jawbreaker Minesweeper Omelettes Some sort of poker strategy game Rectris Nokia Snake Tapper

Here's a list of game ideas I've had for the Channel F but not had time to make yet: Horace Goes Skiing Snake 2 (Nokia 3310) Bejewelled Columns Dr Mario Puyo Puyo Pyromind (PC) Di Lithium Lift (Speccy) TNT Bomb Bomb (PC-88) I also drew the background for Donkey Kong Jr Game & Watch but can't for the life of me find the Gimp file....

On mine it's a Jerry Lawson tribute, with a little playable platform game editor. Slightly misleading as to what the Channel F was capable of but hey!

Just to clarify, I'm not cxsfx who created the original browser-based game. Like Thomas I saw it in a roundup for the game jam it was written for and thought it was a nice little concept. Happy that Thomas has built on the idea, my version is very much one of those frustrating 'endless runners' like Flappy Bird that are anything but endless due to their difficulty....but like Flappy Bird it does have the 'one more go' factor. It's pretty crazy that two of us were working on ports of the same extremely obscure game tucked away in a corner of the internet, for the same system at the same time!

I'll see if I can drum up an order in one the discord servers I'm in. By the way you have me down as USA in the original post, I'm in the UK - let me know if you need my address again!

Sorry I'm currently on a cruise ship so haven't had any internet for a few days. Will reply properly when we are back!

A raw disassembly wouldn't be much use, you can get this for any game using Stella in any case. The ones with comments, labels, constants etc have been reversed engineered to the point where it could be considered as good as having the original source code, probably better because back in the day they didn't have the space or time to put extensive comments. So there's a big difference between 'commented disassembly' and 'disassembly'.

Source code for my finished games so far: https://github.com/1888games/Stepz-2600 https://github.com/1888games/top

So is the consensus that the flickering is too much on real hardware to make two player viable? Bearing in mind even single player Puyo Puyo is normally player against an AI opponent. I'll need to watch some videos of endless solo mode in Puyo Puyo Tetris to see how fun that might be, think there's a mode where you have two minutes to score as highly as possible too.

I had a feeling it would be too much on a real system. Can't really insist everyone plays on Stella 😬

Guess that's an emulation issue, i.e. timing is more forgiving. If I delay by even one cycle, the rest of the colours would be out.

That'd be cool, thanks!

How it looks in Stella....

Have been noodling with some puzzle game kernels after seeing the Dr Mario example. This one might have some promise, and certainly a solo version is definitely viable, but for two players I was curious as to how this looks on real hardware. In Stella, with phosphorus turned on and blending set quite high, it looks great. But in the Javatari emulator within 8bitworkshop the flicker is uncomfortable. Javatari seems to have some CRT options but none of them seem to make much difference at all. I suspect a real 2600 on a CRT it will be somewhere in between? main (2).a26

It's looking increasingly likely it will have to be just one colour anyway, as on scanlines where enemies are being repositioned I have no cycles available to update the BG colour, so when they move vertically the location of the bands change.

I'll share the source code when the game is finished.

Finally got sprite multiplexing working reliably, had to do all sorts of gymnastics with my kernel. One more cycle on the last row of each block and the positioning code pushes it onto an extra scanline. Also moved the level data to a separate bank and added a second level to test progressing to the next one. Last job before coding some enemy behaviour is to find a place to perform the kernel loop exit check without a couple of junk scanlines being drawn. bj_012.a26

Haha - at that stage I might as well just go back to C64 or Unity

72 bytes = 26 rows with three bytes for each. Same as the arcade except rows are 6 pixels tall instead of 8. Not much I can do about that without significantly changing the level designs, which are pretty integral to how the game plays. 24 rows might work like the single-screen stages in Mighty Bomb Jack but probably not worth it for the sake of 6 bytes, especially now I'm using Superchip RAM.

Yeah, unfortunately there's no way I can afford to be drawing the playfield on odd rows as well. That scanline is going to be for A) drawing the current enemy, B) getting sprite and colour pointers for the next enemy or C) positioning the next enemy. With an asymmetric playfield I need to be setting PF2 on exactly cycle 48, as well as clearing PF1 before that, so that would come slap bang in the middle of the enemy code.

Have done some shuffling around to free up cycles for enemy sprites, so now the entire playfield, background colour, player sprite & colour are done in one scanline, leaving this kernel to repeat 26 times: PLAYFIELD: (lines 0,2,4) 11 cycles from 49-60 BLANK: (1,3) 76 cycles from 1-76 LAST ROW: (6) 62 cycles from 1-62. My fingers are crossed that with the play area starting at PF1 and only being 96 pixels wide, there will be enough time to decide whether to reposition P1 or draw it/do nothing, and still be able to position the sprite without calling a WSYNC. Taking a break for the weekend now for Ludum Dare, which depending on the theme may well be a 2600 game.

New version uploaded to itch.io with a couple of bug fixes.

Thanks, I'll take a look at the Stay Frosty stuff, especially the masking as I'm starting to implement enemies. I'm already using just PF1 and PF2 in mirrored mode, I just don't bother with the second PF1 for the sake of two extra playfield pixels, especially as the PF data has to be stored in ZP (although I could move it to the super chip RAM) so the bombs can be cleared - 72 bytes is a hefty chunk as it is.

Just noticed it glitches a bit in Stella, having tested in 8bitworkshop/javatari. Working on it... EDIT: That's better! bj_0_11.a26

I've hopefully found the 'big' project I was looking for. Bomb Jack is one of my favourite arcade games and after checking out the demo from 2007 I was inspired to see what was possible. What I have so far: ability to display maps to match the arcade, albeit 24 x 26 blocks instead of 26 x 26 (first level in so far) map uses PF1 (left only) & PF2 to minimise cycles required player movement and animation including walking, jumping, gliding, and falling fire bombs displayed in the same order as the arcade bombs can be collected and score updated accordingly 8K ROM with 128 bytes extra RAM. Bank 0 currently un-used - title screen, music data & routines etc? In the attached binary you can mess around on the first level, with an added vertical wall for testing. You can fall through the top of that wall but in a proper map there would be another platform stopping that happening. For those not familiar with the game you can hold up while jumping to get extra height, fire while jumping will cancel the jump and spamming fire while falling allows you to 'glide' across the screen. ----------------------------------------------------------------------------------- Now comes the hard part - enemies and power-ups. I'm making this post partly to gather some thoughts on the best way to handle those. I have a pretty tight kernel using macros and 76 cycle-exact sections to avoid looping and WSYNC's, giving the following cycles free: [PLAYFIELD, BLANK, PLAYFIELD, BLANK, PLAYFIELD, LAST ROW] repeats x 26 PLAYFIELD: 7 cycles from 30-36 16 cycles from 49-64 BLANK: 62 cycles from 1-62 LAST ROW: 47 cycles from 13-59 or 5-51 PL1 is free for enemies, and I was thinking of using a ball or missile for the main power-up, as it doesn't matter if that flashes random colours based on the playfield or player colours. Not sure about the 'B', 'E' and 'S' power-ups as having them using PL1 too just makes that even more complicated, but they do really need to be identifiable. I'm not adverse to changing enemy behaviour quite a bit to suit the 2600, keeping in them in horizontal zones rather than chasing the player all over the screen. They would still get in the way of the bombs you need. Or perhaps I have enough free cycles for genuine multiplexing....? One of the main obstacles is that Y and X are both tied up, Y counting down scanlines until PL0 should be drawn (similar to DrawHarry in Pitfall), and X keeping track of the map row from 25 to 0.