sack-c0s

I think this is less down to relative technical specs and more about who did the porting. Either the original author did the port and just had more experience with this first machine so that version was technically better but the gameplay survived or the second coder who ported it understood the machine well enough but missed the point of the game a bit. For example I was playing one version of Missile command where the time between firing and the missile hitting that point on the screen was *random*, giving you bugger all way of timing your shots and fundamentally missing the point of the game. I think it might've been the xbox 360 version so you can't blame the hardware specs for that one. Play creatures on the c64, then the Amiga version. the 16-bit version looks okay, is technically competent but feels a bit... well.. soulless. There's sprites. Collisions, scrolls smoothly... All the code there to make a game but I'll be damned if I can figure out why it just plain doesn't feel like one. I think the first platform is probably going to win out 90% of the time regardless of if it was the Atari or Commodore - Attack of the mutant camels being a big exception here - Heaven should backport that version to the C64 as payback .

When I was that age I was programming 6502 on the Commodore 64 and I felt really bloody clever for some of the tricks I was doing... ... Then I discovered the 2600 and realised those tricks were par for the course to do anything whatsoever and felt like a newbie once again which brings me to the point - if you feel the urge to code for something retro you could always try another machine with slightly more memory and better specs that could bring you closer to what you want to make, then work your way down to the 2600. Start with the 8-bit atari, Commodore 64 or VIC 20 (that'll get you used to not having much memory) maybe?

It's amazing how most C64 people disregard Atari POKEY chip, which is actually, besides other things, very good sound chip. Forget the SID - at times it's starting to sound like the FM chip in the megadrive/genesis. nice work

I liked the BBC in school to write BASIC programs on (and I've got a master 128 back in the UK), but I had a commodore 16 (because 'the spectrum looked a bit crap' according to my dad) and 64 at home. I tried the 'It'll help me with my homework' line a second time to try and get an Amiga but it backfired because my dad went into school, saw the Archimedes and got me an Acorn A3010. So I was a sort-of BBC owner. but hey! At least I got to learn ARM assembler at an early age, which seems to be more useful these days than 68k - even if my mates had all the best games on Amiga and ST....

I don't know how it's done - but if I had to write it right now here's how I'd do it *Each 'road section' would consist of 2 bytes - a distance and a signed curvature (keeps the definition size down) *You then load the current curvature and put the distance into your timer variable. I'd then calculate the line offsets *once* and buffer them up (Not sure if you can get away with this on the VCS due to space constraints though) *Each frame after that for every line I'd either move the offset left or right one step if it doesn't match the curvature position (to simulate entering/leaving a curve) I'd also use the curvature amount to control the force placed on the car to throw it to the outside of the curve. If I'm right then this scheme means you can represent each curve or straight in 2 bytes. an oval (2 big curves+2 straights) would be just 10 bytes (assuming one straight was defined in 2 halves at the beginning and end, and a dummy section definition to flag the lap point) so you could get quite a lot of track in a small amount of space.

anyone familiar with the Yamaha QY70? I used to have one but needed the cash so I sold it. I like the way the editor worked on there though. Would be really nice to have a sequencing prog that worked in the same way with the harmonising and patterns

christ! the atari has some shocking problems when it comes to putting colours in arbitary places in 2D - but going ahead and doing a decent job like that in *3D*... That is an awesome piece of work! - A c64 owner who is glad this wasn't posted in the atari vs c64 thread

I'm not sure what I have against the CPC to be honest. Either the fact it has a nice display but (at least prior to the CPC+) no realistic way of shifting it fast enough to use it to make a decent game (and if they did most people had the cheaper package with the greenscreen monitor anyhow which hampers colour choice). Atari, C64... They have their strengths and flaws but at least people thought of putting *something* in there to acknowledge that a lowly 1/2mhz CPU can't move 16k of data around every frame on a whim and to help out in some way. The other reason could be that I first played wizball on the CPC and thought it was a pile of crap, then saw the C64 version years later and realised I'd missed out on an awesome game all this time.

so... at least we can all agree that the Amstrad CPC was a bit naff then?

It would have been good if they upgraded the 6502 for block moves and block fills or writes to same location for I/O or other uses. It would be easier than upgrading to an accelerator. Isn't the ARM (my other favourite CPU) the spiritual successor to the 6502 and has all those great things (along with others like conditional execution of all instructions)? I know you can't exactly drop one of those in as a replacement but whilst we're talking dreams...

my girlfriend has been listening to 'the postal service' recently and there's a few songs on the album that sound like they belong on a highscore table. - such great heights - sleeping in You should give one of those a go - I'm having a go, but can't quite get the feel right

Wot? No Acorn Archimedes?

if I roll this thread over 255 pages will it crash?

I'm as C64 fanboy as you can get (without being obnoxious about it hopefully) - but even taking into account the Z80-based machines I've got to hand this one to the Atari. The z80 always has twice the clockspeed but tends to consume around twice the cycles doing the same things as a 6502, the machines themselves suffer from a lot of contention and all the best support hardware comes in 6502 machines. The A8 has linear addressing, double buffering is a possibility using DLIs and the CPU is a bit quicker. The BBC (another 6502 machine) could come close, but the palette is a bit rubbish really. For small-ish precalculated stuff on the C64 you can render to sprites and have the 3D translations and rotations update as fast as possible but have the object move in 2 dimensions onscreen in a raster interrupt to give the illusion of smoother movement (like imposters in modern 3D engines), but that's not always going to work.

the commodore 16/plus 4 tempts me - purely for the reason the C16 was my first ever computer and I've never actually coded a game for it yet. It needs a little love i think

nice work - don't think I could better that to be honest only thing I can think of is at around 54 seconds in the bit i would consider the lead (stereo right) gets drowned out a bit by the backing coming from the left channel. That said I don't have equal hearing in both ears (slight bias to the left) and I am listening on an emulator so ymmv. maybe someone else should have a listen see if it's just me or if they think the same.

to be honest I just got so bloody bored of that argument (which seems to be becoming increasingly devoid of factual information and full of 'your opinion doesn't count because you're biased in the wrong way') I just buggered off and started coding a game for the VIC 20. It's sort of a warmup before I bite the bullet and go for the atari 2600 I'm guessing people getting bored and wandering off to code something instead is the best thing that can happen there really

Stop this thread it's getting silly. I suggest you take this platform bitching to scrolly messages on the intro screens of games you've written to prove your respective points

my approach would be to have an FPGA with a core running on it (6502/ARM/whatever floats your boat). if you chose 6502 you wouldn't necessarily be limited to the original system speed and could be a multiple but you'd have the advantage of using a familiar instruction set. I'd also have a couple of K RAM and a small area of ROM. The ROM would contain a kernel for the VCS which would iterate through a chunk of the cartridge RAM (maybe 2 chunks for double buffering), drawing the playfield from it, updating the colours, etc. and would end by storing the joystick positions in a couple of bytes of cartridge RAM, write to a latch to signal the frame is complete and time the display as usual. The program on the FPGA would run the game logic, build the screen buffer and then update the screen pointer when the frame completed latch is set. this would be the mother of all cheats - but this way I reckon you could have a first person shooter running natively (well, as natively as starfox runs on the SNES) on the VCS.

actually you're probably seeing 312 pixels because the border is expanded by one row to allow somewhere for smooth scrolling to come from. you can turn this off to have full 320 pixel wide scrolling, but because you've got nowhere for the new data to come from it just judders at the edges (unless you open the borders and use sprites as a continuation of the scroll to give an overscan effect)

anyone have .mp3 files of these captured from the machine? Having moved countries on a budget airline I could only just get my PC across with me and I'm 8/16-bit hardware free at the moment.

under normal circumstances the C64 does that as well and can pull all the display data during half the clock cycle, leaving the CPU with the other half - but for a standard line this needs half of every single clock cycle. The first line of each row of characters (usually referred to as 'the bad line' for this reason) requires more data and it's at this point it starts to intrude on the 6510. Same applies to the sprite data fetch. I'm currently too stuffed with ibuprofen and antibiotics to think of meaningful numbers right now, but I'm sure there's someone around here who can give you the specifics.

I'd say that the VIC/6510 interactions are quite deterministic - but that doesn't stop me listing the WSYNC register of the Atari as the thing I'm jealous of. DLIs too for that matter

2000-ish, platform game engine for the nintendo gameboy colour. works fine, music plays, no graphical corruption.... oh wait. player is running left. so i went over the main loop, the input routines, checked the scrolling code for good measure and blew 2 days going mental at the z80-ish monstrosity I had created until i reached the point the music was making me borderline psychotic and commented it out. problem solved. reinstate music - problem reappears. Turns out that after collecting the input, but before processing it the interrupt routine that called the music driver kicked in every frame. Guess which register I hadn't stacked on entry/exit?

I think me and TMR actually think of ourselves more as '6502 fans' because there's machines out there with a 6502 at their heart that have interesting hardware stuff around them and are a lot of fun to play with and code for.