malducci
-
Content Count
339 -
Joined
-
Last visited
Posts posted by malducci
-
-
can you please correct me in what I've really statedYou'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.
-
There are many games on Atari that use the hardware collision detection. You are exaggerating by saying "countless".Exaggerating? So the tens of thousands of 2D games since the NES in '83 to 2D nowadays on XBOX live and PSN is exaggerating?
The point of saying "GOOD" games to those that use software bounding boxes is subjective.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.
They may be good for you and not good for me. If you don't want to take my word for it, ask some other people here familiar with Atari game internals whether they use hardware collision.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.
Even if you don't own a C64, by siding with a C64 view..Oh man...
It's not a c64 view or thing. It's a game thing and it has nothing to do with c64. -
c64 could display 16color off the shelfCan 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.
*GOOD* games do bounding boxes. That's a subjective view and nothing to do with reality as most Atari games I have which are very good don't do bounding boxes.Maybe you need to go and try out all the games before you make your claim.
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.
-
Nintendo graphics chip the "PPU or Picture Processing Unit" had 16kb of RAM to do all sorts of graphical stuff.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.
-
Good games do a bounding box based collision detection anyway. It's always a horror when a game lets you die because the out pixel at your shoe touched the topmost hair pixel of a bad guy.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....
-
Good games do a bounding box based collision detection anyway. It's always a horror when a game lets you die because the out pixel at your shoe touched the topmost hair pixel of a bad guy.Quoted for the truth.
-
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 <_<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 <_<
-
You know the C64 is a great machine! I really like it. Many people do!BUT YOU'VE GOT TO SAY IT! COME ON, SAY IT! C64 IS THE BEST. IF YOU DON'T SAY IT, I GET LIMP. SAY IT!
Oh my god, that had me busting up laughing
And what makes even more funny is that it's so true too - hehe
-
Looking at those specs... living proof that Sharp should just stick to microwaves and VCRs.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?
-
Musical notes used be the main use in computers since memory was limited but nowadays digitized sample playback is the norm so allowing for 4 DACs to be played at their own rate is better than one DAC (or two at a fixed frequency). Adlib board prior to Sound Blaster did not allow you to adjust volume on each FM channel independently. All the Sound Blasters that I have does not allow you to do it either. So even if you can find some boards that have volume adjustment per channel, once again the point about non-standard useage comes into play. You can't really take advantage of it like you can on Amiga/Atari since you would be making your software specific to a few audio boards.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.
so allowing for 4 DACs to be played at their own rate is better than one DAC (or two at a fixed frequency).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?
And if Malducci thinks I am missing the point, then he's missing a different point than the one that you are missing.Wait... now I'm confused. Hehe.
-
I think you missed my point. What's is the overall goal of those multiple DACs on the Amiga and Atari? Music.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.
-
Sound cards are more of a nonstandard than video cards. That's why you see many DOS games either expecting sound blaster compatibility or giving you a list of sound cards to choose from. But even Sound Blaster directly accessed lacks the multifrequency DACs running simultaneously like you can do on Amiga and Atari.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.
-
Sound cards are more of a nonstandard than video cards. That's why you see many DOS games either expecting sound blaster compatibility or giving you a list of sound cards to choose from. But even Sound Blaster directly accessed lacks the multifrequency DACs running simultaneously like you can do on Amiga and Atari.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.
-
If you look at an oscilloscope or sound card sampling...Normal "square" waves aren't as such. You have a near instantaneous "attack" as you would with a normal square/pulse.
Then, a decay back towards zero, which begins steeply and flattens out.
Then repeat with reverse-phase for the remainder of the cycle.
|\ | \ | \ | - | - | / | / |/
Not a great illustration, but kinda close... I can put a proper pic up later.
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: POKEY volume is a DAC which controls an amplifier transistor directly. in DAC-mode the volume register simply amplifies a constant voltage while in normal mode it amplifies the waveforms.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?
-
Mov AL,Sample1Mov AH,Sample2
Add AL,AH
Jnc GoodValue
Mov AL,255 ;clip to max value
GoodValue: Out DX,AL ;play sample (thru Sound Blaster or whatever 8-bit DAC you have)
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)?
-
4 bits + 4 bits + 4 bits + 4 bits = ~6 bitsAnd:
6 bits + 6 bits + 6 bits + 6 bits = ~8 bits
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 don't think one could be a good game programmer if one's orgin arent at the demoscene, simply because on demoscene coders push up the limits and proove that this or that could be done faster or done at all with given hardware.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.
-
Are you sure about that block copy? 7 bytes per cycle doesn't add up. Even a modern PC only does 8 (or 16/24 if you have dual/triple channel memory access)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.The tasks I mentioned are very relevant. Look at any action game on a 6502, a signigicant number of the CPU cycles are consumed either moving screen data around or drawing objects.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
-
The 68K craps all over the 6502 derivatives.OK, I'm not versed on all the enhancements in the 65816, but does it have:
Store multiple - 68000 in a single instruction can store up to 16 registers in a contiguous region. That's 64 bytes moved in one instruction. Sure, it takes a number of cycles to execute, but would be way quicker than doing the same in a loop.
Bit shift multiple - can shift a 32 bit value by a number of bits specified in the operand, rather than inline or looped.
Multiple base/index register addressing. Rather than having to calculate addresses, store temporarily, add to others etc. the 68K can do such things in single instructions.
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.
Sure, it takes a number of cycles to execute, but would be way quicker than doing the same in a loop.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.
Common tasks such as:- move 1000 bytes to a location 40 above or below in RAM.
- take 64 contiguous bytes in memory. Store to a 64 byte buffer elsewhere, then AND with masks in 64 bytes memory, then OR with another, then store in yet another contiguous block.
- as above, but applying bit-shifting on the data to be ANDed/ORed with.
Those are specific tasks. The majority of code is mostly made up of general tasks. See above.
-
Actually, one of the advantages of the 65816 in embedded systems is that it is faster at the same clock speed.There is a very favorable comparison on Western Design Center's website.
What it does not say is that advantage is only fully realized when you code directly in assembly.
The 6800x0 CPUs support compilers much better than any other CPU of the time except possibly the early RISC CPUs.
Just what I was going to say until I saw your post
Another reason why the 68000 is favored is its a true 16 bit processor with a 16bit bus and has more registers. The 65816 still only works on an 8 bit bus with the A,X,Y registers, although they're 16bit now.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.One other thing you may want to look at is Super Nintendo vs Sega Genesis. The SNES has a 65816 compatible CPU and the Genesis had a full blown 68000 processor. Although the SNES may have a more capable graphics chip with, many games still play smoother on the Genesis.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.
-
Is there a modern equivalent to the 6502 CPU?Kinda like how the x86 is based on the 8088 CPU for the IBM PC?
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.
-
If you were to integrate the zero-page on chip, eliminate the ability to address it in memory through normal reads and writes, eliminate the indexed-indirect addressing mode, then I can start to feel the RISC vibe. Pipeline the machine, and then I think you'd capture what Hennessy and Patterson were going for when they built MIPS and SPARC. But, go in the direction malducci described with the 'T' bit and indirecting through 'X', and I think you end up in quirky microcontroller territory, not RISC machine territory.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.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari v Commodore
in Atari 8-Bit Computers
Posted
WTF are talking about, strawman? Stop using the fraking notation.