Sheddy

oops -128 =11111111 10000000 -0.5

The way you're moving the puck should work fine with + and - You have to be a bit careful on your 2's complements though: your code whilst pretty neat by saving a couple of bytes, doesn't deal with any carry generated by the low byte, which means that when puck_h=0 and negated, the high byte will be out by 1. Not sure, but depending how accurate you want things, that might not be a major issue? I'm sure someone else can clarify that though. This code for 16 bit 2's complement should work ok though: clc lda puck_h eor #$ff adc #1 sta puck_h lda puck_h+1 eor #$ff adc #1 sta puck_h+1 -128=11111111 01111111 when you're testing the -128 don't forget that that high byte must be 255 not 0, as well as the low byte being set to 127. hopefully the darn puck will move the other way then

I'm looking forward to analmux's game(s?) too!

on the homebrew comment, my only point was that if a demo comes out only a few months or so before the game is finished, everyone is happier all round. I just feel in retrospect that it is worth holding back until you know you're ready for sure. I misjudged how long it would take me to finish the game - but I'm glad people have enjoyed the demo. It is still my intention to finish the full game, and the status of "resting" isn't strictly true anymore thanks all for the encouragement

Cool. I still haven't got round to using mine yet, so let us know how you get on!

The sprites and background tiles do exist in the game. If you notice, there are only really 5 PF colours used. and the Player overlays on BUB and BOB. I have recoloured the items to fit the scheme. The cake for instance used the pinks rather than the original arcade spongecake with it orange and creme look. The level colour schemes and the related enemies and items are currently being worked out so that the actual game logic is next. I've got a long way to go yet! I really didn't want to announce the project until I had a working preview to post or a least some of the early stuff as a running preview. Regards.. Oh yeah, I see now! Looks very effective by using the players as overlays. Good Luck with everything!

Nice! Is that level 1 screen shot a mockup or actual in-game? - very colourful!

Sorry for your frustrations, but I'd rather not go down the route of releasing a partial game. If I did have to give up on the game I will release everything to the community so interested parties can have a look or even continue it. But until then or when the game is ready, don't expect to hear too much...I'm embarassed about how long things have taken, and I'll be hiding in the corner! (Note to new homebrew developer's - try not to announce anything until you've nearly finished, or make sure you know exactly what you're doing!)

Did finally get it working, for anyone trying this in future - this also applies to any switchable cart, not just megacart: the normal reset trap can work, but GINTLK ($03fa) must also be correct. on the XL/XE as Bry said, TRIG3 is used to indicate the presence of a cart (0 for no cart, 1 for a cart) the value is copied into GINTLK on coldstart. this gets tested on warmstart (pressing reset). If it doesn't match the value in TRIG3 the system will coldstart - avoiding any reset trapping put in. Switching the cart off is equivalent to removing the cart, so when the RAM under a cart is being used GINTLK should be set to 0 for any warmstart reset trapping to work. Another thing that threw me up was using the $0200-$03ff area of memory for my own code and variables. During a warmstart the OS won't re-initialize itself properly if (at least some of) those locations are changed, and that will cause a coldstart to be performed. NB doing a google search on GINTLK brings up more info

well it's not a 3D game but it is a favourite of many people I am currently working on bringing this to the A8. This post has prompted me to announce it early.. watch this space. Yeah, Stuntcar Racer would be nice too. Wrathchild, you been playing with C64 games again? I'm guessing there'd be enough time to just draw the engine on top every frame and still be able to run at a similar speed to the C64. players and missiles could help out a fair bit too.

Oh dear... it's not a very good test program. the init address is not even pointing into the cart. I don't know why it even does anything...

thanks Bry, I tried messing with those vectors too, but no joy. I had a quick look at what the OS does, but I don't have a good handle on it at all! I thought it might be something to do with the zero page also, so I put together something simple to try and figure things out. Anything obvious wrong anyone can spot? This just puts some colours into the background. It gets copied from the cart to ram when it starts up. the code is then run from ram. the code disables the cart, attempts to set the reset vector to itself, and then just does some background colour changing. On reset it should go back to running itself again. 00:80 A2 00 ldx #0 02:80 BD 0E 80 lda trap_reset+$4000,x 05:80 9D 00 40 sta $4000,x 08:80 CA dex 09:80 D0 F7 bne ?1 0B:80 4C 00 40 jmp $4000 0E:80 A9 80 lda #128 10:80 8D 00 D5 sta $d500 13:80 A9 0E lda #<trap_reset 15:80 85 0C sta $0c 17:80 85 0A sta $0a 19:80 85 02 sta $02 1B:80 A9 40 lda #>trap_reset 1D:80 85 0D sta $0d 1F:80 85 0B sta $0b 21:80 85 03 sta $03 23:80 A9 00 lda #0 25:80 8D 44 02 sta $244 28:80 A9 01 lda #1 2A:80 85 09 sta $9 2C:80 AD 0A D2 lda 53770 2F:80 8D 1A D0 sta 53274 32:80 4C 2C 40 jmp loop FA:BF 00 .byte <setup FB:BF 40 .byte >setup FC:BF 00 .byte 0 FD:BF 00 .byte 0 FE:BF 00 .byte <setup FF:BF 40 .byte >setup Equates: Symbol table: LOOP: 402c SETUP: 4000 TRAP_RESET: 400e

Bit of an unusual scenario I know, but I'm having trouble trapping the reset key when a megacart is switched off to use the ram under it. No problem when a rom bank is switched in of course, it starts by running from the address in $bffe of the rom The normal trick of disk games of putting a 0 (disable reboot) into COLST($244), and the address of the routine you want to run when reset is pressed into $0c and $0d, doesn't seem to work when the megacart is in but switched off- COLDST is being ignored and a reboot is always done. So, is this the correct way of doing things when there is a switchable cart in? Anyone know any games that use switchable megacart that maybe I can peek at? Or do I need to move to another cart format like XEGS that always leaves some ROM mapped in? (Hate to lose the ram though!) I haven't been able to test on a real machine, but am using AtariWinPLus 4.0 beta3 any insights appreciated

Just wanted to add my compliments to the chef - nice job Kenfused I'm now thoroughly addicted to this game.

Encounter does have a "depth map". So the collisions are not done by HW-collision dectection, they are done by software. That is the difference to all other "3D" action games on the A8. When running backwards against a pillar you don't see it. When rotating the vehicle, the pillar is positional always at the right "distance" and "size". The "shoots" are reflected always in the correct degree (impact & reflect). And when moving, you have to check the distance to the enemy and correct the fireing angle. This game is unique on the A8 and technically even more better than the Lucasfilm 3D-Engines. oops - I meant to say Encounter is much more impressive than Dimension X IMO. But the edits are not working today - lots of spelling mistakes etc! the lucasfilm games all had a proper depth-map - eg firing in fractalus took longer to get to a target the further away you were - and the mountain movement as you bank and turn is very impressive. agree the enemies on eidolon are not scaled based on distance or for firing at - but the fireballs and cave is again very impressive and accurate - guess they ran out of memory.

Belonging to the posting-counter? Now one less It's graphics 7 (antic d). The only overlay is in the "aiming square cursor". Encounter - one of all time Atari faves - first time I saw it I just thought WOW!, gotta buy this game! Much more impressive that Dimension X IMO. I always thought at least some of the clouds could be PM graphics - they look the right kind of blocky (streched across) - that would seem a good use of them for this game - never checked though I agree with Emkay and analmux that Antic 5 is certainly an interesting possiblity for a semi-3d Wolf style engine. But think there would be some pretty complex issues for the engine to handle if PM underlays for background/walls etc. especially them not being able to be full width of screen. Think that's probably why people steered away from that idea. Better off using them for enemies or players weapons (like normal games )? Maybe it could be made to work though. Also there'd have to be a fair amount of characters left over for redefining the enemies if they were Antic 5 characters (how big the enemy is at closest range). and if you want more than 1 enemy on screen at once that multiplies it up and complicates things. Still, it'd be nice if somebody puts something together to try and outdo Mood (which is still pretty darn impressive for an 8-bit machine). [/u][/i]

In a word, yes, you will need a header if you want Atari DOS to read or run it AFAIK you won't be able to do BASIC programs with a text editor on the MAC, as the Atari expects a tokenized file, not just BASIC commands in plain text. If it was just machine language, that is much less of a problem. You need a cross-assembler such as ATasm, XASM, DASM etc. Type in assembler code in plain text then use the cross-assembler to generate an executatble file for the emulator. ATasm at least creates the right header info without you having to worry too much (you do need to put an autorun address into the right memory locations though)

Wow some hugely impressive parallax there. Presume that's possible because of the multiplexed sprites?

I had trouble with the WSYNC method, I found it was too easy to "lose" a whole scanline of time to it, if anything ran over, distorting the sound. At the moment I use code that constantly polls for VCOUNT changing. With a gr.7 type screen any DLIS using WSYNC can intermingle with the VCOUNT changes as long as the DLIS exits quickly after the WSYNC. Any VBI has to be kept to an absolute minimum as well. Ideally, instead, as Swiety says, it should be possible to use a Pokey timer though I didn't have much success with that approach.

Now, come on.....didn't Sheddy's Space-Harrier have samples in it? That's graphics 7 too. I wonder how high his Samplerate is. I hope he reads this topic. MY doubts are belonging to "MCS and PCM". GR.7 is another drawer . only 3900Hz guys. think there'd be problems with 7800Hz with DLI's on as well, not that I've experimented much with sound.

I tend to agree that the only really desirable format is cartridge. Even if you had a disk, a really nice disk box, with a manual too, most people would still prefer a cartridge, given the choice. There's no money to be made though. It has to be done just for the love of it. As you can get hold of .ATR's of almost any game that has ever been, and most 8-bit people have APE or SIO2PC cables to make their own disks if they want to - having to pay for the privilige of doing that for a new game will reduce your audience, and a .ATR would soon become available somewhere on the web anyway. I mostly agree with Analmux, that creating new games is more difficult that conversions. Creating new artistic content and original levels cetainly adds to the challenge. However, I would be surprised if any totally original gameplay can be created on an old platform. It's always going to be a bit like something that's already been done. You are limited in your creativity and ambitions by the limitations of the machine itself, which believe it or not is a good thing in some ways! It reduces the skills and resources needed to make something that is good for that platform - more sophisticated techniques, better artwork, music ecetera simply being impossible. Not all conversions are equally difficult. When the platforms are similar in their abilities then maybe things are easier, but every platform has it's own strengths, which can be technically difficult to translate to another platform. I can only talk about what I'm trying to do with Space Harrier, and I can say that I would have rather tried an original game in some ways. You can throw away complex ideas that are hard to do on an original game, but you have to try and make it work somehow with a conversion. It is true however, that I have a clear goal to aim for, which is easier than starting from a blank sheet of paper.

This topic reminds me of those golf games with trackballs they used to have in many bars. to get any distance you had to really roll it fast towards the screen....can I be the only dork who after a few beers has nearly broke their fingers by overrunning and smacking right into the glass of the screen!?

Had the cart a couple of weeks, and at last.....I finally got some paddles today edit: and yes, it was worth the wait

Thanks Andy, the Master System one could have been better but it's very colourful. Luckily mine is not quite as blocky as the Sharp MZ-700 version