famicom disk other port on ram adpater

[kyuusaku]

I'm not sure what my statement had to do with taking over the CPU. I'm talking about reading and writing to where the FDS RAM-Adapter retains the loaded game data.

Dude, you need to read up. In order to read and write memory externally you need to disable the CPU's address bus and enter it into a wait state, otherwise the CPU will also drive the address bus and you'll have a conflict. Neither the 6502 nor 2A03 have this feature so it's not even possible without a bus arbiter chip which the FC doesn't have. It doesn't even matter because the expansion port doesn't have any sort of functionality for even accessing the address/data/control buses much less taking them over. But it doesn't need that functionality, that's what software is for...

I didn't know what memory address ranges are accessible via this post, so I was only guessing from what I've read or seen elsewhere.  I'll have to look into $4026 and $4033 and see what documentation is out there.

NO memory address ranges are accessible through the port, what appears on the port is not an address, it's a register/latch output which is *address decoded*. This isn't complicated stuff but you need to know many basics in order to understand.

Sorry. Data lines for the $4016 and $4017 memory address ranges. Specifically, read for $4017 D0 through D4, along with $4017 and $4016 Read-Enable and $4016 reads on D1 only, but writes three bits (D0, D1 and D2).

This isn't right either, addresses don't have data lines. Data lines are common to ALL addresses. You are talking about output latches/registers and input buffers, which accept input from data lines and external signals respectively by way of address lines (and control signals).

Well, you can't do data reads outside the $4017 and $4016 memory address ranges on the DA-15 port.

As explained above you can't perform arbitrary reads externally, period. You can however read latch/register outputs. You can also toggle signals on an input  and hope the software running chooses to read the address where the input buffer is decoded, then process it (and maybe send back output via a latch/register decoded to another address). Very big difference.

[Xious]

Alright, so I'm calling a register that can be used for addressing or data a MAR. Fine. To me, the singular $4016 address range is the same as saying the $4016 register, even though $4016 can also be a data register: The terms are compatible in my vocabulary, but maybe not in yours... I'll police this usage in the future to avoid confusion. I do want to thank you for the additional information, which I will hopefully put to good use. I finally noticed that the FDS Tech doc om NESDev contains a detailed briefing on the external connections, so I am now partially briefed in their function after skimming it earlier this evening.

I know that the Data lines are shared across all registers. If they weren't, they wouldn't have a shared signal path on the schematics. I've never said anything about being HW controlled though. I've been going on about how Pasofami works, and I know that it's software controlled, and I even mentioned that it requires a special piece of software to operate on the EXP bus of the RAM-Adapter. I'm responding to various other statements directly without quoting , so maybe that's a bad idea for this discussion, but I hate the quoting system (BBCode) used on forums, so I rarely use it.

So, let me try to clarify:

Pasofami uses its own software to access signals across the EXP line for the $4033 and $4026 registers, and i didn't think you can do this using the $4016 and $4017 registers, but I may be mistaken. I'm not an expert on the architecture of the FC, which is why I am gathering and reading up on it in my spare time. I wasn't sure if the data lines on the RAM-Adapter's EXP bus are shared with those of the console: I didn't have a handy reference to tell me what the exact signals were, so I'm going to read the full FDS Technical briefing and apologize in advance if my statement was non-factual.

I guess that it would be possible to write a piece of software that allows for use of the $4016 and $4017 registers, but I'd still need to read more on how the interrupt system works on the FC and how the RAM-Adapter (and FDS) function in order to suggest how to do that. I don't mind being corrected or having the information that I know augmented, as long as it is done professionally and without childish nastiness, so I appreciate your mature and respectful remarks in this thread. My entire purpose for being active in these discussions is to learn more about the FC system architecture so that can create useful devices or assist others in creating them.

I think you're getting hung-up on my wording more than anything else, and I apologize for that.

[kyuusaku]

If you look up a "memory address register", that's another name for what they call the register holding the next data to be fetched by a CPU, so a register decoded somewhere in the 6502's memory space would probably be better called a "memory-mapped register" which is accurate. The registers which control the expansion port are "memory-mapped" and located within the 2A03 (CPU and sound) chip. On a 6502 system, such registers are rarely used for further addressing memory unless they are part of a bankswitching circuit. On some CPU  with paged memory a "MAR" could be confused for a paging register as well, that was the first thing that came to my mind. A CPU like the 68000 also has registers that specifically hold addresses (a pointer), so it conflicts with that as well.

The expansion port "$4016.1, $4016.0 etc" do not have an address range, you are not looking at the address bus, you are not even looking at a "decoded" address signal, ie a signal that is active when every address bit in say $4016 is active, you are looking at the output of a register (more likely a latch from the internal architecture) which you cannot control from the outside.

Data lines are not shared across all registers, some registers will have input from only particular data lines, some will only have input from other registers, some will have input from logic gates connected to data lines, address lines, other registers, and what have you. There is no limit to what a register can get input from; the shift register inside the FC controller gets input from buttons AND from itself.

Data lines are shared however across the 6502 memory. It's the system design that determines whether or not the lines are used on a particular register. When the CPU writes to memory it puts an address on the address bus (such as $0000), which cause an "address decoder" circuit to determine that $0000 means the WRAM chip,  which it then enables, the CPU puts the data it wants to write on the data bus (such as $00), then the selected memory gets a "write strobe" control signal from the CPU (or in the 6502's case two control signals decoded into one) causing data to be loaded into the enabled chip at the address on the address bus (the WRAM chip's address lines are tied to these. It's not the full address since the WRAM is only 2k, it has only 11 address signals instead of the full 16).

To understand this stuff either takes a lot of self-study or education, if you're going to try to talk about it, learn it first or else what you say is just misinformation or nonsense. Due to the well established rules of physics in the case of electricity and well established language for computer theory, if it's not true it's false. I don't really have the time to keep writing long posts explaining this stuff, anyone interested should go take some classes/do reading on analog/digital electronics and computer architecture immediately, it'll help and (to me at least) it's interesting stuff.

[MarioMania]

Where's the point hacking this??

[kyuusaku]

It's a general purpose port (without power) with 7 bidirectional signals while the FC expansion port only has a few unidirectional signals. If you need extra signals for some accessory and don't want to interface with the cartridge bus it could be slightly useful, but otherwise it isn't useful at all, especially since the connector is custom.