It is currently Sun Oct 21, 2018 4:16 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Mon Jul 16, 2018 12:10 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
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.

I worked it out. We have 3.5 KB, no OAM needed.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 12:12 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
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.

But that's the fun part... :(
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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 12:13 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
And software is free. Hardware is not.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 12:16 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 12:48 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10904
Location: Rio de Janeiro - Brazil
orlaisadog wrote:
Add that, and we have 3.5KB.

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.

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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 8:59 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 9:06 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
tokumaru wrote:
crazy at the software level, which makes me much more confident


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 9:15 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
And CHR-RAM would need PPU access anyway. I need to read posts all the way through...


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 10:07 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10904
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 10:43 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 11:21 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7676
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 11:31 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1783
Location: Gothenburg, Sweden
^
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 12:02 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6898
Location: Canada
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.

Tokumaru's response mentioned that it's not practical, but maybe it should be spelled out:

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.)

orlaisadog wrote:
No OAM needed.

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:
And software is free. Hardware is not.

Software is not free. It costs time.

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.


Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 1:34 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10904
Location: Rio de Janeiro - Brazil
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.)

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.

Quote:
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.

Another very good point.

Quote:
That 8k WRAM could be treated as battery backed RAM

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.


Last edited by tokumaru on Mon Jul 16, 2018 1:36 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jul 16, 2018 1:35 pm 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: pubby and 3 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