Is it possible to control a system's address bus externally on pins that aren't being used?
Let's say the CPU is writing to address $0100. If the cartridge puts $0001 on the bus at the same time would it end up writing to $0101 instead?
Now how about the WAI instruction. While the CPU is waiting for an interrupt, is it possible for the cartridge to write or read from memory by itself without screwing up the cpu?
Does all this depend on what the system is?
Depends entirely on the machine.
Machines more like "real" computers often have some variant on a "bus request" signal that will allow an external peripheral to drive something (e.g. 68000's /BR, /BG, /BGACK pins; 6510's AEC pin; 8086+8288's HOLD). Whether the pin is available on the cart edge is another question.
edit: Does not include the 6502
psycopathicteen wrote:
Let's say the CPU is writing to address $0100. If the cartridge puts $0001 on the bus at the same time would it end up writing to $0101 instead?
AFAIK, bus conflicts result in short circuits (Vcc being connected to GND), which are never good. The resulting value on the bus can vary depending on other characteristics of the hardware, I don't think it's simply a function of the 2 values being put there.
I read people did something like this for the Atari 2600.
You cannot force values on the bus, when two things are driving the bus at the same time one will eventually give in and gets physically damaged.
psycopathicteen wrote:
I read people did something like this for the Atari 2600.
Citation wanted!
The 2600's minimalism could really benefit from a coprocessor that would do such a thing, but the 6507 doesn't allow anything else to drive the address bus.
Well, they're overriding the data bus, not the address bus, and they have an explanation (the electronics experts will tell you whether it's a bogus one) for why they think this is safe to do:
Quote:
Even though it seems pretty evil to overdrive the 6507's bus, the designers knew it was fairly safe because the NMOS 6507 used pull-up resistors to drive 1s on the bus, which could be grounded to 0s without overheating the 6507.
That sounds right. You're not sourcing current from a driving transistor when you bring the line low for an NMOS part like that. You wouldn't want to use it on an Atari Flashback II, which is surely a CMOS ASIC.
I'm asking because I had an idea on how to double DMA speed on the SNES.
Have a chip detect when a dma to $2119 is happening. Then have the cart it toggle bus B between $18 and $19, while toggling bus A between two adjacent banks.
tokumaru wrote:
Well, they're overriding the data bus, not the address bus, and they have an explanation (the electronics experts will tell you whether it's a bogus one) for why they think this is safe to do:
Quote:
Even though it seems pretty evil to overdrive the 6507's bus, the designers knew it was fairly safe because the NMOS 6507 used pull-up resistors to drive 1s on the bus, which could be grounded to 0s without overheating the 6507.
Except that they're not pull-up resistors.
They're the same enhancement-mode nMOSFETs that are used as pull-downs ... just being used as pull-ups.
They're not very good at it, because they don't start conducting until the output voltage is at least {the threshold voltage} below the voltage supply, but overriding the remaining 3.5V-4V actually is a fight.
(Technical details: the amount of current that will flow through a MOSFET is a function of how much the "gate" exceeds the voltage on either of the other terminals. In a single voltage supply design, you're limited by that upper rail. This is part of why the use of CMOS helped so much: pMOS pull-ups are now a function of how far ground is below the supply, instead of how much the supply is above the output pin)
And, sure, in the NES, bus conflicts are well documented as "the device pulling down wins" ... because the pullup nMOSFET can't source as much current as the pulldown nMOSFET until it's dumping into a dead short to ground.
Doesn't the SNES's DMA unit already handle swapping between adjacent ports? Why is it useful to have different bit planes on different banks?
So it can copy 2 bytes in one cycle.
So ... just to double the bandwidth? There's a lot more possible places for that to fail than just the question of whether you can safely get in a fight with the SNES's address bus driver.
I wouldn't be at all surprised if the S-PPU couldn't maintain a 5.2MHz access rate.
lidnariq wrote:
tokumaru wrote:
Well, they're overriding the data bus, not the address bus, and they have an explanation (the electronics experts will tell you whether it's a bogus one) for why they think this is safe to do:
Quote:
Even though it seems pretty evil to overdrive the 6507's bus, the designers knew it was fairly safe because the NMOS 6507 used pull-up resistors to drive 1s on the bus, which could be grounded to 0s without overheating the 6507.
Except that they're not pull-up resistors.
They're the same enhancement-mode nMOSFETs that are used as pull-downs ... just being used as pull-ups.
They're not very good at it, because they don't start conducting until the output voltage is at least {the threshold voltage} below the voltage supply, but overriding the remaining 3.5V-4V actually is a fight.
What? The pull-up transistors are not enhancement mode nMOS, they're
depletion-mode nMOS transistors. Meaning, up to a certain point they approximate pretty well current sources.
I wasn't referring to the logic inside, that is depletion-mode. The final output FETs, however, are definitely enhancement-mode.
Hmm, right. Why I posted this I don't know, now I remember seeing the outputs toping at about 4V even with no load whatsoever, that wouldn't happen with depletion-mode transistors.
At least on NES/Famicom (and probably many other systems), the cartridge should not output to the address bus. However, there could be logic in the cartridge to conditionally override the address for access to its own ROM/RAM. But there are many alternatives depending what needs to be done.
For example, an instruction could be loaded that would access the address that is needed. This would require to concern the correct timing to know where and/or when will the instruction be loaded; an interrupt could be used for this purpose (if the system supports cartridge interrupts).
One thing I have read about used in some other system for video (although this isn't quite what you are asking about) is a "cheap video" system, where while rendering the system will render the byte read from the memory but return NOP to the CPU instead of the byte read, using the CPU to provide the address for the display (and then to scroll, you can just change the interrupt vector; well, not quite exactly like that). Although this won't work for a cartridge, a similar idea might be used for some kinds of things that might be done with a cartridge.
In some cases the cartridge might want to access the computer's internal memory. Depending on the circumstances there may be some ways. Some ways are spying on memory (possibly MMC5 will spy on PPU registers). The cartridge can still see the read/write, so sometimes it is possible to take advantage of that. What I did with Famizork mapper is to take advantage of RAM mirrors; reading from them will allow the cartridge to also spy on the value and cause a bankswitch; it is faster than having to first read from the RAM and then write to the bankswitching register.
Some systems might have instruction sets that allow to do more things with it, and possibly some mirrors might trigger a function in the cartridge to override the memory address accessed by the next instruction; since it is a mirror, it can do two things at once.
If you want the cartridge to be able to display contents of system RAM it could include its own "shadow RAM" which is write-only, and then the other port is the read-only side. This can be use for programs that are not meant for such a cartridge, so the cartridge is just like a kind of debug utility I suppose. (This may even be possible with Atari VCS since knowing if it is a read or write may not be as important, but I don't know much about that.)
With NES/Famicom PPU there is a way to control somewhat, for example if you have unusual mapping to CIRAM and then if the cartridge returns for some or all nametable reads can control what address is then accessed. Again it can also be used as a counter, but remember that it will also draw on the screen (unless covered by sprites, or if the palettes are set to make it invisible).
Also with Famicom it may be possible to use OAM DMA with the cartridge for purpose other than sprites too.
Which way to do really depend what you are trying to do and on the computer that it is being used with! Isn't it?
I really don't know what I'm talking about, but
psycopathicteen wrote:
So it can copy 2 bytes in one cycle.
How would this work? It's an 8 bit data bus, although from what lidnariq said, it sounds like you're trying to double the clock speed. How?
In DDR (Dance Dance Revolution), arrows are colored based on their relationship to the beat. If you have a stack of red arrows, you'll press one direction per beat. Blue arrows happen between the beats. A stream of red and blue arrows means two directions per beat, or DDR (Double Data Rate). Modern computer RAM also supports DDR (Double Data Rate), transferring one word at the top of the cycle and one at the bottom.
Normally, DMA transfers one 8-bit word every 8 quarter pixels (qpels). But we know certain parts of memory can complete a write in 3 qpels because 6502 family pulls write enable low for half a cycle, and at 3.58 MHz (fast ROM and register read and write speed), each half cycle is 3 qpels. So psycopathicteen's suggestion would override the address bus to try to DDR the DMA mechanism.
But on the NES, the PPU isn't designed to accept a write every cycle. (Someone else can dig up the forum thread where this was discovered.) I imagine that the S-PPU isn't designed to take writes every 4 qpels either.
I'm pretty sure the DMA already runs at maximum possible speed, and shoving data in manually at speed higher than that will just result in missed writes.