SMD have more powerful CPUza909 wrote:It takes a miniscule amount of time to read in the grand scheme of things (even with an active DMC), and even then some games opted out for an unrolled loop and had the same code repeated 8 times. It works, and honestly my question would rather be why the designers of the Mega Drive felt that a controller port interrupt was necessary. Does such a thing improve responsivity noticeably at all?
Why NES have too ugly arch?
Moderator: Moderators
-
- Posts: 24
- Joined: Thu Mar 23, 2017 11:23 am
Re: Why NES have too ugly arch?
Re: Why NES have too ugly arch?
Reading controllers in software using what amounts to bit-banged SPI has three advantages:
- It makes the hardware cheaper to manufacture.
- It doesn't really burden anything. I counted 228 cycles to read both controllers, which is two scanlines and less than 1% of CPU time.
- It makes the system more flexible, as manufacturers can make specialize controllers that send more detailed reports than the standard controller. Thwaite using the mouse is an example of this.
An interrupt is more necessary for a pin devoted to a 2D light gun's photodiode or serial communication between two machines. Polling is good enough for returning a Y coordinate from a light gun, based on the time between the start of a frame and when its sensor starts to receive light, in order to narrow down which targets are close. But retrieving both X and Y coordinates, as in the case of the Menacer, Justifier, or Super Scope, needs more precise circuitry.za909 wrote:my question would rather be why the designers of the Mega Drive felt that a controller port interrupt was necessary.
Re: Why NES have too ugly arch?
Is that all? A problem you can easily solve with a tiny routine you can call from the NMI handler, that you'll very likely write only once in your life and never think about it again? That hardly sounds like a significant design flaw to me.monobogdan wrote:I'm talking about why nes can't self read input every frame
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Why NES have too ugly arch?
As for something else: I've thought more than once, though without any real reference, how a chunk of address range is wasted on mirrored features, but i don't know if this is normal for comparable systems.
Re: Why NES have too ugly arch?
The ColecoVision memory map has RAM from $6000 to $63FF, but it's mirrored all the way up to $7FFF. Its I/O map is full of mirroring as well.
For hardware external to the CPU die, incomplete decoding is cheaper. The NES APU is completely decoded (and thus not mirrored) because it's on the same die as the CPU.
For hardware external to the CPU die, incomplete decoding is cheaper. The NES APU is completely decoded (and thus not mirrored) because it's on the same die as the CPU.
- rainwarrior
- Posts: 8735
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Why NES have too ugly arch?
It's very normal, and it's the opposite of a waste. Every mirror doubling is the result of one bit of the address being ignored (no circuitry, no cost). To restrict something to just one memory address means you need logic to deal with every single bit of the address.FrankenGraphics wrote:As for something else: I've thought more than once, though without any real reference, how a chunk of address range is wasted on mirrored features, but i don't know if this is normal for comparable systems.
Re: Why NES have too ugly arch?
We've been over this before.monobogdan wrote:SMD have more powerful CPU
Thousands of times across the internet.
In short: no, the Z80 at X MHz is roughly as capable as a 6502 at X/2 MHz.
Re: Why NES have too ugly arch?
Which I think the NES does for the $4000-$4017 registers, so logic is sort-of wasted on this. (Sort-of because this adress range was used by the FDS and other mappers).rainwarrior wrote: It's very normal, and it's the opposite of a waste. Every mirror doubling is the result of one bit of the address being ignored (no circuitry, no cost). To restrict something to just one memory address means you need logic to deal with every single bit of the address.
Re: Why NES have too ugly arch?
Mega Drive, not Master System.lidnariq wrote:We've been over this before.monobogdan wrote:SMD have more powerful CPU
Thousands of times across the internet.
In short: no, the Z80 at X MHz is roughly as capable as a 6502 at X/2 MHz.
But as for the Z80, I don't think the ratio is even as low as 2:1. It's probably 3:1, particularly if you're randomly accessing members of an actor data structure.
Re: Why NES have too ugly arch?
Oh, pff, I keep on forgetting that this entire thread started with comparing the NES to things that are 5-20 years newer.
Re: Why NES have too ugly arch?
The Mega Drive needs the interrupts for the blast processing to work properly.
Just kidding!
Just kidding!
Refreshed in design but not as Oziphantom meant. And I hardly think removing the microphone (which broke compatibility with some games) and the 15-pin expansion port is an upgrade. The new expansion port and controller ports are upgrades though.Bregalad wrote:That's actually exactly what they did - the system looks completely different and cartridges aren't even compatible. They just made sure the software was (mostly) compatible.I fell that Nintendo should have "refreshed" the NES in 85 for the US launch and added in more things to bring it more up to date, having proven the model in Japan for 2 years first.
-
- Posts: 3140
- Joined: Wed May 19, 2010 6:12 pm
Re: Why NES have too ugly arch?
If the NES was released a little bit later, maybe 1987, it could've had the following specs:
- 8 palettes of 4 colors for BG tiles, and 8 palettes of 3 colors for sprites
- 16kB of CHR-ROM, 512 tiles for sprites and 512 tiles for BG
- 16 sprites per scanline
- 8x8 or 8x16 sprites (selected per sprite)
- CHR patterns are stored with each pair of bytes representing an 8x1 sliver
- 6 byte FIFO
- 8 palettes of 4 colors for BG tiles, and 8 palettes of 3 colors for sprites
- 16kB of CHR-ROM, 512 tiles for sprites and 512 tiles for BG
- 16 sprites per scanline
- 8x8 or 8x16 sprites (selected per sprite)
- CHR patterns are stored with each pair of bytes representing an 8x1 sliver
- 6 byte FIFO
- TmEE
- Posts: 960
- Joined: Wed Feb 13, 2008 9:10 am
- Location: Norway (50 and 60Hz compatible :P)
- Contact:
Re: Why NES have too ugly arch?
That interrupt on controller port in MD is for lightguns and RS232 communitation. When TH line is confed to be an input, and Port ints are enabled then high to low transition on the TH line creates a Port int to the 68K, in addition you can conf the VDP to freeze HV counter and read the pixel position where the Port int happened. Changing TH state by software will not cause Port ints, the change must come from external hardware (and to read normal controllers TH must be set as an output, so there can never be Port ints).
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Why NES have too ugly arch?
Sorry I mean Chroma clock. The Dendy is the special hacky Russian/Argentinean NES that uses PAL-M/N right? So it kinda works on NTSC-M displays and SECAM because those countries couldn't really get their TV standards straight? https://en.wikipedia.org/wiki/PAL#PAL-Ntepples wrote:C64 sprites can be most usefully thought of as four 24x21-pixel sprites with 4 colors plus transparency. Each consists of a 1bpp outline plane on top of a chunkier multicolor plane. Thus you have four colors: the two shared multicolor sprite colors and two particular to a single sprite (the outline plane's color and the first multicolor color). Mayhem demonstrates this well.
One serious problem with C64 is that it takes unbearably long to load games from cassette tape. Unlike with NES, few games came on cartridge, and as I understand it, few people outside the USA got a 1541 disk drive because it was so expensive.
Dendy doesn't use "a 3.58Mhz colour clock". It uses the same color subcarrier and master clock frequency as the PAL NES, just with a /15 in the CPU instead of a /16 and a later NMI in the PPU. Use of /15 causes the number of CPU clocks per scanline, which is the important part, to match NTSC.
Re: Why NES have too ugly arch?
The UA6538 PPU in the Dendy outputs PAL video at the standard chroma subcarrier frequency (4.43 MHz). It is not PAL M or N.