Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - saturnu

Pages: [1] 2 3 ... 80
EverDrive 64 / Re: Getting a transfer pak to work
« on: July 19, 2021, 08:44 PM »
It should work, keep in mind that you need the us gb cartridge for the us n64 rom and eu cartridge for the eu n64 rom etc.
The connection between the transfer pack and the controller is a bit fiddly, try to clean the connector with some isoprop alcohol, or window cleaner if you don't have anything "pure".

EverDrive 64 / Re: Question about N64Digital and UltraPIF
« on: July 13, 2021, 01:07 AM »
the ultrapif is capable of generating these clock signals, in fact you can even desolder one of the crystals on the n64 mainboard.
even if you have an ultrapif it depends on the dac, if it's switchable, too.
a mav-nus is switchable, a denc-nus is not - can't remember about vdc-nus.
the best way would be a rgb replacement dac or one of these modern hdmi mods.

EverDrive 64 / Re: Question about N64Digital and UltraPIF
« on: July 11, 2021, 05:55 PM »
not really,
each one has it's specific purpose.

the ultrapif makes the console universal and in addition to that, it can correct the slightly different video/sound output clocks if you play imports
-in this case your cartridges don't need a cic and you can play imports

an ultracic makes the cartridge universal, so you can stick it in a pal/ntsc/m-pal console
-a flashcart can switch between 50/60Hz but the n64 analog output is fed with a 1-2% off signal if you are playing roms of imports
-i'm sure the devs of the hdmi output know about that and deal with these odd frequencies to provide a correct hdmi signal
-flashcarts a pretty common nowadays

No problem. I had to go look it up myself. I looked at the numbers and scratched my head... "Something doesn't look right here!" :D

One other note - the VIDEO being "odd" frequencies will have no affect on the rendering as the video processor does nothing but fetch and display the drawn data. The data is drawn by the rdp, rsp, or cpu... usually the rdp for commercial games. The rsp has a DMA channel it can use to draw to the display (I made a demo for that in libdragon), and you can always draw to the display with the cpu like the recent Doom port and most libdragon stuff. So the video circuitry has an odd frequency to deal with those pesky broadcast timing issues.

I'm not sure why the audio was clocked using the video clock instead of the RCP clock as you would have expected. That would have made it super-simple to handle audio playback rate calculations. Perhaps the audio is fetched interleaved with the video data fetch... X number of words per line like the Amiga audio.

the hdmi mods are just for the video output, it doesn't hassle with the region locks at all
-but i guess the ultracic in a flashcart is just enough for most of the people in this case

as far as my understanding goes the game speed is correct if you play with flashcarts, only the analog video/sound can be bit jitterish? i guess :>

EverDrive 64 / Re: Question about N64Digital and UltraPIF
« on: July 11, 2021, 10:57 AM »

yes the UltaPIF turns your n64 into a multiregion console, it is (optional soldering required) replacing the crystal based on what you are puttin in your n64.
-it has an inbuild cic detection - but you can switch what cic settings it should set, too.
-basically it can simulate both, pal/ntsc pif roms and set the hardware (input) frequency correct

a flashcart with an ultracic turns the cartridge into a multiregion cartridge, so it can boot in standard n64 consoles of every region, but it can't change the crystals of your n64s, or the pifrom from one region to another.
-that's why the everdrive64 uses a pif-simulator for starting games
-it sets some settings the pif would set for a specific cic and region
-and it can set the digital video output of the rpc to 50/60Hz

i watched the n64digital mod installation video and the guy doesn't touch the clock generator chips at all nor the crystals
-maybe the frequency swapping is meant for different input frequencies into the n64digital board?

the UltraCIC III in comparison to the UltraCIC II gets rid of the old manual region switch, setting the cic automatically to ntsc or pal, so you can use it in different regional consoles.
-you don't need an ultracic at all with a console that has an ultrapif installed
-and the video output doesn't care if there is a cic on the cartridge or not

to get true accuracy you need to take care of "three" frequencies - cpu frequency, video output frequency and sound frequency (rambus freq is the same in every region)

i don't know if you can achieve accuracy with an hdmi mod at all, maybe it's adding a minimal lag between controller inputs and the video output, and what is about sound accuracy, if you take it analog and the video is processed digital- is the sound some milliseconds shifted then?
-some new tvs have a game mode to reduce the input lag and on some tvs you can hardly play at all

i guess the best option would be to buy a good crt and a rgb mod instead of a hdmi mod - if you want the highest accuracy
-in combination with an ultrapif mod

if you want to play via hdmi, i would suggest to ignore the 1-2% region specific frequency differencies of the video signal, it's probably taken care of

EverDrive 64 / Re: saturnus archive compilation :>
« on: June 16, 2021, 08:54 PM »
I guess I'm one of these guys, that never delete anything.
main post updated

EverDrive GB / Re: Transfer Pak
« on: June 12, 2021, 09:53 AM »
the idea passing "emulated" commands to the data lines of the cartridge is what the edgb loader app does - but it's flawed.
i think you can't really write to a specific register, think of the transfer pak more like a sd-card reader - like nuu pointed out.

you can read and write in 32byte blocks, so if certain registers are near to each other, you may write to both of them with one command.
in the end - it all depends on the way the state machine is written on the edgb x-series side.

but i might be wrong, the edgb loader app is based on reversed engineering of some n64 roms and some snippets found on the internet.
in the last years new leaked source code of the sdk appeard, maybe there is a way to command the tp to write only a specific part of the 32byte block to an address?
it's a bit ugly 'cause you have to communicate with the pif to let the tp send commands to the gb-cartridge - but maybe it's worth looking into that. yadayada.. :>

EverDrive 64 / Re: Bootloader V3 file for the Everdrive V2.0?
« on: September 06, 2020, 09:40 AM »
the bootloader v3 was removed from the dl page years ago, but it was possible to update the bootloader of the ed64v2.
for the ed64v1 it's possible to update the firmware as nuu stated out via a jtag adapter.

these are all different things:
bootloader (minimal N64 rom, that loads the menu from the sdcard)
firmware (FPGA bitstream)
OS (Menu) (since the ed64v2 - new firmware files are included inside the OS)

EverDrive 64 / Re: New Neon64 beta released
« on: July 27, 2020, 12:14 AM »
it looks like the source code of the famicom emulator in Dōbutsu no Mori was leaked, too.

i seems like the original rtc has some error response and an alarm time that is settable.
i wonder if that is used somewhere in animal forest and if this is even implemented in the ed64 rtc simulation at all.
i don't have an ed64v3 or x7 to test this, it's just a wild guess.

maybe this is an incompatibility or just nothing...

EverDrive 64 / Re: saturnus archive compilation :>
« on: June 03, 2020, 09:48 PM »
What are the chances this is ever updated for the X7 in the future?

Not good.
I don't own a x7 and i don't know how it's accessing the file system.

EverDrive 64 / Re: saturnus archive compilation :>
« on: May 08, 2020, 07:14 AM »
the software is only compatible and tested up to the ed64v3. basically i know nothing about the x7

EverDrive 64 / Re: saturnus archive compilation :>
« on: May 07, 2020, 10:52 PM »
fixed these links in the opening post

EverDrive 64 / Re: Injecting Gameshark Codes into rom
« on: April 04, 2020, 05:26 PM »
modding gameshark codes into a rom...
it seems like you want to embed gs codes that alter ram positions.

the ed64 copies the patcher routine to a location into ram and than the codelist is attached.
as far as i know a general exception handler is registered, that calls the cheat engine routine every time it is triggered.

the max length of codes is determined by performance issues that would accure if the routine would need too much cpu time.

so in praxis the n64 must manipulate some ram settings many times beside calculating the game itself.
if the routine needs to go over a bigger number of codes it does consume more cpu time and the game slows down.

keeping that in mind one solution of this problem would be to patch the rom-code itself to do the things you want.
so as a romhacker you need to find the spots in the rom that alters the memory locations for your gameshark codes.

if game performance doesn't really matter to you can edit the ed64 menu source, so you can attach more then 24 codes. in this case you would need some basic coding skills.

i would say it is possible, but it's not an easy task.


Can you explain a little more what the Video Table and its region is?

the videotable as itself has no region.
it is an array of SViMode structures with configuration values for the VI.
it's called a table, well... you can look up the tv-region_settingxy in the first entry on each struchture in the array it's a table with tv-type colums and setting rows, if you like

patching the video table means search for e.g. a X_LAN1 setting and replace it with X_LPN1
which are just #defines for some constants to mark the position in the videotable. ^^


The graphics and audio co-processor is programmable through microcode.[7] By altering the microcode, a developer can access different operations, create new effects, and optimize for speed or quality. While promoting this feature of custom microcodes, Nintendo initially refused to share information on how to use the related microcode tools. This was due to the fear that it would be copied by their competitors. However during the console's last few years, Nintendo shared the microcode information with a few developers. Nintendo's official code tools are basic, with no debugger and poor documentation.

SGI's default microcode for Nintendo 64 is called "Fast3D", which some developers claimed was poorly profiled for use in games. Although it generates more than 100,000 high accuracy polygons per second, this microcode is optimized more for accuracy than for speed, and performance suffered. Nintendo's "Turbo3D" microcode allows 500,000–600,000 normal accuracy polygons per second. However, due to the graphical degradation, Nintendo officially discouraged its use. Companies such as Factor 5,[3] Boss Game Studios and Rare, were able to write custom microcode that reportedly runs their game engines better than SGI's standard microcode.

ok this is a bit abstract, too.
in practise the videolist is something like a bit field for microcode settings as far as i can remember
- but don't quote me on that.

the patcher searches for microcode patterns in the rom, that's why it's important to select the right microcode.
for you statistics aficionados, yes it is possible to find some spot that acutally isn't the microcode videolist
but has the same pattern.

Also is -n the same we are doing with the Gameshark so far or is this the Hardware/Texture AA?
What is the Videolist patching good for?

the equivalent to the gamedshark codes is '-f'

hardware aa:
there is some second level of hardware smoothing of the picture that can be filtered by a replacement DAC.
maybe this can't be disabled by patching roms.

videolist patching alters the rdp microcode settings

long sentence short:
you can patch the VI-Register, VideoTable, VideoList
and do some filtering with a replacement RGB-DAC

Extra options:
-q, --dummy - just test - don't output file
-s, --swap - swap VideoTable region (new experimental)
-n, --no-anti-aliasing\tdisable AA in VideoTable, too
-k, --fast3d - search F3D SETOTHERMODE_L (highly experimental)
-2, --f3dex2 - search F3DEX2 SETOTHERMODE_L (highly experimental)
-l, --videolist - patch VideoList - [stackable] (highly experimental)

the patcher is a bit hard to handle. ^^

after -l  is mentioned that the command is stackable
so you can use -ll oder -lll to try even harder. the limit is 9 times btw. - if this wasn't clear in the first place lol

you need to know which microcode to search for fast3d or f3dex2 - replace 'k' with '2' as needed
it's not documented but you can stack -v, too to be more verbose. ^^

-ll2vvvn or -lllknvv are valid parameters ^^

Pages: [1] 2 3 ... 80