Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Koh1Fds

Pages: [1] 2 3 4
EverDrive N8 / Re: Mapper 8 why?
« on: December 22, 2018, 05:56 PM »
GoodNES romset have a lot of roms with bad iNes headers. This is one of them. But most emulators have build-in rom's data base. So when you load a rom with bad iNES header then emulator uses rom's check sum to find it in database. If rom have bad iNes header - emulator uses info from database instead. So most of the times you can't notice that you have Bad Rom. But, obviously, as far as i know, everdrive don't have such database.

EverDrive N8 / Re: Mapper 8 why?
« on: December 17, 2018, 04:27 PM »
Try to change iNes header of the rom. You can do that with Nestopia for example.

News / Re: EDN8 OS v20-BETA. Large update incoming
« on: November 23, 2018, 11:13 AM »
I got random crash in "Donkey Kong Jr. no Sansuu Asobi" (game without mapper) on Rev 07, but i'm not sure if it's caused by Rev 07.

News / Re: EDN8 OS v20-BETA. Large update incoming
« on: November 20, 2018, 05:57 PM »
Is it know what version of os are the best for AV Famicom if i don't care about fds sound?  ;D

News / Re: EDN8 OS v20-BETA. Large update incoming
« on: November 11, 2018, 02:13 PM »
That's not only mine issue as you can see. Also, i'm using 100% unmodified AV Famicom (console that was recommended on everdrive's buying page). Then make so everdrive's os properly initialize that address.

Also, that glitch was mentioned by YogiTheMonk. He said that if he uses original cart then everything sounds perfect.

News / Re: EDN8 OS v20-BETA. Large update incoming
« on: November 03, 2018, 08:05 AM »
This just was mentioned on best of nes marathon. I didn't found this reported anywhere on everdrive forum. So if this a repeat then i'm sorry.

Defender of the Crown game have inaccurate catapult sound effects on everdrive. On real cart and emulators catapult makes like chacka chacka chacka sounds. And on everdrive it makes straight psshhhhhhhh noise (no separate chacka chacka chacka sounds)
I tested same rom on everdrive v20 R7 and emulator and difference are there. So it isn't caused by different rom versions. Here is examples of the sounds: - everdrive - real cart

Also, Defender of the Crown are mmc1 game.

edit: if it's necessary i can post everdrive savestate for that part of the game. Makes testing easier

EverDrive N8 / Re: Save states and how they work?
« on: November 02, 2018, 06:24 PM »
Yep! I didn't test it, but i'm 99.999% sure if roms have same name then save-states gonna overwrite each other. Like if you launch rom from /roms/by-developer/nintendo/Super Mario Bros.nes directory and make a save-state and then if you go and launch /roms/by-release/1985/Super Mario Bros.nes and load save-state - it would loud save state made with /roms/by-developer/nintendo/Super Mario Bros.nes rom.

But this should help you to deal with it:

EverDrive N8 / Re: Emulation Speed Setting
« on: October 24, 2018, 06:11 PM »
Because it's not 10% slower, but almost 20% slower.  ;)  10 fps of 60 fps = 16.7% slower

EverDrive N8 / Re: Emulation Speed Setting
« on: October 23, 2018, 07:42 PM »
>but seems like while some ntsc roms will have major graphics issues on pal console
Some games can even crash or doesn't work at all on PAL nes. You need PAL Famiclone instead. PAL Famiclones designed to run NTSC games at "50 fps"

Also, pal nes shifts pitch of different audio channels differently LUL So ntsc games sounds just horrible on Pal NES because of that. Pal famiclones doesn't have such issue. All channels shifts at the same rate on pal famiclones. So they stay in the same "tonality".

edit: here is example of NTSC game played on such famiclone

EverDrive N8 / Re: Emulation Speed Setting
« on: October 17, 2018, 04:34 AM »
Most nes carts are made from 3 main parts:
1. PRG memory chip = contains all game's code
2. CHR memory chip = contains all game's graphics
But because NES can only "see" not more than 32kb on PRG chip and 8kb on CHR - most of the carts also contains let's call it "memory control" chip. Basically, let's say developers want to use 16kb of graphics instead of 8kb. They put 16kb CHR chip into cart and then they also have to put memory control chip in it. And that's memory control chip's job to split those 16kb into two 8kb parts suitable for the console. That's very basic anatomy of the nes cart. Also, because 32kb and 8kb are extremely little - there was a lot of different types of those memory control chips made in the life span of nes.

And now how everdrive works. Everdrive basically have two re-writable memory chips as PRG and CHR. So when you start a rom on everdrive - rom splits into two parts (CHR and PRG) and those parts loads to chr and prg chips. But because there are a lot of types of those memory control chips then everdrive should somehow recreate those. I'm pretty sure that's FPGA's job to basically EMULATE all of those different memory control chips for different games. That's it. That's my attempt to explain how everdrive works )

And when you "increase speed" of emulation you basically increase FPS! of emulator. So if you want to do something like this on the console you have to modify console so it outputs more fps (or less fps). But that wouldn't work actually.

EverDrive N8 / Re: Initial RAM State
« on: October 08, 2018, 12:01 AM »
Yeah! I'm bad at English ;C Sorry. You didn't understand what i said :C

>However, in US Metroid the "random value", regardless of what the value is, will not cause Polyps

Because it's not current "random value" that determines what those Polyps gonna do, but rather last bit of RESULTING VALUE of the XOR operation between 002D and 002E!!!
Let's say before you changed anything last bit was always 0 no matter what. When you changed 002D or 002E then maybe now that bit are always 1. That's why those polyps only changed their direction. Because they gets different value now, but that's value still never changes. It's just always 1 for now.
This is US version of the game with only 1 important change. Now 002E calculates exactly like in JP version. And now resulting value after XOR between 002D and 002E can have different last bit every frame. This fixes all enemies in the game.

edit: Ok. Let's simplify it. Depending on the starting value of 002D - resulting value of the XOR will always have 0 or 1 as the last bit. Because of that all enemies that should be random aren't random in US. Fire balls flies by the same trajectories, jumping guys jump at the same height etc. And if so happen that last bit always 0 then let's say fire balls shoots to the left and jumping guys always jump low. If last bit always 1 then let's say fire balls always flies to the right and jumping guys always jump high.

EverDrive N8 / Re: Initial RAM State
« on: October 07, 2018, 04:47 AM »
Ok. I can explain to you what's going on in details)

There are some enemies and projectiles in Metroid that uses 002D and 002E addresses to calculate their patterns / trajectories. They do XOR (something like bit to bit logic "or" operation) between those 2 values and resulting value determine what those enemies should do. Usually it's just a last bit of resulting value that important. 002D are just a frame counter and random 002E value calculates by taking previous 002E value and like calculating new value from that.

Let's check specific enemy in japanese version first:
Notice how those "fireballs from the ground" flies all over the place in different directions. So this means that resulting value after XOR between 002D and 002E can have different "last" bit (0 or 1)

And now let's check same enemy in US version:
Notice how all those fireballs flies in the SAME direction! This happens because developers for some reason changed how "random" 002E value calculates in US version and now when game do XOR between 002D then game always gets same last bit in resulting value.

So it's like if (depending on starting 002D value) game gets 0 as the last bit after XOR then it gonna get same result no matter on what frame XOR calculation happens until you take a death or do a reset. That's because when you die game drops 002D and 002E calculations for a few frames. And now those values are shifted exactly by 1 frame of calculations comparing to each other. So if like before death after XOR game always gets 0 as the last bit in resulting value then after death it always gets 1 as the last bit after XOR. So this is actually a bug in US version of the game  ;)

edit: and also also also. When Nintendo made SMB3 they reused a lot of ideas from previous games like Metroid, Japanese version of SMB2, Doki Doki Panic etc. There are 1 enemy in SMB3 that was clearly inspired by Metroid enemy and that enemy in SMB3 uses behavior as enemy from US version of metroid.

EverDrive N8 / Re: Initial RAM State
« on: October 06, 2018, 04:49 PM »
It's not that easy to actually show what bad and good "pattern" means, because it's only noticeable late in the game. So it would take too much time to demonstrate that in that video. Also, every Metroid speedrunnner knows what that means and that video was made for speedrunners  :)

EverDrive N8 / Re: Initial RAM State
« on: October 03, 2018, 04:57 PM »

Seems like Metroid on NES toploader always give bad pattern from power-on with real cartridge, but everdrive gives a good pattern every time. It depends on starting value in 002D address.

edit: i don't know exactly how everdrive works, but i think it doesn't initialize ram on purpose. It just overwrites some parts of the ram to show that menu, etc. So it's understandable that maybe it's impossible to make such option like fill ram with FF or 00 

Pages: [1] 2 3 4