Junosix

Yeah, just realised that I'd uploaded the wrong file! Did a cheeky reupload a few minutes ago (same filename). The life meter thing is all part of the puzzle (something you'll find is vital to be very careful of further on). You'll find as you play it a few times you'll pick up speed on the earlier levels and have more in reserve for starting each new room.

Heh heh It was a very tough call with the platforms, they are difficult but lowering them by a line would have made it too easy, then the game would be over a lot quicker. There's 19 rooms in total, keep at it!

Keep practising, some of the platforms are pixel perfect (but you'll get the hang of them), however sometimes careful use of swimming is better than trying to keep your head above the water. There's a couple of ways to complete some of the levels which might not be obvious at first glance. In the later levels, button mashing underwater is your friend

Okay, think I've crushed that bug, so I think this could very well work out to be the final version: http://junosix.adsl24.co.uk/TheWickedFather-releasecandidate2.bin It's also 4096 bytes

Cool, I'll pad it out another 2 bytes in that case. The passing through walls thing is the showstopper. It seems to only happen when you're by a wall and you quickly switch from turning right to turning left (can't replicate it the other way around though). Anyway, I think I figured out the solution (thought about it when I was doing the washing up a few minutes ago), so time for an RC2 in due course

Yeah! I don't know if it is a proper showstopper, or an endearing glitch. If no one finds it, great. If someone finds it, then there'll be a release candidate 2

Release candidate here: http://junosix.adsl24.co.uk/TheWickedFather-releasecandidate.bin Grab the Stella emulator from http://stella.sourceforge.net/downloads.php There is one small bug that will either be a showstopper or glitchy curiosity that the odd player may occasionally get. Don't know which because I can play it from start to finish without making too many errors (obviously). Let me know if you come across anything.

Another little video of the progress, now has levels (though they're yet to be designed), a title screen (and will also have a definite end screen). Managed also to shunt the display kernel around to lose the jagged bit in the water and save 4 cycles so I can have a gradient background. Major gameplay difference now is that he can swim in the water rather than just jump, which has actually transformed how it plays a lot. To do: title music (written, just got to shove the code in there), design levels. YouTube Video.

Brilliant work, that Shiraz Shivji interview from the March 1986 issue is fascinating, and was interesting to read exactly why MIDI was introduced - they realised the onboard sound was weak because not everyone needed sound and stuck MIDI on as an upgrade path, fair enough thinking really!

That's splendid!

Thanks chaps! Sadly I can't find a way of moving that COLUBK, my display kernel only has 2 spare cycles left and no room for shifting things around that I can see. Did try to hide it behind PF0 on the right but couldn't find a way. Hopefully going to get some time over Christmas to get some levels sorted!

YouTube video of it running on a CRT TV.

Hi folks, here's a one-level sort-of demo of a game I've been working on (in straight assembly language) - The Wicked Father. You play the unconsionable character of the title who has locked his family in the basement and flooded his 15 storey (or 20 or however much room I have left in 4K) mansion. Life insurance + house insurance = PROFIT!!! Make your way to the top of the house to escape or you will die with them! In this demo, you control the player with the left and right directions on the joystick, pressing fire to jump. Standard Mario-type controls, when you want to jump over a wall you must take a running jump to clear it, and when in water you'll need to hammer the fire button to get him to move. The aim in this demo is to make it to the "door handle" in the top right before you drown (although I haven't added the check which detects if you've got to the door handle or not). Let me know how it drives! Merry Christmas wicked.bin

Tell you what is weird - I got my STFM in 1990 and it definitely had TOS 1.2. TOS 1.4 had been out for about a year before I got my ST so is there any good reason that it came with the older TOS? Got it in March 1990 from Currys in the UK and it was the Power Pack bundle.

Thanks for the replies! Funnily enough I was thinking about how VDELP0 could be used for doing it over a 4-scanline kernel, and that wouldn't be a problem as I'm only using GRP0 anyway. But I'm thinking about just using illegal opcodes to reserve cycles for other things. For purity, I was trying to avoid using illegal opcodes, but thinking through I realise I could do lots of tasty stuff if I use them (there are other points in the code where they'd be handy, there's at least one I know of that can be used in skipdraw). The game's main element is rising water so I think I might even have enough time left over to change the colour of PF/GRP depending on whether they're submerged or not. I shall have a play and report back

Been working on my first bit of 2600 code which I'm quite happy with, managed to get it going without asking any questions so far. It's actually at a state where I can start designing levels and a proper game around it, but I just wanted to ask a couple of questions before I plough ahead. I've attached my code to this post. You'll see that I build the level using a sort of tile map method, and that map is near the end of the code, labelled "pfmapleft" and "pfmapright". Due to the way I've got the sprite jumping, my collision routine depends on a platform being at least a height of 4-scanlines (it's a two-scanline kernel), so I have to double up the data for each platform (should be pretty clear what I mean if you look at the code). So what I'd like to do is not have to do that doubling-up on the data and just refresh from the tile map every other read. My way of thinking is that I would use the data from the Y register (which I use for counting down through the scanlines), and divide it by two, but I just can't find a way to get enough cycles free to do that. I've even done away with STA WSYNC to try to claim as many cycles as I can (there are a few free though, but they're scattered separately throughout the kernel). Do you think it's possible? Ignore what's going on in the vertical blank routine, there's a load of tidying up to do and logic to add. The display kernel is what I'm concerned about at the moment Does that make any sense? I hope it does EDIT - I also thought about using a 4-scanline kernel, but that would complicate the resolution of the sprite movement, I think. wicked.zip

Had an early STFM for a while, which had a circuit board which is similar to what you describe. Always reckoned it had something to do with allowing a double-sided drive to work. I think the date's on it somewhere? Mine said 1987 if I remember correctly.

Download someone else's 2600 source code (there's loads of examples available for download), compile it, and see if it runs under Stella.

You need to type: ./dasm filename.asm -f3 -ofilename.bin Replace "filename" with the name of your source and desired output name, of course

High-res original so you can make your own...

Hoorah!

What? Maybe the chap who maintains it is just busy or something?

The title music on the 1MB version also seems to be lacking the crash cymbal. 2MB: 1MB:

What's odd is that the warranty sticker is intact - you'd have to break it to upgrade the memory.

Just to say - Zazzle cancelled my order as they don't do copyright stuff, used www.tshirtstudio.com in the end, £15, looks perfect.