upernes

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: upernes

Post by mikejmoffitt »

I'm not intricately familiar with the SNES's DMA, but msot DMA units will let you change the post-increment value. Does the SNES's DMA truly not allow this?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: upernes

Post by tepples »

VMAIN has three increment modes: one adding 1 for horizontal transfers, one adding 32 for columns of mode 0-6 nametables, and one adding 128 for columns of mode 7 nametables. Writing to VRAM uses whatever increment mode is set in VMAIN, regardless of whether it's through PIO or DMA.
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

Writing in VRAM would do it with the 32word increment. But I must have my column in a continuous array in ram.
Maybe it can work with an indirect HDMA mode and tables?
However making a copy of 30 words to a transfer buffer can be quick, I made one of 128Bytes from the sprite buffer and it took 5 rendering lines. Maybe doing it by software is not that bad. I must try it.
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

I added the APU emulation today. I tried to use the source code of Memblers emulator but it seemed not up to date on the 65816 side (I could not load the SPC700 code, and used the routine form the NSF player ROM instead). And I do not have the assembler for the SPC700 code.
Therefore I used directly the binary data extracted from the NSF player big ROM using the memory dump of the SPC700 RAM and an hex editor to cut it out.
However I must find out what it does to emulate $4015 and other register updates.
The update_dsp routine works, but I need to understand what it does to the APU registers during the interrupt on the 65816 side. The APU emulation routines from the NSF player ROM and from the source in 2a03-src.zip are different.
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: upernes

Post by Memblers »

If it helps, here is a link to the assembler I used for SPC700: http://6502.org/tools/asm/tasm301.zip
Attached to this post is the needed instruction table. Command to assemble is "tasm -t700 -b -a spc.asm"

Sorry the source release was a mess, the original project is too (1,944 files all in a single directory).

It tracks register updates in the "detect_changes" subroutine. The RAM at $7F4116 has some flags to tell the SPC when $4003,$4007, etc. were written. The trick is, the value the NES code writes to $4003,$4007,etc. has to be non-zero for it to be detected! This works out because the length counter bits must be non-zero for there to be sound anyways.

The length counters are emulated on the 65816 side, and this adds some extra handling to the $4015 register. The program uploads $4015 to the SPC, masked with the length counter result bits, like this:

Code: Select all

        lda $7F4115  ; length counter enable flags, sent to SPC
        and $7F4015 ; what the NES program wrote to $4015
        sta $7F4115
If I can get upernes to build over here, I'd like to take a shot at improving the sound quality. The main thing I'd like to try is using longer samples for the waveforms, because the short samples are extremely affected by the SPC's interpolation.
Attachments
TASM700.zip
SPC700 for TASM
(2.13 KiB) Downloaded 274 times
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

Thank you Memblers, I used the disassembly windows of bsnes+ and two of the procedures are exactly the same as the source zip. Only the code loading the binary on the SPC700 is clearly different. And the fast rom init sets slow rom in the source code.
I will check if what I have from the two other routines and the source code are the same.

Tasm may help, thanks.

I could not understand what 4116 was for. I though it was the gamepad data :D. I was confused by this value.
Your 4 routines are already in Sound.asm, only two of them work and my backup register offsets are a mess in var.inc because I have an hardcoded ram @ after them (not enough reserved space). But by removing the unused backup registers, it should begin to work.
I will work on this tomorrow.

I you have a windows 64bits, you do not need to compile upernes. If the exe runs, it should be fine, the development is mostly in the asm files. (If the SDL graphic window showing the progress makes problems it can be removed)

About my progress:
Today I tried to update columns instead of using the DMA and even with loop unrolling it takes about 15 rendering lines instead of 4, and it glitches.
A way to improve the nametable transfer would help a lot, maybe by converting vertical scrollers like Xevious first. Lines updates are easy using the DMA. Column updates are tricky.
Maybe it could work by preparing the data from column to line after the sound emulation code. If enough cycles are available there. Or by preparing an HDMA table for colums.

My smb1.txt file to disassemble the indirect jump areas:

Code: Select all

##########################################
# smb1.nes

crc32:	$F2DB8422

DisableIndJumpPatching

SoundEmuLine: $97

IndirectJump: $06
addr: $8231
addr: $8FCF
addr: $8567
addr: $858B
addr: $859B
addr: $8652
addr: $865A
addr: $8693
addr: $86A8
addr: $86E6
addr: $93FC
addr: $88AE
addr: $92DB
addr: $9B0E
addr: $9A2E
addr: $85BF
addr: $85E3
addr: $8643
addr: $86FF
addr: $8732
addr: $8749
addr: $9061
addr: $8245
addr: $9131
addr: $B069
addr: $B0E9
addr: $B35A
addr: $AEDC
addr: $8FE4
addr: $889D
addr: $9071
addr: $AEEA
addr: $B376
addr: $C2F1
addr: $C8E0
addr: $CA77
addr: $98E5
addr: $B36D
addr: $BDD2
addr: $BC85
addr: $B233
addr: $9B01
addr: $BB38
addr: $B269
addr: $9B41
addr: $91CD
addr: $B245
addr: $9B14
addr: $B27D
addr: $B1E5
addr: $96C5
addr: $9B19
addr: $9A50
addr: $99F2
addr: $B94B
addr: $98AB
addr: $970D
addr: $B206
addr: $9AB7
addr: $999E
addr: $9218
addr: $C8D6
addr: $9806
addr: $D2D9
addr: $C30E
addr: $BDD8
addr: $9968
addr: $9A59
addr: $D311
addr: $B2A4
addr: $B3CF
addr: $B2CA
addr: $D2F2
addr: $D312
addr: $D34E
addr: $D3A2
addr: $9882
addr: $9224
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

I updated the variables used in sound emulation, the routines code is identical from what is in the ROM (except 2 or 3 areas were it did not branch and were I do not have the disassembled code). Not tested yet.
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

I added the two last procedures. It improved a lot the sound :!: I have a problem with the noise channel, and weird effects sometimes. Probably wrong offsets in some registers.
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

I improved the background update by writing directly into VRAM instead of having a buffer+DMA. But it does not update everything because a VRAM write is not possible during rendering. And when this occurs on a screen change where a lot of writes are made, the screen is messed up because the writes after line 0 fail.

I could try the HDMA transfer:
A 4byte transfer to the VRAM gate static addresses, first 2bytes are the VRAM@ and the next 2 bytes are the data. I will take the data from the ram buffer.
Every update @ and data must be written in the table.

Actually it works well but the attribute table refresh lags because it must use the rolling DMA update.
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

The BG update works perfectly now on SMB1 :!: :D :beer:
The trick was to properly emulate ForceVBLANK. The nes code forces vblank before updating the screen. I was not emulating it because it was easier to debug BG data, but is was time to add it.
Now it works. The VRAM update is made during the register write emulation and not during vblank. It saves 4 more lines during VBLANK.

Sound seems to have an initialisation problem, I must check the registers initial values.
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

I was cleaning the scripts and tried to convert other roms like Xevious. And I have a bug in sprite 0 irq handling.
I checked the other mappers, and with some more work any mapper 0 game will pass. Mapper 2 should also pass.
However mapper 4 will probably never work wel because of the CHR bank switching. It could be done for a specific game but not for automatic conversion.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: upernes

Post by tepples »

I'd like to see your results for Concentration Room, Thwaite, and RHDE. It should be OK to upload videos of those games to major video hosts, as they won't trigger Content ID.
Patrick FR
Posts: 78
Joined: Tue Jan 19, 2010 10:35 am
Location: Lyon

Re: upernes

Post by Patrick FR »

Hello I tried your roms and it did not work because uperness lacked bit Io emulation. The bit instruction is used on the ppustatus. But since, I improved many things (see the commits), and thwaite works except the controller buttons, I do not know why. Croom seems to work, same controller problem (weird theme you chose for this game).
I passed the following games:
ExciteBike 100%
BalloonFight 100%
Pinbal Nametable bug at start but everything is fine then.

Pacman: control keys also messed up.
Xevious begins to do something but it behaves like writing the Nametables during rendering. Is it possible????

Battle city does not work well, like it is using sprites from the 2 CHR banks at the same time. Pinbal swaps sprite and backgorund banks between the title screen and the game, but Battle City is like switching sprite banks during rendering. Weird behaviour, does anyone have information about this?
Last edited by Patrick FR on Mon Aug 14, 2017 12:22 pm, edited 1 time in total.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: upernes

Post by tepples »

Thanks for trying them.

Hi-Def NES also had problems with the controller reading routine I use in most of my games the first time Kevin tried it. It interleaves reading bits from controller 1 and controller 2.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: upernes

Post by AWJ »

Patrick FR wrote:Battle city does not work well, like it is using sprites from the 2 CHR banks at the same time. Pinbal swaps sprite and backgorund banks between the title screen and the game, but Battle City is like switching sprite banks during rendering. Weird behaviour, does anyone have information about this?
8x16 sprites on the NES use both pattern banks simultaneously. The sprite bank select in $2000 is ignored, and instead the LSB of each sprite's character index is used as the bank number for that sprite.
Post Reply