malducci

You've made over generalized statements quite a few times of the C64 being able to do 320x192x16 or 160x192x16, or such. That is considered a BITMAP description and you damn well the c64 works on character(tiles) and associated palettes map, not an unrestricted BITMAP layout. It's *not* the same thing. It's not an Atari ST. If you're going to say the c64 can display 16 colors per frame, then you need acknowledge that the A8 could display its whole palette in a single frame as well. stop using the straw man. WTF are talking about, strawman? Stop using the fraking notation.

You've made over generalized statements quite a few times of the C64 being able to do 320x192x16 or 160x192x16, or such. That is considered a BITMAP description and you damn well the c64 works on character(tiles) and associated palettes map, not an unrestricted BITMAP layout. It's *not* the same thing. It's not an Atari ST. If you're going to say the c64 can display 16 colors per frame, then you need acknowledge that the A8 could display its whole palette in a single frame as well.

Exaggerating? So the tens of thousands of 2D games since the NES in '83 to 2D nowadays on XBOX live and PSN is exaggerating? No. Take for instances a platform game. If the main character gets even just one pixel to collide with another sprite, and you base your hit detection on that, that will make for some really poor gameplay and great frustration. Shooters, platformers, run n' gun, etc. Smaller than the displayed object 'hit boxes' allows for more complex and less limited gameplay design. If pixel accurate detection was such a big deal, then why did systems stop including it in hardware? The NES had it, and it was ignored. The Genesis had it and it was ignored. The SMS had it and it was ignored. The TG16, the SNES, quite a few arcade system too. All had pixel accurate hardware collision detection and guess what? It wasn't used. I don't need to. I do classic 2D game development myself and understand game engine designs. I have no doubt very simple and old games like Tank or Centipede can lend themselves to pixel accurate collision, but I was under the impression that Atari 8bit computer dev community was moving to a more capable game design than that. Oh man... It's not a c64 view or thing. It's a game thing and it has nothing to do with c64.

Can you PLEASE stop saying this? It's NOT a 16 color bitmap mode no matter what you say or think. It's a tile based system. It's not the same. Subjective? Are you for real? Subjective, ehh? That's why COUNTLESS games use DON'T use pixel accurate collision detection and still don't to this day? Many later console systems, and even arcade systems, had pixel perfect collision detection as well and guess what? They don't use the hardware. I might not know as much about the A8 as you, but when you spew crap like this, then you just discredit yourself and make me second guess your other points in this thread. Man.. It's also funny that you claim that I'm a biased sidekick when I've never even owned a c64 and have argued with Frogen on more than one occasion. Get yourself straight. You're coming off more like a fanboy than anything else.

You sure the NES has that much memory? I thought it was more like 2K ram + 2K video ram. Most later NES games had an additional 8k work ram. But the video ram is different. Although the PPU comes with 2k ram for the tilemap and attribute table(and a small amount of palette ram), the rest of the PPU address lines are mapped to the cartridge directly. You could use VRAM or VROM. The lesser games that use VRAM usually only have 8k on cart. The games that use VROM range from 16k to 512k and are able to swap in/out up to small amounts of 256byte sections or larger sections like 2/4/8k (all depends on the mapper and what regs you enable). It could swap in/out sections of VROM faster than even 32bit consoles could write ram or vram. This CHR ROM is separate from PRG ROM (data/code) address lines and mapper regs. I did some NES emulation.

Quoted for the truth. Quoted for being a biased sidekick. What!? How am I a biased sidekick? Maybe you need to re-read the quote again. Jesus....

Quoted for the truth.

They only want you to compare games that have their fast loaders and not consider time to upload fast loader to the 1541. So, they certain games had to load this 'fastload' routine into memory before they achieved this faster rate - every time?

Did c64 really take 10 minutes to read in 50k!? Man, that's pathetic. Zaxxon tape for my CoCo 2 only took about ~1 minute to load all 64k <_<

Oh my god, that had me busting up laughing And what makes even more funny is that it's so true too - hehe

But then they would have never moved on to develop the X68000 home computer that puts the Amiga to shame

Ok, some one list some specs: Number of sprites per scanline (hardware and lowest color count - i.e not pairing)? Number of sprites per screen? If the total number of sprites can be extended (by changing the registers on the fly), what's the CPU resource ratio? What res are the sprites available in? Can you mixed hi-res and low-res sprites, and can you mix them with a different background res? How many colors per sprite (both for pairing or non pairing)? Native/max sprite sizes?

I more familiar with Yamaha's other chips (OPN), but AFAIK all Yamaha chips including the OPL types (even the lesser cut down types with predefined instruments) have an adjustable TL register. There's a pinball game that came out in the early 90's that did the same (or similar) trick that I described to playback digitized samples on FM channels of Adlib sound cards. It wasn't restrictive to a certain set of Adlib cards either. Well, that depends on the resolution of the DAC. FM chips accumulate the channel output digitally and then feed it do a DAC. So do some wavetable synth setups. But you're still using a fixed point counter for each channel, right? I assume you're running/incrementing each counter from a timed interrupt. What's the base timer frequency? 15.7khz? Wait... now I'm confused. Hehe.

No you missed the point. While the Amiga easily can play 4 different samples at different DAC feeding frequencies at the same time, the A8 can't because it doesn't have the processing power to do so. The A8 could aswell have one single 6 bit DAC, the output quality of MOD players would be the same. Uhm... what you talking? I think you missed the point I made of atariksi missing the port. The SB only having a single DAC isn't a hindrance because it has 9 (or 18 for OPL3) FM channels. The whole point of the DAC(s) in the first place, especially relative to this discussion, is to output music as the end goal. And Atariksi implying the SB's single DAC, without mentioning the benefits of the additional FM channels that each create complex waveforms and modeling instruments, as a weakness relative to the other two systems.

Well, they had more than just a stereo DAC. There was opl2 (sound blaster) and opl3 (sound blaster 16) FM chips on the sound cards. Some recent music examples of just OPL2 here. For digital audio playback, Amiga has 4 tracks and 4 8-bit DACs with their own frequency and volume settings. Atari has 4 4-bit DACs each can be played at their own frequency using IRQ or cycle exact coding. Sound Blasters have 1 DAC with stereo you have 2 DACs but they have to run at the same sampling rate. Adlib stuff is just for music notes not for generic digital audio playback. I think you missed my point. What's is the overall goal of those multiple DACs on the Amiga and Atari? Music. You didn't need multiple DACs because you had 9 FM channels in OPL2 or 18 FM channels with OPL3, not to mention the use of software mixing for the direct DAC if needed. Plus, if you wanted - you could could freeze the FM channel's carrier and use the volume for sample playback on each FM channel.

Well, they had more than just a stereo DAC. There was opl2 (sound blaster) and opl3 (sound blaster 16) FM chips on the sound cards. Some recent music examples of just OPL2 here.

That's a "return to 0" system. Every "audio" device I know of uses it (supposedly you can damage a speaker if it's held in one spot too long and this prevents that. I have no idea what amount of duration is considered damaging though). My guess is that it's like the NES audio. Each channel has a 4bit DAC. The waveform is square/duty cycle so the volume mechanism is digital, i.e. the phase of the waveform is shifted(multiplied) according to the linear 'volume' level. It has a triangle channel, but the triangle waveform uses all 4bit levels of the DAC and therefore has no volume control. I take it POKEY works like this too. Wiki says four 8bit channels, but it looks like it's referring to the resolution of the frequency divider register and not the DAC itself. It wouldn't make any sense to have 8bit DACs and only 4 volumes for 1bit noise/square waveforms. It also doesn't mention anything about being able to change the duty cycle of the square wave - is that correct?

There are two definitions of clipping: one means to stop at a point(ceiling) and the other means a value wraps around. I always used the word 'clipping' because in the music/audio world it means the value flattens out for either position or negative phase. I don't use the word "clipping" for samples anymore because some people misinterpret it. I just refer to it as saturation (there's another term too, but I forget what it is at the moment). But my question was, about POKEY, if the volume (attenuation) is digital as in it's applied to the sample before going to the DAC or if it's external to the DAC (applied after the sample is sent to the DAC)?

If I understand that correctly, you'd still have to do software volume before mixing all channels into a single 8bit DAC output. So unless the samples are played at max volume all the time, they'll loose fidelity due to the downward multiplication LUT for linear volume. Or right shifts for LOG volumes. Is the A8 4bit DAC method using the hardware volume in conjunction with a waveform state to get 4bit output, or is the hardware volume mechanism free to change? Is the hardware volume of each channel on the POKEY LOG? What's the resolution of the volume levels?

I'm sorry, but I've got to call bullshit on that. You *need* to be from the demoscene to be a good game programmer? I'm assume you don't code. Also if you could sum up one thing about demos, it's that they exploit the *hell* out a given situation to unrealistic levels. Be it a waste of memory (huge precalculated LUTs), 100% cpu resource, fixed whatever (graphic rendering, patterns,etc), and totally non-interactive situations. These demos aren't variable in nature like a game. Everything is fixed from a code and design point of view and demos coders exploit that to the very end. Are there cross overs between the two camps in relation to optimization? In some areas sure, but you don't need to be from the demoscene understand concepts relative to game design, music, special effects, and other related aesthetics when it comes to 'pushing' a machine. There are plenty of capable game or other coders that are not or do not come from the demoscene.

No no, 7 cycles per byte copy. 7 cycles to: read byte from source, write byte to destination, decrement source,destination,length and then compare. Not 7bytes per cycle. My god, that would be fantastic if it were so Funny enough, on the 65x 8bit variant that I use - the block transfer is 6 cycles per byte. Well, I know the 65x when it comes to game programming. It's the target platform (65x variant) that I mainly code for. Not only do I do game development, I've also hacked some games and traced through many other game code. Matter of fact, if you run the statistics you'll see the top most used instructions are what I mentioned previously. Granted my experience is with 2D of hardware multiplexed sprites and scrollable tilemaps, but the experience is relative. My specialty is insane optimizations and game coding

Nope. Nope. And nope. Are you trying to make the '816 look bad? Shifting a 16bit register is actually faster on the '816, but only for the Acc reg and requires multiple instructions. The 68k has a few more addressing modes, but the '816 has more addressing registers for indirect addressing (128 VS 8 ). The 68k has nice quick addi and addq instructions that the '816 could have really used. And of course the 68k has 32bit operations for most instructions, but at the cost of additional cycles. Matter of fact, just looking over the 68k instruction set, you'd think there's no competition with the 68k. If you never coded for '816 (or even a 65x) but have for a 68k or other more well rounded processor, then you'll probably think the processors aren't much with their small immediate register set. But you'd be a fool to think that. The programming approach is totally different than most large register set CPUs. When it comes to optimizing code in assembly, most of the instruction set of the '816 and 65x goes out the window. You optimize for the fastest instructions. You keep operations to a 16bit minimum (8bit for 65x). The 65x/'816 load/or/and/xor/compare/etc immediate addressing is fast at 2/3 cycles. Responds well to unrolled logic as well as self modifying code. Conditional branching is also faster on the '816. The majority of your code is going to be load/store/add/sub/or/and/xor/compare/branch_on. The 65x and '816 excel in these areas for cycle times over the 68k. The '816 also have the benefit of dropping into 8bit emulation mode to save some cycles for non 16bit stuff. Like I said, you optimize accordingly. In the end though, your code is overly complex regardless of speed. And not in all situations is that going to be necessarily faster or just as fast as the 68k. Motorola had the right method of thinking when they designed the 68000 and ditching the 6809 model - as much as I love 6809 (the 6809 and the 65x are step brothers, which makes the '816 its step brother as well). The 68k might have had slow cycle times, but it was a forward thinking model. Something the 65x didn't, but should have evolved into. For that reason alone, I'm not a big fan of the '816. Such wasted potential. And you have to load the register before hand. The '816 has 'block transfer' instructions. Little DMA-ish instructions. No looping or compare logic needed. It copies 7 cycles a byte. Not super fast, but faster than a loop copy. Those are specific tasks. The majority of code is mostly made up of general tasks. See above.

Just what I was going to say until I saw your post When it comes to speed, isn't it speed is all that matters? But from a development point of view, the 68k is a better choice for a computer system. Nice linear memory layout and easily optimized compiler friendly processor/setup. The SNES also had wait states on the system ram. Even when run at 3.57mhz(as opposed to the slower mode of 2.69mhz), most instructions ran at 3mhz due to the wait states. I'm not sure what a full blown 68000 processor is, but a regular 68k at 3mhz would be hard pressed to due much better.

IIRC, I think the SNES CPU, the Ricoh 5A22, would be the newest descendant, as it is based around a 65c816 core. The current WDC versions of the 65816 have all the missing instructions that the original 65816 and SNES version are missing, that the R65C02 introduced (SMB/TRB,etc). That'd be the newest version if I'm not mistaken.

The AVR is considered RISC and it shares a lot in common with the 65x. Memory mapped registers just like ZP. Even the I/O registers are memory mapped in what would the ZP location, just like how 2600 mapped external ports to half the ZP address range. That's a huge advantage that a lot of other manufactures failed to take advantage of IMO.