Official topic for RockNES releases. ^_^;;
Website:
http://rocknes.web.fc2.com/Latest version is
5.54 September 23rd 2017.
Code:
What's new for version 5.54 (09/23/2017)
----------------------------------------
- Improved Famicom Disk System PPU IRQ timing (thanks Sour).
- Fixed "Skip Disk System license screen" option, working ok.
- Fixed scanlines in NSF mode (while playing a tune & drawing circles).
- Fixed version number in the file properties.
- Minor fixes and improvements.
1) Final version need these external libraries to run (again):
- libgcc_s_dw2-1.dll
- zlib1.dll
Old betas
have same problems, but you've fixed it on RC4.
2) "misc -> videos resolution -> fullscreen options" not implemented yet? (this window hangs)
3) set
vertical retrace GUI bug since RC4.
4) MMC3 hell again. Bucky O'Hare for example:
After demo-play, press start.
title screen glitches + lifebar shakes + text color wrong (i can show where is)
On 5.20 RC4 this game work correct.
Kick Master, Monster in my Pocket crashes emulator due to unofficial opcode, first game also have graphical glitches
I don't know what's wrong with Bucky O'Hare... just that screen (mirroring error?) after the 1st gameplay demo.
With Kick Master, most unexpected. I traced the CPU code and I don't know either.
Yup, I fixed a couple of mistakes in the MMC3 IRQ - Mickey games (Letterland/Numberland) are working again, plus a problem with the IRQ logic in the PPU registers.
Quote:
I don't know what's wrong with Bucky O'Hare... just that screen (mirroring error?) after the 1st gameplay demo.
1) Lifebar shakes
2) Press (and hold) "B" on intro to make fast text scrolling and you'll see a bug:
blue text instead white. If you don't hold B, bug not appear. Strange behaviour.
3) ?-about (c) 1998-2015 need to update
4) all stretched blitters (2x, 4x, 4.5x) does some kind of software interpolation:
Quote:
to stretch the image into 640 pixels, the 3rd pixel was being repeated (pattern AABBCCCAABBCCC..., A=1st, B=2nd, C=3rd pixel). Now, it's interpolated.
except 3x, which looks raw. I think interpolation need to be optionally
viewtopic.php?f=3&t=10108&start=15#p124260because old raw stretch method that used in 5.061 to "2x", and used only for "3x" in 5.20, looks better on some machines.
@Eugene.S:
1. I don't know what's up with Kick Master or Bucky O'Hare. -_-;; Still looking for problems...
2. Fixed the color style selection in the GUI, the copyright year, disabled item "view palette ram" and the vertical retrace flag.
3. I couldn't reproduce the problem with misc->palette->set default palette, as you said to be black screen...??
4. About the pixel interpolation, well... I'll see what can be done.
Anything else?
EDIT: oh sh*t! Big thanks to ME for saving the sources of 5.20 RC4. ^_^;; A very obscure bug introduced in the MMC3 IRQ logic. HAHAHA, it's fixed and working like a charm!
New version.
There's more things to do... but I'm taking a short break. ^_^;;
Thanks Eugene.S for the feedback. Just wait for more changes, ok?
Fixed a few things, but I did not change the version number. Keep an eye in the 1st post. ^_^;;
up!
I'm aware of the MinGW dependancy, but it comes from zlib1.dll which I don't know how to remove such dependancy.Fixed. ^_^;;
5.23 is good release, many mmc3 glitches are fixed. Sound volume is really better.
Games that have DPCM-channel sounds distorted on lastest version
(Zen Intergalactic Ninja, Bucky O'Hare, Journey to Silius) if option "use unsigned samples" = 1.
Sound stumbles very often if "Vertical Retrace" or "Triple Buffering" are enabled
Eugene.S wrote:
5.23 is good release, many mmc3 glitches are fixed. Sound volume is really better.
Games that have DPCM-channel sounds distorted on lastest version
(Zen Intergalactic Ninja, Bucky O'Hare, Journey to Silius) if option "use unsigned samples" = 1.
Support for unsigned samples must be improved.
Regarding this:
Quote:
Sound stumbles very often if "Vertical Retrace" or "Triple Buffering" are enabled
Does it occur with the signed waves (default)?
Quote:
Does it occur with the signed waves?
Sorry for false alarm. It occur only on
old laptop cpu (with signed / unsigned samples and even with games lacks DPCM). But on desktop core i7-2600k it works good.
Up! Version 5.24 fixes the unsigned samples, plus a few things.
New version available.
Major news is the APU sound output remixer rewritten.
First post updated, a must read thing.
Quote:
The source code is portable and 100% written by myself
If you keep portability in mind, why RockNES is closed source and limited to windows-only platform?
Great Allegro library is supported on Linux, Mac OSX, iPhone/Android too.
You can take some interesting ideas from abandoned
FakeNES, this is open source NES emulator
that depends on allegro library also.
It also has nice old-look GUI, including many useful features, but emulation is less accuracy than RockNES has.
DOS and Linux versions available too.
I can think of at least four factors:
- You can't legally test Mac software on anything but a Mac, and with Brazil's abnormally high import tariffs, a Mac is probably prohibitively expensive.
- Android devices tend to lack physical buttons. On-screen gamepads tend to be unwieldy, and most Android users don't carry around a DualShock 3 or 4 to use through USB or Bluetooth. Please see the topic Adapting and publishing a handheld game.
- iOS has both the disadvantage I mentioned for Mac and the disadvantage I mentioned for Android. In addition, because Apple requires apps to be self-contained, emulator developers can't release an emulator by itself. Only the publisher of an NES game can actually release the emulator with an included ROM.
- Wine is available for Mac computers made in the past decade, as well as for x86 PCs running an X11/POSIX (e.g. *BSD, GNU/Linux) operating system (either 32-bit or 64-bit with 32-bit multiarch). If Zepper treats bugs filed by Wine users as valid, as the FCEUX team has, only Windows binaries need be published.
Eugene.S wrote:
Quote:
The source code is portable and 100% written by myself
If you keep portability in mind, why RockNES is closed source and limited to windows-only platform?
Great Allegro library is supported on Linux, Mac OSX, iPhone/Android too.
Open source (OS) isn't a
must be instance. I own the choice of keeping it closed sourced for a couple of factors, such as...
The old FCE Ultra (by Xodnizel) has become OS... and abandoned by him. Now we have no emulator, but a hacking tool with debugging features.
It's something supported since 1998, fully rewritten around 2000, and at every step I took the care of producing a 100% code written by me; a few years ago, Matt Conte's 6502 emulator and NSF player skelleton-code was used, for example. No more in present days.
Licensing.
Fear of becoming another OS + abandoned project, much like many others.
Partners. In the past, I had a few ones... but ALL of them vanished, like kritz, katharsis (Geoshock's head) and others.
Lack of objectives. While I know that an OS project is interesting (and I wish to do that), I don't know how to handle it.
Lack of interest in the current project. Well, I don't get any feedback of users, except for a few ones in this forum. So, I don't know how popular RockNES is around the globe.
Quote:
You can take some interesting ideas from abandoned
FakeNES, this is open source NES emulator
that depends on allegro library also.
It also has nice old-look GUI, including many useful features, but emulation is less accuracy than RockNES has.
DOS and Linux versions available too.
No. I prefer to take my own path and my own errors. ^_^;;
If you want to make RockNES more popular, you're need to add some features that are
already *de-facto* standard in all modern emulators (of course it's only my opinion).
Most of these features related to image processing, like linear interpolation (all recent emuls),
prescale nX filter (bizhawk,fceux,mesen,punes), ntsc-filter (if you don't want use blargg or bizqwit code, you can write own), additional modern filters like xBRZ, different TV-aspect ratios, etc.
Other features improve general usability, like netplay, cheats, turbo buttons, stereo/echo/reverb, GUI themes, etc.
Third sort of features override NES hardware limits -> overclock, no_spritelimit (punes/fceux).
PAL and Hybrid (aka Dendy) mode support also in-trend.
ZSNES also has dos-look GUI, but still popular due to these features. FakeNES has most of interesting features too.
P.S.
"Color Style" feature is good thing, i wish good luck to your emulator! And thank you for 18-years active development
Most of these filters require an open source project. So, I wouldn't be able to use any of them in my emulator.
In that case, I would need to write my own code.
The lack of features have a reason - accuracy VS interface/features. I'll see what can be done.
You'd still need NTSC filter for proper accuracy. There's a test ROM called "tvpassfail" that'll make an indistinct mess of colored diagonal stripes on an RGB-modded NES (2C03/2C05, NESRGB, or Hi-Def NES) or a clear-as-day "PASS" on an NTSC NES. And the next version of the 240p test suite for NES will include it.
What you say about open source applies to GPL libraries. But if a library is under the MIT, BSD, or zlib license, you can use it in the same way as Allegro: just credit the author. And for an LGPL licensed library, you need to distribute the library's source code and allow relinking your application with an updated copy of the library. This can be done in one of two ways: either A. make the library as a DLL or B. distribute object files (.o or .obj) to the owner of a lawfully made copy of the application.
Blargg's NTSC filter is LGPL, you don't need to open source your project to use it. It will be difficult to reach the same level of quality and performance with a new implementation (the code is highly optimized).
Proper video emulation (correct aspect ratio + accurate NTSC artifacts) is a must-have for me when I'm just playing.
I'm not being inaccurate if I have the preference for no image filtering.
Even that DirectX automatic interpolation sucks.
Zepper wrote:
I'm not being inaccurate if I have the preference for no image filtering.
It depends... when I plug my NES on my TV, what I see is not an image made of crispy clear pixels, but actually a garbled mess of NTSC artifacts, that actually happen to make a lot of games look nicer than they would otherwise. If you're not emulating the kind of picture the NES outputs, that could be considered an inaccuracy. People who prefer crispy clear images might consider it an enhancement, though...
Regardless of whether this is an accuracy issue or not, the beauty of emulators is that we have the option to configure them the way we want. Different people like different palettes, different resolutions, regardless of how accurate these options are compared to the real hardware. You, for example, offer a lot of settings that have nothing to do with how an NES really is, such as a bunch of color filters, the dotted rendering or the exaggerated stretching, but you refuse to include something the NES really does, which is NTSC video, and I happen to think that's kind of a big deal.
I'm not demanding anything though, it's your emulator and you're free to do whatever you want with it. I'm satisfied enough with the emulators I currently use that I don't have to beg anyone for features.
Quote:
Even that DirectX automatic interpolation sucks.
We definitely agree on that!
Quote:
Fear of becoming another OpenSource + abandoned project, much like many others.
Why do you mean, if the project is opensource, it will be abandoned soon?
--
In 2016, your "decent" dos-like interface is original and unique feature, which give "personal face" to RockNES.
I think more features will make your emulator more popular, if you want this, of course.
tokumaru wrote:
It depends... when I plug my NES on my TV, what I see is not an image made of crispy clear pixels, but actually a garbled mess of NTSC artifacts, that actually happen to make a lot of games look nicer than they would otherwise. If you're not emulating the kind of picture the NES outputs, that could be considered an inaccuracy. People who prefer crispy clear images might consider it an enhancement, though...
If the lack of NTSC artifacts is inaccurate, then the lack of screen curvature is another item to the list of inaccuracies.
Even the video output type (antenna, composite cable) just makes the list even bigger. Am I wrong?
You have somewhat of a point about emulation of RF noise and curvature. But many later CRT TVs have negligible curvature. And if you view an emulated NES game in full screen on a CRT computer monitor, the monitor itself may introduce curvature.
But there's often a valid interpretation of several features being included or ignored.
- Correct 8:7 sample aspect ratio, NTSC filter, no RF, no scanlines, no curvature:
It's an AV Famicom or front-loading NES connected to an LCD through a composite 240p to 480p/720p upscaler such as the Framemeister. - Correct 8:7 sample aspect ratio, no NTSC filter or RF, no scanlines, no curvature:
It's a PlayChoice connected to an LCD through an RGB 240p to 480p/720p upscaler.
Zepper wrote:
If the lack of NTSC artifacts is inaccurate, then the lack of screen curvature is another item to the list of inaccuracies.
Even the video output type (antenna, composite cable) just makes the list even bigger. Am I wrong?
All of this is debatable, there's no definitive answer I guess. The composite signal comes straight out of the PPU, so it's an inherent characteristic of the NES. Curvature is something the TV does, not the NES. I for example have a flat screen CRT TV that doesn't curve the picture at all.
Anyway, like I said, accuracy issue or not, emulation should be about options, because each person wants a different experience. NTSC video might not be essential for playing games, but it is a characteristic that many people remember the NES for, which makes it an important feature to offer players. Way more important than things that were never associated with the NES to begin with, such as sepia colors.
New release available.
See the first post to see what's new & download.
Zepper wrote:
New release available.
See the first post to see what's new & download.
In the Metal Slader Glory intro, the bottom row of pixels in the green text is missing.
It's still unknown if there is supposed to be a horizontal, blue line at the bottom of the box containing the person.
No need to be sarcastic.
It's not sarcasm, it's just a bugtest, as always.
As expected, a bug-fix version.
Sorry.
Some clipping issues (default settings), maybe DPCM problem:
Thanks for the report. I believe it's fixed now.
Thank you
New version will support wallpapers!
OMG
After a HUGE beta testing thanks to Eugene.S, here's RockNES 5.40. ^_^;;
Check the 1st post.
Yeah, again another update to fix some major bugs and problems. >_<;;
You know... I'm on vacation, so I work around 12h per day in this emulator.
You may expect a new update during the day/week.
Aladdin (Mapper 4).7z <Aladdin (SuperGame) (Mapper 4) [!].nes> from GoodNES3.23b
Press Start when prompted results in:
ERROR:
unofficial opcode 62 trapped at PC 62A1!
The emulator has stopped now.
The title screen has a green-ish color instead of black.
If I press start, the game reboots; in the 3rd try, it hangs on PC $0000.
Weird.
Anything special, like WRAM $6000-$7FFF normal or blocked?
EDIT: just select "alternate IRQ" in the General settings, and the game will work.
New version. Check the first post to download it.
I've figured out how RAMBO-1 IRQ timing works. The wiki (discussion page) has been updated.
Rolling Thunder (U.S. version) glitches badly in the latest RockNES, and also uses RAMBO-1.
Untested game, as far as I know... Shinobi, Klax, Skull&Crossbones and Hard Drivin'.
I'll check it out. That's why I didn't make these changes official in the wiki.
Thank you.
(EDIT: strange, a copy floating the net brings mapper 4 in the header, which is incorrect according to the database).
EDIT2: Found the problem, it's a bug setting a 2K CHR page (should be value >> 1).
Rolling Thunder (U.S.) now works, but the status bar text is partially cut off.
Here's a capture from real hardware showing how it's supposed to look --- some glitches at the right-hand side of the screen are there, but no cut-off status line letters. And
this video shows that it's ok for the status bare to shake once when pressing START at the title screen.
NewRisingSun wrote:
Rolling Thunder (U.S.) now works, but the status bar text is partially cut off.
Here's a capture from real hardware showing how it's supposed to look --- some glitches at the right-hand side of the screen are there, but no cut-off status line letters. And
this video shows that it's ok for the status bare to shake once when pressing START at the title screen.
Yes, I know. You should consider a major step of getting RAMBO-1 IRQ timing working for all those games. There's a problem of a scanline which I couldn't figure out yet (probably IRQ_latch+1), and the lack of interest in more people helping me. ^_^;;
On other side, my gfx engine might glitch a few games (see Mega Man 3' scanline on ShadowMan), which needs a rewrite to match what's described in the wiki.
Attached find a Nintendulator source file that runs both
Skull & Crossbones,
Hard Drivin',
Rolling Thunder (U.S. version) and
Xybots like in the various videos I posted. Basically, I am making two assumptions that are not described in the wiki:
- It's not IRQcounter=IRQlatch +1, but IRQcounter=IRQlatch |1.
- The |1 part is only done if the write sequence is C000 C001 E001 (as in Skull & Crossbones). If the write sequence is C001 C000 E001 (as in Hard Drivin'), then the IRQcounter is loaded with the unmodified IRQlatch.
These two assumptions should be testable with real hardware.
Did you read the discussion page?
Yes, and your proposal does not run all games glitch-free (->Rolling Thunder's status bar) while mine does. The "AND $FE" seems to break Rolling Thunder's Status bar.
NewRisingSun wrote:
Yes, and your proposal does not run all games glitch-free (->Rolling Thunder's status bar) while mine does. The "AND $FE" seems to break Rolling Thunder's Status bar.
Did you test Skull&Crossbones? Did you see the scorebar without any glitched scanline?
Thanks a lot to the both of you for your work on this.
I modified Mesen based on the implementation NewRisingSun posted, and it works much better than the hacks that I was using before.
Hard Drivin' is still giving me very minor glitches during gameplay though (e.g I sometimes get a full blue garbage scanline just above the status bar, mostly when crashing into things). Hard Drivin' seems to need tighter timings than all the other games. I noticed you had it trigger the IRQ on cycle 256, but shouldn't that normally be done on clock ~261 (e.g at the time of the first sprite fetch?) - assuming the wiki is correct and the Rambo-1 uses A12 to detect horizontal blank.
I tried keeping the trigger on cycle 260 (like it already was in my code), and reducing the irq delay to 3 or 2 (instead of 4), but that didn't help.
Triggering the IRQ at cycle 256/257 ends up giving me the best results.
Try Klax and look at the bottom.
Bah, now
Klax is imperfect.
Basically, the whole problem is whether after a C001 write, the IRQ counter should be loaded with the latch +1 or with the unmodified latch.
The
NesDev RAMBO-1 wiki article claimed, based on experiments, that it's always +1, although it admitted to a lack of knowledge on where the +1 comes from.
Nocash/
Kevin Horton claim the same.
Klax wants always +1 as well.
Hard Drivin' on the other hand always needs the unmodified latch value.
Skull & Crossbones generally wants latch +1 except for the IRQ just above the status line.
I thought I was onto something when I observed that
Hard Drivin' writes first to C001 and then to C000, while S&C writes to C000 first and then to C001. But
Klax turns out to mix both methods, yet consistently wants +1.
Of course we cannot rule out that there are different revisions of the Rambo 1 chip that behave differently. If I understand the Japanese description of that
Hard Drivin' video I linked to earlier correctly however, the guy modified a
Skull & Crossbones board to put
Hard Drivin on it, which speaks against that theory.
Edit: And
this guy of course put
Hard Drivin' on a
Klax board, so I think we can shelve the the hardware revision theory.
From the Rambo-1 games on NesCartDB there's two kinds of PCBs, one with an extra logic chip and one without. Mapper chip has same markings on all.
Skull and Crossbones and Klax don't have the chip, Shinobi, Rolling Thunder and Road Runner have a 74x32 on them.
In addition to this, S&C and Road Runner have a jumper in different spot compared to others.
The 74'32 is just there to allow the use of a 28-pin 128 KiB CHR-ROM.
I've documented specifics on
nesdevwiki:Tengen RAMBO-1 pinout
NewRisingSun wrote:
Attached find a Nintendulator source file that runs both
Skull & Crossbones,
Hard Drivin',
Rolling Thunder (U.S. version) and
Xybots like in the various videos I posted. Basically, I am making two assumptions that are not described in the wiki:
- It's not IRQcounter=IRQlatch +1, but IRQcounter=IRQlatch |1.
- The |1 part is only done if the write sequence is C000 C001 E001 (as in Skull & Crossbones). If the write sequence is C001 C000 E001 (as in Hard Drivin'), then the IRQcounter is loaded with the unmodified IRQlatch.
These two assumptions should be testable with real hardware.
This strikes me as being unlikely to be the physical implmenentation.
I tried myself to see if I could get any good results using different assumptions.
Here were my assumptions:
1. always use latch+1
2. IRQCounter decrements immediately when reloaded via C001
3. writes to E000 clear IRQcounter as well, and thus a decrement from zero will also load latch + 1 but this will look like just latch
Using these assumptions I got Skull and crossbones and Klax to work glitch free, Hard Drivin has a blue line on the driving sections above the timer, and rolling thunder status bar moves up by 1 scanline when I shoot.
Well, not perfect, but maybe it will give someone else an idea.
Alyosha_TAS wrote:
Skull and crossbones and Klax to work glitch free
Have you checked
all of the glitch candidates I posted here? When you use always latch +0 or always latch +1, you'll either get the garbage line above the status bar (visible only once you scroll down in the introductory level), or corrupted "continue" lettering in the item screen.
I think at this point definite answers from more direct experimentation with the chip are needed. The first thing to study would be to find out the specific circumstances in which writing 0 to both $C000 and $C001 will result in IRQ at the very next clock,
instead of the clock after that, as found in previous experiments. This is the main thing that is important for getting Hard Drivin' working without breaking other games.
Well, my current proposal (wiki discussion page) seems the most correct until now. That's because the IRQ is off by -1 in all games, except Skull&Crossbones. But ya, an hardware test is required.
WHO could do such test, please?
NewRisingSun wrote:
Have you checked
all of the glitch candidates I posted here? When you use always latch +0 or always latch +1, you'll either get the garbage line above the status bar (visible only once you scroll down in the introductory level), or corrupted "continue" lettering in the item screen.
I think at this point definite answers from more direct experimentation with the chip are needed. The first thing to study would be to find out the specific circumstances in which writing 0 to both $C000 and $C001 will result in IRQ at the very next clock,
instead of the clock after that, as found in previous experiments. This is the main thing that is important for getting Hard Drivin' working without breaking other games.
Ah, you're right the glitch line in the item screen is there. Well back to the drawing board i guess.
I agree that hardware testing is needed.
I'd say
kevtris or
James might be the persons to ask for hardware testing. I suggest the following initial list of things to investigate:
- Can it be confirmed that under normal circumstances, in scanline mode, writing 0 to C000 and C001 returns in exactly one IRQ being asserted not at the next A12 rise, but the one after that, as Kevin Horton describes?
- Can circumstances be found under which writing 0 to C001 and C000 causes the IRQ to be asserted at the next A12 rise after all, and not at the one after that? That's what Hard Drivin' needs. Its IRQ handler that does such a thing starts at PC $FDB4. Circumstances could include the order in which registers are written to, or the timing of the register writes relative to what's happening on the A12 line.
- Does it make any difference whether C001 is written before C000, or vice-versa?
- Does writing to E000 or E001 clear the IRQ counter, as Alyosha_TAS suggested?
- Are any of the latch value bits written to C000 ignored, as Zepper suggests on the wiki discussion page?
- Is the prescaler in CPU cycle mode actually cleared every time when writing to C001, as the wiki claims? Is it cleared even when scanline mode is selected?
- Does anything funny happen when switching from CPU cycle to scanline mode? An earlier version of puNES' source code seems to suggest that when switching form M2 to A12 mode, the next M2 falling edge will still clock the chip even as the chip is already in scanline mode (variable tengen_rambo.irq_force_clock in puNES' mapper_Tengen.c, not in the current source code version, tough).
Here's my best result so far. Now, Klax is off by 1 scanline only - all the other games are perfect.
It's better than my suggestion in the discussion page. Here we go.
Code:
writes to $C000: irq_latch=data;
writes to $C001: irq_reload=true; irq_mode=data&1;
writes to $E000: irq_enable=false; IRQ acknowledge by CPU.
writes to $E001: irq_enable=true; IRQ acknowledge by CPU.
When the IRQ is clocked by CPU or scanline modes:
* If irq_reload == true:
irq_counter = irq_latch;
if(irq_latch != 0) irq_counter |= 1;
irq_reload=false;
* Else if irq_counter == 0:
irq_counter = irq_latch;
* Else irq_counter--;
* If irq_counter == 0 and irq_enable == true
irq_delay=4 (IRQ will be fired 4 CPU cycles later)
EDIT: as side note, using
irq_latch ORed with 1 reduces the glitched area in Klax to 1 scanline only, though it STILL requires
irq_latch+1 to work properly, glitch free. As a collateral effect, Hard Drivin' becomes glitched by 1 scanline... and interesting enough, the panel vanishes during the gameplay if the IRQ timing (down counting result) is off by -1. In short words, I couldn't get BOTH games working perfectly. If I fix Klax, then HD' becomes glitched, and so on. I tried to carefully re-read the description by Kevin Horton, but the results weren't good, as the games were really off by
+2. The only interesting part is about
irq_latch!=0, when the
irq_counter must be ORed with 1.
Perhaps it's another race condition with $2006..? Still, is the
irq_counter really counting downward rather than
upward, as I had suggested?
New version. Check the first message.
Zepper wrote:
EDIT: as side note, using irq_latch ORed with 1 reduces the glitched area in Klax to 1 scanline only, though it STILL requires irq_latch+1 to work properly, glitch free. As a collateral effect, Hard Drivin' becomes glitched by 1 scanline... and interesting enough, the panel vanishes during the gameplay if the IRQ timing (down counting result) is off by -1. In short words, I couldn't get BOTH games working perfectly. If I fix Klax, then HD' becomes glitched, and so on. I tried to carefully re-read the description by Kevin Horton, but the results weren't good, as the games were really off by +2. The only interesting part is about irq_latch!=0, when the irq_counter must be ORed with 1. Perhaps it's another race condition with $2006..? Still, is the irq_counter really counting downward rather than upward, as I had suggested?
We have seen how Klax is supposed to work on a real cartridge, but no one has ever seen how Hard Drivin' is supposed to work on real hardware, right? Maybe HD does have a minor 1-scanline glitch that they did not resolve in the prototype.
FrankWDoom has a few TV pictures of his reproduction in
that thread.
There's also this video of it running on a Skull & Crossbones cart on a famiclone:
https://www.youtube.com/watch?v=TWacLAxHZzk
The panel colors are different. There's some yellow-ish on it. Other than that, well, no surprises until then. Both games work with no glitches, but is the exact same board? As I said, Klax requires +1, but HD doesn't.
Zepper wrote:
The panel colors are different. There's some yellow-ish on it. Other than that, well, no surprises until then. Both games work with no glitches, but is the exact same board? As I said, Klax requires +1, but HD doesn't.
How rare are these carts? I'd be willing to pitch in some money towards getting them in the hands of someone who can do some exhaustive hardware testing and pinning down the exact behaviour. Maybe they are slightly different? Maybe the behaviour is still more complicated then we expect?
It would be nice to be able to wrap this issue up definitively and move on. This has wasted the time of numerous devs already with inconclusive results.
Zepper wrote:
Both games work with no glitches, but is the exact same board?
Yes.
Pedantically, there are two subtle variations in the 800032 PCB (called 42826 and 42826-1 by BootGod), but they only have subtle routing differences around
R3 and R4, specifically concerning support of 28-pin 128 KiB CHR. Furthermore, NesCartDB already has instances of Klax and Rolling Thunder on both PCB variants.
Alyosha_TAS wrote:
How rare are these carts? I'd be willing to pitch in some money towards getting them in the hands of someone who can do some exhaustive hardware testing and pinning down the exact behaviour. Maybe they are slightly different? Maybe the behaviour is still more complicated then we expect?
Not terribly rare—I believe I could just pick one up at the local retrogaming store for something around $10 to $20—but I don't have the patience to figure out how to make the test cases to establish what's going on. The most I'd be willing to offer is making a flashcart and sharing logic analyzer traces for each of the games (and any test cases that other people write), showing the exact relative timing of writes, M2, PPUA12, and /IRQ ... but for the games we already know when the IRQs are supposed to be asserted, don't we?
lidnariq wrote:
Not terribly rare—I believe I could just pick one up at the local retrogaming store for something around $10 to $20—but I don't have the patience to figure out how to make the test cases to establish what's going on. The most I'd be willing to offer is making a flashcart and sharing logic analyzer traces for each of the games (and any test cases that other people write), showing the exact relative timing of writes, M2, PPUA12, and /IRQ ... but for the games we already know when the IRQs are supposed to be asserted, don't we?
I'd be willing to write test ROMs, the things that need to be tested are all pretty easy to set up in a clean slate environment.
We know when the IRQ's should be asserted but not how to get the timer to assert IRQs correctly for every game with consistent timer behaviour.
New version. Please, check the first post.