andreaorru / laines Goto Github PK

Pretty tired of having to reconfigure the joystick every time I open this :)

BRK is a two-byte instruction, so PC is incremented twice before being pushed, not just once.

Sources:
http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=BRK
http://nesdev.com/the%20%27B%27%20flag%20&%20BRK%20instruction.txt
and blaggr's instr_test_v5

Is this a known issue?

../lib/include/Blip_Buffer.h:230: void Blip_Buffer::end_frame(blip_time_t): Assertion `( "Blip_Buffer::end_frame(): Frame went past end of buffer", samples_avail() <= (long) buffer_size_ )' failed.

It happens here:

#4  0x00007fffed56903d in Blip_Buffer::end_frame (this=0x7fffed5ce0c0 <APU::buf>, t=29783) at ../lib/include/Blip_Buffer.h:229
#5  0x00007fffed568e31 in APU::run_frame (elapsed=29783) at ../src/apu.cpp:45
#6  0x00007fffed55da7d in CPU::run_frame () at ../src/cpu.cpp:273

For context, I was working on a libretro port of your emulator core, but I do not think that is the issue here. The frame count is always at 38 when this crash happens. I'm testing with SMB1 (World).

?

Not sure what I meant for this 2 years ago. Investigate.

Hi,
maybe I'm wrong (if so, sorry for that), but I can't find the two extra circles, if a branch goes to a new ram page. (see: http://obelisk.me.uk/6502/reference.html#BCC )

should this:
template<Flag f, bool v> void br() { s8 j = rd(imm()); if (P[f] == v) { T; PC += j; } }

be maybe something like this:
template<Flag f, bool v> void br() { s8 j = rd(imm()); if (P[f] == v) { T; if(cross(PC, j)) {T;T;} PC += j; } }

Thank you

Micro Machines won't work!

Steps to reproduce:

Build OS X version
open lines and open a directory with 40+ rom files
try going to the last one.

Result: while it does select the rom, it won't show it on screen so you have no idea which rom you picked.

It would be quite nice (especially for development of the emulator, but also for development of homebrew and/or examining commercial games) for some amount of debugging capability. I could imagine, variously:

• ROM Header Viewer
• CPU State Viewer
• PPU State Viewer
• Tilemap RAM Viewer
• Palette Viewer

Etc. ( example: http://www.fceux.com/web/assets/debugging_environment_1900px.png )

I don't know if this aligns with the goals of the project or not.

The directory re-org seems to have broken several games

Is it possible to modify this code to remove all frame limiting mechanisms? For instance, if I wanted to adapt this library to allow a machine learning algorithm to process game data at something close to 1000 frames per second (rough number), would that be doable?

Removing the frame limiting mechanism in the run function of the GUI appears to provide some speedup, but are there other modifications to potentially boost this further?

I'm going to change it into a two-player-online-game.Could you give me some advice?

Refer to the relevant sections of:
http://nemulator.com/files/nes_emu.txt

http://wiki.nesdev.com/w/index.php/PPU_OAM

Enable/disable, left edge, etc...

Hello,
I didn't manage to build the project on Ubuntu
More precisely, "scons" provokes 404 errors

Any idea how to fix?
Can you please provide a build executable for people who have the same issue?
Thanks!

Hey, I recently stumbled across your project because I am currently fiddling around with emulators myself and got to say, that I really like your simple, clean interface :) Just wanted to recommend setting the SDL_HINT_RENDER_SCALE_QUALITY hint to 'nearest' instead of 'linear' which (on my opinion) looks way better when upscaling the window.

This has been proposed on /r/emulation and Hacker News. I think there would be a lot of value in it. Prioritize.

Building on OSX for me needed some extra flags in the SConstruct.

Error:

>  scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
clang++ -o src/Sound_Queue.o -c -O3 -march=native -std=c++11 -Wno-unused-value -Isrc src/Sound_Queue.cpp
In file included from src/Sound_Queue.cpp:4:
src/Sound_Queue.h:9:10: fatal error: 'SDL2/SDL.h' file not found
#include <SDL2/SDL.h>
         ^
1 error generated.
scons: *** [src/Sound_Queue.o] Error 1
scons: building terminated because of errors.

I get a successful build with:

diff --git a/SConstruct b/SConstruct
index d9b6582..e95887f 100644
--- a/SConstruct
+++ b/SConstruct
@@ -1,6 +1,6 @@
 from os import environ
 
-flags = ['-O3', '-march=native', '-std=c++11']
+flags = ['-O3', '-march=native', '-std=c++11', '-I/usr/local/include', '-L/usr/local/lib']
 
 env = Environment(ENV       = environ,
                   CXX       = 'clang++',

But it also has a bunch of build spam like:

clang: warning: argument unused during compilation: '-L/usr/local/lib'

for every unit that doesn't need SDL. I'm an ignoramus when it comes to scons so posting an issue vs a pull request in the hope someone else knows how to resolve that trivially.

This is an absolute priority in order to remove the dependency from boost and Blargg's stuff.

Battery-backed RAM should be saved in a file. This is pretty important.

Hi!
Nice project. "1000 lines of code" is really hacker-style :))
Please remake it into UWP app for Win11/XBox Compatibilty ;)

Is a Windows build an eventual goal of LaiNES?

Hi, there appears to be a global buffer overflow caused by line 187 here:

Because n is allowed to be 8, the next loop iteration where n == 8 overflows the secOam buffer because it can only hold 8 elements.

Starting a game of puzznic, when you move a piece, LaiNES exits with code 1. Invalid opcode?

See description

http://wiki.nesdev.com/w/index.php/NMI

At least check if it compiles correctly.

I find cycles of instruction don't match the information is list here.
for example:

ADC<imm>() :
inline u8  rd(u16 a)            { T; return access<0>(a);      }
#define G  u16 a = m(); u8 p = rd(a) 
inline u16 imm()   { return PC++;                                       }
template<Mode m> void ADC() { G       ; s16 r = A + p + P[C]; upd_cv(A, p, r); upd_nz(A = r); }

it only ticks once, but in that link this ins need two cycles

 +----------------+-----------------------+---------+---------+----------+
  | Addressing Mode| Assembly Language Form| OP CODE |No. Bytes|No. Cycles|
  +----------------+-----------------------+---------+---------+----------+
  |  Immediate     |   ADC #Oper           |    69   |    2    |    2     |