It is currently Tue Oct 17, 2017 12:53 am

All times are UTC - 7 hours

Post new topic Reply to topic  [ 1 post ] 
Author Message
PostPosted: Fri Jul 15, 2016 5:22 pm 
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
clueless, here wrote:
Going out on a limb here....

Maybe someone with a great deal of brains could design a "mapper language". Not as low-level as a net-list. Maybe it implements a logic-gate level abstraction, maybe a higher level abstraction, like "if/then/else" and some integer array for maintaining state. The iNES format can be extended to flag the existence of this "mapper implementation", and it would be appended to the ROM after the (optional) char-rom segment.

I lack the time right now to go into greater detail, but I can envision how to implement MMC1 and NROM this way (in fact, NROM is just a null statement, kind of trivial).

I like this approach (I did my senior "capstone" college credit work on a compiler / language translator), so it appeals to me. Unfortunately, I lack the time to devote to making a reference implementation right now. :(

Any thoughts?

(edit, added content)

Wow. I never actually finished typing up my thought. Emulators could be adapted to implement the mapper lang -> byte code conversion, and byte-code VM. The VM would be receive the same input info as a real cart would (addr bus, data bus, ctrl signals). It would be capable of implementing a small state engine that would determine what gets mapped when, and when to fire IRQs. This layer within the emulator would handle all of the reads and writes to the cart. It would need access to the RAM allocated in the EMU that holds the contents of the RAM and ROM chips on the cart.

This might seem like a crazy idea, and indeed the lang -> byte_code "compiler" would be a bit of work (maybe ~1000 lines of C code?), but a fairly efficient VM can be constructed to handle this. A modern PC running an emulator should have NO problems maintaining a proper frame-rate.

I would also like to see an emulator that exposes, via its debugger, the internal state of its current (or future) mapper implementation. For example, when debugging a MMC1 game in FCEUX, it would be nice if I could access to pop-up window (debug -> cart mapper) that would show what pieces of ROM are currently switched in, and the current state of the MMC1 latch

Damn, I wish I had time to work on this. Maybe later this summer.

NROM should not be a null statement, because 1. mirroring and 2. connections. However, it should be allowed to be a null statement, as it has only default-type connections.

I've started working on thinking up how one would work, sort of in a Verilog style. Comments, suggestions appreciated.

Ideally, it should have enough information to compile to a Verilog description or C module for an emulator, defining what registers exist (/need saving in savestates), how a read assembles an address, and so on.

To head it off, yes I'm aware it's unlikely anyone will adopt this format, that "iNES successors are like assholes", and so forth. That is not germane to specifying the language and figuring out how to best make some shorthand to make it not just re-syntaxed, limited Verilog.

Audio needs better specification to do, though (without hacks like PDM): it's its own realm. As mentioned on the page I've got, the VRC7 oscillator especially makes a problem…

(Shorthand description should also allow for bank-on-READ, for e.g. Oeka Kids, MMC2/4; it doesn't yet.)

edit: I should just make some Verilog macros, really.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC - 7 hours

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group