I'll just leave this here...

News from administrators.
User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: I'll just leave this here...

Post by Snowstorm64 » Fri Jan 09, 2015 7:26 pm

LuigiBlood wrote: We have a third owner.

Here's the thing, at the point of the screenshot: It was loading the game data. It was about to load the game and run it.
But something messed up: And I don't find it.
Perhaps it counts how the disk is read, for example the byte order or the speed? Can you try 64DD Sector Viewer on CEN64?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: I'll just leave this here...

Post by Snowstorm64 » Thu Jan 15, 2015 11:33 am

LuigiBlood, how's going with the 64DD development? Some progress?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: I'll just leave this here...

Post by LuigiBlood » Thu Jan 15, 2015 11:43 am

Snowstorm64 wrote:LuigiBlood, how's going with the 64DD development? Some progress?
None. Still stuck at the same point.

Currently waiting for CEN64's debugger so I can find this out.

User avatar
Happy
Posts: 1
Joined: Thu Jan 22, 2015 10:39 am

Re: I'll just leave this here...

Post by Happy » Thu Jan 22, 2015 3:39 pm

The Read Errors for the System Area (LBA's 0-23) may be because the IPL accesses these as 192 byte sectors, instead of 232 bytes for Zone 0 sectors.

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: I'll just leave this here...

Post by LuigiBlood » Thu Jan 22, 2015 9:26 pm

Happy wrote:The Read Errors for the System Area (LBA's 0-23) may be because the IPL accesses these as 192 byte sectors, instead of 232 bytes for Zone 0 sectors.
192 bytes ONLY for Development 64DD disks.
It's 232 bytes for normal retail disks.

And for development disks, it reads the System Area just fine.

The read errors are for Block Mode at this point. (When IPL reads LBA 24+ to load the game, that's where it messes up because I don't know how block mode is implemented.)

I can't work on 64DD emulation for the moment because I'm in the process of reinstalling and repartitioning everything on my PC.

User avatar
Buddybenj
Posts: 4
Joined: Tue Mar 10, 2015 6:52 pm

Re: I'll just leave this here...

Post by Buddybenj » Wed Mar 11, 2015 12:13 pm

LuigiBlood wrote:Doshin The Giant 2's dump is bad. There are bad blocks in bad places.
LuigiBlood wrote:
Snowstorm64 wrote:
LuigiBlood wrote:Doshin The Giant 2's dump is bad. There are bad blocks in bad places.
Because the disk is damaged? It's strange that there are only two dumps of Doshin the giant 2 so far...We need a third owner of this game.
We have a third owner.
What's the status on this? Has this disk been dumped properly yet? Have any other prototypes/betas/unlicensed games been dumped yet? I heard somewhere that the owner of the Super Mario 64 Disk Version was being shipped a dumper, but I'm not sure if it's true or not.

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: I'll just leave this here...

Post by LuigiBlood » Wed Mar 11, 2015 7:57 pm

Buddybenj wrote:What's the status on this? Has this disk been dumped properly yet? Have any other prototypes/betas/unlicensed games been dumped yet? I heard somewhere that the owner of the Super Mario 64 Disk Version was being shipped a dumper, but I'm not sure if it's true or not.
Dumped, and you can find it on Google. It's public stuff.

And recently someone emulated the 64DD on MESS. It works now.

User avatar
Buddybenj
Posts: 4
Joined: Tue Mar 10, 2015 6:52 pm

Re: I'll just leave this here...

Post by Buddybenj » Wed Mar 11, 2015 10:20 pm

LuigiBlood wrote: Dumped, and you can find it on Google. It's public stuff.
Which one? The proper Doshin the Giant dump, the Super Mario 64 Disk Version, or both?

If you mean the proper Doshin the Giant dump, could you tell me the MD5 sum of a good dump of Doshin the Giant?

Here's the one I currently have:
File: Kyojin no Doshin.bin
CRC-32: b30f6e64
MD4: d54346f00c440f7a92797df51731cd4f
MD5: 1424518e956a23d189b12574f6f67247
SHA-1: 92f714b52a27b280a47c346bae4c753f3b65701f
LuigiBlood wrote:And recently someone emulated the 64DD on MESS. It works now.
This is amazing considering 64DD dumps were only released a couple of months ago!

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: I'll just leave this here...

Post by Snowstorm64 » Thu Mar 12, 2015 8:31 am

LuigiBlood wrote: And recently someone emulated the 64DD on MESS. It works now.
That's amazing! There's any chance that the code will be ported to CEN64?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: I'll just leave this here...

Post by LuigiBlood » Thu Mar 12, 2015 1:43 pm

Buddybenj wrote:Which one? The proper Doshin the Giant dump, the Super Mario 64 Disk Version, or both?
Both. And Doshin The Giant always had a good dump. The 2nd one however, isn't that way.
Snowstorm64 wrote:That's amazing! There's any chance that the code will be ported to CEN64?
I need to look at the code first. It's not pushed yet. Once it's pushed anyway, chances are there will be a build for it so you can try it out.
Porting the code shouldn't be impossible though.

User avatar
e2118289
Posts: 13
Joined: Tue Dec 31, 2013 12:24 am

Support for the N64DD in MAME!

Post by e2118289 » Wed Mar 25, 2015 1:16 pm

And heeeeere we go! :mrgreen:
Happy[/url] @ [url=https://github.com/mamedev/mame/pull/151]MAME wrote:Current use: mess n64dd -quickload disk -cart cart (also adding -nodrc flag as MIPS drc seems to be broken) (both disk and cart are optional)

Disk images need to be in head/track format. See https://github.com/Happy-yappH/ddconvert.git for format.

Intended as proof of concept. Does not currently support disk swapping or saving disk to files. Writes only update the copy in memory, once the mess process ends the changes are lost. Possibility that the BM Interrupts may be cleared differently on actual hardware. In code, I work with the hypothesis that the BM monitors the PI Read/Write lines for transitions to clear the interrupt and start transfer of the next sector. Currently no support for C1/C2 error correction, I only have a very basic understanding of how they are implemented and as long as no errors are reported the emulation seems to work okay, i.e. no copy protection schemes relying on intentional errors.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: I'll just leave this here...

Post by Snowstorm64 » Mon Mar 30, 2015 11:09 am

I can't post it here because copyrighted materials etc, but LuigiBlood has hinted something on his website. Earthbound64 or Zelda URA, please! :)
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: I'll just leave this here...

Post by Snowstorm64 » Wed Apr 01, 2015 11:17 am

It turns out to be Ura Zelda! Please tell me it's not an april fool!
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
chriztr
Posts: 38
Joined: Sun Oct 06, 2013 4:15 pm

Re: I'll just leave this here...

Post by chriztr » Thu Apr 02, 2015 3:54 am

Snowstorm64 wrote:It turns out to be Ura Zelda! Please tell me it's not an april fool!
Let's check it out then!
Attachments
wops.png
wops.png (36.17 KiB) Viewed 22980 times

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: I'll just leave this here...

Post by Snowstorm64 » Thu Apr 02, 2015 2:38 pm

chriztr wrote:Let's check it out then!
ddconvert isn't reliable for that, it will also "convert" plain text files in .ndd format.

However, it turned out to be indeed an april fool, sadly.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
numanoid
Posts: 3
Joined: Wed Apr 01, 2015 7:03 pm

Re: I'll just leave this here...

Post by numanoid » Mon Apr 06, 2015 9:13 am

Yeah, among all the available 64dd dumps it was the only one that froze MESS during the boot sequence (I would have posted this on the same day it got "released" but I had no internet for the past few days :P ).

But besides that it was still amazing for me to see the other dumps boot up (even if they're slow and glitchy at some parts), I'm glad that n64 dd emulation is finally becoming a reality, even if its just for a couple of games.

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: I'll just leave this here...

Post by LuigiBlood » Sun Apr 12, 2015 8:56 am

numanoid wrote:Yeah, among all the available 64dd dumps it was the only one that froze MESS during the boot sequence (I would have posted this on the same day it got "released" but I had no internet for the past few days :P ).

But besides that it was still amazing for me to see the other dumps boot up (even if they're slow and glitchy at some parts), I'm glad that n64 dd emulation is finally becoming a reality, even if its just for a couple of games.
Well, the excuse for this was the fact it's a blue disk. Blue disks doesn't work on retail 64DDs, even if you force it as it is. :D
But yeah it was an April Fools. However I released pretty recently a legit unreleased 1st party SNES game prototype, a holy grail that could have been the follow up to Mario Paint: Sound Fantasy (aka Sound Factory before the name change). All thanks to an anonymous donor who bought it high price and dumped it.

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: I'll just leave this here...

Post by Snowstorm64 » Tue Apr 14, 2015 11:31 am

Then, what we need to load a blue disk image on MESS, the 64DD dev kit's BIOS instead of the regular one?

Also, do you still plan to backport MESS's code for 64DD support on CEN64? Because CEN64's development is a bit...dormant right now...
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: I'll just leave this here...

Post by LuigiBlood » Thu Apr 16, 2015 3:05 pm

Snowstorm64 wrote:Then, what we need to load a blue disk image on MESS, the 64DD dev kit's BIOS instead of the regular one?

Also, do you still plan to backport MESS's code for 64DD support on CEN64? Because CEN64's development is a bit...dormant right now...
There's more into it than that. You need to change a few more things.

And backporting MESS's code to CEN64: I planned to but I'm doing other things that are slightly more important.

User avatar
numanoid
Posts: 3
Joined: Wed Apr 01, 2015 7:03 pm

Re: I'll just leave this here...

Post by numanoid » Mon Apr 20, 2015 6:22 am

LuigiBlood wrote:Well, the excuse for this was the fact it's a blue disk. Blue disks doesn't work on retail 64DDs, even if you force it as it is. :D
Wait, so this is actually a legit copy of Ura Zelda but its just not accessible at the current point in time?
If not, what game does the disk contain?

Also thanks for the info about Sound Factory, I never heard about it before but its definitely an interesting gem ;)

User avatar
LuigiBlood
Posts: 22
Joined: Wed Jan 07, 2015 1:02 pm

Re: I'll just leave this here...

Post by LuigiBlood » Tue Apr 21, 2015 9:53 am

numanoid wrote:
LuigiBlood wrote:Well, the excuse for this was the fact it's a blue disk. Blue disks doesn't work on retail 64DDs, even if you force it as it is. :D
Wait, so this is actually a legit copy of Ura Zelda but its just not accessible at the current point in time?
If not, what game does the disk contain?

Also thanks for the info about Sound Factory, I never heard about it before but its definitely an interesting gem ;)
No, it's not real. It's just that we had a valid excuse on why it wouldn't work. :D

I want to get the final ROM of Sound Fantasy so bad...

User avatar
Nintendo Maniac 64
Posts: 185
Joined: Fri Oct 04, 2013 11:37 pm

Re: I'll just leave this here...

Post by Nintendo Maniac 64 » Sat Jan 30, 2016 3:55 am

beannaich wrote:
Nintendo Maniac 64 wrote:Ok, but now the question is, does the real-life N64 hardware actually scale up the 320x237 / 640x474 image to 320x240 / 640x480, or is that something done by the TV? If the latter, shouldn't that be something that isn't directly "burned" into Cen64's simulated N64 rendering pipeline in the same way that it doesn't include any CRT or NTSC filters?
TVs (Especially the tube TVs of the mid 90's) normally don't display the entire generated picture. So it's possible that the N64 just generates black during those raster lines since they won't be seen anyways. Someone with an old TV can test this by very carefully screwing with the vertical hold dial on their tube :) If the picture can't ever cover the entire screen, then it's not generating 320x240, and the CEN64 window should be resized accordingly.

What's the point of having a pixel accurate RDP, if the pixels are then skewed when blitting to the screen?
I finally got my hands on a tube TV with a vertical hold dial, so I hooked up my N64 and did as you described, but the results weren't quite what I expected...

Basically, when I adjusted the picture so that the top of the N64's video signal was located in the middle of the screen and the bottom of the N64's video signal was positioned above it, there was a large black bar ) between the top and bottom of the N64's video signal.

And no, the black bars weren't from the game itself because I used with the title screen for The World Is Not Enough (which has no black bars at all as tested with Cen64).


Using a screenshot from Cen64 as a mock-up, it basically looked something like this:
image.png
image.png (48.55 KiB) Viewed 21547 times
CEN64 Forum's resident straight-male kuutsundere
(just "tsundere" makes people think of "Shana clones" *shivers*)

CPU+iGPU: Pentium G3258 @ 4.6GHz/1.281v
dGPU: Radeon HD5870 1GB
RAM: Vengeance 1600 4x4GB
OS: Windows 7

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest