Front Far East copier

by kyuusaku on 2006-06-30 (#14893)

The socalled "FFE" mappers are 6 and 17, all the others are duplicates of legitimate mappers (ie GNROM) which happen to be "modes" of the "FFE" copier.

F6XXX means a 6 disk game or 3M game, it is not a specific bankswitching type; all 2M or greater FFE games use mapper 6 or mapper 17 (which should be treated as a single mapper) except for UOROM games.

by -_pentium5.1_- on 2006-06-30 (#14897)

Oops, I stand corrected - I know next to nothing about FFE's NES copiers. So do the codes F4xxx and F3xxx have the same derivation as F6xxx?

by kyuusaku on 2006-06-30 (#14902)

Yes, F4XXX means 2M, F3XXX means 1M PRG/256K CHR (nearly all 3 disk games are unhacked GNROM).

Only 2M-16k switch at $8000 mapper 6 games are somewhat emulated anyway so it's not like any of this matters, this was never properly implemented--obviously because Marat didn't understand the header, which configured the unit and would have allowed for there to only be one FFE "mapper".

by -_pentium5.1_- on 2006-07-01 (#14923)

For the safety of n00bs who would otherwise d/l bad ROMs, would it be a good idea for emulator authors to drop emulation of the FFE mappers right away? Or is there some objection to this (i.e., does someone want more accurate emulation of "the FFE mapper")?

by tepples on 2006-07-01 (#14925)

I don't know about iNES, but UNIF should define a board type for each kind of copier hardware, where the PRG and CHR are as expected and a third chunk specifies the copier configuration, such as the fusemap for a cart with a CPLD mapper or the header for the FFE copier. Does anybody own that kind of copier? If so, what is the writing on the circuit board?

by kyuusaku on 2006-07-01 (#14942)

-_pentium5.1_- wrote:
would it be a good idea for emulator authors to drop emulation of the FFE mappers right away?

Not really, either way it doesn't accomplish anything, nobody plays Super Magic Card ("FFE") images anyway.

tepples wrote:
Does anybody own that kind of copier? If so, what is the writing on the circuit board?

I own one. Why writing on the circuit board?

Basically the copier is built upon it's predecessors, all logical clones of Bung units:

First generation plays only CNROM, UN/UOROM, GNROM so there's no need for it to be emulated.

Second generation plays the above but extends CNROM to add UOROM bankswitching on D2-D5 and "CNROM" CRAM bankswitching to UOROM D4-D5. This is more or less mapper 6, there are 4 banks of 8k CRAM. The entire game, CHR and all, is banked in the CPU space.

Third generation is the same as above but has a "4M mode" (4x6 bit register file) which adds 8k swapping at $8000,$A000,$C000,$E000 by writing the bank<<2 ala second generation.

Fourth generation (Super Magic Card) has the above and the addition of actual CHR ROM emulation, 8-bit/1MB PRG addressing, and an IRQ counter. This mode is covered completely by mapper 17.

There should be 3 mappers in all:

-Second generation type A (perhaps with fourth generation IRQ and CHR registers, some images hackishly mixed modes)
-Second generation type B (also with fourth generation registers)
-Third generation and fourth generation, many fourth generation hacks use bank<<2 switching for whatever reason. The presense of CHR ROM would determine whether or not the unit is in the third or fourth generation mode for CHR.

That would cover nearly all the hacked Front Fareast (one word) images. There really is no place for hacks like Y's which are UOROM with GD mirroring heh (BTW, that is where the Final Fantasy UOROMs came from--Bung)

by tepples on 2006-07-01 (#14944)

kyuusaku wrote:
Why writing on the circuit board?

In general, that's where the UNIF "board names" come from.

Quote:
extends CNROM to add UOROM bankswitching on D2-D5 and "CNROM" CRAM bankswitching to UOROM D4-D5. This is more or less mapper 6, there are 4 banks of 8k CRAM.

So BNROM is to UNROM as Color Dreams is to this, right? Doesn't Squeedo do something like this, U*ROM style PRG switching plus 8 KB CHR RAM switching out of 32 KB?

by kyuusaku on 2006-07-01 (#14945)

I see, the copier doesn't have a board name in that sense, it's nothing like a cartridge. I would just call it SMC-801 after it's model number but that's deceiving as the previous models are incorporated into the design and they really aren't FFE's work at all. Because the unit has so many things unemulated it doesn't make sense for any emulator support except for the 3 memory models (which should be recognized as "poison" mappers since there are no original images)

tepples wrote:
So BNROM is to UNROM as Color Dreams is to this, right? Doesn't Squeedo do something like this, U*ROM style PRG switching plus 8 KB CHR RAM switching out of 32 KB?

Heh, you've lost me

------PP 32k vs ----PPPP 16k
CCCCPPPP 32k vs -PPPPCC 16k or -CCPPPP 16k ?

by -_pentium5.1_- on 2006-07-03 (#14981)

kyuusaku wrote:
...nobody plays Super Magic Card ("FFE") images anyway.

Proper users don't. N00bs might. Shouldn't emulators at least display a warning of some sort?
kyuusaku wrote:
Because the unit has so many things unemulated it doesn't make sense for any emulator support except for the 3 memory models (which should be recognized as "poison" mappers since there are no original images)

Isn't this further justification for speedy deprecation of the FFE mappers?

Maybe the information that is known so far should go on NESdevWiki? (Sorry, I have neither enough experience with NES technical stuff nor with MediaWiki sites to do it myself.)

by oRBIT2002 on 2006-07-03 (#14989)

kyuusaku, so you've got an old Famicom copier? That's cool. What can you do with it? Does it come with a 3.5" floppy or similar?
Can you post pictures?

by kyuusaku on 2006-07-05 (#15059)

As far as I know I own every revision of every Famicom copier (except for the Dr PC Jr which arguably isn't a copier.) I won't post pictures (they can be found elsewhere) but I can talk a little about them.

They hijack the system around when the Nintendo header loads in the FDS BIOS (they all load game images from 2.8" disks.) They cannot backup games, their GUI is a simple "Insert Disk A,B,C,D [sic]" prompt. After loading the disks, the game starts.

The games are organized into FDS blocks, there is a block for the copier header (generally two bytes which configure the mode), a block for a "trainer" if present, then the blocks for program ROM followed by character ROM.

The earliest units could only play these modes (which were 99% of the games in 1987):

--PPPPCC (extended CNROM)
----PPPP (UOROM)
--CCPPPP (reverse mode 1)
--CC--PP (GNROM)

Then support was added for trained games to support MMC1 and other 3rd party hardware. As I said earlier another mode was added which made $8000/A000/C000/E000 banks swappable.

Until 1989, all units were logical clones of Bung's Game Doctor line (74 series/SPLD) with either original or hacked BIOS, in 1989 proprietary ASIC units came out. Each company (there are really only 3: Bung, Venus and Front Fareast) had their own style of PHI2 IRQ counter and included character ROM emulation with 1k switching instead of using CNROM style CRAM bankswitching.

The Super Magic Card ("FFE") is an exception in that it comes with built in 3.5" support and PC link and a GUI to manage files on the disk. The basic "FFE" image format (512b header) is:

first 8 bytes - legacy copier header block
ID bytes - AAh BBh
rest - 00h
followed by PRG then CHR ROM.

The earliest (1M) units use the FDS RAM adapter to decode $6000-7FFF, this means of course the area is volatile and saves aren't kept. Units by Front Fareast decode WRAM to a local SRAM and is retained by the unit's power supply or battery pack. Starting with the ASIC units the copiers had either a real time save addon device (Venus units) or it built in (Bung/Front Fareast) operated by a pushbutton (Venus/Front Fareast) or a button sequence (Bung). Bung's technology for real time save is used in the Game Action Replay (which was developed by the man behind all Bung products)

Basically all you can do with FC copiers is playback games (which you would have had to hack yourself or purchase illegally from a vendor.) Because earlier units had to make due with 4x8k SRAM banks, trainers often had to turn off rendering, transfer character data from CPU RAM to CRAM by way of $2007 and resume. This causes the screen to flicker of course, in games that bankswitch often, this flicker can be REALLY annoying. Should a trainer make the game logic spill into another frame, this causes slowdown as well.

by tepples on 2006-07-05 (#15067)

kyuusaku wrote:
The Super Magic Card ("FFE") is an exception in that it comes with built in 3.5" support and PC link and a GUI to manage files on the disk. The basic "FFE" image format (512b header) is:

first 8 bytes - legacy copier header block
ID bytes - AAh BBh
rest - 00h

Would proper iNES support for Super Magic Card images put the 512-byte FFE header in the "trainer" section?

Quote:
Basically all you can do with FC copiers is playback games (which you would have had to hack yourself or purchase illegally from a vendor.)

Does your use of "hack" include the classic jargon senses? If so, then the SMC might be useful for homebrew, and it might be useful for emulation even if only as a quick spot-check before running a nightly build on Famicom/NES hardware.

by kyuusaku on 2006-07-05 (#15069)

I don't think there can be such a thing as proper iNES support, proper support would be to get rid of the iNES header and use normal SMC images. The trainer section of iNES is necessary if you're going to use the FFE images.
Trainers are code loaded into $7000 before the game starts, they usually just contain a few bankswitching routines. To "train" a game, you generally replace a STA $E000 with JSR $7018 where $7018 is a routine to preform that specific bankswitch.

I meant hack as in modify the game to use trainer routines or directly access the unit's bankswitch registers instead of say MMC1's.

by tepples on 2006-07-05 (#15071)

kyuusaku wrote:
proper support would be to get rid of the iNES header and use normal SMC images.

But aren't "normal SMC images" associated to a Super NES emulator on most users' computers? The situation resembles that of .bin, which can be either a common extension for a Sega Genesis uninterleaved ROM or a deprecated extension for a GBA ROM.

by kyuusaku on 2006-07-05 (#15072)

They probably are but there's no reason why Magic Card images couldn't be ".ffe" (which I've seen people use back when un-iNESed images were still available) or something entirely new. People could also rename their .SMC ROMs to .SWC (it supersedes .SMC) and associate all SMC to a NES emulator.

Re: Front Far East copier
by deadbody on 2016-01-12 (#162399)

Nothing like resurrecting a ten year old topic, and I think this question should be in the hardware section, but anyway...

What is the format of the 8 byte copier header/config data? From analysis (of the three disks I have) I have deduced that the middle 4 bytes are some kind of name/ident string. But what about the first two bytes and the last two bytes? How do they work and what do they do?

Re: Front Far East copier
by kyuusaku on 2018-05-19 (#218775)

The FDS BIOS loads the contents of the config file as it's scanning disk (side) "A", in doing so it configures two of the copier's internal registers and boostraps it's own internal BIOS for control (to facilitate loading the subsequent disks). The file may or may not also hold the game's "catalog number" so the disk or disk image can be easily identified, but that information is just ignored as nothing's mapped there in the hardware. The letters generally correspond to a game's size and/or mapper, and letters to a release number (these were published in Hong Kong/Taiwan game shop flyers and magazines.) The Nintendo header area is also frequently embellished a little with copier related extensions, but aside from extending the disk count I'm not sure they mean much.