It is currently Mon Dec 10, 2018 1:12 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: Sun Jul 15, 2018 7:46 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1786
Location: Gothenburg, Sweden
I wouldn’t hardcode specific opcodes to the controller - you need it to be able to edit code!

Rather, i’d keep 16 soft buttons on the lower portion of the screen. They’d change title on context. So, the 8th button would be labeled MATH. if you push it, you then set x id (buttons now labeled 0-F), then y id (same), then operation to be carried out between them (OR, AND, XOR, ADD and so on).

D-pad = cursor
A = confirm
B = go back a step and erase

Sel + A or B = step forward or backward without editing
Sel + d-pad = move edit cursor freely. // remember to update the soft key readout contextually/accordingly.

Start = takes us to a menu from where you load, save and run programs and change file metadata like emulation speed, if possible.


edit: you could perhaps let the player use 2nd controller for user defined hotkeys. maybe initialized as
the most common opcodes used as per frequency count in public domain games.

edit2: you can speed up this input procedure even more by predicting likely followup instructions, and set the cursor to the corresponding soft button after one opcode is completed. For example, a chip-8 branch instruction (which always increases PC by an absolute 2 if taken) will mostly be followed by a jump or jump to subroutine, so in a LUT, it makes sense to let all branch cells point the cursor to jump. Other follow-up predictions can be derived from a frequency analysis of pairs in the freely available chip-8 library, just like how we can sort the frequency of the most used single opcodes.

An analogy is letter frequency analysis. A table of (opcode) pairs where one axis represents the first of the two could then be frequency sorted in order to generate the LUT to be used.

I suppose cursor positions for X and Y register ID:s are well enough predicted to often be the same or neighboring ID:s, which also makes the editor simple in this respect. Just keep the last used x and y ID:s in RAM.

edit3:
sel + start = toggle insert mode editing

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


Last edited by FrankenGraphics on Sun Jul 15, 2018 10:09 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 9:46 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7802
Location: Seattle
orlaisadog wrote:
I've just realised that OAM memory will decay if forced blanking is used. Could sprites be turned on occasionally during emulation to keep it refreshed or would there not be enough time?
What would you be using OAM for here? The CHIP-8 "sprites" seem to be more accurately called a bitblit operation...

Turning on sprite evaluation for just a scanline or two will corrupt its contents unless you turn it off at the exact right time, or let it turn itself off naturally at the bottom of the screen redraw. It's almost certainly easier to just save the 256b shadow copy of OAM and re-upload it.

Quote:
Edit: Offtopic but I just read that the decay is affected by temperature. Could there be a NES thermometer?
Probably! But it'd require a lot more characterization than we've done yet.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 9:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20851
Location: NE Indiana, USA (NTSC)
Perhaps instructions' cycle counts in the original interpreter for RCA 1802 might inform roughly how long we have for each instruction in an interpreter on NES or Game Boy, including sprite blits, though we probably don't need to be anywhere near cycle accurate. Is that interpreter archived anywhere accessible?


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 10:10 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
lidnariq wrote:
orlaisadog wrote:
I've just realised that OAM memory will decay if forced blanking is used. Could sprites be turned on occasionally during emulation to keep it refreshed or would there not be enough time?
What would you be using OAM for here? The CHIP-8 "sprites" seem to be more accurately called a bitblit operation...

Turning on sprite evaluation for just a scanline or two will corrupt its contents unless you turn it off at the exact right time, or let it turn itself off naturally at the bottom of the screen redraw. It's almost certainly easier to just save the 256b shadow copy of OAM and re-upload it.

Quote:
Edit: Offtopic but I just read that the decay is affected by temperature. Could there be a NES thermometer?
Probably! But it'd require a lot more characterization than we've done yet.

It could be as as extra RAM if we do forced blanking most of the time.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 10:34 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7802
Location: Seattle
Well, that's why you wouldn't use the OAM shadow, but why do you need OAM at all?

Also, you can store the OAM shadow in ROM, although that's wasteful and constrains what you can show.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 10:37 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
lidnariq wrote:
Well, that's why you wouldn't use the OAM shadow, but why do you need OAM at all?

Also, you can store the OAM shadow in ROM, although that's wasteful and constrains what you can show.

I mean the OAM itself as extra RAM. We can do forced blanking during game logic.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 10:48 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7802
Location: Seattle
Oh, gosh. That's certainly clever, but given that OAM isn't readable on older PPUs (2C02A,B,C,D,E, most Famicoms) and OAM can only be accessed sequentially on the 2C02G (writes to OAMADDR cause corruption), I doubt it's practical.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 10:49 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
lidnariq wrote:
Oh, gosh. That's certainly clever, but given that OAM isn't readable on older PPUs (2C02A,B,C,D,E, most Famicoms) and OAM can only be accessed sequentially on the 2C02G (writes to OAMADDR cause corruption), I doubt it's practical.

Oh, OK.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 10:59 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
Is anyone considering making this?


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 11:02 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7005
Location: Canada
Why don't you give it a shot?


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 11:08 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
rainwarrior wrote:
Why don't you give it a shot?

orlaisadog wrote:
I don't have enough experience yet- I know a lot about how the NES works in theory from browsing the forums but can't do much assembly. I could do it myself one day, probably.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 11:11 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7005
Location: Canada
That one day could be any day you choose, even today.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 11:14 am 
Offline
User avatar

Joined: Thu May 31, 2018 11:12 am
Posts: 153
Location: Bristol, England
rainwarrior wrote:
That one day could be any day you choose, even today.

But I have to learn first, and that could take a while.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 11:23 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7005
Location: Canada
This project would take more than one day even if you were already an NES expert. Learning will add more time, but consider it still part of the project.

Anyhow, if that's not the answer you were hoping to hear, I will just say that most people have their own projects they're interested in, and have no reason* to want to fulfil your wish. There are always a lot more interesting ideas around than there are capable developers to implement them. If you're hoping to get a wish, you need to wish for something a lot smaller than this project. You'll find a lot of people here are very willing to help you learn by answering questions.

* I'd do it for a suitable wage.


Top
 Profile  
 
PostPosted: Sun Jul 15, 2018 11:50 am 
Offline
User avatar

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


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: Google [Bot] and 2 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