Sheddy

Just didn't want people to think you're cheating by using the anti-aliasing that jpeg images end up with Here's a .gif of the relevant bit from the emulator.

Can you post the pic as a .gif or .tiff emkay? ...We can't see the details of the clever stuff you've done because of the jpeg artifacting Thanks

Golly, does Andrew Davie know this? You better stop him quick before he actually finishes his game that uses it! Heck .... what is he doing? A game with triple interlaced GTIA-Screens? ... and in 10 years all ATARIfreaks are blind? Do you have a link? It is unbelievable to me anyone would even take a thought on this.... Check out the Fu Kung forum emkay - it's for 2600, (and pretty interesting too) But yes, you might need the So "Chronocolour interleaved " = ColorView? What's that "TM" all about then. Get an American patent on it too Andrew, should be no problem! I'm curious to see how the objects look when they are moving in Chronocolour - Because of the triple interlace, I would imagine you'd get some kind of ghosting effect... Cheers for the MCS explanation, emkay - interesting

Very Interesting! Umm.... I don't know whether I should be happy or sad! But thanks anyway for the kind words, people. The graphics are less accurate on that old demo, but because of the full screen size and some oversized objects (compared to the original), the objects have more detail and the scaling would look better, I guess.... so the question is, what should I do now? Carry on regardless....or tweak what I have been doing recently...or revisit the idea of 4 colour (maybe with a colourful twist, as emkay suggests)

It is no miracle The 64 colors I mentioned in earlier threads are a calculation of the colors that are truely different and worthy to use in Games. The MSC uses up to 9 colors at a scanline. The usage of the colors is still depending on the Game. So you can chose to create pictures by using fullscreen "DLI" and you can add colors by using the GTIA bug of mixing the colors... so a blue dot with a yellow dot under it in the next scanline will become "real" green... You have to find the right technique to produce graphics with as much colors as possible for each game... Another possible way to produce a scrolling game ist to use a fixed mcs screen (8 fonts and 5 colors) and use the PMg (3 color in overlay)with much as possible multiplexing to create a scrolling screen and use the fixed background with its 5 colors for the sprites: For Turrican you need: Black White Brown Blue Yellow Red Green will be mixed by blue and yellow... Brown can be mixed by red and green... Due to the fixed background, you can use as much DLIs until no more CPU time is available.... So it is only a clever usage of the capabilities ... nothing else... In theory it was possible to create games with a PMg-multiplex-screen and using Hi-res Sprites. Due to the fixed screen you could left the "HERO" allways in the center of the screen and make it colorfull with DLIs... Thanks Emkay - I'll read your other threads as well. I'd like to have the extra colours but reduce the flicker; I can't do some of the really clever, smart techniques like Andrew Davie's "Interleaved Chronocolour" (and also TIP/HIP of course), because they take away too much CPU time, and are not so suited for fast animation

Thought you all might be amused to see this... an early proto, before I gave up first time round (as it was too crap) Avram asked about my first attempts at Space Harrier in another post, and I had good hunt round and found some of the original disks - surprisingly some of them still work after all this time. I finally managed to get it into an .ATR image after giving up on ProSystem and just using APE. I think this dates back to around 1991 before I had some sound effects put in. strangely in some ways it is better than what I have done this time around ...full screen, up/down scrolling when the man dies...but hopefully you can see why I don't want to do a 4 colour only version.... shdemo91.zip

I'm sure it could be done - but I'm not so sure it could be as good.. OK, you CAN multiplex Players and Missiles in x position, but only at the expense of having DLIS every line where that is required, or more efficiently, a VCS 2600 style kernel. Both options severely limit the amount of CPU time you have left for any actual gameplay logic or anything else. Sorry, but the C64 sprites are just awesome compared to the Ataris - if only just for the fact of getting all 8 of them on a scanline at once, 12 pix wide with 4 colours each. Even with horizonal multiplexing on the Atari, it can't come close to that. Sure, things are different vertically, and on the Atari its easy to split them this way - whereas the C64 may well be a bit more tricky (I'm not 100% sure about this since I'm not a C64 coder) Parallax (which is always a big cheat on nearly all 8-bit systems) I suspect is also harder, due to having only 128 characters in the character set with the Atari, and having to resort to interrupts mid screen again to up the count....

I think when a system has reached a certain amount of market penetration, the one-upmanship between developers becomes much greater (plus there is marketshare to go for). To show you can do the best on a leading platform is an intense buzz, I suspect!

Tell me more about MCS mode, guys. EmKay is that where you stretch the players and use them as background colour? How'd you get to 64 colours that way? Maybe 8-bit developers did not push the Atari as hard as the C64 in the day. During most of the Atari's lifespan it proved more than capable of making good versions of simple games, without a huge amount of intense programming effort to REALLY push the boat out. It had no real competitors. It was only towards the end of its life that arcade, and other systems games were becoming more sophisticated (visually and sonically) that people even felt the need to try for better. The C64 was born into this age of vast improvements in arcade graphics etc. so it was necessary for its developers to keep up with the trends...the Atari was more or less dead by this time, so no one tried - except the demo coders and crews. They were not responsible for the lack of impressive software - they only showed what could be done, even if it might not be possible to make some of the effects into a full game. Still IMHO the gameplay is more important than graphics or sound. Maybe someone could make something fantastic looking and sounding but utterly unplayable - but to me there would be no point in that at all. Each has to complement the other, so there are limits to what should be done, as against what could be done. just my 2 cents...

Maybe! You got me thinking and I found an early version of the original ........but can I get my darn ProSystem to work Won't detect the drive all... Had enough trouble getting APE going too - as it is it doesn't work on my nforce2 PC, and I had to put it on our "file server".

Would have loved to have seen those protos. Maybe Tempest knows more, but we only have theses rumours I find it hard to believe BallBlazer only runs at 20fps! It's just so well done though.

You've got some interesting sounds out of Pokey

excellent idea guys - I'm signed up

Even though I've bought every issue (including the ultra rare no.1) they just don't call Edge do sometimes cover retro - but they are not really interested in ports - only original content. BTW Paul Slocum got a small mention in there last month, with his excellent "Marble Craze" for the 2600

I'd love to make the game work on all Ataris, but there are a couple of problems, as sTeVE has mentioned. RAM is a problem if you want more than a "standard" 4 colour screen - which I refuse to use for this game ( it does the original Space Harrier no justice at all - its main pull is the graphics and sound - my original work on this game in the late 80's was 4 colour, and I just didn't like it - although it was blindingly fast). I'd need all 16K RAM of the 5200/400 for the screens alone, and preferably 24K to maximize the speed with triple buffering as I'm doing at the moment. 32K ROM size on the 5200 would be a major problem too - interested if anyone knows how to work round this. Also intrigued by prospect of adding RAM... Until I hear a reply about officially licencing the game, either yea or nay, (I rather NOT just produce a clone), or being given some kind of response from Sega or Elite Systems (they haven't replied to anything I have asked via e-mail, so far), I don't want to get invoved in anything that would involve money changing hands (which involves any kind of Cart of course) Saying that, however, I'm very keen on the idea of a mega cart that could run on 800/800xl/600xe/130xe - anything with 48k or more of RAM. Also using the full expanse of the cart, I can take away a lot of the limitations that I've had to place on myself: I'd do more colourful objects - I'm limited to 4 colours per object right now. There's another faster sprite routine that's waiting in the wings if I get a whole load of rom space (and I mean something like 2MB ) ...And the rest of the sound samples.

Ah ha! so this is the secret project for which you wanted to know about voice samples. Wish you well. Don't forget to check out the arcade version using mame. Always nice to try and get as close to the original IMHO

Well, not quite, but it needs to be about that kind of speed for it to sound OK with 4-bit samples. VCOUNT changes every 2 scanlines. Syncing to vcount gives you just under 8000 samples per second, and like EmKay says the quality is not bad. Every scanline gives you twice that of course. I'm using every other VCOUNT in the Space Harrier demo so I have a bit of time to do some other stuff - and I think it sounds reasonable enough

I agree with JetBoot - most likely memory restrictions. Working it in could be very hard without upping the ram requirements or creating a new cart version. Hve - I'm too tired after all that typing in the reply yesterday! EmKay - where are you today?!

Sorry Tempest, no time to do it myself (got to see a man about a dragon...) I had trouble getting the samples into the Atari too. With a bit of trial and error this is what I found on the samples I was looking at: Once you have a .wav file though it's not too bad if you know the original sample size 8-bit/16-bit and rate. There's no compression or anything on .wavs I had to knock up some VB code to convert it to 4-bit, although there may well be some utility to do it already somewhere - my brother's copy of soundforge couldn't do it though! There's about 43 (or 44?) bytes in the .wav header. After this in the 8-bit samples I looked at they were just signed integers (-127 to 128) of the volume level. 0 means quiet, -127 speaker full out one way, 128, full out the other way. I guess the header tells you somewhere whether they're signed or not, but it was easy to tell by the godawfulness of the sound when it was wrong! So simply a matter or some division on each byte to get it to +/-7.5 for the Atari. 4000 4-bit samples/sec sounds sort of OK, 8000 is pretty good. But the sample rate is straightforward to pick - once you know the little secret about sample playing with the screen going.... try something like SAM with a 4k or 8k screen on, and it sounds like he's really drunk - slurring awfully. Why? The DMA fetches for the screen data slow the processor down, and you can't time precisely enough when to do the next sample, without your ears noticing. So you need something external for the 6502 to get its timing from. Maybe you can try Pokey interrupts - but they seem to get affected by the DMA fetch too! (and no emulator does them properly yet either). That only leaves a couple of things that change quickly enough and reliably enough to use to re-synchronize the processor - either WSYNC or VCOUNT - which aren't affected by DMA. These registers get changed at the end of each scanline. VCOUNT changes every other scanline, and goes from a value of 0 to 130 (NTSC TV) in each TV frame. 60 frames in a second. So 60*131=7860 changes per second. Voila - 7860 samples a second is not too shabby a number to choose - or 3930. Well, jeez, I said a bit more there than I intended. Sorry about that everyone else - turned into more of a programming thing there.

Definitely worth turning into a book IMO. (Still can't beat the user interface of a book) You've a great way of explaining things, which makes it SEEM almost straightforward to use the 2600!

Cheers for the link Nukey. Somehow missed that thread - Fascinating stuff. Could have saved myself asking Andrew some numbskull questions about his excellent Fu-Kung work and picture demos with all those good explanations there

I agree with Eric, Frustrating though it is, a re-write is no bad thing - you often end up with something better. If it was easy, you wouldn't get any real satisfaction out of it either. It was 8 years before I picked my project up again with a complete re-write - no need to rush! I constantly re-write code if I think of a better way to do things (to the frustration of anyone actually wanting the game finished, I'm sure!)

Another cross-assembler for the 8-bits. Atasm - Mac/65 compatible too. http://www.cs.utah.edu/~schmelze/atari/atasm/

That's good to know. Thanks!