Super Mario Bros on the Genesis
Moderator: Mask of Destiny
-
- Very interested
- Posts: 326
- Joined: Mon Mar 12, 2007 1:53 am
- Contact:
Tasco, here's a runthrough of your second patch.
http://www.youtube.com/watch?v=6_DIdJrZsN8
Not really any changes I see audio wise. Graphically there are some things different, including some what looks to be VSync tearing.
I plan to get a capture card for my Mac today and will try to post some high quality 60fps videos..
http://www.youtube.com/watch?v=6_DIdJrZsN8
Not really any changes I see audio wise. Graphically there are some things different, including some what looks to be VSync tearing.
I plan to get a capture card for my Mac today and will try to post some high quality 60fps videos..
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
hey guys, you don't need to patch my game, I can do it by myself
But, seriously, I have a revision ready to be launched who SHOULD works on the real thing: it fix some bugs, now initialize the controlers, the H40 cheat is gone(useless adition) but now you can set the interlace mode (as requested localh), and the checksum is gone, because makes no sence to have it (anyone can hack it), but those bugs in the real hardware really worry me. In the next revision, I will implemet a buffer for avoid the VRAM reads, but for now, what solutions I have? Should I put some NOPs between each "adress set" and "read" instructions?
But, seriously, I have a revision ready to be launched who SHOULD works on the real thing: it fix some bugs, now initialize the controlers, the H40 cheat is gone(useless adition) but now you can set the interlace mode (as requested localh), and the checksum is gone, because makes no sence to have it (anyone can hack it), but those bugs in the real hardware really worry me. In the next revision, I will implemet a buffer for avoid the VRAM reads, but for now, what solutions I have? Should I put some NOPs between each "adress set" and "read" instructions?
well, patches were more a quick way to test if stuffs are really handle on real hardware as we thought it was, your ROM is also very interesting as it can help improving accuracy of emulators
Regarding VRAM access, here's what official tech bulletins are saying:
Hope that helps, good luck for next releases, I'm sure all the bugs can be ironed out and as you can see, there is a lot of interest for this port !
Regarding VRAM access, here's what official tech bulletins are saying:
Hope that helps, good luck for next releases, I'm sure all the bugs can be ironed out and as you can see, there is a lot of interest for this port !
Where was that memo hiding?
So it seems the delay belongs after the last read. If you reorganize the code, you probably don't need any artificial delays (NOPs or such) -- just move anything you can between the last read and setting the address for the next write. But, using a buffer is a wonderful idea.
And, before I forget, a couple more bugs I spotted:
* In DigitsMathRoutine, OperMode is read from the wrong location (ROM instead of RAM). Probably just a typo. The effect is rather interesting, though.
* In TopScoreCheck at around 'bcc NoTopSc', bad flag check (because SUBQ alters the X flag).
So it seems the delay belongs after the last read. If you reorganize the code, you probably don't need any artificial delays (NOPs or such) -- just move anything you can between the last read and setting the address for the next write. But, using a buffer is a wonderful idea.
And, before I forget, a couple more bugs I spotted:
* In DigitsMathRoutine, OperMode is read from the wrong location (ROM instead of RAM). Probably just a typo. The effect is rather interesting, though.
* In TopScoreCheck at around 'bcc NoTopSc', bad flag check (because SUBQ alters the X flag).
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
One last shot: hackpatch v3. Only fixes for hardware in this one.
Sorry, couldn't help myself.
I believe the tearing evildragon pointed out is caused by updating the scroll values midscreen. I didn't bother myself with that.
Sorry, couldn't help myself.
I believe the tearing evildragon pointed out is caused by updating the scroll values midscreen. I didn't bother myself with that.
cool, what fixes did you add ?TascoDLX wrote:One last shot: hackpatch v3. Only fixes for hardware in this one.
Sorry, couldn't help myself.
I believe the tearing evildragon pointed out is caused by updating the scroll values midscreen. I didn't bother myself with that.
-
- Very interested
- Posts: 326
- Joined: Mon Mar 12, 2007 1:53 am
- Contact:
I basically just rearranged the VRAM code according to the tech memo: plenty of time between the last read and next setting the control reg. Didn't do much more than reorder the instructions, really.
I made sure to spend at least 116 CPU clocks following each read sequence (consecutive reads are not a problem, so says the doc). To get there, I had to insert a very small busy loop. Don't know if that was absolutely neccessary, but I just assumed it was.
As suspected, reading VRAM immediately after writing VRAM is perfectly OK. In fact, here's a piece of it:
Maybe a bit extreme, but apparently it works.
I made sure to spend at least 116 CPU clocks following each read sequence (consecutive reads are not a problem, so says the doc). To get there, I had to insert a very small busy loop. Don't know if that was absolutely neccessary, but I just assumed it was.
As suspected, reading VRAM immediately after writing VRAM is perfectly OK. In fact, here's a piece of it:
Code: Select all
MOVE.L D6,$0004(A6) ; A6 = $C00000
MOVE.L D3,(A6)
MOVE.L D4,(A6)
MOVE.L D7,$0004(A6)
MOVE.L (A6),D3
MOVE.L (A6),D4
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Works great on my Neo Myth. Nice work.TascoDLX wrote:One last shot: hackpatch v3. Only fixes for hardware in this one.
Sorry, couldn't help myself.
I believe the tearing evildragon pointed out is caused by updating the scroll values midscreen. I didn't bother myself with that.