Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

Sheddy

Members
 View Profile  See their activity

  • Content Count

    798

  • Joined

  • Days Won

    1

Posts posted by Sheddy

  1. Posted

    Sheddy, will the NTSC version be identical to the PAL one? NTSC Ataris produce screen with slightly different colours and different pixel aspect ratio. Knowing that your game is an excersise in perfectionism ;), I'm curious whether you take the above issue into account.

    Not quite that much perfectionism ;) I am looking at defining different colour palette for NTSC though, although it might look strange on some of the Emus that don't have a NTSC palette

  2. Posted · Edited by Sheddy

    Thanks, I'll keep you posted Jason.

     

    Brutal, ta for that.

     

    It'll be free, so officially Emu only, but if Retro Gamer will pony up for a blank 8mbit AtariMax cart on expenses :lol:, you'll be just fine on real hardware

     

    What, people think i get expenses?! =-) Actually, how much would that cart cost because i've got an 800XL sat here looking rather hungry and might be able to scrape together some pennies if it's not too expensive (i'm currently saving for an SIO2SD, so that's got priority).

     

    And before i forget, would you be up for an interview at some point? =-)

     

    Ha ha!

    yeah, you'd need the cable too. And the blank carts are about $20 a pop (Atarimax.com) Good of Sal to offer a cart up. I might have another cart knocking about somewhere too, which could save you on shipping (although you'd miss out on the fancy lablel!). Thanks, I'd be up for an interview at some point. We're talking about a few months or so before things will be ready though. I hope to be quite good at interviews by then, as I'll be out of work in a couple of weeks :ponder:

  3. Posted · Edited by Sheddy

    I bow to your knowledge, never having done much parsing code :)

    Hmm, disappointed the double quotes are not working as expected either.

    There's definitely some more general parsing problems going on with 1.07 though

    I'd converted RTM player over to ATasm a while back, but 1.07 choked on this:

    .IF FEAT_TABLETYPE .OR FEAT_TABLEMODE

    I'd assumed it was just some extra error check because strictly it probably should be this

    .IF FEAT_TABLETYPE | FEAT_TABLEMODE

    or

    .IF FEAT_TABLETYPE>0 .OR FEAT_TABLEMODE>0

    But the error message returned implied it thought FEAT_TABLETYPE.OR.FEAT_TABLEMODE was a label

  4. Posted

    When I'm done with Space Harrier (soon!), that'll be it (apart from any serious bug fixes).

     

    So who do i have to see about a review copy for Retro Gamer then...? =-)

     

    Thanks, I'll keep you posted Jason. It'll be free, so officially Emu only, but if Retro Gamer will pony up for a blank 8mbit AtariMax cart on expenses :lol:, you'll be just fine on real hardware

  5. Posted · Edited by Sheddy

    I guess it could complicate the parser or error checking, depending how it's done now

    Is surrounding with double quotes exactly equivalent to the single apostrophe though (Edit: I guess it must be)? If it is then it seems reasonable to leave it as it is to me - substituting double quotes for apostrophes (and vice-versa)in the text editor is not too bad? If not, then I agree it would be useful to allow both forms

  6. Posted

    I agree with sticking with stock hardware too. But you can think of the stereo music as an unexpected bonus (it was for me too!) I've made sure it doesn't impact the performance with normal single Pokey though. I kinda forgot stereo was on when I made the movie as I leave it on the whole time to pick up on those performance problems.

     

    When I'm done with Space Harrier (soon!), that'll be it (apart from any serious bug fixes).

  7. Posted · Edited by Sheddy

    Looks like a new bug unfortunately :(

     

    I haven't used the single quote in my code either (not much text processing!). Nice shorthand. Suppose surrounding with double quotes (not single!) is equivalent?:

    lda #"z"+1

     

    Have sent a PM to Gauntman in case he's not checking the topic that often. He's usually pretty quick with fixes

  9. Posted

    A few comments:

    • Yes, go to scanline (gs) is the only way to do a frame step right now. I might put in a go to vertical blank (gv) command for convenience.
    • Redock the display window by releasing the mouse over the center of the docking target.
    • Memory randomization only takes place on cold start and is not something you can rely on. Having blocks of memory be zeroed on cold start is a valid condition, especially if the Atari was quickly turned off and back on again, as it can take several seconds for DRAM to decay enough for a byte to change. (Occasionally, a real Atari will improperly warm start on power on because of this.) Therefore, if you've got a problem with warm start only working reliably if that option is on a particular setting, you've got a bug with reading uninitialized data.

     

    Ahh...docking target :dunce:

     

    Also...I think I must have been confusing 1.5 with one of the 1.6 beta test versions when talking about a warm start/randomize problem on 1.5

  10. Posted

    Pause and frame advance can be had from the debugger, break will obviously cause a pause :) and there's a go till scanline command so you can just gs 0 to advance to the top of the next frame.

     

    Screenshots, copy frame to clipboard which is fine unless you want to take lots of shots.

     

    The .traceser command saved me endless debugging, many MANY thanks for that one :)

     

     

    Pete

     

    thanks Pete, that's good to know :)

  11. Posted · Edited by Sheddy

    Excellent work as usual. Just keeps getting better. Many thanks!

     

    Very glad to see the randomize of memory fix. Thought I had a serious problem with my warm start code for a while using 1.5

     

    Is there a quick way of docking the display window back into the emu window after the display has been moved out? I seem to do that accidently far too often!

     

    Only things I personally miss at the moment are screenshots, movie recording and a pause or single frame step (mind you that may be somewhere in the debugger already, I've hardly touched the surface of that yet - it looks just awesome)

  12. Posted · Edited by Sheddy

    I've asked Mark (Schmelzenbach) about having a way to return the bank number of a label in ATasm ages ago, but I'm not sure I explained the usefulness of it well enough so he'd actually implement it ;)

     

    This probably doesn't help much, but if you're prepared to create another label for each routine that may be called by the macros, it should be possible to compare them to the current bank in the macro? If there are hundreds I guess you don't want to go there though

     

    top of each bank has a redefined label (EG CurrBank .= CurrBank + 1)

     

    routine_1_label

    routine_1_label_bank .= CurrBank

    code

    ...

    routine_x_label

    routine_x_label_bank .=CurrBank

     

    the macros can then check ...label_bank to CurrBank

  13. Posted · Edited by Sheddy

    IMHO alternating colours on each frame for more colours in-game is really only something of a last resort when all other alternatives have been considered. It will always flicker, and some people really can't stand it, even if the TV/Monitor has had its brighness and contrast adjusted to try and minimise the flicker. Therefore colour needs to be very important to the game to seriously consider it. That being said, most 2600/VCS games had no choice but to use it, at least in places, and people accepted it back in the day. Although most games try to keep it limited to small sprites, 2600 Asteroids is an example of flickering large objects.

     

    Would Space Harrier code be any good as an "engine" for other Sega sprite zooming games?

    Never having thought deeply about how to approach those other games, I can't really say for sure. Others would know better than me! I think doing the graphics and sprites with the same routines(as a bit-map screen) would probably be too slow unless things were very heavily cut back. (The rotating ground on Afterburner would concern me particularly, and the huge number of zoomed sprites in Galaxy Force II). There'd have to be far, far fewer sprites and many more compromises. A character based mode like that being attempted with OutRun might make more sense. However, IMO (some others may disagree here!), even the originals of those games don't seem very playable or enjoyable enough to warrant a conversion to me. No amount of skill seems to make a lot of difference as to how long you play for. They were all about shoveling in more money in to continue and just see what happens next. At least OutRun and Space Harrier (when you've got to know it) are pretty playable and do rely on skill to progress.

  14. Posted

    We had a thread about Stereo Pokey detection some time back.

     

    I think the Pots will return 228 if not attached. Second Pokey should be as per Pot4-7 on XL/XE since they're not normally attached.

     

    IIRC, the method I put forward was: start a Pot scan, then read POT4 at $D204 and POT4 at $D214. If you have two Pokeys installed, then one should be counting upwards, the other should remain static.

     

    Another method which probably would be easier:

     

    Set second Pokey's SKCTL to 3, then first Pokey's SKCTL to zero. set Wait a little bit, then read RANDOM from $D21A. Or it with same address once or twice. RANDOM should read zero if Pokey is in an init state.

    Zero from second Pokey's address will mean that you have a mono machine since mappings repeat each 16 bytes. Stereo machine, mappings normally repeat each 32 bytes for each Pokey.

     

    thanks for the info Rybags, surprised I missed that thread

  15. Posted

    Candle, what is the best way to detect whether stereo pokey is installed?

    I read some instructions on building others from Internet that the extra POTs and KBCODE should read zero if installed? I haven't treated myself to stereo yet, but checking for zero on POTs didn't seem to work on a friends stereo machine in a prog I sent them. Some Emulators seem to return zero on POTs, others not. So, I'm not sure. Hopefully you or someone knows a sure fire way to detect a stereo set up? thanks

  16. Posted · Edited by Sheddy

     

    So can base code in low RAM switch out the 8K ROM space altogether and use the "Shadow RAM" underneath, then turn the cart back on again? Clearly SDX's "X" command does exactly this, so it must be possible.

     

    EDIT: Looks like ATASM will compile to a "RAW" binary image with the "-r" directive, which hopefully means no headers. Any script-processing should be unnecessary, if that's the case.

     

    yep, raw is no headers

     

    $d580-$d5ff turns off 8mbit cart for RAM access, think the 1mbit is different though

    just write $d500-$d7ff as usual when you want a bank back in again

     

    check out the .bank directive on ATasm - really useful for assembling a whole cart in one hit (although the example in the doc doesn't have cart headers like it should - that's partly my fault :P - sorry gauntman)

  17. Posted · Edited by Sheddy

    The VBlank checks the cartridge status via TRIG2 - changing banks shouldn't affect that. Warmstart though, checks the status and the Checksum of ROM from $BFF0-$C0EF so if your topmost bank is changed it'll cause a coldstart.

     

    Just why it checks that range is beyond me - $BF00-BFFF is what it should check (maybe a typo crept into the source).

     

    But, typo or not, it makes it easy to have a non-volatile situation for a mult-bank cartridge - just ensure the checksum of $BFF0-BFFF is the same in all your banks (as well as providing valid cart flags/vectors)

     

    IMHO all that OS checksum and TRIG stuff on XL/XE is a bit of a pain in the butt. Not sure how you avoid it trashing some locations in page 2 and 3 that the OS uses to do it either (GINTLK and ?). Maybe I'm a bit simple minded about it, but using the diagnostic avoids all the faffing about by stopping that check from happening.

    [Edit: Although if the cart is just going to completely re-initialize on reset it's not such a big deal I guess. That would be normal expected behaviour for most carts - to just init like power on]

  18. Posted · Edited by Sheddy

    Be careful when testing in Atari800WinPlus, Andy. I thought I had reset trapped nicely at one point last year, but it didn't work on a real (XL/XE) machine. Altirra behaves correctly now, at least with AtariMax cart format. XL/XE reset gets done by the hardware rather than NMI which may explain some of the emu problems.

     

    Used RAM under the cart when I tried using MegaCart format a while back, but that was only through Atari800WinPlus (pre Altirra). I did have some grand plan of trying to use just 48K RAM rather than 64K (XL/XE only), so I hadn't touched the 8K RAM under the AtariMax cart yet. Since that's pretty unlikely to be possible for me, I'll probably be trying to get at the RAM in the not too distant future. I expect(hope) that if the cart is turned off when reset happens on XL/XE the cart will also init and the default cart bank will pop back into mem...

     

    [Edit: Sorry this is kind of redundant having re-read the previous posts properly. don't think you can get away without the cart header in every bank unless you don't mind crashing.]

     

    I wasn't very clear that it wouldn't be necessary to have code in all the different cart banks:

     

    At least for Atarimax, set the diagnotic bit in the cart header (shouldn't that be footer!) for all the non-default banks and point their init addrs to your reset trap in RAM (diagnostic takes control straight away before OS clears RAM). Although Star Raiders gets away with it, you probably don't want the default bank to be a diagnostic, as the OS H/W initialize is different between 400/800 and XL/XE

  21. Posted · Edited by Sheddy

    Be careful when testing in Atari800WinPlus, Andy. I thought I had reset trapped nicely at one point last year, but it didn't work on a real (XL/XE) machine. Altirra behaves correctly now, at least with AtariMax cart format. XL/XE reset gets done by the hardware rather than NMI which may explain some of the emu problems.

     

    Used RAM under the cart when I tried using MegaCart format a while back, but that was only through Atari800WinPlus (pre Altirra). I did have some grand plan of trying to use just 48K RAM rather than 64K (XL/XE only), so I hadn't touched the 8K RAM under the AtariMax cart yet. Since that's pretty unlikely to be possible for me, I'll probably be trying to get at the RAM in the not too distant future. I expect(hope) that if the cart is turned off when reset happens on XL/XE the cart will also init and the default cart bank will pop back into mem...

  22. Posted

    And also the lack of the 15K timer matching the scanline timing on NTSC makes for a major pain in the butt..

    Could be wrong, but AFAIK it should match. CPU clock is 114 cycles per line on both PAL & NTSC and 15Hz timer is derived from that?

     

    Really looking forward to this. One of my absolute favourites on PC Engine (Gunhed next maybe ;) ) Sounds like you have loads of really interesting implementation ideas to pick and choose from to make this a reality. This should be a real technical tour-de-force if you can pull it off completely. Wish you well on your endeavour! Even if it can't match the best ones on C64, the A8 is definitely lacking in sophisticated scrolling shoot-em-ups and needs more!

  24. Posted

    i agreed up until there matey, the only version i thought was worth the cash was on the 32X and it's the reason i owned that mushroom-shaped thing in the first place. =-)

     

    snap! that's why my brother Nick and I got one too. It was the definitive version at the time, and it darn well should be given that they're running the original code! Before the 32X, the NEC PC Engine and Sharp X68000 ones were the pick of the bunch.

  25. Posted

    Space Harrier.

     

    I believe a port of this game was underway for the Atari 8-bit. See http://www.sheddyshack.co.uk/

     

    Was it ever done on the C64?

     

    Yes, it exists on C64 :

     

    but it has been developped in few month under time/commercial constraint. Now the XL Version is in development for years under no constraint...

     

    It's also a single, 64K load on the C64 whilst Sheddy's version is taking just a tad more memory... =-)

     

    It certainly isn't a fair comparison, and I wouldn't recommend rewriting it for the C64 either for comparison purposes. It'd be a huge amount of work. Art assets alone, if done properly, take more than 2000 frames since we can't scale in real time...

     

    It's a shame though. The C64 (and other computer) versions could have been so much better if Elite Systems hadn't been in such a rush to just cash in. I just remember being very disappointed at the time, even with the Amiga version: All their Space Harrier "conversions" give nothing more than a cut down flavour of a couple of stages of the original arcade game. Now I'm not saying that isn't a good idea given the sheer size of the original game, but with a disk version or multi-load it could have been a lot closer. The Japanese console versions were much better than any of the computer versions IMHO

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...