It is currently Thu Sep 20, 2018 11:16 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 31 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Thu Jun 21, 2018 1:51 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
It just occurred me that maybe a lua script can simulate this automatic switching in emulators... I might give this a try.


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 2:30 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 516
tokumaru wrote:
It just occurred me that maybe a lua script can simulate this automatic switching in emulators... I might give this a try.

Something like this should work for Mesen:
Code:
local mirroringReg = 0xA000
local horizontalMirroring = 1
local verticalMirroring = 0
local lastAddr = 0

function switchNametables(addr) 
  if (addr & 0x3FF) < 0x3C0 then --ignore attribute fetches
    if (lastAddr & 0x20) ~= (addr & 0x20) then
      if addr & 0x20 == 0 then
        emu.write(mirroringReg, horizontalMirroring, emu.memType.cpu)
      else
        emu.write(mirroringReg, verticalMirroring, emu.memType.cpu)
      end 
    end
    lastAddr = addr
  end
end

emu.addMemoryCallback(switchNametables, emu.memCallbackType.ppuRead, 0x2000, 0x2FFF)


Obviously this is just a test (for MMC3) but you should be able to tweak it easily enough for any other mapper.

Result:
Attachment:
smb3.png
smb3.png [ 20.81 KiB | Viewed 1551 times ]


Top
 Profile  
 
PostPosted: Thu Jun 21, 2018 7:40 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
Thanks for the example, Sour!


Top
 Profile  
 
PostPosted: Fri Jun 22, 2018 3:31 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7517
Location: Chexbres, VD, Switzerland
If you can admit lost area at the top of the screen and loosing perhaps some CPU time, you could probably pull it off with some DMC IRQ trickery combined with roughly timed code ? Triggering IRQs each 8 lines and even each 4 lines is possible with this method after all. The problem is that it's extremely though to control where those IRQs will trigger, also they won't trigger exactly each 8 and 4 lines but only a non-integer # of scanlines slightly shorter than that. The fact that high timing precision for $2000 writes can be taken advantage of to some extent so perhaps something smart is possible.

Very likely you'll have to have a time-compensating loop on each IRQ whose waiting time will be pre-calculated and variable each time, and you'll lose up to 25% of CPU time doing this.


Top
 Profile  
 
PostPosted: Fri Jun 22, 2018 11:22 am 
Offline

Joined: Sun Jan 31, 2016 9:55 pm
Posts: 44
I've done some work with DMC IRQs to try to have arbitrary splits -- I wouldn't recommend trying this for this many scanlines. Remember that IRQs happen on their own clock, starting up to 432 cycles after you trigger them. Depending on the alignment you could waste a lot of time on many of the scanlines.


Top
 Profile  
 
PostPosted: Sat Jun 23, 2018 2:38 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
All this talk about custom mappers and such is great, but in the end, that's way too experimental for me. Too many places where things could go wrong, from the mapper design and prototyping, to modifying emulators and even manufacturing carts if the game ever gets completed.

I'm contemplating doing something I also consider crazy, but crazy at the software level, which makes me much more confident. I'll try dividing the rendering logic in my raycaster into fixed-time chunks of 4 or 8 scanlines (whatever works best), so I can alternate name tables in software in between logic chunks. Then, after the 3D view, comes the bottom of the screen with the status bar and such, which doesn't need timed code, so the game/object logic can run during that time.

Dividing the ray casting and texture scaling into constant-timed chunks sounds like a bit of a challenge, but they are extremely repetitive tasks, so it just might work. I do expect to lose some processing time simply making the best cases take as much time as the worst cases, but I'd also lose a lot of time with other software-only solutions, such as using DMC IRQs or generating all patterns on the fly.


Top
 Profile  
 
PostPosted: Sun Jun 24, 2018 12:45 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7517
Location: Chexbres, VD, Switzerland
Good luck having code that is even remotely maitainable... But it's what makes the most sense. If you're already loosing a lot of times to render the screen, you don't want to loose any CPU time waiting for synchronization, even if it is just a little. So I think it makes sense, but you want to make sure your rendering algorithm is set is stone and is not going to be changed once you start coding this... because maintaining it will be a complete nightmare.

You could also aim at constant-time rendering, so that the framerate even if slow will be constant. I think it's a good idea. At least you'll be really pushing the system to its limit.

If you needed to develop a new mapper anyway, you might as well have the mapper doing the ray-casting itself, so I agree it's a bad approach.


Top
 Profile  
 
PostPosted: Sun Jun 24, 2018 1:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7532
Location: Seattle
Bregalad wrote:
If you needed to develop a new mapper anyway, you might as well have the mapper doing the ray-casting itself, so I agree it's a bad approach.
Oh, come on. That's wholly unfair. There's a huge difference between a trivial chunk of discrete logic doing something like the Oeka Kids mapper and a coprocessor.


Top
 Profile  
 
PostPosted: Sun Jun 24, 2018 1:58 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Good luck having code that is even remotely maitainable...

Well, it's just the rendering code, so I don't expect it to change at all once it's working and generating proper results.

Quote:
If you're already loosing a lot of times to render the screen, you don't want to loose any CPU time waiting for synchronization, even if it is just a little.

The strategy I plan on using is basically to unroll the tasks and do as much as possible in 4 or 8 scanlines, and then decide whether to continue in the same block or jump to another one. For example, there'll be a block of code that just extends the ray and checks the map for collisions with walls, and this will be used over and over until a wall is found. If there's enough time to test, say, 6 wall boundaries between scroll splits, I'll have to include wait loops for when a wall is found before the 6 checks, so that the block still takes the same amount of time to finish. That could add up to a lot of lost CPU time, unfortunately.

Quote:
but you want to make sure your rendering algorithm is set is stone and is not going to be changed once you start coding this... because maintaining it will be a complete nightmare.

Not much worse than an Atari 2600 kernel, I suppose.

Quote:
You could also aim at constant-time rendering, so that the framerate even if slow will be constant. I think it's a good idea. At least you'll be really pushing the system to its limit.

With the different amounts of distances rays have to travel, the different heights of the walls, and the varying amounts of enemies and their proximity to the player, I think that'd be very hard, and wasteful. I have to believe that these things are going to compensate for each other (e.g. a longer ray that takes more time to cast will result in a smaller wall that takes less time to texture), and design the levels in ways that avoid too much heavy processing in the same spot.

Quote:
If you needed to develop a new mapper anyway, you might as well have the mapper doing the ray-casting itself, so I agree it's a bad approach.

That doesn't sound particularly fun to me. I want to see the NES do all the work, not just have the PPU pump out the pixels.


Top
 Profile  
 
PostPosted: Sun Jun 24, 2018 10:19 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
I've been giving some more thought to this and the constant-timed rendering chunks will end up wasting much more CPU time than I anticipated. Not only will I constantly have to "do nothing" when the task finishes too soon, but I'll also waste lots of time in NTSC if I plan on supporting PAL consoles, since PAL scanlines are shorter. The most sensible thing to do would be to just bite the bullet and go with the MMC3. If I'm doing something complex, there's no shame in using a more complex mapper, and if I insist in chasing crazy alternative solutions I'll probably just be shooting myself in the foot.

Thanks for all the replies. I particularly liked lidnariq's idea of constructing a simple custom mapper, and I even learned a bit more about mapper design from it, so thanks for the suggestion!


Top
 Profile  
 
PostPosted: Sun Jun 24, 2018 11:19 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7532
Location: Seattle
tokumaru wrote:
I particularly liked lidnariq's idea of constructing a simple custom mapper, and I even learned a bit more about mapper design from it, so thanks for the suggestion!
I've been occasionally tempted to make a special emulator build that has all these wacky experimental hardware designs. To keep the scope sane, it'd have to be only hardware that uses a small handful of 74xx ICs.

What with Mesen having a useful debugger and running on Linux I might even get around to it.


Top
 Profile  
 
PostPosted: Sun Jun 24, 2018 11:43 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
That'd be really cool! I really like to read/talk about these cool little mapper ideas, but for someone who's not very experienced with hardware, the idea of physically constructing these cartridges to test their viability is a bit daunting. The very few times I tried, things didn't go well. The possibility of simulating these ideas before actually constructing anything sounds great.


Top
 Profile  
 
PostPosted: Mon Jun 25, 2018 6:54 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20562
Location: NE Indiana, USA (NTSC)
The other option is to write an emulator that supports mappers written in WebAssembly or some other intermediate language that can be JIT-recompiled. Someone in the GBDev Discord server discussed making an emulator that supports exactly this.


Top
 Profile  
 
PostPosted: Mon Jun 25, 2018 8:15 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3127
Location: Tampere, Finland
tepples wrote:
The other option is to write an emulator that supports mappers written in WebAssembly or some other intermediate language that can be JIT-recompiled. Someone in the GBDev Discord server discussed making an emulator that supports exactly this.

I don't think having JIT-compiled mappers is very useful. Mapper development for emulators is easy enough by compiling offline. What lidnariq is proposing (being able to simulate the mapper hardware in an emulator using a predefined set of readily available hardware components) would provide a very simple transition path from simulation to hardware, maybe lowering barrier of entry for people who might be unsure what kind of mapper designs would be feasible on hardware.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jun 25, 2018 10:34 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7532
Location: Seattle
Oh, no, sorry, nothing so sophisticated. I was just observing that Mesen definitely gives me enough rope, its mapper descriptions are succinct enough, and it has a highly-useful debugger, such that I could easily manually make the full set of "what if I attach a latch in this weird place" mappers.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users 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