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

  2. Posted

    What was meant by 'others C64 30 seconds conversion'? Are these Amiga->C64 that other people have done or quick conversions from C64->A8, I'm not seeing the point here? Granted that for RPG's and Adventures I have no problem that there is typically more processing time available for such an engine. Still I'd have reservations, e.g. in the castle gate picture is there a (mouse) cursor movable over all areas whilst retaining its colours and not affecting the background?

    Those pictures are just a normal 320x200 16 colour screens (one foreground colour, one background colour per 8x8 cell (Spectrum mode)).. Underneath the Hires screen there are 7 x-expanded 3 colour sprites, multiplexed down the screen.. This gives a 80x200 (actually 84x200) 3 colour underlay over the entire screen.. You only need 7 sprites since they'll cover 336 pixels in x-expanded mode.. The only cpu overhead is 9 interrupts down the screen to reload sprite pointers.. There's no colour reloading, no other effects apart from just repositioning the sprites vertically and changing sprite pointers (9 times per frame, every 21 scanlines)..

    So yes, there's a sprite left over for a cursor, and pretty much all of the cpu remaining as well..

  3. Posted

    By "bitmap", I mean character set data.

     

    The "cycle loss" is similar on the C-64... it's just that it's CPU runs at half the bus speed, so most of it is transparent.

    But even with that taken into account..

    A quick calculation (of a 320x200 screen) gives me...

    25 badlines = 25 * 23 (23 cpu cycles remaining per BL)..

    175 normal lines = 175 * 65

    112 blanked lines = 112 * 65

    So we get ~19230 cycles per frames..

     

    With A8 if I've got this right.. These 'badlines' happen (usually) every 8 lines I guess ?

    25 'badlines' = 25 * 32

    175 normal lines = 175 * 65

    112 blanked lines = 112 * 114

    so ~24943 cycles per frame..

     

    It had never dawned on me that there was such little difference between the two platforms cpu-wise..

    Anyway, I'm waffling now.....

     

    Is there a difference in consumed cycles between character modes and bitmap modes on the A8 ?

     

    And is there a document for the A8s like the infamous Vic-Article https://sh.scs-trc.net/vic/ that describes the memory accesses of the system ?? Preferably something along the lines of 3.6.3. TIMING OF A RASTER LINE. ?

  4. Posted

    By "bitmap", I mean character set data.

     

    The "cycle loss" is similar on the C-64... it's just that it's CPU runs at half the bus speed, so most of it is transparent.

     

    It dawned on me about this just after posting that :) But I hadn't clicked that you lose so much of the CPU to the display still, I was always imagining you had far more cycles per scanline to play with.. No I'm even more curious about the ability to sensibly and usefully horizontally split sprites given your remaining cycles, and the overhead of any interrupts you'd be throwing around.. Though I suppose you'd abandon DLIs and go with a fixed display kernel as with a 2600 ??

    I've been toying with this on the 64, but with sprites not being guaranteed to be enabled on some lines (and no really practical way to make this happen in a useful way within the context of a multiplexor) it makes the timing far too complex to even contemplate, but I guess the timing is far more stable on the A8 given player fetches and other memory fetches will be constant over the screen..

    I'm really fascinated by this 23 colour approach, but even after some of the wacky platforms I've programmed for over the last 30 years, I'm not sure I even want to go near that in a game scenario, let alone try to build sensible tools to work with it..

  5. Posted

    A8 does have "badlines" but you're only losing 33 cycles or so compared to a normal line in most cases.

     

    e.g. Badline you have 1 DList, 40 code, 40 bitmap, 1 Refresh cycle steals = 82 taken, 32 left for CPU

    Next line you have 40 bitmap, 9 Refresh = 49 taken, 65 left for CPU

     

    In the case of 9 Refresh per line (most), they occur from just before normal visible window until about halfway, every 4th cycle.

    In the case of only 1 Refresh cycle, it occurs just after the visible screen window.

     

    Wow, that's interesting to know.. I had no idea the A8 lost cycles quite as much.. But I guess that's down to the flexibility of the display, and I had no idea you were having bitmap accesses per scanline.. I've been spoilt by the VIC I guess ;)

    I really must get my arse in gear sometime and do some A8 programming :)

  6. Posted · Edited by andym00

    But they are taller on both systems-- makes it easier to multiplex vertically.

     

    In many games pillars were used to add another layer to the parallax scrolling effect.

    just two pokes for the whole image and the effect is there... on the C64 it cost addition cpu time everywhere the sprites got reused.

     

    Some additional GPRIOR settings will add many more visuals for a grat parallax effect.

     

    You're wrong here.. For example.. Lets use 3 players to give you same width as a c64 sprite..

    You use 3 players full screen height, you have to reload 200 lines of data..

    That's going to be (best case assuming lda#imm sta abs pairs) 6 * 200 * 3 cycles.. So just for loading the sprites images you've burnt 3600 cycles (more realistically 6000 assuming indexed loading and storing)..

    There's no doubt the cost of the video chip reading from memory as well, so that'll (i guess) add more cycles to your cost.. I guess 1 or 2 cycles per scanline, per enabled player ?

     

    And since the c64 has pointers for each sprites we don't move any data, so the 64 consumes (worst case) 5 * 200 cycles (best case) 2 * 200 (For a single one off sprite.. There's DMA startup costs if the displayed sprites are not contiguous)..

    So where's the competition ??? 64 has to reposition sprites and change colours with an interrupt, but then again so do you.. I can't see any advantage at all to what you're saying.. In fact the 64 comes out of this way way way better off..

     

    If we go into the cost for using all 8 sprites, split all the way down the screen, we're looking at

    200 * (3 + (2 * 8)) cycles, so we burn 3800 cycles for having the sprites re-used completely over the screen height..

     

    So we can have all 8 sprites (covering 192 pixels hires), re-used full screen height for the same cost of you having covered 24 pixels (and that was a very generous cycle count for that!)..

     

    No competition emkay, sorry... You still have to have your splits like us, you still have to sort stuff, you're in the same barrel when it comes to this, but having achieved far less in terms of screen sprite coverage for the same cost..

     

    Edit: I kind of got a bit confused with Emkays posts about the parallax use and a general purpose sprite approach from something earlier I wanted to reply to, but the point still stands about comparison.. I realise for his parallax idea mentioned, that no re-loading is required..

  7. Posted · Edited by andym00

    btw. Why when C64 users shows real pictures, Atari users: only famous listing "23 colors per scanline" ;) or fake pictures. We strongly need gfx conventer to show Atari real power. Conventer with computer placed sprites, computer dli, computer rasters. G2f is nice but everything is manual, sometimes very unfriendly, very hard like rasters.

    Sorry, but this still misses the point.

     

    It is all well and good using a PC or MAC's power to analyze a picture and produce the most optimal implementation of this on the A8 but that same program doesn't know which areas are (or will be) software/hardware sprites in an actual port/conversion of the game and mostly, when this is taken into consideration, you'll find that the game engine required to support it all will impact greatly on the special display code produced by the gfx converter you describe.

     

    Perhaps an engine such as this shows promise... Two Moons and One Sun?

     

    I don't agree with you. :P

    First: In some games like adventures, rpg, others static screens games (like Elvira - see at bottom) , this converter would be very useful. And also to show what atari can do in gfx. C64 user in 30 seconds can convert any picture. On Atari this takes days and will never be like from convert-program. Easy to write: "look Atari can 23 colors in scanline..." and show only listing or "But the tree is red, not brown, while on the A8 were more colours possible" and show fake image (with in fact RGB colors - not Atari colors and 1x1 pixels btw. For me always red tree is better then NOTHING :) ) - but really hard to prove this and show truly great image. Computers invents to relieve us from very complex work. On AtariGfx there is no more complicated things then correct placed sprites, priorites, rasters (look in g2f - this is paint tool or assembly code ?)

     

    Second: Imagine this: there is engine which allows you to place sprites on screen - in realtime on 8bit Atari. And this engine is very fast because it is only add-on to zx spectrum emulator and this emulator takes the most cpu time.

    Look here: http://tiny.pl/36v2 (original in polish, translated via google)

    When you looked on pictures maybe you think - not good - but this engine has a big potential. I ask author, great Atari Coder ;) - Mono - about PC version, he answer: Can be done and without Atari cpu limits, on PC can be check every possible sprites, colors combination, and other resolutions like 2x1 pixel - and in effect more accurate conversion.

     

    Third: G2Font is very good gfx program but i know much better like Grafx2 or Cosmigo Pro Motion. Of course in this programs you can't save files in Atari formats - but when we have a converter, then we can paint in any program, final picture convert to *.g2f file and retouch and correct minor conversion errors. Overall, much easier way to produce pictures to games, demos instead fake pictures or famous "23 colors listing". Much easier way to show C64 user why Atari is better in gfx. :D

     

    ------

    - sorry for my poor english.

    - i am Atari user since 1986 and never bought C64

    - others C64 30 seconds conversion:

    elvira.png

     

    utopia.png

     

    Interesting point, BUT there is nothing stopping the C64 remake of such classic adventure games as The Pawn and The Guild of Thieves on the C64 using trick screenmodes likes MCI IFLI HIFLI etc etc. In which case the graphics would look pretty much identical to the ST/Amiga graphics given you only need a few extra hues of a few colours for that 16 colour artwork :)

     

    If I'm correct, that's MUCSU-Hires (MUltiColor Sprite Underlay Hires) which is about the simplest method available for nicer modes.. Just 9 sprite-splits per frame and pointer changes and bugger all CPU useage.. But still only shares a common 3 colours under the bitmap.. I'd like to see this with more vertical colour splits if Algorithm ever released the source code, or added such a mode..

     

    Here's the tool if anyones interested ;)

    http://noname.c64.org/csdb/release/?id=76055

     

    I've actually been toying with this mode recently, and investigating doing software sprites on this mode, plotting both HiRes data and the expanded underlays, but it's getting mind bogglingly complicated and am close to canning it and reverting to a basic Hires screen mode, and then letting objects use sprite underlays on demand, rather than assuming we can underlay the entire screen.. But then we've got enough sprite coverage to do so without any fancy trickery, so it remains a very very low cpu overhead approach..

     

    And it's interesting to know that the A8 suffers from 'badlines' too.. It had been kept very quiet here that you only get 30 odd cycles on those lines (maybe it had been mentioned, but I missed it in this snowstorm of a thread), and with that simple fact a lot of your argument for horizontal re-use goes out of the window I'd imagine..

     

    How come the A8 loses so much to memory refresh in one go ? And where about on the scanline does it occur ? And is there anyway to delay it ?

  12. Posted · Edited by andym00

    The hardware doesn't change (it's the same C64 and A8 as it was in 1980s). Your software technique uses up CPU resources and timing to achieve higher bit depth. You have to distinguish that from hardware support for 4 DACs vs. 1 DAC on the SID. Keep software techniques separate from hardware.

     

    Okay, seriously apologies for getting you mixed up with someone else regards the EGs.. I just lost track of who said what in here again..

     

    Regards the DACs.. Of course the hardware doesn't change, but the discovery that the output stages will hold the last outputted waveform value for a short period of time once the voice has it's waveforms disabled does make a big difference to what's capable ;) So, it takes for 4 STAs to output a true 8bit sample instead of 1 STA.. Doesn't mean it's to be discounted..

     

    I highly doubt it's just 4 STAs to get a TRUE 8-bit sample. I would need to see some proof. Your envelope generators are limited to millisecond accuracy not microseconds so getting a true 8-bit sample beyond 1Khz would require some cycle-exact coding and even then the delays between register writes to simulate the 8-bit sample would not make it a true 8-bit sample playback like an 8-bit DAC does.

    It works not using the EGs.. It works because even with no waveform selected programming a frequency will still let the internal phase accumulators run..

    Setting the 'Test' bit on a voice reset the internal phase accumulators to 0..

     

    So you disable all waveforms on the voice, set your frequency, then wait (typically 126 cycles) 2 scanlines or so..

    When you next return to the interrupt the phase accumulator will have reached the desired value, set by the frequency..

    You then momentarily enable the triangle waveform (sawtooth if you want it louder) then disable it, leaving the current output of the waveform held in the voices outputs for a short time..

    You then set your new frequency (sample value) and reset the voice phase accumulators and let it run (though with no waveform selected) by clearing the test bit..

     

    So your code to play one sample is this.. And clearly we're assuming this is being driven this from some stable interrupt source... And step 1 is actually the part where you latch the previously selected output value from the prior interrupt..

     

    ; Step 1	Start playing a sample (enable saw/triangle)
lda #$11
sta $d412
; Step 2 & 3	Sustain the current DAC level (disable saw/triangle output) - Reset phase accu (set test bit)
lda #$09
sta $d412
; Step 4	Set the frequency of the oscillator to the sample level we wish to seek
lda $1000
sta $d40f		
; Step 5	Start seeking (clear test bit) and wait...
lda #$01
sta $d412

     

    You rely upon the fact that a SID voice at it's highest frequency $ffff still takes 256 cycles to wrap.. Clearly with ~8Khz sample rate and using a triangle waveform you will only reach half the peak output level voltage, but by using a sawtooth you can circumvent this.. So obviously as the sample rate gets higher you also limit the maximum output voltage that is going to be generated..

    The waveforms held output level is then fed through the EGs, and through the filters like any other signal generated internally by the voice hardware.. Even the Ring Modulation will 'work', and the sync too though the results are going to be mildly comical ;)

     

    All you're doing is altering the slope of the waveform over a set number of cycles, momentarily enabling its output, then disabling it so it's held on its output for a few thousand cycles (though a new will be set in 126 cycles, typically), then programming in a new rate and then clearing the test bit to let the voices phase accumulator run again..

     

    Clearly there's issues with the non-linearity of the C64 output DACs, but that's something that can be worked around..

    ...

    Sounds like it's highly CPU driven not just a few LDA/STAs. The timing requires that you use a kernel and your sampling rate is related to the number of levels you can get and is an approximation of 256 levels. By having hardware DACs, you have more flexibility. The only full throttle true DAC on SID useable by software is at 54296 and it's 4-bits.

     

    >If you really want the nitty gritty details, read the article in Vandalism News #50 where SoundDemons article on this was first presented, in addition to another way of doing it.. It a fascinating discovery, especially the concept of the SID voice holding the last outputted value..

     

    Okay, I'll look at it if you give the link.

     

    Edit: No hard feelings man, I think you know your shit, and if you stop and think about what's been discussed here you might actually realise this could *possibly* benefit the pokey cause as well if you only stop knee-jerking and stop and spend time looking at what your chip is doing under the bonnet..

    You've obviously chosen to blinker yourself on this subject and so be it,,

    Goodnight..

  13. Posted · Edited by andym00

    The hardware doesn't change (it's the same C64 and A8 as it was in 1980s). Your software technique uses up CPU resources and timing to achieve higher bit depth. You have to distinguish that from hardware support for 4 DACs vs. 1 DAC on the SID. Keep software techniques separate from hardware.

     

    Okay, seriously apologies for getting you mixed up with someone else regards the EGs.. I just lost track of who said what in here again..

     

    Regards the DACs.. Of course the hardware doesn't change, but the discovery that the output stages will hold the last outputted waveform value for a short period of time once the voice has it's waveforms disabled does make a big difference to what's capable ;) So, it takes for 4 STAs to output a true 8bit sample instead of 1 STA.. Doesn't mean it's to be discounted..

     

    I highly doubt it's just 4 STAs to get a TRUE 8-bit sample. I would need to see some proof. Your envelope generators are limited to millisecond accuracy not microseconds so getting a true 8-bit sample beyond 1Khz would require some cycle-exact coding and even then the delays between register writes to simulate the 8-bit sample would not make it a true 8-bit sample playback like an 8-bit DAC does.

    It works not using the EGs.. It works because even with no waveform selected programming a frequency will still let the internal phase accumulators run..

    Setting the 'Test' bit on a voice reset the internal phase accumulators to 0..

     

    So you disable all waveforms on the voice, set your frequency, then wait (typically 126 cycles) 2 scanlines or so..

    When you next return to the interrupt the phase accumulator will have reached the desired value, set by the frequency..

    You then momentarily enable the triangle waveform (sawtooth if you want it louder) then disable it, leaving the current output of the waveform held in the voices outputs for a short time..

    You then set your new frequency (sample value) and reset the voice phase accumulators and let it run (though with no waveform selected) by clearing the test bit..

     

    So your code to play one sample is this.. And clearly we're assuming this is being driven this from some stable interrupt source... And step 1 is actually the part where you latch the previously selected output value from the prior interrupt..

     

    ; Step 1	Start playing a sample (enable saw/triangle)
lda #$11
sta $d412
; Step 2 & 3	Sustain the current DAC level (disable saw/triangle output) - Reset phase accu (set test bit)
lda #$09
sta $d412
; Step 4	Set the frequency of the oscillator to the sample level we wish to seek
lda $1000
sta $d40f		
; Step 5	Start seeking (clear test bit) and wait...
lda #$01
sta $d412

     

    You rely upon the fact that a SID voice at it's highest frequency $ffff still takes 256 cycles to wrap.. Clearly with ~8Khz sample rate and using a triangle waveform you will only reach half the peak output level voltage, but by using a sawtooth you can circumvent this.. So obviously as the sample rate gets higher you also limit the maximum output voltage that is going to be generated..

    The waveforms held output level is then fed through the EGs, and through the filters like any other signal generated internally by the voice hardware.. Even the Ring Modulation will 'work', and the sync too though the results are going to be mildly comical ;)

     

    All you're doing is altering the slope of the waveform over a set number of cycles, momentarily enabling its output, then disabling it so it's held on its output for a few thousand cycles (though a new will be set in 126 cycles, typically), then programming in a new rate and then clearing the test bit to let the voices phase accumulator run again..

     

    Clearly there's issues with the non-linearity of the C64 output DACs, but that's something that can be worked around..

     

    If you really want the nitty gritty details, read the article in Vandalism News #50 where SoundDemons article on this was first presented, in addition to another way of doing it.. It a fascinating discovery, especially the concept of the SID voice holding the last outputted value..

  14. Posted · Edited by andym00

    I for one have had my interest in SID rejuvenated by this techinque.. And all kudos to SoundDemon for figuring it out :)

     

    They still sound like SID and sometimes with bad samples ;)

     

    Have a look at this thread.... POKEY changes it's face by using different programming techniques.

     

    http://www.atariage.com/forums/index.php?s...&hl=complex

     

     

    I'd say: In sounding variations, POKEY beats all soundchip that were built into early 80s 8 bit computers.

     

    Changes its face by using 2 POKEYs you mean ;)

    Anyway, I'm not here to argue to point of which is better.. Just popped in to set the record straight on 2 (false) points that had been thrown into the arena and left unchallenged.. That's all..

     

    You are arguing inconsistently. If you claim multiple DACs (and higher bit depth) can be done with software techniques on SID then don't argue against POKEY doing ADSR with software. Atari can also do software techniques. And I never stated which is the better chip-- just stated that it depends on what you want to do. One thing is for sure though-- you cannot simulate the higher frequency playback on multiple POKEY DACs using software techniques on C64's SID given the CPU limitations. Let's see the 8-bit playback routine so we can see the amount of CPU overhead involved.

     

    The cost per sample is 3 LDA immediates, one LDA absolute, 4 STA absolute.. This being the cost of loading the sample and setting the DAC output.. It doesn't include any other address handling, interrupt overheads etc..

     

    Okay so more than 1 LDA & 1 STA that you probably incur on the POKEY (I'm not 100% how you write to your DACs but I can imagine)..

     

    And it uses only one voice for one 8 bit channel, so we can have 3 8 bit voices running..

    And it's not the god'awful PWM technique either!!

  15. Posted

    The hardware doesn't change (it's the same C64 and A8 as it was in 1980s). Your software technique uses up CPU resources and timing to achieve higher bit depth. You have to distinguish that from hardware support for 4 DACs vs. 1 DAC on the SID. Keep software techniques separate from hardware.

     

    Okay, seriously apologies for getting you mixed up with someone else regards the EGs.. I just lost track of who said what in here again..

     

    Regards the DACs.. Of course the hardware doesn't change, but the discovery that the output stages will hold the last outputted waveform value for a short period of time once the voice has it's waveforms disabled does make a big difference to what's capable ;) So, it takes for 4 STAs to output a true 8bit sample instead of 1 STA.. Doesn't mean it's to be discounted..

  16. Posted

    Strange thing is that POKEY here is blamed for sounding the same all the time but personally I always thought and think that POKEY has far more variable sound than SID and that SID music sounds all the same way cause of the ugly grating "filter". Sure there are some really nice songs on SID but generally I don't like the sounds. It looks to me that you can hear like 5 different music on SID and you already heard everything what is SID capable of. On other side POKEY has more pleasant sounding and there is more variability in sounds and I'm suprised again and again what it can produce what I didn't heard before. Just my opinion. Don't take it too seriously because I'm musically deaf really deaf but I like what I like.

     

    The reason why I prefer the SID is simply that I'm not into music that try to jam an entire 10 piece band into 3 voices and just end up sounding confused, and then needing you to forgive them for trying.. Kind of like (wanky) graphics modes with missing lines and things and flickering and artifacts.. I don't want to have to stand 10ft away and squint to see something that looks like a picture of ALF or something.. I want something that doesn't have to be forgiven because it tries so hard to be something it's not and doesn't quite succeed..

     

    I want to enjoy the sound for what it is without having to forgive its flaws, and for me that's stuff that combines expression and movement within the sounds themselves.. Something I think the SID does better through its frequency control, filter control, pulse width control, resonance and Envelope Generators.. I think when used like that it does a stunning job and providing a complex and highly unique (within computer sound chips) sound experience.. Without having to stand 10ft away and squint your ears ;)

  17. Posted

    I for one have had my interest in SID rejuvenated by this techinque.. And all kudos to SoundDemon for figuring it out :)

     

    They still sound like SID and sometimes with bad samples ;)

     

    Have a look at this thread.... POKEY changes it's face by using different programming techniques.

     

    http://www.atariage.com/forums/index.php?s...&hl=complex

     

     

    I'd say: In sounding variations, POKEY beats all soundchip that were built into early 80s 8 bit computers.

     

    Changes its face by using 2 POKEYs you mean ;)

    Anyway, I'm not here to argue to point of which is better.. Just popped in to set the record straight on 2 (false) points that had been thrown into the arena and left unchallenged.. That's all..

  18. Posted

    You can't really draw a conclusion based on listening to a few music samples on each machine especially if the music samples are not the same music on both machines. Sometimes, you like the music and that makes you like the hardware. I guess you need a more controlled experiment where you isolate the audio so it's only the hardware making the difference. I never argued just number of voices would make the difference between which audio hardware is superior, but there are other features of POKEY like 4 DACs that can be played at higher sampling rates and using multiple frequencies which would be undoable on C64 at same quality.

     

    Your repeated claims that the Pokey has ADSR (albeit via software implementations) is utter claptrap.. Of course you can change the level of a voice, but not as rapidly as it's possible with hardware, and since the changing levels of the envelope generator over time produce an amplitude modulation of the source waveform you're potentially creating harmonically more interesting timbres during times of rapid envelope activity.. I mean with it's highest attack rate of 2ms, you're looking at needing a software EG update rate of ~4K just to match that if you want to generate the harmoniclly equivalent high rate change portions, and you know that not happening ;)

     

    Either way, that aside, you might as well say that a spectrum has sprites because it can draw them in software.. C'mon man.. Get a grip :)

     

    Anyway, just listen to Jeroen Tels winning SID tune from X2008 for a very good example of how those 'real' EGs make a difference..

    http://noname.c64.org/csdb/release/?id=72564

    Plus, there's a lot of other stuff here that I believe that POKEY would have a very hard time with..

    My own personal view is that whilst I love a lot of the POKEY stuff, it's very samey to me, and there's not a lot of movement with the sounds themselves.. Just my 0.02Euros worth on this..

     

    Secondly the DAC issue.. Not true at all, at least not now.. A new (and I have to say very novel) technique surfaced which allows 8 bit sample playback on each SID voice.. Plus, with the ability for it to be routed through the (hardware) EGs and through the filters is (I think) one of the biggest break throughs for SID in the last few years.. It's a fairly simple method, and hopefully more and more use of this will, and potentially offers 12bit playback..

     

    There's 2 examples of this method..

    First, a straight forward music piece..

    http://noname.c64.org/csdb/release/?id=72563

     

    Secondly the Demo 'Vicious Sid' demonstrating this technique.. Sadly with some Amiga Mods..

    http://noname.c64.org/csdb/release/?id=72678

     

    I don't think either of these pieces really do the technique justice yet, but I think more will come as people get to grips with the techniques required and good and better support for this technique of sample playback are thought about..

     

    I for one have had my interest in SID rejuvenated by this techinque.. And all kudos to SoundDemon for figuring it out :)

  19. Posted

    Regards the 64s hardware collision being all but useless, yeah mostly that's true, but it does have some uses, especially when it comes to generating interrupts from sprite to sprite, or sprite to graphics collisions.. A one pixel sprite being used to generate positional interrupts when it 'collides' were handy sometimes, and were useful when people were fathoming out what the VIC-II was up to under it's borders because you can essentially sample the screen output from it..

    Granted the positional stuff can be done other ways, but it's just one of the uses for it and something in it's arsenal for a rainy day ;)

     

    And no doubt in the very early days, having the collision detection was useful for people writing stuff in basic and learning the machine without having to overtly worry about how things like collision might work.. I for one used it in my earliest things I wrote when learning the C64 way back in the days..

    Granted for a modern game it's toss, but in the first generation of C64 games (the really early ones!) I suspect it saw a lot of use, even with it's flaws ;)

  22. Posted

    Came across this when looking through the MOS Wiki entry...

     

    http://homepage.mac.com/jorgechamorro/a2th...agic/index.html

     

    Is this actually feasible ? Reading it seems to make sense to me, and the amount of memory it could potentially shift seems not to be sniffed at..

    Clearly it's a bit late for it to be of any practical use on systems, but I'm just curious if this is viable, and if so, why it was never implemented back in the days or even used in some 6502 variant as some built in background-DMA device..

     

    Just curious :)

  23. Posted

    Sure you can do it on the 2600 if you dont mind graphics like the Crypts of Chaos! Yikes!

     

    Uhuh.. As usual, the repsonse to the grandmaster (perhaps we should just skip the shit and refer to you as Carmack Jr.) is that, you don't have the fucking foggiest what you're talking about..

     

    Well that's my offical diagnoses right now....

     

    Seeing as I can't for the life of me figure out your dmage over this now, perhaps you should stop picking

    fights with people and actually dispute me with something a little more logical than just name calling. I

    know....it would be a first but you should try it. You wont come across like an utter jerk.

     

    ok.. explain to me how you imagine you would shovel X amount of external data over a 2600 bus and render anything reselmbling a normal display ? I expect cycle count acccute results here..

     

    Really man, you can only go so far before someone calls your bluff..

  24. Posted · Edited by andym00

    Sure you can do it on the 2600 if you dont mind graphics like the Crypts of Chaos! Yikes!

     

    Uhuh.. As usual, the repsonse to the grandmaster (perhaps we should just skip the shit and refer to you as Carmack Jr.) is that, you don't have the fucking foggiest what you're talking about..

     

    Well that's my offical diagnoses right now....

  25. Posted

    Let me just add the following......I , being a HUGE 7800 fan do appreciate your work on it.

    I would never come into the 7800 forum badmouthing you work or commenting on it as

    if I co-wrote it. If this was NOT your intention with me, then fine, however that is not how it

    has come across a couple of times. Im not your enemy....really

    I didn't come into the Jaguar world badmouthing anybody or commenting on it as if I co-wrote it.. Absolutely not.. You've read that into it for whatever reasons, and I'd like to suggest we just drop this now, as it's ultimately a fruitless pastime..

     

    Perhaps an olive branch......

    Consider the olive branch reciprocated ;)

     

    I for one would love to trade my Jag knowledge for your 7800 knowledge.

     

    My point is I think we have more to offer each other than not.

    Ditto..

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...