i found this link on a forum and look like a cool stuff if some one tried to do it will be cool
links: http://ayasuke.exblog.jp/8672106/
http://ayasuke.exblog.jp/7417029
sorry me English
I have contemplated hacking an FDS RAM adaptor for some time now, though I have not done so simply because I didn't have a Famicom. I'll have my first in less than a week, and I intend to get right down to business with hacking etc. Unfortunately I don't know any Japanese at all, so I can't make much of that website besides the pictures and a few acronyms. I recognize the development board he is using, and that's about it. However, the FDS data protocol is well documented at places like NES Dev so a project to do, for example, an arduino or propeller MCU based FDS backup/hacking device would be perfectly possible.
Does anybody have a pinout of that port, or a schematic of the RAM Adapter?
-Xious
Just what could hacking of the FDS RAM cart accomplish?
I believe it would allow you to write or dump disks or you could emulate the disk drive through it. I think someone on Tototek.com has the pinout. I remember someone was tearing apart a Hacker Pro ram adapter to see how it worked.
Quote from: satoshi_matrix on August 29, 2010, 09:57:03 pm
Just what could hacking of the FDS RAM cart accomplish?
I would say, backups and disk writing would only be a fraction of what it could do. Running FDS games without a disk drive comes to mind. Running FDS homebrew. Converting other games to FDS format. Dumping disks.
Besides converting games to fds format, I said the rest of what you just said. FDSLoader can do pretty much all of that right now, except loading and dumping game doctor formatted disks. Many cart games can be manually converted to run on the FDS, but most require a game doctor to work. Since there are already reliable ways to dump and write disks (Pasodisk w/ the Chameleon Set, MGD1, and FDSLoader, and some other more obscure ways), I'm not really sure what the benefit would be to hacking the ram adapter to do this. FDSLoader can already emulate the disk drive, at least for correctly formatted FDS images. It would be nice to have a USB device, though, instead of having to rely on DOS and a parallel port.
This port is just a 7-bit open-collector parallel port. The Hacker Intl hardware uses it for nibble-wide access to access 32 KiB of RAM. Instead of developing for this port, I would suggest using the Famicom's expansion port, which while less versatile is more available and obviously can be used in projects without a RAM adapter.
kyuusaku, didn't I read on Tototek that you were trying to disassemble a Hacker Pro ram adapter? If so, did you ever get all the epoxy off it to see the pcb?
Yup I was trying to, I don't remember even posting about that, must have been forever ago. It's still disassembled XD I would like to finish removing the epoxy but it's in between the chip legs and I already scratched a bit of the PCB trying to get it off :(( This stuff is SUPER tough, I'm not sure how I even chipped it before, maybe with a drill... Not only did they glop on the epoxy but they also filed off some of the chip names! The only two I couldn't make out logically have to be counters for the RAM's address lines, and the only chip that would make sense would be the '393. So here's an IC list for the Hacker thing:
-62256 (32k x 8 sram)
-125 (4 x 3-state buffers)
-14 (6 schmitt trigger inverters)
-257 (8:4 multiplexer with 3-state output)
-173 (4-bit register)
-123 (dual monostable) -- seems unnecessary/out of place, I guess it's used to speed up reads/writes
-393? (dual 4-bit ripple counters)
-393?
The data bus must be 4-bits so the 173 register holds the most significant nibble during writes.
The 125 is used to drive the open-collector bus during reads. The 125 is fed by the 257 multiplexer which is attached to the RAM's 8-bit data bus.
Since there are only 7 free bits on this port, and the data bus is 4-bit, there are only 3 control signals...
-One must be an address clock/data strobe
-One must be R/W or bus direction (enabling either the register or multiplexer outputs)
-One could be a reset signal for the address counters, though this is technically unnecessary since data will repeat every 32768 clocks)
-One could instead control the data register and multiplexer which would be faster than using the least significant address line for that.
I still dunno what's up with the monostable.
That other port is also on the side of a Twin Famicom. Supposedly, it's to allow you to plug in a RAM adapter and use the Sharp Twin's disk drive with a regular or AV Famicom. However, that other port is too small for the standard RAM adapter plug.
Whoever said that is very wrong, not only is it like impossible since the port is software controlled and the FC is not fast enough to play FDS Loader, it wouldn't even make sense from a marketing perspective. Since the regular FDS has one, does that mean it should allow someone to use a FC+FDS on another FC? XD
The port is good for a few things:
-simple peripherals that use very little or no power, like a system link cable
-peripherals that have their own power supply (such as the Hacker thing)
And nothing high speed either, at most you could get like 30KiB/s interfacing to hardware, using 4 data bits. Probably a system link cable would be like 5KiB/s with the software handshaking.
That thing about connecting a second FDS is a tidbit of mis-information spread like a disease via Wikipedia pages on the Sharp Twin Famicom. I wasn't aware that the hacker-pro used it--I underbid on a couple of them and haven't held one in my hands yet--and I was pretty sure it was some kind of data port, but I wasn't sure what the original concept behind it was until more recently by reading about the FDSLoader stuff. it does seem that Pasofami uses it though, with a custom bootstrapping disk or something like that, to run FDS games in the emulator using actual disks. (From what I saw in a blog+video.)
I think I'm right in my understanding that you can R/W to the FDS RAM-Adapter memory ranges using the port, but I'm not sure how (pinout unavailable at present?). I'm guessing here, but I'd figure that it was probably used by some SW companies when developing FDS titles for debugging or for loading data directly into the RAM adapter from a computer. I wonder what NCL had in mind when they included it. Perhaps some way to connect the FDS and the Family BASIC set or something along those lines, that never materialized.
Certainly, connecting a second FDS has little (really no) practical value, even if it would be possible. The only advantage would be less disk swapping, which is pointless, as few games came on more than one disk, except Doctor Disk games, which Nintendo wouldn't have planned to authorize. (It's rather like emulating a PC on a Mac, then running a Mac emulator therein: Aside from just being silly, it serves no logical purpose.)
Depending on the capabilities of the port, it could be used in developing an FDS peripheral, such as my suggested Family BASIC FDS attachment, although that could be done within ROM or with disk handling routines in BASIC on disk. The DA-15 port has $4017 and $4016 address lines, so developing something to connect to the RAM-Adapter port would be a completely different type of peripheral.You can't do direct memory reads of FDS games loaded into the RAM-Adapter via these address ranges, so it is certainly possible to do something unusual and interesting with the FDS Expansion bus, but I'm at a loss for anything good to do with it until I have factual data on what it does.
-Xious
Quote from: Xious on September 23, 2010, 11:02:13 am
it does seem that Pasofami uses it though, with a custom bootstrapping disk or something like that, to run FDS games in the emulator using actual disks. (From what I saw in a blog+video.)
It's dumping the disks, not accessing them in real time.
QuoteI think I'm right in my understanding that you can R/W to the FDS RAM-Adapter memory ranges using the port
No. You'd be hard pressed to find a peripheral port that can take over the CPU bus with 7 pins. The 2A03 doesn't even have a mechanism for that. This port is entirely software defined, bits you write to $4026 appear on the port. If you want to read back data from the port, set the bits high and read $4033. If you don't get it read about computer buses and open-collector buses.
QuoteI'm not sure how (pinout unavailable at present?)
Keep looking, it's out there, you may have to consult a technical document.
QuoteThe DA-15 port has $4017 and $4016 address lines
Please don't confuse memory-mapped I/O @ $4016 and $4017 for address lines... An address line is a single bit of a binary number making up a memory address that the CPU is currently accessing. Here are the address lines: A0, A1, A2.... A15. Again, read about computer buses.
Quoteso developing something to connect to the RAM-Adapter port would be a completely different type of peripheral.
Actually it wouldn't be, if you develop a peripheral for the FC expansion port (2 outputs and 4 inputs that aren't also used by the controllers), the RAM adapter port is more than capable of interfacing with the device (which has 7 bidirectional).
QuoteYou can't do direct memory reads of FDS games loaded into the RAM-Adapter via these address ranges
This doesn't make sense.
Quoteso it is certainly possible to do something unusual and interesting with the FDS Expansion bus, but I'm at a loss for anything good to do with it until I have factual data on what it does.
You have factual data on what it does... It's 7 memory mapped signals, figure out what you want to do with them.
Quote from: kyuusaku on September 23, 2010, 01:15:40 pm
No. You'd be hard pressed to find a peripheral port that can take over the CPU bus with 7 pins. The 2A03 doesn't even have a mechanism for that. This port is entirely software defined, bits you write to $4026 appear on the port. If you want to read back data from the port, set the bits high and read $4033. If you don't get it read about computer buses and open-collector buses.
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. 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.
Quote
Please don't confuse memory-mapped I/O @ $4016 and $4017 for address lines... An address line is a single bit of a binary number making up a memory address that the CPU is currently accessing. Here are the address lines: A0, A1, A2.... A15. Again, read about computer buses.
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).
Quote
QuoteYou can't do direct memory reads of FDS games loaded into the RAM-Adapter via these address ranges
This doesn't make sense.
Well, you can't do data reads outside the $4017 and $4016 memory address ranges on the DA-15 port.
QuoteI'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...
QuoteI 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.
QuoteSorry. 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).
QuoteWell, 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.
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.
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.
Where's the point hacking this??
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.