sack-c0s

the thing with Arkanoid/Breakout is that the graphics are a false distraction. I reckon anyone could do it if they spent a little time on it. Having written a couple of clones myself I've found the almost impossible part of it is capturing the smooth flowing feeling of playing the original Atari Breakout. It's deceptively difficult. If someone could come up with something with the detail of 'the Pacman dossier' (another game that suffers the same issue) for Breakout and Arkanoid then we could build a game around that and go all-out on the graphics knowing that there was a solid and satisfying game underneath it.

I like the idea of a 3D chip that can fill a framebuffer you then map into the cartridge space and is displayed by the Atari itself. If it only did PSX-style affine mapping it wouldn't be so bad - it would just be a more flexible blitter really. You can build one in FPGA but I've no idea how fast it'll be. I've used PCs strapped to such testchips and it's not pretty (pretty much useful for validation and development work but slooow) but if your base machine is a 1mhz 6502 to start with then it might be less of an issue.

or indeed on any article they have ever written ever...

Fixed that for you

Being from the UK it'd be normal to see a BBC computer around here being used for those kind of things - I remember seeing them driving train station displays and the BBC themselves used them for TV (props, titling and their main intended purpose of teaching people computing). I also remember seeing an impressive amount of expansion hanging out of the back of ZX Spectrums, but I think the logic there was that there were so many kicking around they had enough to blow one up every couple of days and still not run out before the universe succumbs to heat death - I don't think it was down to any actual attachment or preference for the machine.

I'm surprised that they didn't glorify the spectrum as being a great British machine, whilst the Atari is a dirty immigrant of a machine, which is used to connect via dialup to electronically demand unemployment benefits and use the NHS...

The mastersystem loses a line for horizontal scrolling, but it has a way more flexible palette than the NES The mastersystem does that - and it has more flexible colour placement than the NES. It also allows you to lock a predefined amount of rows/columns (I forget how many) to act as a status display area. I reckon it's quite an under appreciated machine really. My only disappointment is you can't do gameboy-style Y-scrolling raster tricks because it latches the Y scroll position once per frame. The minute you want to do something that works better with a bitmap display pretty much all the 8-bit computers start to gain an advantage over the consoles though.

Really? I thought the c64 and A8 versions were pretty much indistinguishable...

Are the Ataris still going though? I used to quite like listening to them... My dads mate used to code on his C64 whilst chainsmoking cigars. I used to be able to sort disks by smell.

you could also write the entire thing to run from lower RAM and have a stub routine to move it down into the right area of memory. the advantage of doing this is that you can potentially compress the program in the cartridge and store more than the 8K a cartridge would allow

yep - without a recompile. Mostly because I didn't know the kind of things that would break 26/32-bit compatibility at the time though.

I can run some of my code on a Raspberry pi that also ran on a 1987 Archimedes.

I'm actually really impressed with the simplicity of how they made it work with the accumulator stuff

I'd do this one: http://www.youtube.com/watch?v=abmytJ4npxw Or these: http://www.youtube.com/watch?v=P3qL_mIw7jo

I quite like that actually - it seems like the kind of thing I'd do

the Inty is a bit wierd, so you'd probably do have to pay people to code for it From my quick initial experiments it seems quite a nice machine though, quirky CPU aside...

another plus: you can use C/C++/Python to do the heavy lifting when it comes to generating data, converting from other map editor/graphics editor formats, compressing code and data, etc. The little experimental thing I'm playing with on the C64 at the moment (Although I intend to get it running on the A8 afterwards) uses a python script to compress a relative shedload of data (down to about 350kb), cross-compile some code that runs from RAM using ACME assembler, and then builds a raw easyflash-compatible cartridge image using another python script and then calls the VICE cartridge maker tool to make an emulator-compatible .crt file. it takes about a minute and a half to build the cartridge image from scratch, or about a second if you don't have to do the data generation.

just a thought - would it be possible to get it to artifact in hardware? It strikes me as something that would be 'fairly simple' to do, but then again I've spent weeks on things that seemed 'fairly simple' before I started actually doing them, so I'm not going to say that edit: I *really* need to build an FPGA TED that can sit on a daughterboard and drop into a Commodore 16 - my first ever computer is sat around broken and there's no way in hell that's going in a skip...

They drive them in Spain though because they're cheaper than Shoguns. Anyhow - I need to worry more about having a game than a title at the moment. One of my ideas has a questionable title anyway...

I always thought it was odd they changed the Vauxhall/Opel Nova (no va - it doesn't work/run) to Corsa, let someone else let Pajero stand... A name that questions the build quality of the car is wrong, yet one that suggests the driver may be sexually self-sufficient is okay?

Well they say in Europe 'if you speak 3 language you're Trilingual, if you speak 2 languages you're bilingual, if you speak one language you're English'

The C64-land trick is to acknowledge that drawing out the vector objects is slow and separate out what is happening into rotations (which need the object redrawing) and translation (where you can more or less just move what you've already drawn). You have the main loop going flat-out trying to rotate and render the objects as fast as it realistically can to sprites and have an interrupt routine that moves them on the screen so even if the object update isn't really 25 or 50FPS it gives the illusion that the framerate is higher than it really is and keeps it smooth for the player/viewer. Might be a bit trickier on the Atari with the PMG sprite setup, but maybe there's some way of making it work in a usable way?

TIP #2 (and this is VERY important): *don't write ANYTHING before your first coffee of the day!*, because if you do you end up making the kind of mistakes I did just then. I meant LDA #$00 TAX although LDX #$00 TXA would do the exact same thing. What I wrote will just stick 0 in X then copy A to X, which could be just about anything. D'oh!

This part ldx #$00 lda #$00 Could be replaced with this to save a byte: ldx #$00 tax