andym00

Okay okay, the choice of saying 'the only one' maybe wasn't the best first choice.. I've read most of this thread over it's life, and I've ignored most of the clearly wrong stuff because it wasn't being picked up on, or simply wasn't relevant, or simply didn't want to get involved.. I just feel that you're being overly vocal here and were thoroughly mispresenting the 64, and think it fair that it be pointed out that you've made mistakes in your statements before.. Though on the whole, bar being a bit wonky, you've done a fair job when not splitting hairs.. I'm not digging for that post, you can find it if you want.. It's where you're going on about pets and their cpu configurations.. I've also heard from many people about the memory corruption (I've also heard the moon is made of cheese), but that fact of the matter is there's a work around.. Demos don't care that the memory might corrupt, as long as it survives the duration of the effect.. Games obviously have different criteria.. No go figure why commerical games featuring these effects work fine.. Big cluestick time.. It's nothing to do with the memory refresh being altered by the dma-delay..

And the point of this is ? I'm not biased here at all.. If I knew the A8 as well as I know the 64, or the 7800 or the 2600 then I would be posting pro's and cons on both sides.. Since I don't, we're left in an ever decreasing circle of petulance from you.. Umm, we don't in the context of what we're talking about.. So, why would you use 11Khz or 22Khz ? Instead of 7.8Khz or 15.6 Khz then ? Go on, I'm dying to hear this answer.. I believe you're just being deliberately obtuse here now.. Next you'll be saying that the 64 fails because we can't have a 320x256 or 256x256 screen, because that's a common size of images on Windows.. I did hold you in some high regard up until now, but you've really just blown it with that I didn't say it was in this context.. I simply gave one of many ways of ensuring a constant set of cycles over the screen.. Your choice of word here, replicating, is deliberately chosen to mislead.. GTIA doesn't replicate sprites for you at all.. It has no idea of a sprite in the context of an isolated on screen object occupying a fixed vertical region, just an array of memory that it blindly displays down the height of the screen.. You're required to put the data in the right place, and handle the interrupts for positioning and colours, and that overhead of putting the data in the right place is not going to be insubstantial in a busy game.. Granted I'll give you the idea of a sprite being the full-screen height, but in the context you've chosen to write that and chosing to use the word replicating here you're trying to misconstrue again.. You're implying more than the hardware is capable of.. Anyway, by your own definition, the Vic supports variable hardware sprite stretching I don't believe this, but this is what your rules now say is possible.. Life in the world of Atarski could be fun So does this mean, that by messing with the sprite addressing hardware, and forcing it not to add 3 to each sprite line, and 2 instead (or the other possibilities, there are many!) that we support hardware sprite distortion ? Or maybe at a pinch, (holy crows!!!) hardware texture mapping!!! After all, we're just setting a register at the right time, and the hardware does the rest for the duration of the sprite.. And please, for the love of god, don't answer this It's not.. I've told you once already how to ensure jitter free interrupts, you've chosen to ignore that..

I beg to differ because the code involved is fairly constant, and very easy to set up.. Far far easier then this pie in the sky idea of horizontally multiplexing players.. I'm ready to be proved wrong on this, and would love to be.. Colour Ram doesn't incur any overhead on the 64.. Colour Ram is connected via a seperate bus to VIC internal 1k x 4bit memory.. Scrolling doesn't affect timing at all.. Timing is exactly the same.. You're BASIC example is exactly that.. It shows 23 colours, now do something sensible with if you please...

Please don't confuse me with a fanboy here Atariski, like both, I have owned both for a very long time.. I'm simply trying to get some balanced view of what both are capable of technically.. Apparently it's fine for the A8 team to throw around ideas that are nigh on impossible to implement if not impossible, only to be greeted by the cheer of the supporters.. You questioned some facts I stated, I answered all of them.. The only one throwing blatently inaccurate facts around is you, and people choose to ignore when you do so.. Ie: with regards to your statements on the multiple processors configurations of Pet computers.. Anyway regards your straw-man distraction I'm not playing your games, you've had your questions answered.. Regards your point about VSP ? I suggest you go read up.. The only issues are with demos (no surprise really there).. The games that use this don't have a problem.. You go figure why, it's not rocket science really.. I figure the only way to answer this is to build a technical prototype for a game on both and then see.. I guess 3D is out because we've a weaker processor as has been agreed on.. Both since it's clear from the rational discussion here that the A8 can match the 64 on all other aspects if not exceed it in many areas, pick your poison.. edit: I don't really expect any sensible outcome to come from this, but I'm open to this if it remains civil..

During the frame you let the incorrect character data exist and use them as sprite pointers.. One the single raster line where VIC would fetch incorrect character data (on the raster line where the sprite pointers are in the character screen) we momentarily switch to the other screen which has correct character data, then switch back to the one with the correct sprite data.. There's only a character fetch every 8 lines, the badline.. The character fetch is made, and buffered internally in VIC until the next badline condition, where upon it fetches again.. Sprite data is reloaded via the sprite DMA, beginning the right hand side of the screen, if sprite DMA is enabled, which is started if the sprites y position matches the raster line.. And starts shifting out once the x-position matches.. It can't be switched off until the sprites internal data address is equal to 63, the normal termination condition.. Through voodoo you can break the address mechanism and make it add only 1 or 2 on a sprite line (instead of the normal 3), hence getting sprites that are taller than normal..

I don't think we're hassling you over this, I'm just finding it mind meltingly complex to envision the idea of splitting sprites horizontally (edit: as Jetboot Jack seems to think also (sorry I got you two confused there for a minute)) in the context of a game and this 23 colour overlay mind-melt mode.. That's something I really wouldn't want to get into.. And if there was anyway we could re-use sprites horizontally of the 64 I'm sure it would have been used already, unfortunately we can't because once the sprite graphics shift registers have emptied there's no way to reload them until the next normal sprite DMA takes place, which is a bit of a bummer.. Timing on the 64 is more of a pain since we have no lovely WSYNC, but with the CIA timing method mentioned before, it's not really so much of a problem, or in fact with any of the multitude ways of obtaining stable timing.. I just happen to like the elegance of the CIA method personally As for the sprite pointers being shifted into the visible screen there's two ways to deal with it.. Some games just design the levels around that, and ensure they're not visible in the level (either via colour ram if in char mode or bitmap data if in bitmap mode), but another way is to have a another character screen that holds the correct sprite pointers, and then swap banks over the single line where the sprite fetches would be otherwise be wrong.. There's only exactly one line on screen where this needs to be done, so it's not exactly a show-stopper in anyway at all..

I'm all for commodore but have to correct you In every line where you use sprites VIC has to read pointer and sprite data... So you lose 2 cycles for each sprite and 2 or 3 cycles because only instructions that perform write are possible in those last two or 3 cycles before sprite fetching begins... So you end up losing 14+(2 or 3) cycles, roughly 15 * 200 lines = 3000 cycles... It's not without cost And as I know one line is 63 cycles long on PAL system ? 25 badlines = 25 * 21 (23 cpu cycles remaining per BL).. 175 normal lines = 175 * 63 112 blanked lines = 112 * 63 So we get 18606 cycles per frame.. But still easier to set up than ataris horizontal multiplexing of players, and with more colors and resolution... As Rybags stated in post #6443, it's not just cycles you have to look at but uniformity of it and being able to sync up to particular cycles and I would say exactness of them. I can play back a digitized audio file knowing DMA is pretty much uniform in graphics modes (no bad lines). So what happens when you play audio with bad lines on C64? What's the worst case latency? And then of course those sprites and color RAM don't always use up same number of cycles so writing kernels would be a much more difficult task. Atari CPU clock syncs up with video color burst. PAL/NTSC have same number of CPU cycles/scanline on Atari so one version of kernel will work on both machines. And you can use sprites in replicate mode w/screen off and get 105 cycles/scanline (27510/frame NTSC or 32760/frame PAL) for applications that need the time. Easily handled, but since we've less CPU power, this is more of a pain.. The easy way to handle the jitter is to point the NMIs directly at the CIA registers.. Set a counter that counts down from the desired cycle count, and when it triggers, (we've programmed the previous timer register to hold a jmp abs opcode) the NMI will jump to the correct routine based upon the cycle count.. You simply have 8 routines that are coded to each be 0 to 7 cycles of jitter.. This also means that we don't have to waste those cycles.. I mean that if the jitter is at least 4 cycles or more then we can ack the nmi.. So useful work is done instead of just burning cycles.. Clearly what work is app specific... So you're pointing the NMI vector directly at the hardware registers ) It's very evil, but a lovely solution.. By correct initial triggering of the timer, you have more than enough time to execute your sample playback even on a badline (which has 23 cycles left) as long as you align the initial interrupt point nicely.. Yeah, we burn some cycles, but it's a simple and easy way to handle the jitter.. But as for playing audio on badlines.. You just simply wouldn't.. I wouldn't dream of trying 15.6Khz playback on the c64 in a games (without a cycle fixed kernel).. 7.8Khz no problem, you just make sure you don't interrupt on badlines when you fire up the interrupt But you're right.. The sprites are a pain when it comes to handling cycle exact stuff, especially a badline with all 8 sprites enabled.. But you work around that in whatever you're building.. And the benefits of them more than outweigh the downsides.. If you really must, you can always stretch (not multiplex!) the sprites down the screen completely to ensure consistent timing, and then through judicious use of sprite pointers change the sprite pointer to change data in a line by line basis, so even if the sprite wasn't displayed, you'd still be setting it to empty sprite data.. But this is exploiting more bugs in Vic so it probably doesn't count in your books since it's not a 'hardware' feature Or another way, in your multiplexor, just ensure that unused sprites are re-enabled immediately with an empty pattern, a little more work for the plexor (and adds a few minor potential restrictions), but then you have absolutely uniform cycle availability over the displayed frame.. But we're way outside of typical game scenarios here and firmly into demo land now with sprite stretching.. But in answer to your question the handling of interrupt jitter is a no brainer really..

Two questions.. can you do those same techniques in an Atari? (and if you don't know, can you point to a webpage with info, or describe them a little ) and.. do you have a limit to the scroll speed that you can use with those techniques? something like "1 character per frame"? (or maybe you only need more setup time if you go over "that" limit) thanx NRV There's no need for these techinques on the A8, you have them essentially built in.. You're limited only by how much new data you can get to the screen and colour memory, since double buffering doesn't help here.. Scrolling horizontally at 8 pixels a frame means copying in 200 bytes of Bitmap data, 25 bytes of character data (used for colour data in bitmap modes) and optionally 25 bytes of colour Ram if you're using multicolour bitmap mode.. So 250 bytes need to be copied for 8 pixels per frame.. Double that for 16 pixels a frame and so on and so on.. Vertically it's the same thing... 320 bytes of bitmap data 40 bytes of character memory, 40 bytes of colour memory.. So, 400 Bytes per frame when scrolling at 8 pixels a frame.. 32 Pixels a frame would be manageable horizontally, and probably 24 vertically... And in combination in a freescroll, 16 pixels a frames is easily manageable in a real game scenario, probably more, but when was the last time we saw a game that was scrolling a those speeds.. Obviously if you do this in character modes, then you're data movement requirements are minimal, like (horizontall) 25+25 bytes and (vertically) 40+40 bytes per 8 pixels moved, so the world is your oyster.. It's still useful in character modes, because it saves on having to move the Vics on chip colour ram in one block which is without these techniques a pain because it means updating a whole 1K of colour ram data in one go otherwise, and that colour ram can't be double-buffered[1].. For more reading, try this... But it's very code orientated.. http://codebase64.org/doku.php?id=base:vic And for a full description of LineCrunch https://sh.scs-trc.net/vic/vic_article_3.14.htm#3.14.4. And for a full Description of VSP (aka DMADelay) https://sh.scs-trc.net/vic/vic_article_3.14.htm#3.14.6. In fact chapter 3.14 of the Vic Article explains most of the tricks the Vic can be made to perform.. [1] Well not unless you do clever tricks to fool Vic into producing 8x16 character cells by aborting every second Badline, and switching character sets to generate this mode, then you can use linecrunch to essentially swap between to colour ram buffers.. So you've created a 40x13 display composed of 8x16 character cells, with a double buffered colour RAM.. The only overhead is interupting every 16 scanlines, and aborting the badline there, but the cost reclaimed of not having half the bad lines more than makes up for this.. A very nice idea this indeed

But what about techniques such as VSP, which allow you to scroll the screen in a very flexible way ? Bitmaps wrap around at 8k boundaries, Screens at 1K boundaries.. And it costs you at most 2 scanlines to do.. There's never any large copies, just updating new data at the edge of the screen as required.. I'm hesitant to suggest combining this with LineCrunch to achieve the same thing vertically, because it will cost you 25 scanlines to setup, but again that gives you vertical wrap around.. But it is easily doable and has been used many times in games.. The technique for them both combined is AGSP But with these 2 techniques combined you have full XY scrolling with Colour Ram with only updating new data at the screen edges..

Okay Emkay, how about showing us something that's actually viable and can work instead of spouting repeated 'theoretical' ideas.. Really this whole thread comes down to 'in theory' the A8 is better, but we can't in practic prove it.. Your move sunshine..... edit: I'm a bit tipsy and maybe regreting what i said..

Of course you're right.. That'll teach me to be thinking in NTSC land before writing that.. Don't notice I'd mixed PAL (63) with NTSC (65) there...Oops.. And yes, I'm guilty of forgetting to take the multiplexed sprite cost into the frame when saying it's almost no cpu cost.. Oops

Thanks for that, very interesting reading that...

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..

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. ?

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..

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

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 * ) 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..

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. 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. ------ - sorry for my poor english. - i am Atari user since 1986 and never bought C64 - others C64 30 seconds conversion: 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 ?

That's barely recognisable as R-Type though.. And the frame rate is truly abysmal.. Out of curiosity, has anyone ever built some demo or prototype of R-Type on the Atari 8-Bits ? That's something I'd love to see, and would answer a lot of questions for me

I'm just curious, but how comes it's not possible to directly map the 3 square voices and noise voice directly to Pokey voices, with some frequency translation lookup on each frequency write ?

There's also this site, alas from C64 stuff, but does that matter ? http://kofler.dot.at/c64/font_01.html There's a fair few 2x2 fonts if I remember rightly.. There was also a site dedicated to ripping fonts from Demos, but I can't for the life of me recall it now..

Why ?

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..

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..

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!!