Sheddy

so easy to do that... An error seems to have crept in during the massive changes I made to your code - all 3 lines of it. The "bmi" should of course be a "bpl"

Ah, start and stop bits make up the 10 bits. Sure you already found it, but this is what I was getting at: that "txa" is bad news for your data?! ;Process one byte tax ;make an index lda $0680,x;get the next byte ldy #10 ;Process 10 bits! clc ;start bit... rol a ;...into position 0 (& bit 7 in C) inx ;move us to next read position bmi saveindex ldx #0 saveindex stx $067C;save it (for next time) sta WSYNC;Do this so timing is always the same ? Interesting project though - It'll be really cool to have a game or app chatting away!

Just skimming Bry, and I may not be understanding something, but, I can't see you restoring your data byte to A after setting up the next index position?

Silly question, but, have you tried cleaning the contacts on the cartridges? - the cartridges just may not be seating in the same way in the 800 as the 600XL/800XL - slightly different connector sizes/angles etc. - unlikely, I know, but it seems such a strange problem (I've never owned an 800 myself though).

Well i think you are right there Atari UK were trying to get me to port an ST racing car game they had released but i stopped doing anything for them as getting paid was so hard. But i am sure they would have been asking others. Then with Harlequin i think we could have done some good stuff. There were a good set of people working on things for them. I am sure Ivan and Richard of Black lamp fame would have done so cool stuff with Harlequin too and i had access to a good C64 man Steve Bak so i could have picked his brains on how the C64 was doing things. But it all came to an end as i got going. It's a shame - I really like what you and the Harlequin guys were working on but that'll never see the light of day! The stuff on Steve's (JetBoot Jack) site is mouth watering stuff - Menance/Shadow of Beast/PacLand. Just saw Steve said nothing further is likely to happen with the games (But it's still nice to see you back around here Steve!) Back on topic. I tried out PowerDrift on the c64 the other day, and it is really quite nice, even if it does use redefined chars. Not as many other cars as OutRun though, and Scenery is limited. But "hill" effect is good. As TMR has noted, there are a lot of redefined characters required. I guess that is one reason there are so few roadside objects, other cars etc. used on c64 OutRun - and not so much because of speed considerations. I could be wrong here, but I'm thinking even less objects would be possible on the Atari without going to some extreme lengths? Sure, we can switch character sets anywhere vertically down the screen, but then you're going to have to be shuffling data all the time into the data of those character sets to get the objects where you want (IE like a graphics mode) - the objects on OutRun don't stick to nicely defined vertical sections of the screen. From what those interesting articles said, ElectraGlide looks like it was designed to work with and take full advantage of the Atari hardware (probably the best way to design an original game). There isn't much scope for it doing a lot more with it than it's already doing. IE there can't be more or more colourful objects on the road, as it's maxing out the hardware sprites already (and you can't add soft sprites as it's scrolling the whole screen left/right differently every scan-line to do the road) It's a really great game, cleverly designed.

I'd think not a lot of point stuffing the data registers yourself - the DMA is very efficient at stuffing the data - only 1 cycle per player per scan-line. It can't do it automatically more than every scan-line though. The linear memory area of each player is quite quick to move around with the proc. You'd need to have a similar arrangement anyway to do it manually. Also, doing it manually you going to have to keep tight reign on where in your prog you are for every scan-line - IE a 2600 type kernel. This zaps a lot of potential cycles. Main problem I see with player overlays/underlays for sprites is what to do when you run out of them? 4 or 5 single colour, skinny players a line just won't cut it for a lot of games - you need to design something that is pretty contrived to make use of them that way. So, just don't display the underlays players when there's too many soft sprites on the scan-line?

Well, maybe it was still supported officially, but I know we missed out on "big name" games in the UK from at least 1986/7 - it was all just Spectrum/C64/Amstrad only when they did ports.

I think if the Atari had been commercially viable for just a year or two more, I'm sure we would have seen these kind of games done just like that - ported over from c64. I wonder if the c64 having more characters in its character set for redefining has anything to do with it not being done like that on Atari? - I would have expected to see at least some attempt at it too.

Lack of colours per scan-line always a problem with our baby Atari The c64 has its arse whipped from that point of view. I think G2F style mode would place some pretty heavy restrictions on where things can be drawn on screen. I can't see it working well with how OutRun moves things all over the screen. But maybe if limitations are worked to... IMO Char-mode always looks ugly for these 3D style games (although it'd certainly help with speed). You need the freedom of y movement to give a good effect of moving into/out of the screen convincingly - things won't look like they're actually on the road otherwise - even with as much character redefinition as possible i think it'd be working against the grain. I imagine going over the "hills" in OutRun would not be very pretty sight. 80x192 is too chunky for these type of scaling game I would say (check out Koronis Rift) although it'd give us some more colours to play with. 160x is really too chunky as well. 3D engine for OutRun? Just for example I'd look at doing an interlaced 160x96 graphic mode. (Using colour interrupts on background is going to mess with using any soft-sprites otherwise) For even a vaguely faithful port of the original, the road alone is going to be quite CPU intense I would guess. There are a heck of a lot of huge sprites being thrown around. The number of those would have to be cut down a lot, to render them in a reasonable time - maybe only one third the amount of the original at a rough guess (and probably smaller too). There is a lot of background clouds/mountains etc. to scroll around too, if we try and keep faithfull. I would imagine we'd be lucky to hit a top speed of 12fps, and probably slower most of the time. I'd probably use the players for the players car and move that in VBI to keep the game responsive (12fps doesn't give much feeling of control) Maybe missiles could help with lines on the road, but there wouldn't be time to reposition them all every scan-line. So maybe they'd need to drawn as graphics too. All in all, I think what was done with Turbo OutRun on the c64 is really pretty good considering the problems to be worked round. OutRun on the c64 looks like a sad and rushed and cash-in on the license though. Very few elements of what makes OutRun OutRun, actually seem to remain.

If the dark areas on the hi-res are taken as just see-through, then there is an advantage with doing the graphics in hi-res (they just need OR'ing together). Doesn't look like Kult does that though. It does seem to do proper masking of the sprites - there is no speed advantage in hi-res for masking sprites as far as I know.

ATASM's a great MAC/65-like cross assembler http://www.cs.utah.edu/~schmelze/atari/atasm/ I second Atari800WinPlus 4 as one of the best emulators for developing could be interesting - someone here http://www.cox-internet.com/wa5bdu/amac.txt gets AMAC working on the XFormer emulator (although that isn't such a great emulator IMO) but doing the editing on PC

This game is the only reason I've found for stealing the paddle controllers from my 2600! It's just such a fun game, and expertly implemented.

What you're wanting to do is still called interlacing A TV only displays a complete picture every 30th of a second (NTSC- a 25th for PAL). The 1st 60th of a second it only displays the odd scan lines, then the next 60th it displays the even scan lines - these two fields "interlace" each other to give a complete frame every 30th of a second. The code to swap between two different screens is not too mind bending when you get down to it: One way is to have 2 display lists that point to the two different screens. But instead of having the jump at the end of each display list pointing back to itself, point it to the other display list! Make either of the display lists active, and they will happily swap between each other every VBI without you having to get involved at all! That is a simplistic example because it doesn't deal with any palette swapping, double buffering, or cope well if your code drops a frame ocassionally, but it just shows how neat display lists are! So you can do pretty much the same thing yourself in the VBI. One of the easiest ways to alternate between things is to do an EOR EG lda whichdlist eor #1 sta whichdlist beq dlist2 dlist1 ...code to set dlist1 and palette colours jmp out dlist2 ...code to set dlist2 and palette colours out the whichdlist variable alternates between 0 and 1 every time eor #1 is done. That's all probably too simplistic for what you're wanting, but it's a start

Yeah, seems strange to start with, but we shouldn't blame the emulator. It's happily doing the right thing at 50Hz for a PAL atari or 60 Hz for an NTSC one. However your PC video card and monitor is probably set up nice for that ultra smooth game of Doom3, and running at 85Hz+ !

In my experience, for the best results with interlace using emulators, set your monitor refresh speed to the same as the Atari, ie 60Hz for an NTSC Atari. Also make sure the vertical sync option is turned on in the emulator. When interlacing if you can also interleave the scan-lines and/or dither the pixels horizontally the results are much easier on the eye. Without breaking up the image in some way, large areas of colour appear to flicker worse otherwise (Unfortunately I haven't enough cycles left over to use these techniques effectively on my game) Keeping the luminances similar on overlapping areas also helps minimise flicker. For some really neat examples of interlacing check out any HIP/TIP pics, or there are some example pictures given with the Lepix program (see recent thread on the 8-bit forum). You can pause an emulator to see what it's doing on the different interlaced screens.

Thanks for sharing the code Cybernoid - I'll be looking at it with a fine tooth comb - My experiments with combining channel volumes on samples were awful! In fact I was even thinking that when using volume only the full excursion of the speaker was effected by just one channel. Nice to know it can be done

Nice one Cybernoid - Pretty good sound quality Just curious regarding your first one - 6 Bit, 4Khz. (I'm too lazy to dissable your code I guess) If your're not wiggling the volumes faster than the sample rate like the other example, how're you doing it then? thanks!

thanks for sharing - Very nice - has a good "look" to it already, even at this early stage. Of course a few little glitches to work out. As you are already doing, I agree it is important to get the basics working first, so you have more time to get the "feel" of the game right. I know this is only test level - but some gaps too big? Depending how big levels are, testing to make sure they are all playable could be tricky. Mind you, when it is decided exactly how many pixels the ball can jump across, it should be easy enough to make sure that when designing level that this is never over stretched. (But then again, I suppose there will be power-up to jump much further too!) Have fun

I just didn't want to get the screen cluttered up with bullets for the movie :wink: I really don't know why I still like this game - I've always totally sucked at it. My brother Nick is the expert - just the other day he played our real Space Harrier machine (discretely placed in the middle of our back room) all the way through without losing a life (again). I think he's only done that once before. Guess who's going to do the most of the later playtesting...I might not listen if he says it's too easy though!

Since you all seem to like it.... ...I suppose I'd better try to finish it... The movie was made straight from AtariWinPLus - the only changes to it were the black borders have been cropped to try and make the file smaller.

sure - I'll put some on the web site soon OK - some new pics are up on my www site Thanks very much Tezz Look forward to seeing your progress with Bubble Bobble (I notice yours got a mention in RetroGamer mag this month - they had a big article on Bubble Bobble )

You may need to install the XviD Codec if you haven't already got it. But here's a clip of Stage 2 Dial-up users beware - it's nearly 6MB (and it won't stream either )

sure - I'll put some on the web site soon

Thanks for the question - but the only news is that it hasn't completely stopped and I have been working on it again for a few months now. I put a small update on my website last month (or was it the month before - my doesn't time fly by!) Progress is slow (I'm at the end of redoing Stage 2 now) - but at least something is happening. I did a pretty major rewrite when I decided to move over to having it cartridge based. All the graphics drawing code changed. Also I've been redrawing all the graphics to be a more faithful to the original (well, as near as the A8 can be in my non-artistic hands) I'm not releasing any more code, but I will probably do a movie clip now I've figured a format that can do the interlace without looking absolutely terrible (Xvid). I hope people will think the rewrite is worthwhile. There's some sweet features I'm very pleased with (OK I'm a bit biased!) like parallax scrolling and samples playing while everything else is still going on.