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

andym00

Members
 View Profile  See their activity

  • Content Count

    1,048

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by andym00

  1. Posted · Edited by andym00

    Just had a look at Slot Machine... ST could do it... of course only STE would be able to do the 16 lumas.

    You got a link to that ? I'm having a hard time with google search results for searches along the lines of Slot Machine Atari, not surprisingly ;)

     

    edit: All I can find are these two, and I'm guessing they're not what you meant, given the mention of 16 Lumas ?

    post-3913-1248775736_thumb.pngpost-3913-1248775751_thumb.png

  3. Posted

    Another source to consider would be the NES version that surfaced a few years ago, interesting given it's very weak sprite abilities and not being so hot in the bitmap manipulation stakes.. An interesting solution, and Andrew Davie in that thread also comments on how they handled the graphics, by splitting charsets on each line, and the charset containing everything that's need for that particular character line of the fighter..

    Anyway, food for thought..

     

    Here's the thread..

    http://www.atariage.com/forums/index.php?showtopic=87396

    And here's the youtube video of it in action.. Looks mightly impressive for the NES actually..

  5. Posted

    no post by me here? why did I missed this thread??? ;)

    Ummm....

    just back from taipei (computex) and just saw this which is very interesting... have to look more into the code... ;)

    :)

    But glad you nudged this thread up, I was looking for this particular one about software sprites but wasn't getting anywhere finding it..

  6. Posted

    Still not working with Vice 2.0. Or at least I hope it isn't Please tell me it isn't supposed to be flickering like that? including the colour splits on the side borders? I don't think Crest would produce something so ugly. I think if you're seeing flickering anywhere then it isn't working.
    Works okay in WinVice here but does flicker, though the flickering is never going to vanish, unless the emulation is properly synced to the monitor display rate.. This kind of stuff just doesn't look good on emulators at all unless you're at 60hz and running something NTSC based.. Unfortunely this isn't NTSC compatible and hadn't been NTSC fixed yet, if indeed there's even enough time left over from the display to run the music and scroller and handle the loading..

    But you knew this already of course ;)

  7. Posted

    The problem I had with Vice is the "Drive Error"... playing around with the settings helps but it sometimes does it again.

     

    I think my version of Vice is buggy... or something. The sound went completely earlier on and nothing's bringing it back.

     

    Make sure 'True Drive Emulation' is enabled..

  8. Posted

    Because its using sprites over chars on the c64 it's barely any cpu time. Smooth scroll the background gray chars, it's a repeating pattern so when it gets to the 8 pixel limit just push it back to 0 again, then move the sprites over the top, sprites 0-7 then when 1 sprite has gone off screen 1-7,0 (move 1st one to the right side) then 2-7,0-1. I don't think it's rotating through the sprites (something that most oldschool sprite scrollers did). If it was it would actually be easier to do the variable width stuff but it still isn't difficult.

     

    That last part doesn't work on vice or ccs64 :( I really wish I still had my C64 :( I think the scroller in the middle is just hires with some colour ram being changed to make a pattern, don't think it's using this new mode.

     

    Erm, it's the main scroller in the slide show that you & Rybags are talking about ? If so, that one's in the bottom border, so it's just $3fff (or whatever is appropriate) being set each scanline..

     

    The last part scroller, looks to me like just inverted text being scroller over in the center some x-expanded sprites, and then on the left and right edges, 2 x-expanded sprites overlaying on top to maskover the scroller, with maybe some colour ram shenanigans going on as well..

     

    The last part does work on vice, just seems to take a while to sort itself out for some reason...

     

    There's a lovely loading screen if you hit space to skip the pictures ;)

     

    As regards SID differences, I know of the differences in capacitors, but the frequency response of the 8580 is markedly different to that of the 6581, I mean way off, as is the resonance.. Of course there's differences between the same models as well, but that's not really stopped people using the filters ;)

    I'm just saying that the real difference is between the 6581 and 8580, and not just regards sample playback, which is easily cured by ensuring DC offsets are up in the chip close to something resembling the 6581..

    Plus there's the differences in combined waveforms as well ;)

  9. Posted

    I think it's supposed to sound "muffled" lol A lot of people use filters on purpose to create that effect, something that the C64 was good at but far too much difference between machines. You couldn't rely on a filter being the same on two C64s sitting next to each other.

     

    You can't but you can detect which SID revision you're running on very easily buy setting oscillator 3 to its maximum frequency.. setting the testbit to lock the oscillator, then select sawtooth and gate off and then read immediately with the next instruction (lda abs) from the oscillator output.. They start at slightly different sample values, 3 on the 6581, 2 on the 8580..

    Easy peasy ;)

  10. Posted · Edited by andym00

    Been a very long time for me too lol I can barely remember the C64 hardware registers.

     

    I can see what you're saying now (I think). Use a high priority sprite (say the last one), fill that with a hires mask, shove it behind the background and because its higher priority than the foreground sprites it will mask them? If that is what you mean then I'm pretty sure it doesn't work that way. The hardware draws the sprite thats been put in the background before the foreground and before the other sprites. It totally ignores it once it's been drawn so it wont effect the foreground sprites at all. I've just done a quick bit of code, 2 sprites, 1st one all FF 2nd 00 then FF, set them overlapping each other, filled the screen with C0 (dunno why I picked that but it's a reasonably solid character) then set the 2nd sprites priority to behind the background and that's where it goes, behind the background and behind the other sprite. All of that is with hires stuff. Not sure if it makes a difference if the background is MC or not.

     

    Highest priority sprite is 0 ;) Lowest is 7.. So you'd want to put sprite 0 behind the background, sprite 1 in front, and (if memory serves me right) it'll display foreground data where sprite 1 overlaps sprite 0..

     

    If I recall right it resolves sprites to sprite priority before sprite to foreground priority.. It's decided to draw the masked sprite, but then oops, it's behind the foreground, ergo (it appears) to cut a hole in sprite ;) Logically, the hardware simply takes the pixel for the first sprite it finds that has NZ data regardless of the foreground/background setting then resolves it against the screen pixel based upon the foreground/background setting for that sprite..

     

    It's a standard way of doing things on a fair few consoles for exactly this type of effect..

     

    I'll give it a go when I get home.. I just grabbed winvice, and trying the keyboard on my laptop is acting very weird when typing in WinVice..

  11. Posted

    Even IRQ is perfectly synched with the video using the 15Khz (scanline rate) or 1.78979Mhz color clock/2 rate.

    Okay, apologies for bringing this up again, but it's just been pointed out to me, that using the timers means you lose audio voices ? You kept that very very quiet in your sales pitch.. :roll:

     

    You want a 15Khz timer ? You lose one voice..

    You want your 1.79Mhz timer ? You lose two voices..

     

    Hmmm, interesting.. So you can have your cycle-exact interrupts, as long as..

    1. You're in bitmap mode, or have rolled your own bad-line free character mode..

    2. You're prepared to lose 2 voices..

    3. You WSYNC every line

    4. (IF) you use DLIs, they use the same cycles each time..

     

    OR

     

    You do exactly as the c64 does and de-jitter the interrupt manually and regain the use of the CPU during the frame when not servicing interrupts.. Suddenly life doesn't seem so bad on the 64 with regards to cycle-exact interrupts, in comparison to the trade-offs you glossed over..

  12. Posted

    You get the advantage of knowing exactly where the beam is after a WSYNC but no, it won't give you access to the middle of a badline. If you want to do a bunch of free-form mid-line stuff you're probably better off in a straight graphics mode.

     

    There are a few neat things you can do like extend the height of a char row using VSCROL so you have fewer (or no) badlines. You can dynamically change the character set pointer to make every line of the extended characters unique.

    I'm very familiar with the WSYNC stuff from my many years spent on the 2600 and also on the 7800 with DLIs and co ;)

    That's all I wanted from him, rather than the incomplete pictures that have been painted by him..

    And yeah, in bitmap modes you have way more freedom, of that I'm very envious and so are my interrupts ;)

     

    What was interesting to just find out was that on A8 you must write to WSYNC before cycle 100 ?? Does this mean that you lose the remaining 14 additional cycles, or would they have been consumed by other memory accesses anyway ?

  13. Posted

    Read the original message. DLIs/WSYNCs work in all modes. There's no unstable BA signals to worry about in any mode. Whatever DMA cycles there are, are well-defined. And if you need to make it more accurate, you can switch modes for the lines where you need the extra cycles. Atari wins in Horizontal kernels even with char mode; there's a lot more choices for Atari. There's no way you can tell me your software algorithm is better than hardware that's already perfectly in sync with video beam.

    No, you read, and properly this time and don't go mis-quoting me and making out I said things I didn't..

    I didn't dispute that DLIs or WSYNCs work in all modes.. You've just made that up..

    I didn't say there were unstable/undeterminisitic/subjective/random/pink/alien-generated 'BA signals' in any mode... You just made that up again..

     

    And of course you can switch modes where you want the cycles back, I didn't say you couldn't.. Ummm and for that matter, so can the 64.. Want a character screen with no badlines ? No problem, just abort the DMA on every 8th scanline, viola, no badlines and a display too boot[1]..

     

    The fact is that you're not portraying a clear picture here at all, willy-nilly deciding to leave out details of critical importance..

     

    As for your question of "software algorithm is better than hardware that's already perfectly in sync with video beam", it seems like you have similar restrictions to the 64 the real difference being just a faster processor to do shit with when it comes to monkeying around with registers on those scanlines..

     

    [1] Whereas Atariski would choose to leave it at that, there is the issue that doing that means the character matrix is repeated from the first fetch, as is the colour ram, so you have to change character sets every 8th line, but it does what it says on the tin.. A display with no badlines, and a display with stable/deterministic/objective/non-random/blue/hardware-generated 'BA signals'...

  14. Posted

    So all of your exact pixels are contained within those 33 cycles on an A8 badline ??? You're 100% sure about this ???

    Well, that's some pretty damn tiny screen you must have then...

     

    During the first char line you have interleaved char fetches and 1st line gfx fetches which shut down all CPU activity during the active part of the line. The remaining cycles are in the off-screen area (porches).

     

    So a very tiny, and invisible window :)

    That's all I was trying to get him to come clean with.. His claim that:

    "you can sync up IRQ on exact pixel in char mode."
    is not entirely truthful, again..

     

    It should really say like the c64, we have to write off the idea of doing any cycle exact interrupts on a badline.. Instead of making it sound like it can interrupt anywhere, anytime with exact cycle accuracy..

     

    And I guess this also rather blows the idea of doing any of the much talked horizontal colour changes, mode changes, sprite plexing and other fancy shenangians in character modes since it'll look a bit poor not being able to do anything on every 8th line.. I'm sure you could work some design into it, but I'm just being baffled with all this talk of what you can do, but then it turns out it's not quite as Atariski, Emkay and Co. make out or there's some fairly large restrictions that someones deliberately forgotten to mention..

  15. Posted

    I'm not sure how they do it currently on c64 but I don't think there would be enough sprites on A8 to do it by copying a mask from the background data into a sprite. Also then what colour will it be? you can't overlay a sprite over another one to mask it unless its got data in it and even on the C64 you're limited to colours per sprite (1 background, 1 unique and 2 the same over all sprites) so your sprites would have to have the same colours as the background.

     

    I'm actually a bit confused about your explanation of putting sprites behind the background and them masking the foreground and err you lost me ;)

     

    C64 you can set the sprite priority to either foreground or background but even in background mode they still show through pixels with the high bit of the colour index nibble cleared. ie colours 0 and 1 sprites appear over, 2 and 3 they appear behind. It can be useful, it can be a right pain in the arse.

     

    I recall the stupid priority problem, but I don't believe they apply here with hires sprites.. Maybe I'm wrong, it's been a long long time...

     

    And anyway, even if it wasn't correct the colour data doesn't matter in the hidden sprite because you'll never see it, because it's covered by the foreground.. You only put bit patterns into the masking sprite (just a simple lookup table to translate as you copy bitmap data into sprite, or even have a mask for it if memory allows) that will remain hidden because the colour information doesn't matter because you will never see it, only the fact that it has a pixel there that isn't transparent is what matters..

    But anyway, in hires sprites I didn't think this was a problem.. I never tried it with multicolour screens, only with hires stuff, and maybe I'm a bit rusty on how it works now.. I should go check really, just for my own sanity...

     

    And on the A8, if you only used two players for the LN, then you could use in expanded one underneath to mask with, since the foreground is lores anyway.. But I'm not properly familiar with A8s player setup, so maybe it's not feasible..

  16. Posted

    Your interrupts have to be stabilized with software; it's not in hardware. I can also do software sprites. You are misrepresenting things. Get a life. We already argued this already. Perhaps, you didn't read the reply.

    You can sync up IRQ on exact pixel in char mode.

    Really now.. You're just saying things now in the hope that no-one will contradict you because they're tired of you, well think again..

     

    Sorry to quote Rybags on this, but...

    Atari = 114 cycles per line. "Badline" = 81 cycles lost, 33 free, other lines = 49 lost, 65 free (50/64 or 52/62 for Dlist fetches)

    C64 = 65 cycles per line. "Badline" = 40 lost, 25 free, other lines = 65 free

    So all of your exact pixels are contained within those 33 cycles on an A8 badline ??? You're 100% sure about this ???

    Well, that's some pretty damn tiny screen you must have then...

     

    That's not even to broach the old subject of 'yes, we can do that too!!' regards getting synced up nicely.. So you burn some cycles wasting with your WSYNC, and (what a surprise) so do we burn a few cycles syncing up.. I mean really, surely you should be counting your cycles and not even relying on WSYNC that like real VCS programmers do ;) Smacks as just plain lazy, and not pushing the hardware anyway..

  17. Posted · Edited by andym00

    Stupid question, but on the A8, can you use the player to player priorities and player to background priorities to cutout automagically the foreground from the player ?

    I mean on the 64, if you place a higher priority sprite under the background it will cut out the foreground of lower priority sprites in front of the foreground, and display only the background where the 2 sprites overlap..

    I've no idea how LN does it for real, but I've always guessed it was like that, since all you have to do is find the overlapping masked objects, and transfer it into a sprite, and since you can just use a single x-expanded hires sprite (since the forground is lo-res anyway) to cover 6 characters worth of width there's very little moving of memory required, and certainly no arsing about with painfully slow masking of sprites..

     

    And secondly, if anyone is seriously considering LN on the A8, I think the way to go is building a display kernel as you construct the screen.. Just write off the entire display cycle-wise, and build a screen of code in memory that changes whatever needs to be changed at exactly the right time, bitmap mode of course.. If you're prepared to burn the screen time entirely that is.. I'm sure you could do a better job than G2F does of this given you have so much more information available to you as you're building the screen.. I don't mean like E***** spectrum screens with rectangles of colour.. I mean that given the angles presented, I think with single cycle adjustments you could pretty much form the basic colour requirements of the screen..

     

    Granted it's going to cost a bit more drawing-wise, but then the A8s CPU is like a Cray-1 compared to the poor wee c64 ;)

     

    If you really are considering a proper port of it, then it might be worth tracking down and getting hold of John Wells.. He did a prototype of LN4 for System 3 that never got off the ground, and I know for a fact that he has given the existing code to someone in the 64 world with the intention of completing[1] it..

     

    Your guess is as good as mine as too whether or not that will ever happen, but I just thought I'd mention it..

     

    Anyway...

     

    [1] I say completing it, because it only has a single level from LN2 (I think it's LN2 anyway) in it, but it is a new engine, that even allows you too walk in the grass!!!!! ;)

  19. Posted · Edited by andym00

    As far as horizontal kernels, Atari obviously wins there as it can sync up without having to deal with non-deterministic BA signals thus lowering the software burden. And DLIs/WSYNCs are not Atari tricks-- they were purposely put in hardware so colors/sprites can be changed on scanline basis.

    Even IRQ is perfectly synched with the video using the 15Khz (scanline rate) or 1.78979Mhz color clock/2 rate.

     

    Firstly, so what do you think a Raster interrupt is synced to then ? Bored cats ?

    Secondly, what on earth do you think the timer interrupt clock source is from ? Sleepy donkeys ?

     

    And we won't even touch on the fact that you've glossed over (some would say wholly misrepresented) the fact that your syncing argument, with regards to you implying useful horizontal changes being made during the display of a single scanline, are applicable in bitmap mode only, not in character mode from what I recall in this thread..

  23. Posted · Edited by andym00

    There was Blaster, an unreleased shooter for the Atari 8-bits that got turned into a very limited release arcade game by Williams. Details at http://www.atarimania.com/detail_soft.php?...ERSION_ID=11544. It's not greyscale, though.

     

    I'm familiar with Blaster and that's not what I was thinking of..

     

    Perhaps a better way to describe it might be more akin to Ant Attacks blocky style of graphics, but with a first person view..

    I will find this thing somehow...

  24. Posted · Edited by andym00

    Because Commodore has all these hardware tricks, does it make the system better then atari...and visa versa

    ...

    If a hardware trick on Atari or C64 works consistently then it's as good as a feature. If it causes system to become unstable or locks up some machines, I don't consider it worth much.

     

    >Untill then i'm off to play with my a1200 enhanced 1tb HD upgraded 256mbyte p/s 256bit cpu with 128 gig of memory sinclair spectrum x 256 (I'm using version 1a at the mo, Sir Clive is working with the 'god' of hardware design , one Mr Miner on creating version 2...and it plays a mean game of SR)

     

    Too many acronyms-- what's SR and a1200?

     

    A1200 is an Amiga, no idea what game SR is when it's at home.. The only game I recall that fits the bill could be Space Rogue ;)

     

    Oh, and PeteD (or should I say JCB :) ), I like your ideas and too some degree agree with you on Enforcer 2, but I do still think E2 is a lovely bit of code, even though it looks on the surface fairly straight forward given the 64s hardware.. I'd be happily alongside you with doing something like that on the A8s, but the thought of learning the ins and outs of *yet* another 8bit machine fills me with dread, if only from what the missus would say ;)

     

    It's good to see you're still alive and have still got the 8bit bug, and are here :)

  25. Posted

    The thread in the 8bit programming forum triggered my mind about some '3d' shooter on the 8bit Ataris..

    It was presented as a view into the screen with blocky greyscale colours, but was done in some 'voxelesque' style... Quite low resolution, but looked very nice indeed..

    It kind of reminded me of Zaxxon, but with a 1st person view of the level..

    I can't for the life of me remember the name, and no amount of googling is getting me anywhere today, and searching atariage isn't yielding any results, though I'm sure I heard about it here some years back..

    It's annoying, I want to know if it's really as good as my memory is painting it for me...

    Plus, I'll go mad if I don't remember..

    Please save my sanity :)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...