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.
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.
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
- SPC700 for TASM
- (2.13 KiB) Downloaded 193 times
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 . 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
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.
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.
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.
I passed the following games:
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?
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.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?