Sheddy

yep you're right, that wouldn't help - audf1 is the timer value. what about audc1? doing anything with that? probably the volume should be set to off, and volume only off too - they could possibly be causing unintended noise. you probably will need to post the irq code and the irq setup code if you get really stuck - the timers can be a bit fiddly to set up right sometimes.

Very nice Jason does get difficult very quickly for me - more practice I guess! goochman - every block just around the cursor gets flipped on or off - it's tucked away in the scroller. the 1st level needs to put the cursor right in the middle of the 3x3 blocks to flip them all to off and clear the level. after that, well..that's where it gets interesting!

Have you got "GDI for windows" on the "view" window of Atari800WinPlus ticked? I couldn't get it to work at all without doing that. Just something to try if you haven't already.

sorry, nothing as yet

Glad that works for you - makes life easier for me not messing with different formats. I'll put the player links up on the site - thanks guys. Galaxy Force XE - even a pale imitation of the original will be an incredible miracle - have fun!

thankyou all and thanks to big cartridges to make it all possible For any other Mac/Linux users interested, but having problems with .avi/xvid, I'll have a go at an Mpeg a bit later, as Skunkworkz suggests.

It's hard to imagine a machine more tricky to program than the 2600, so it would be fascinating to see why people who were frequently pulling off sweet little miracles on that hardware were so scared of the 3200! - maybe there were serious design flaws I'm thinking - no DMA still (but jumped up clock speed, more players, improved playfield), but then something added with interrupts (like a POKEY maybe ) - now that would be scary...

sorry Andy, the emu makes an .avi, and the freebie PC software I'm using (VirtualDub) doesn't seem capable of converting it into a .mov - I'll have to look into it some more

Hmm, xvid seems a little awkward sometimes - this is the version of codec I'm using, and it just worked with mediaplayer http://www.koepi.org/xvid.shtml http://www.xvidmovies.com/codec/ yes, still using flicker principle, Mux. I rather not use it, because of the strain on the eye - but for this type of game it seems useful: freedom of placement of colour; good resolution; spreads cpu load of colour processing over more than 1 frame

Whoa. Just.. whoa! The parallaxing horizon and arcade voice samples are very nice touches! It's a shame the music will never be as good as the C-64's release, but you're doing a commendable job! 863497[/snapback] Didn't think I'd be able get those features in and running at a reasonable speed, so I was pretty pleased too it's not final on the in-game music yet - there's definitely room for some improvement. I will be having a go at hacking in a decent music player, rather than my own, which was just quickly lashed together, and bolted on top of the simple sound effects player. Although maybe there is room for a little polish, something as interesting as emkay's efforts(Hardsynth) could be possible in-game. It's debateable how it might work out though - because I feel the sound effects are such an integral part of the game, the tune would have to be cut-back to allow the atari to play them both at the same time.

thanks - here you go stage 3 movie (10MB) NB - need XVID codec

syntax for setting PC in monitor is "setpc hexaddr" so if you want to change the program counter to routine at $4000 it would be: >setpc 4000 then to run from that address use the "cont" to continue >cont if they are on disk as autorun binary files you may be able to look at the 6 byte file header to see where the run address is - off the top of my head, I forget which 2 bytes it is in there though.

Most of that stuff was possible back then too. The more RAM you have, the more you can play with selfmodifying code. That's why Supercharger games look so good. 856780[/snapback] That would explain a lot - for some reason I hadn't realised the Supercharger had a whole extra 6K of RAM - However, it is rather limited by having to load it all from a slow tape. So, lots of bank switch ROM + easily filled extra RAM = even nicer possibilities?

Excellent work Andrew! It'll be really interesting to see what other games are possible now with these carts with extra RAM and clever engines like Andrew's.

Here's the full list of XASM assembler non-standard 6502 syntax "pseudo-commands" and the real 6502 code they generate. Maybe it should be called a compiler rather than an assembler!: PSEUDO-COMMANDS Pseudo-commands are built-in macros. ADD - addition without carry If you have ever programmed a 6502, you must have noticed that you had to use a CLC before ADC for every simple addition. xasm can do it for you. ADD replaces two instructions: CLC and ADC. SUB - subtraction It is SEC and SBC. RCC, RCS, REQ, RMI, RNE, RPL, RVC, RVS - conditional repeat These are branches to the previous instruction. They take no operand, because the branch target is the address of previously assembled instruction. Example: ldx #0 mva:rne $500,x $600,x+ The example code copies memory $500-$5ff to $600-$6ff. Here is the same written with standard 6502 commands only: ldx #0 loop lda $500,x sta $600,x inx bne loop SCC, SCS, SEQ, SMI, SNE, SPL, SVC, SVS - conditional skip These are branches over the next instructions. No operand is required, because the target is the address of the instruction following the next instruction. Example: lda #40 add:sta $80 scc:inc $81 In the above example the word-sized variable $80 is incremented by 40. JCC, JCS, JEQ, JMI, JNE, JPL, JVC, JVS - conditional jumps These are a kind of 'long' branches. While standard branches (such as BNE) have range of -128..+127, these jumps have range of all 64 kB. Example: jne dest is equivalent to: seq:jmp dest INW - increment word Increments a 16-bit word in the memory. Example: inw dest is equivalent to: inc dest sne:inc dest+1 MVA, MVX, MVY - move byte using accumulator, X or Y Each of these pseudo-commands requires two operands and substitutes two commands: mva source dest = lda source : sta dest mvx source dest = ldx source : stx dest mvy source dest = ldy source : sty dest MWA, MWX, MWY - move word using accumulator, X or Y These pseudo-commands require two operands and are combinations of two MV*'s: one to move the low byte, and the other to move the high byte. You can't use indirect nor pseudo addressing mode with MW*. Destination must be an absolute address (optionally indexed). When source is also absolute, an mw* source dest will be: mv* source dest mv* source+1 dest+1 When source is an immediate, an mw* #immed dest will be: mv* <immed dest mv* >immed dest+1 When <immed equals >immed and immed is not forward-referenced, xasm uses an optimization: mv* <immed dest st* dest+1 If possible, MWX and MWY use increment/decrement commands. E.g. mwx #1 dest is assembled as: ldx #1 stx dest dex stx dest+1

Definitely was an XEGS cart bug in all versions of Atari800WinPlus - caused me a lot of grief too! Only recently fixed in the latest version 4.0 Beta 4

Do you have "issues" with your body mass index...? Yeah, it is quite often a bit of a negative thing for us 6502 coders...

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.