I worked it out. We have 3.5 KB, no OAM needed.tokumaru wrote:While this isn't the simplest thing to do on the NES, it isn't the most complex either. There's actually very little NES-specific stuff involved... once you figure out the screen drawing and input, the rest is basically pure 6502 logic.
Ditch the crazy RAM layout though, there's no way that'll work. OAM isn't even a full 256 bytes you can use, since the unused bits of the sprite attribute bytes aren't even stored.
[IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RAM)
Moderator: Moderators
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
But that's the fun part...tokumaru wrote:Ditch the crazy RAM layout though, there's no way that'll work. OAM isn't even a full 256 bytes you can use, since the unused bits of the sprite attribute bytes aren't even stored.
Anyway, 2KB of onboard RAM, plus 1KB for the unused nametable. I need 16 full-width rows of tiles out of 30 for the screen so I have 14 left, so (960/30)*14=448 bytes. Add 64 because we can use the whole attribute table, and... 512 bytes. Add that, and we have 3.5KB. No OAM needed. I'll explain how I have interpreter RAM later, but I already have.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
And software is free. Hardware is not.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
orlaisadog wrote:We can get more memory for the interpreter by duplicating tiles 16 times, so we can used the unused 4 bits to get more RAM for the interpreter.
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
That's just not enough... Even if you could somehow identify what's constant and what's variable in any given CHIP-8 program, you'd still have to map this somehow, in order to know what goes in ROM and what goes in RAM. In addition to that, you need RAM for the emulator itself, there's a lot of state to maintain.orlaisadog wrote:Add that, and we have 3.5KB.
You're only doing the math and adding up as much RAM as you can, but like you said, you don't have much programming experience, so you're probably not thinking of practical ways to allocate and access all this scattered RAM. Trust me, this won't be fun, or efficient.
If you insist on using a "bare bones" cartridge configuration for this, you could go with a CHR-RAM cartridge (e.g. UNROM), and you'd have an entire pattern table (i.e. exactly 4KB) to work with, since only one would be necessary to draw the screen. Being able to access it only during vblank or forced blanking would still be pretty limiting, but if so many CHIP-8 programs work fine with so few instructions per frame, that might just work.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
But we only need 3.5K. Anyway it should only take a few instructions to access and I can program, just in Scratch (very well) and Python (not so well). Scratch is like any other language, but people think it's simple as it's block-based but if you try hard enough you can even do proper polygon-based realtime lit 3D.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
tokumaru wrote:crazy at the software level, which makes me much more confident
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
If you decide to go through with the project, you're obviously free to implement this in any way you want. I'm just warning you, as an experienced programmer, that the kind of memory mapping you're trying to do in real time is extremely impractical, and will add a lot of unnecessary complexity and computation overhead.
I do understand the fun aspect of a programming challenge, but there's a difference between fun and masochism. Simulating another machine inside the NES is fun, but it's a known fact that to simulate a machine, you need a superset of said machine, and trying to do it with less resources than that will only lead to frustration and/or subpar results.
Maybe it's just me, but I'd much rather claim that "I made a proper CHIP-8 interpreter on the NES that runs all programs well", than that "I made a CHIP-8 interpreter that runs some programs and does it at a fraction of the speed the NES CPU allows because my memory layout is so limited". If a "challenge" significantly compromises the workflow and quality of the final product, that's not fun, it's unnecessary masochism.
I'll stop arguing about this now. This is not my project, so if you're really going to pursue this, you're free to do it however you want. I'm just trying to give you GOOD advice, since as an unexperienced NES programmer you might not have considered all the ramifications of the crazy idea that is simulating a contiguous block of memory using all the bits and pieces of memory the NES has, and that's without even considering that you don't need only the memory the CHIP-8 uses, the interpreter itself needs RAM to function. You're just looking at the raw numbers and going "yeah, 3.5KB is almost 4KB, that'll do it" without actually considering HOW you're gonna make that work.
I do understand the fun aspect of a programming challenge, but there's a difference between fun and masochism. Simulating another machine inside the NES is fun, but it's a known fact that to simulate a machine, you need a superset of said machine, and trying to do it with less resources than that will only lead to frustration and/or subpar results.
Maybe it's just me, but I'd much rather claim that "I made a proper CHIP-8 interpreter on the NES that runs all programs well", than that "I made a CHIP-8 interpreter that runs some programs and does it at a fraction of the speed the NES CPU allows because my memory layout is so limited". If a "challenge" significantly compromises the workflow and quality of the final product, that's not fun, it's unnecessary masochism.
I'll stop arguing about this now. This is not my project, so if you're really going to pursue this, you're free to do it however you want. I'm just trying to give you GOOD advice, since as an unexperienced NES programmer you might not have considered all the ramifications of the crazy idea that is simulating a contiguous block of memory using all the bits and pieces of memory the NES has, and that's without even considering that you don't need only the memory the CHIP-8 uses, the interpreter itself needs RAM to function. You're just looking at the raw numbers and going "yeah, 3.5KB is almost 4KB, that'll do it" without actually considering HOW you're gonna make that work.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
Well, 512 bytes are reserved so it's fine The CHIP-8 only has 3.5KB of usable RAM, so the figures are perfect. Anyway, isn't that what NesDev is about? By the way, I'm not saying this is the best way, I'm just discussing how it could be done.
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
I think it'd be a lot easier to start with NROM with expansion RAM (and solve all the "how do you emulate CHIP8 at all"),
followed by porting to something with CHR-RAM (and then solve the "how to emulate CHIP-8 with limited bandwidth to the emulated CPU's RAM)
and only then port to this "no cart memory" model (and solve the "how to deal with fragmented memory)
This process of breaking it into manageable chunks is basically what one learns in first-level classes in project management.
followed by porting to something with CHR-RAM (and then solve the "how to emulate CHIP-8 with limited bandwidth to the emulated CPU's RAM)
and only then port to this "no cart memory" model (and solve the "how to deal with fragmented memory)
This process of breaking it into manageable chunks is basically what one learns in first-level classes in project management.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
^
Sound advice. It's a logical three stage rocket.
Note that figuring out how to get it to work with wRAM is the most feature-light version. Beginning with identifying the simplest thing that could work is always a good starting point.
Sound advice. It's a logical three stage rocket.
Note that figuring out how to get it to work with wRAM is the most feature-light version. Beginning with identifying the simplest thing that could work is always a good starting point.
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
Tokumaru's response mentioned that it's not practical, but maybe it should be spelled out:orlaisadog wrote:2KB of onboard RAM, plus 1KB for the unused nametable. I need 16 full-width rows of tiles out of 30 for the screen so I have 14 left, so (960/30)*14=448 bytes. Add 64 because we can use the whole attribute table, and... 512 bytes. Add that, and we have 3.5KB. No OAM needed. I'll explain how I have interpreter RAM later, but I already have.
The PPU's RAM is not equivalent to the CPU's RAM. You can't treat them interchangeably. You can only access PPU RAM from the CPU during vertical blank (~10% of the frame time), and that access is much slower than with CPU RAM, so whatever you're planning to do here could easily end up cutting the speed of emulation down 50x.
Even with CPU's onboard RAM, probably 3 pages (768 bytes) of this aren't really usable for your emulation. (The three relevant concepts are: the Zero Page, the Stack, and the OAM buffer.)
You might think the internal OAM is another 256 bytes of storage, but in reality this is even less practical as general purpose RAM than PPU RAM is. The constraints for this one are kind of insane, so I won't go into it, but under normal circumstances this is considered "write only" memory. (This is also related to why we usually reserve a 256 byte page of CPU RAM as a buffer to be copied into OAM.)orlaisadog wrote:No OAM needed.
Software is not free. It costs time.orlaisadog wrote:And software is free. Hardware is not.
The hardware for 8k WRAM will add <$1 to a board. The software constraints you're putting on will add many, many hours of extra work to the project, or more likely just make it impossible. That $1 per board would normally only matter if this was a mass market venture where you could sell enough copies to overcome the extra work it necessitated.
According to bootgod's databse 17% of NES games had WRAM, (and 25% had CHR-RAM) so it's really not an unusual thing to have in the cart at all.
Another thing to consider is how to get your CHIP-8 program into the cartridge. That 8k WRAM could be treated as battery backed RAM, allowing you to use it to store the individual program, which is probably a lot more convenient than having to recompile each program directly into the ROM.
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
The OAM isn't even a clean 256-byte block, since the unused attribute bytes are not saved anywhere. And there's also the fact that in some revisions of the PPU (only used in early Famicoms, it seems) the OAM isn't readable.rainwarrior wrote:You might think the internal OAM is another 256 bytes of storage, but in reality this is even less practical as general purpose RAM than PPU RAM is. The constraints for this one are kind of insane, so I won't go into it, but under normal circumstances this is considered "write only" memory. (This is also related to why we usually reserve a 256 byte page of CPU RAM as a buffer to be copied into OAM.)
Another very good point.The hardware for 8k WRAM will add <$1 to a board. The software constraints you're putting on will add many, many hours of extra work to the project, or more likely just make it impossible.
Being able to save your program so you can work on it between play sessions is definitely a plus, and would also simplify the process of loading other people's programs when using emulators and Flash carts.That 8k WRAM could be treated as battery backed RAM
Last edited by tokumaru on Mon Jul 16, 2018 1:36 pm, edited 1 time in total.
- orlaisadog
- Posts: 166
- Joined: Thu May 31, 2018 11:12 am
- Location: Bristol, England
Re: [IDEA] CHIP-8 interpreter on NES? (NROM, no expansion RA
As I said (many times) I'll use forced blanking for more PPU communication time. What you said about RAM is a good point, but I enjoy programming so the time thing isn't relevent for me.