It is currently Mon Jul 22, 2019 3:00 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 154 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 11  Next
Author Message
PostPosted: Mon Dec 05, 2016 10:01 am 
Offline
User avatar

Joined: Sat Jul 04, 2009 2:28 pm
Posts: 141
Location: Wunstorf, Germany
@byuu
Thanks. Also I recall that on the 1CHIP some (but not all) games that use mid-screen mode changes cause sync glitches where the mode change occurs.
I'm guessing(!) that the APU was simply fixed but the rest of the phenomena probably just stem from changes in the analog world where the levels are off, maybe caused by a different manufacturing process for the die.

Oh, and $2100 is a strange beast either way. Still haven't quite figured out the DMA/HDMA weirdness that seems to surround it. Didn't verify against 1/1/1 and 1CHIP yet though.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 10:35 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8488
Location: Seattle
calima wrote:
My usb keyboard has 1ms latency. The OS overhead can be expected to be less than half a ms.
USB keyboards are usually low speed (1.5Mbit/s) devices, which operate on a 100Hz timebase—unlike high speed (12Mbit/s)'s 1kHz timebase. Are you sure about that latency figure?


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 11:06 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 956
lidnariq wrote:
USB keyboards are usually low speed (1.5Mbit/s) devices, which operate on a 100Hz timebase—unlike high speed (12Mbit/s)'s 1kHz timebase. Are you sure about that latency figure?

I haven't measured, going by the reported specs.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 2:41 pm 
Offline

Joined: Sun Sep 30, 2012 3:44 am
Posts: 83
dougeff wrote:
For me, the lack of compiler is the least of my worries. I'll use ASM (ca65).

My main concerns are...
-no specific GUI tool for working with SNES graphics
-music (SPC programming)
-I had to read multiple, very large technical documents just to print "Hello World" on the screen.

But, at least we have 2 decent SNES emulators with debugging tools (thanks guys)

Oh, and I still need to buy a flash cart. RetroUSB is out of SNES PowerPaks, and Krikzz doesn't take PayPal... so I'm not sure what I'm going to do there (I don't like paying for online things with credit cards).


YYCHR supports 3bpp and 4bpp SNES graphics. I think it's windows only tho.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 2:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21510
Location: NE Indiana, USA (NTSC)
My NES and Super NES project templates include a converter written in Python that converts an indexed PNG to 2bpp, 3bpp, or 4bpp tiles. This lets you use any paint program you want as a tile editor, so long as it supports indexed color (such as GIMP or Graphics Gale, not Pyxel Edit).

Code:
# Format 0 is 1bpp; it has a shorthand -1
./pilbmp2nes.py --planes "0" ascii.png ascii.chr
./pilbmp2nes.py -1 ascii.png ascii.chr

# 0;1 is NES format: bit 0 then bit 1, interleaved by tile
./pilbmp2nes.py --planes "0;1" sonic.png sonic.chr

# 0,1 is Game Boy (or Super NES 2bpp) format: bit 0 then bit 1, interleaved by row
./pilbmp2nes.py --planes "0,1" sonic.png sonic.chrgb

# 0,1,2,3 is Master System/Game Gear format:
# bit 0 then 1 then 2 then and 3, interleaved by tile
./pilbmp2nes.py --planes "0,1,2,3" sonic.png sonic.chrsms

# 0,1;2,3 is Super NES 4bpp (or TG16 background) format:
# bit 0 then bit 1, interleaved by row, then bit 2 and bit 3, interleaved by row
./pilbmp2nes.py --planes "0,1;2,3" sonic.png sonic.chrsfc

# 0,1;2 is Super Mario World format:
# bit 0 then bit 1, interleaved by row, then bit 2, interleaved by row
./pilbmp2nes.py --planes "0,1;2" sonic.png sonic.chrsmw

# 0,1;2,3;4,5;6,7 is Super NES 8bpp format for mode 3:
# bit 0 then bit 1, interleaved by row, then bits 2 and 3 similarly, 4 and 5, and 6 and 7
./pilbmp2nes.py --planes "0,1;2,3;4,5;6,7" sonic.png sonic.chrm3

# 3210 is Genesis format: bits 3-0, packed
./pilbmp2nes.py --planes "3210" sonic.png sonic.chrmd

# 76543210 is Super NES mode 7 (or GBA/DS 8bpp) format: bits 7-0, packed
./pilbmp2nes.py --planes "76543210" sonic.png sonic.chrm7

# 10 hflip little is Virtual Boy format:
# bits 1 and 0, tile horizontally flipped, bytes in reverse order
# the GBA BIOS has a function to upconvert this to GBA 4bpp format
./pilbmp2nes.py --planes "10" --hflip --little sonic.png sonic.chrvb

# 3210 hflip little is Game Boy Advance/Nintendo DS 4bpp format:
# bits 3, 2, 1, and 0, tile horizontally flipped, bytes in reverse order
./pilbmp2nes.py --planes "3210" --hflip --little sonic.png sonic.chrgba


So use PNG as your master format, and have your makefile (or other build tool) run the converter whenever the PNG file changes. The one drawback of this workflow is that it's more useful for original software rather than hacks of someone else's proprietary ROM.

But then you might actually want something Super NES-specific, such as ability to remove duplicate tiles from a screen or convert a single image that uses multiple palettes. I haven't yet provided that.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 3:48 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1060
Kismet wrote:
RAM and Flash memory do not have the same speed as Mask ROM, which is another unknown variable. So what might be fast on a software emulator becomes sluggish on a real SNES with a flash cart due to using the SRAM as workspace.

What do you mean? Unless I'm mistaken, the S-CPU doesn't respond to wait states. All the timing is on-die. If the memory is too slow, you get errors, not slowdown.

calima wrote:
My usb keyboard has 1ms latency. The OS overhead can be expected to be less than half a ms. Does it really matter when a frame is 16.666ms? It's slower than a SNES controller, but in any visible way?

It's not just input latency, though that's not always as good as you'd expect. It's the whole chain from input to display.

I once played F-Zero in emulation extensively when I was away from home and didn't have a TV, and when I came back for the holidays I booted up the real thing and immediately drove into a wall due to learned latency compensation. This caused me to swear off playing F-Zero in emulation. I've noted distracting jump precision issues in Super Mario World and pilot-induced oscillation in Super Mario Kart, for the same reason. And I just tried F-Zero again, and yep - pilot-induced oscillation. The controls feel horribly stiff and muddy.

It's real, and it's substantial. There's even an article about it on byuu's site. (Although near the end he seems to be claiming something about latency perception that I know isn't true, because I've messed with software synthesizers and I know what the difference between a 5 ms ASIO buffer and a 20 ms ASIO buffer feels like (even for a single keypress - so no, it's not just jitter I'm sensing). Also, I can feel the latency in Mario Golf on a real N64 on a CRT. Just because you can't repeat an action faster than a certain timeframe doesn't mean you can't perceive gaps smaller than that timeframe, or target a particular instant more precisely for a single action. Now, if he just means that the difference between 100 ms and 83 ms is immaterial, there may be a case for that...)

It kinda makes me worry about the public perception of classic NES and SNES games when I realize that most people playing them nowadays are using either emulators or HDTVs (and I'm sure the NES Mini is framebuffer-based, which adds a frame of latency before the TV even gets involved). I bet if you actually asked some of these people, they'd say Super Mario Bros. 3 has issues with control tightness, and put it down to the ancient technology of the NES rather than the modern technology that's actually the source of the problem...


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 5:19 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 774
93143 wrote:
Kismet wrote:
RAM and Flash memory do not have the same speed as Mask ROM, which is another unknown variable. So what might be fast on a software emulator becomes sluggish on a real SNES with a flash cart due to using the SRAM as workspace.

What do you mean? Unless I'm mistaken, the S-CPU doesn't respond to wait states. All the timing is on-die. If the memory is too slow, you get errors, not slowdown.

Correct, the CPU has no concept of the memory state, it just reads the data on the bus at a specific rate. If the memory isn't fast enough, you just get undefined values, which can cause glitches, or crashes, but not slowdown. Also, modern SRAM/NOR Flash are considerably faster than the specced access times of the S/NES MaskROM's (for example, a Micron M29F160 has an access speed of 55ns), so it's a complete non-issue for the most part, unless you're dealing with really old obsolete parts or some really slow voltage translation buffers.


Quote:
It kinda makes me worry about the public perception of classic NES and SNES games when I realize that most people playing them nowadays are using either emulators or HDTVs (and I'm sure the NES Mini is framebuffer-based, which adds a frame of latency before the TV even gets involved). I bet if you actually asked some of these people, they'd say Super Mario Bros. 3 has issues with control tightness, and put it down to the ancient technology of the NES rather than the modern technology that's actually the source of the problem...

Don't the old-school Mario games have a ~4 frame input delay anyway? I would never describe Mario controls as "tight".


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 5:24 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 1177
Location: Hokkaido, Japan
93143 yeah that's why I don't like emulators when playing for fun, being it Virtual Console, NES Classic Edition or free ones for PCs. Playing on emulators for development purposes are great though.

byuu wrote:
> In every single one of those cases, I would refuse to speculate on the behaviour of a SNES Jr. without specifically testing on one. Apparently they're a fair bit different internally. Even the ASP brightness change trick doesn't work properly...

As I've said before, I can't prove it, but my guess is higan is closer to a real SNES than the SNES Jr is.

They really made radical changes to the PPU's mid-scanline behavior. Which turns out to be fine since only ASP actually does anything with it.

People seem unwilling to group the SNES Jr into the clone category simply because it's official hardware, yet they don't seem to have that hangup with the official NES Classic device.

Depends on how you define clone. I think most people think a clone is when outside people try to mimic the hardware of another. No matter how much they change it's still not a clone in that case.
But yeah Nintendo almost always release an inferior version of their systems full with ridiculousness. The Famicom got the New Famicom that removes the microphone and the NES got the toploader missing a bunch of things, then we have the SFC Jr and late N64 without the EXP port, late Gamecube without the analogue output port (and removed the unused exp port), the backlit GBA SP AGS-101 (ok that one was actually better then the original SP I guess) and finaly the worst of all, the Wii without Gamecube backwards compatibility. The NES is also often jokely called the most accurate Famiclone.


koitsu wrote:
Pokun wrote:
Another thing I don't like about the Powerpak is that it only supports CF cards which are getting harder to come by here, and are also quite expensive.

So buy an SD-to-CF adapter? I say this without having tried one. I should also point out that I asked bunnyboy many years ago about why he went with CF over SD (SD at the time was around/available). I don't remember the exact quote, but his explanation was that CF was a lot easier to interface with (either in the FPGA code or circuit-wise, I don't know) than SD.

Good point about the SD-to-CF-adapter, didn't knew about those.
The explanation I always heard about using CF is that it will allow much faster loading since the Famicom/SFC CPU has to do the job. But then the Everdrives came out using SD and booted games at least as fast as the Powerpaks did (except the ones that use flash).
Another flaw of the Super Powerpak is that the vertical bar on the screen is supposedly more pronounced on it due to noise.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 6:34 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2536
Location: DIGDUG
Quote:
Don't the old-school Mario games have a ~4 frame input delay anyway? I would never describe Mario controls as "tight".


I believe SMB uses bit shifting to calculate current speed, so ...acceleration + bit shift = zero for the first few frames. Deceleration is also a bit sluggish.

Modern games would use floating point speed and position, thus immediate response to input.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 9:20 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 1060
qwertymodo wrote:
Don't the old-school Mario games have a ~4 frame input delay anyway?

No.

Maybe the original SMB did something with acceleration that had that result when walking or running, but jump timing? No way. I believe SMW has a 1-frame delay on jumps, and the NES games were certainly not more sluggish than that.

Quote:
I would never describe Mario controls as "tight".

This may be a terminology issue. I always found SMB3's controls to be extremely responsive and immediate on real hardware; I never felt like I was fighting the controls like I did with SMB. But if you think "tight" means no inertia or something, then I agree it isn't like that.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 10:16 pm 
Offline

Joined: Wed Nov 30, 2016 9:59 pm
Posts: 57
93143 wrote:
qwertymodo wrote:
Don't the old-school Mario games have a ~4 frame input delay anyway?

No.

Maybe the original SMB did something with acceleration that had that result when walking or running, but jump timing? No way.

Quote:
I would never describe Mario controls as "tight".

This may be a terminology issue. I always found SMB3's controls to be extremely responsive and immediate on real hardware; I never felt like I was fighting the controls like I did with SMB. But if you think "tight" means no inertia or something, then I agree it isn't like that.


I don't remember where it was, but someone developed another kind of AI to play SMB, and found that they had latency issues when reading off the analog output over the emulated input they developed against. Claiming that there is no latency, or not perceptible latency in a television is just marketing. There is always latency, and it always depends on how a circuit is routed.

On a 1970's, early 80's TV (whom the RF converter was for) I in fact played the NES on, there is no perceived latency because this is what both the Famicom/Super Famicom and NES/SNES were designed against. RCA composite inputs didn't start appearing on televisions as standard until the 90's (N64, PS1.) By that time 3D comb filters were what started adding latency.

Any scanline delays inside the console are not perceptible until you try playing the exact same unit on a LCD monitor and discover that anywhere from 1 to 6 frames being buffered through the various stages used to decode, scale and stretch. When you go back to the CRT it's like "wow is that LCD ever rubbish." Right now you're better off with a "gaming" monitor than an expensive TV, due to the propensity for manufacturers to make "smartTV"'s and all the extra latency added by having that junk in it. People buy smartTV's to watch Netflix, not much else.

At any rate, we will never see a return to CRT screens, so we may as well not chase that optimization.

_________________
I come from the net. Through systems, peoples and cities to this place.


Top
 Profile  
 
PostPosted: Tue Dec 06, 2016 4:42 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 956
I couldn't find any mention in Google about a N64 edition without the bottom exp port. You sure it exists?


Top
 Profile  
 
PostPosted: Tue Dec 06, 2016 5:00 am 
Offline
User avatar

Joined: Sat Dec 01, 2012 4:10 am
Posts: 70
The Pikachu Edition doesnt have the EXP Port


Top
 Profile  
 
PostPosted: Tue Dec 06, 2016 7:02 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1505
> It's real, and it's substantial. There's even an article about it on byuu's site. (Although near the end he seems to be claiming something about latency perception that I know isn't true...)

Everyone misinterprets that point.

I've experienced the latency effect myself. I was playing Ninja Gaiden Trilogy on my real SNES + Sony PVM. I had every move timed to avoid taking any damage until stage 6-1. But I got tired of one loss to Jaquio restarting the entire level, so I switched to emulation to save state between each 6-N stage. And my timing was entirely off. I was getting hit constantly. Took a while to adapt to the new timings for everything. But I did, and I was right back to not getting hit at all until 6-1.

My point was more in line with people claiming they can totally tell the difference between lossless CD-quality audio and 24-bit 192KHz audio. Everyone wants to imagine themselves as some kind of god with superhuman abilities.

The thing with Ninja Gaiden is that I relearned how to play it and was back to not noticing it at all. It didn't make the game much harder.

I put a latency value for input polling into v101, and one thing you can do is raise it as high as you want. The difficulty of games doesn't start to go up until you reach around 80-100ms from the default of 5ms. (note that this is *added* latency to the rest of the chain.)

So the takeaway from that section of the article was: don't let perfection be the enemy of good. Shaving off 16ms of latency isn't going to turn your average game into a perfect world record-setting game.

It might be important if you're beating Tetris: Grand Master, or doing a no-hit Touhou game run. But for 99.999% of gamers, it's not the end of the world and proof you should go spend $1500+ buying old game systems, flash carts, CRT monitors, etc.

> Now, if he just means that the difference between 100 ms and 83 ms is immaterial, there may be a case for that

It's the same thing. 16ms is 16ms.

> and finaly the worst of all, the Wii without Gamecube backwards compatibility

Don't forget the Wii Mini without component output (composite only) and without internet connectivity.

You would really think consoles would become better in time as costs fell, not worse. Of course, now they're starting to (New 3DS, PS4 Pro, Scorpio). So now I have no idea when the best time to buy a system is :/


Top
 Profile  
 
PostPosted: Tue Dec 06, 2016 8:20 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 1177
Location: Hokkaido, Japan
byuu wrote:
> and finaly the worst of all, the Wii without Gamecube backwards compatibility

Don't forget the Wii Mini without component output (composite only) and without internet connectivity.

You would really think consoles would become better in time as costs fell, not worse. Of course, now they're starting to (New 3DS, PS4 Pro, Scorpio). So now I have no idea when the best time to buy a system is :/

I didn't forget about the RVL-201 Wii Mini, I just lumped it together with the RVL-101, and it's just so ridicilous that I didn't even wanted to mention it. I forgot about the GBA Micro though, it had lots of stuff removed including disabling most of the GBz80 I think. I don't know if DS had any though? The DSi is closer to a sequel console rather than a new model (same goes for New 3DS). The closest thing for 3DS would probably be the 2DS so far, but it's released more as a budget alternative for children.


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

All times are UTC - 7 hours


Who is online

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