News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: slidelljohn (a.k.a.[J]) snes projects page  (Read 1412 times)

slidelljohn

  • Full Member
  • ***
  • Posts: 178
    • View Profile
slidelljohn (a.k.a.[J]) snes projects page
« on: January 01, 2019, 10:46:14 pm »
Welcome To My Projects Page!

I currently have 2 important projects that need to be finished and released.

Project #1 Gradius 3 (fast rom about 99% complete, sram support work in progress)

I have a near complete Gradius 3 fast rom. All assembly is complete there is just some data that still needs
to be changed to fast rom locations but it shouldn't really affect the speed much. There is definitely a noticeable
amount of decreased slowdowns but it still doesn't remove all slowdowns. Here is the patch:

http://www.mediafire.com/file/cg9yg9tpce03ytk/Gradius_III_%2528U%2529_%255B%2521%255D_%257BFast_Rom%257D.rar/file

I also added extra difficulties that you can unlock by holding L, R, Y, and B buttons at the same time when you go into the
option menu. There are 4 new difficulties which are elite, master, expert and pro. Normal, hard and arcade are slightly easier.
Elite difficulty is the same as the original arcade difficulty but master, expert, and pro are gradually harder with pro as the
hardest.



The lastdual helped me with this patch by checking for bugs that I might have missed. There could still be some bugs so let me
know if you find any. I really need someone to try and beat the hardest level to see if there are any bugs in the gameplay.

My main goal for gradius 3 is to remove all slowdown, add sram and make it feel like a competition cart. I also want to add
a new system for calculating your score after each boss kind of similar to super punch out. Now fast rom will never remove all
of the slowdowns so I have been learning about the sa-1 chip. I do have a gradius 3 rom that is updated to use the sa-1 chip but it
does not load gradius 3's assembly yet. I have been gradually changing the assembly code to store all wram data into bw-ram for
the sa-1 chip to work properly, this is near complete. When I complete the wram to bw-ram change I'll start working on getting
the sa-1 to load most of the assembly. I plan on having the snes cpu live in wram so the cpu's don't collide so I can get the full
speed out of the sa-1 chip. I have no clue how long this is going to take but I chose gradius 3 for this because it is a small rom.
I hope everyone enjoys the fast rom patch and the extra difficulties.





Project #2 New snes mod chip called Super V-Power! (v = vram) (100% working but could still be improved)

This mod chip is for adding extra vram to the snes. The snes has 64kb of vram but the ppu is capable of using 128kb of vram.
Creating this mod chip kind of just fell in my lap. I did not figure out the ppu can use the extra vram and I'm not really sure who
did but byuu made higan v1.00 and up capable of using the extra vram because he said it should be possible. You can see how I ended
up creating this mod chip on byuu's forum. Byuu's forum is gone but it has been completely archived here:

http://helmet.kafuka.org/byuubackup2/viewtopic.php@f=16&t=1559.html

All of the mod chip stuff is at the end of that page but you can see how it ended up getting made from reading everything from the
beginning. I also modified a snes debugger to show the extra vram in the vram viewer so there is a debugger that's supports the extra
graphics. The link to the debugger is on that 1st page. Qwertymodo was a really big help in showing me how to create the castellated
holes to mount the pcb to the snes and he helped me in how/who to send the pcb to to get made. The entire pcb I designed myself and
created in eagle cad. Im getting ready to create a updated version of the super v-power mod chip and when its finished I'll upload
all of my schematics. Im not interested in making any money off of the mod chip it will be fully open source for anyone to make it if
they want to. I do have a few mod chips that Im willing to give away for free to people that have the skills and want to create hacks
that use the extra vram. If anyone has a fully working level editor for a snes game and would like to add this feature to their editor
I would be willing to modify the game that uses their editor to use the 128kb of vram. I already have a mmx v1.1 rom that fully supports
the extra vram but I need to write a editor from scratch to be able to use it. As far as all my searching online I am the only person
to try and get 128kb of vram to work on the snes. I was trying to get analog to get their super nt to support the extra vram but I
didn't have any luck probably because nothing uses the extra vram yet. One day they might add support for it.

Here is my mod chip installed on the snes motherboard:



If I can get the sa-1 hack completed it would set me up for a project that will blow all other projects that I have worked on away,
which is, mega man x with sa-1, 128kb vram and a new engine to have game play like super metroid.



Moderators:
Hopefully it was/is ok for me to talk about this chip here because it could be a game changer for future snes rom hacks. If I broke any
rules let me know and it wont happen again and I'll delete the Project #2 post.




« Last Edit: January 02, 2019, 01:10:16 am by slidelljohn »

niuus

  • Jr. Member
  • **
  • Posts: 28
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #1 on: January 04, 2019, 02:37:53 pm »
Wow. I find your mod chip project one of the most interesting things i've seen for a long time on the SNES scene (since the MSU-1, for me). Please, more info! I've read the thread, it does sound really amazing.  :beer:
« Last Edit: January 04, 2019, 03:01:43 pm by niuus »

darkmoon2321

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #2 on: January 04, 2019, 08:54:24 pm »
Interesting.  Gradius III is a fun game that I played through a few times back in the day.  The game would slow to a crawl every time one of those big serpent creatures was on-screen though.  Out of curiosity, have you done any kind of analysis on the code to figure out why it is lagging so badly in the first place?  I haven't looked into the game's code myself, though I might take a look now.  My guess is that it would be significantly easier to correct some inefficient code rather than try to convert over to SA-1.  If it's an issue of graphics decompression, there is also the route of placing decompressed graphics directly in the ROM and bypassing the decompression routine, particularly for commonly used images.

slidelljohn

  • Full Member
  • ***
  • Posts: 178
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #3 on: January 04, 2019, 09:20:17 pm »
More info you got it 8)

I have some more pcb components on the way from China as soon as these come in(about 2 weeks) I’ll be able to see if I’ll be able make the upgrade that I would like to do. I’m going to try to split the pcb into 2 pcb’s. One pcb I’m going to try and put header pins on it to mount it around the cpu and the ppu1 and it will have all of the resistors, transistors, status leds, a couple switches and a connector for a flat ribbon cable on it. The other pcb will only have the two ram chips and a connector for a flat ribbon cable. The second pcb I will also drop the castellated holes for a bga setup. I think this setup will make everything a lot cleaner and professional looking. Now this 2 pcb setup probably won’t work on the 1st released motherboard that has the vertical ram chips because you have to solder directly to the pins on the cpu and ppu but I might be able to figure something out for that one.

With my current setup for the pcb using the cpu unused i/o ports I haven’t found any games that don’t work properly. Without using those ports from the cpu there are games that don’t work properly with the major one being super mario world 2.

All of the major details are in the link to byuu’s archived forum. I have good pictures for mega man x1 showing what the original 64kb of vram looks like and what the upgraded 128kb of vram looks like and it has the patch for mmx1 and the nSide debugger to create hacks for it.

Currently the only games I plan on hacking with the extra vram are mega man x1 and the 7th saga. The only other games I’ll probably add the 128kb of vram to is one that someone has a level editor for that they are willing to add support for the extra vram.

darkmoon2321:
Yes I looked into some of it but I still need to do more research on that. From what I was seeing the slowdown is caused by the algorithm for the sprites. Yes removing compression does speed things up but not really during gameplay mostly when levels are loading. I have mmx1 and 7th saga that I have removed all graphics compression and gameplay still slows down but level loading is way faster. I already have 100% of gradius 3 asm disassembled and most of the data mapped out so interesting things are being worked on to improve the game.

I could release the disassembled asm for gradius 3 but I’m not really sure what the right way is to release it. Can I release a text file with all of the asm on romhacking.net without getting in trouble or do I need to write a program that rips it out of the game?
« Last Edit: January 04, 2019, 09:32:35 pm by slidelljohn »

darkmoon2321

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #4 on: January 04, 2019, 10:30:19 pm »
I could release the disassembled asm for gradius 3 but I’m not really sure what the right way is to release it. Can I release a text file with all of the asm on romhacking.net without getting in trouble or do I need to write a program that rips it out of the game?

I'm pretty sure you can release it here.  There are a few complete disassembly documents on the site already.  I don't see any for SNES titles yet though, so that could be a first.  I did go ahead and get a trace log on some of the lag, and I can see where it happens, but you're probably miles ahead of me if you already have a full disassembly.

Edit: I did a little more research into this.  The sprite drawing code does consume a lot of processing time, and I think it is possible to make it run more efficiently.  However, that's not the only issue.  On the lag trace that I got, the game didn't even reach the sprite drawing routine before it was interrupted by the next NMI.  It appears that collision detection is occupying the largest chunk of time, in my test case approximately half of an entire frame.
« Last Edit: January 05, 2019, 05:12:01 pm by darkmoon2321 »

lastdual

  • Jr. Member
  • **
  • Posts: 66
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #5 on: January 05, 2019, 07:36:22 pm »
Good luck with that vram project! It sounds really ambitious :beer:

I've done a number of side-by-side tests with the Gradius 3 fastrom hack and the improvement is noticeable, though as slidelljohn stated there is still slowdown. However, when combining the hack with an emulator that allows for overclocking (such as the Snes9X 2010 Libretro core for RetroArch), the game is virtually slowdown-free. It's pretty awesome after all these years to play one of the first 16-bit shmups the way it was meant to be played. Gradius 3 is a personal favorite of mine (I prefer the SNES version--that soundtrack is gold), and seeing it running so smooth (also flicker-free using the above emulator) is a real treat.

slidelljohn

  • Full Member
  • ***
  • Posts: 178
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #6 on: January 07, 2019, 10:05:27 pm »
I'm pretty sure you can release it here.  There are a few complete disassembly documents on the site already.  I don't see any for SNES titles yet though, so that could be a first.  I did go ahead and get a trace log on some of the lag, and I can see where it happens, but you're probably miles ahead of me if you already have a full disassembly.

Edit: I did a little more research into this.  The sprite drawing code does consume a lot of processing time, and I think it is possible to make it run more efficiently.  However, that's not the only issue.  On the lag trace that I got, the game didn't even reach the sprite drawing routine before it was interrupted by the next NMI.  It appears that collision detection is occupying the largest chunk of time, in my test case approximately half of an entire frame.

I'm still not sure about the rules for releasing the full disassembly but Ill probably end up writing a program that can extract it. I do have the main function for gradius 3 that I used to pinpoint the slowdown that I found.
Here is a text file of the main function:
http://www.mediafire.com/file/36ld5ftx8tq24b5/gradius_3_main_function.txt/file

In the main function if this line ($80/82A2 22 F1 8E 80 JSL $808EF1[$80:8EF1]) is nop'ed reload the cart from the begging and
just let the game play until the ship crashes. It should crash around 2 minutes and 31 seconds. Now if you let the game play
without removing that line the game will crash around 2 minutes and 46 seconds. So just that one line of code eats up 15 seconds.
Not sure if the collision detection is loaded from that line but I recall 2 or 3 sections of code that shows the slowdown.

I definitely wouldn't mind teaming up and try to make the code more efficient. I would think there is room for improvement especially when the programmers do stuff like this
Code: [Select]
$80/8223 C2 20       REP #$20
$80/8225 C2 10       REP #$10

instead of this
Code: [Select]
$00/0000 C2 30       REP #$30
I do have a lot of stuff that I am working on right now so I am not sure when I'll have a chance to look at the code again
but improving the code is definitely something that I would like to do.

Good luck with that vram project! It sounds really ambitious :beer:

I've done a number of side-by-side tests with the Gradius 3 fastrom hack and the improvement is noticeable, though as slidelljohn stated there is still slowdown. However, when combining the hack with an emulator that allows for overclocking (such as the Snes9X 2010 Libretro core for RetroArch), the game is virtually slowdown-free. It's pretty awesome after all these years to play one of the first 16-bit shmups the way it was meant to be played. Gradius 3 is a personal favorite of mine (I prefer the SNES version--that soundtrack is gold), and seeing it running so smooth (also flicker-free using the above emulator) is a real treat.
Thanks! I still never tried RetroArch. I guess all the hacking I do eats up all of my free time. :D

I got one of the parts that I was waiting on to see if I can improve the super v-power mod chip and I came up with something even better. I wanted to split the chip into 2 chips so I wouldn't solder wires directly to the board but as I was testing everything I came up with the idea of having one pcb wrapping around the cpu and the ppu so there would be no wires and no ribbon cables. This will only be possible by getting a custom injection molded header pin that connects to the cpu pins, ppu pin, and all of the vram pins. I found a company that can make the custom header pin for me but its going to take some time to get all of the correct measurements for the holes. If I can get this done I can add a bonus to the super v-power mod chip. I can add the super cic chip to the super v-power as well because it also has a hole for every pin for the cic chip. Imagine a all in on 128kb vram and super cic. This is turning out way better than I expected.

Here is a image showing all of the holes for all of the pins for the 2 vram chips and the cic chip. url image is large:
https://imgur.com/ONDw8XG

Here is a paper cutout to give everyone a idea of the shape of the new pcb design with the super cic added:
https://imgur.com/KCgeDEM

After I get the pcb shape and the holes correctly mapped out in eagle cad I'll see about getting the custom header pins made.
My schematics and custom header pins will all be open source when they are ready.

One of the bsnes plus developers is currently working on adding the super v-power capabilities to the bsnes plus debugger so
hopefully soon we will all have a really good debugger for future rom hacks that can use this new unused hidden feature for the original snes console. :woot!:

« Last Edit: January 07, 2019, 11:34:59 pm by slidelljohn »

darkmoon2321

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #7 on: January 08, 2019, 11:48:05 am »
In the main function if this line ($80/82A2 22 F1 8E 80 JSL $808EF1[$80:8EF1]) is nop'ed reload the cart from the begging and
just let the game play until the ship crashes. It should crash around 2 minutes and 31 seconds. Now if you let the game play
without removing that line the game will crash around 2 minutes and 46 seconds. So just that one line of code eats up 15 seconds.
Not sure if the collision detection is loaded from that line but I recall 2 or 3 sections of code that shows the slowdown.

That function does indeed call the sprite handling code.  I wrote a simple program that parses through Geiger's trace logs and counts the number of times each line of code executes so that I can find good targets for optimizing code.  The collision detection code that I identified before spans 80/EA7A to 80/EC3C.  From the main function, it is reached the line before the sprites, so ($80/829E 22 8E 87 80 JSL $80878E).  I'm not entirely sure if collision detection is all this code does, but it appears to be a significant part of it.  If you're interested in the short program I made, source is here: https://www.dropbox.com/s/0x3p0p9hsp3dmcm/geiger_trace_frequency_counter.cpp?dl=0

I can take a quick look at optimizing the sprite display code a bit, I have a better understanding of that than the collision code at the moment.

slidelljohn

  • Full Member
  • ***
  • Posts: 178
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #8 on: January 08, 2019, 07:13:45 pm »
I cant seem to download that file from dropbox. The web page just shows a white screen. It says
the server is encrypted.

I think this is all of the assembly that is used for the sprites at $80:8EF1:
http://www.mediafire.com/file/h444w9o6k5vm64d/gradius_3_sprite_assembly_0x008ef1.txt/file

I have some notes on some lines in the text file but they are not complete as I was still in the process
of documenting them before I took a break on this project.

« Last Edit: January 08, 2019, 07:26:32 pm by slidelljohn »

ExL

  • Jr. Member
  • **
  • Posts: 28
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #9 on: January 10, 2019, 01:00:25 am »
Use this link instead - https://www.dropbox.com/s/0x3p0p9hsp3dmcm/geiger_trace_frequency_counter.cpp?dl=1
"dl=0" prevented you from downloading. But just in case I've reuploaded it here: https://mega.nz/#!7V0hUIpB!BfP0jc1Hx2qDfP0ivSh6JGblVSHSMEvgSRcAwNjuMOk
I'm just passing by, with no knowledge on subject, but that looks very interesting ::) I hope snes9x and other emulators will add support for Super V-Power and that'll lead to lagless hacks comfortably played everywhere :thumbsup:

slidelljohn

  • Full Member
  • ***
  • Posts: 178
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #10 on: January 10, 2019, 07:31:37 am »
Thanks ExL! I didn’t know what was going on with that link. ;D
The Super V-Power mod chip isn’t actually for helping with lag but a creative programmer could speed up some things with it.

I sent the new pcb design for the Super V-Power mod chip to the manufacturer but I’m going to have to do a few test before it’s ready to show off the new version of it. Hopefully within the next 2 months I’ll have something ready to show. The new design is gonna be crazy! :o
« Last Edit: January 10, 2019, 07:39:16 am by slidelljohn »

darkmoon2321

  • Jr. Member
  • **
  • Posts: 54
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #11 on: January 10, 2019, 02:23:35 pm »
Sorry about the link, never had that issue with dropbox before.  I did some work on optimizing the sprite routine:

https://www.mediafire.com/file/6ec2cavwn9vuvd3/Gradius3_spriteOptimization.ips/file

Apply this patch on top of your fastROM patch.  It reduces the amount of time spent computing individual sprite tiles by about 10% or so.  Further optimization is possible, but it would likely be at the expense of rom space and provide benefit mainly for large sprites containing lots of tiles.  In other words, creating separate routines for sprites that are vertically flipped, horizontally flipped, both, or neither.  This would eliminate the branch checking for these conditions that occurs for individual tiles right now.

slidelljohn

  • Full Member
  • ***
  • Posts: 178
    • View Profile
Re: slidelljohn (a.k.a.[J]) snes projects page
« Reply #12 on: January 10, 2019, 04:32:42 pm »
About 10%, that’s great!  :thumbsup:
I don’t have time to look at it today but I’ll definitely look at it tomorrow. I may have to put some of my other projects on hold and work on this one some more. I’ll look more into optimizing the asm code, expanding the rom, and remove all compression this weekend. Im also going to submit the complete disassembled assembly tomorrow.

I was able to test your patch right before I left to go to work and it looks like it’s around a .7 second speed up from when the ship first crashes if you let the game play on its own. So yea, definitely around a 10% speed up on top of the fastrom patch. Good work! I am interested in what you did to speed it up but I would probably hold off on the details just in case I can come up with something different to add to it.

Update 1-12-19:
I just now submitted 2 complete gradius 3 assembly documents and they can be seen in the Submission Queue Status Page. Hopefully within 24-48 hours they are accepted. The 2 gradius 3 assembly documents are for banks $00 and $02. Those 2 banks have the assembly for the whole game.  If these get accepted I may start uploading more assembly documents that I have for mega man x v1.1 and the 7th saga.
« Last Edit: January 12, 2019, 08:22:25 am by slidelljohn »