|
|
GoldenEye 007 Nintendo 64 Community, GoldenEye X, Nintendo 64 Games Discussion GoldenEye Cheats, GoldenEye X Codes, Tips, Help, Nintendo 64 Gaming Community
|
|
|
|
|
|
|
|
|
|
|
Wreck Administrator
Joined: 14 Dec 2005 Posts: 7215 Location: Ontario, Canada |
Posted: Fri May 27, 2022 9:08 am Post subject: |
|
|
I have a very hard time seeing modifications to the cartridges having any real impact on performance, though. That would be the console itself, and how it processes data. |
|
|
|
|
|
|
|
|
|
|
Graslu Agent
Joined: 15 Dec 2016 Posts: 119 Location: Almeria, Andalucia, Spain |
Posted: Fri May 27, 2022 1:32 pm Post subject: Re: Okay |
|
|
MultiplayerX wrote: | Speaking with him first hand he is not attempting to scam anyone and says he sells very little. It's mainly for fans and people wanting more solid direct hardware, etc. |
Yes, not a scam by definition as I mentioned earlier but again, he's selling mods that were meant for a closed group of friends without letting them know, and also tries to make people think his solution is cheaper than simply getting a flash cart which is waaaay more useful and powerful than repro cartridges.
I know you meant well, MultiplayerX, but I feel like this needed to be said. We're all just not very fond of the idea of people selling our work - specially when we were never contacted to begin with.
We'd appreciate if the Pheonarx levels and the Mario mod were removed. I believe Wreck would like to see his gone from the listings as well. _________________ You can't win.
YouTube: https://www.youtube.com/c/Graslu00
Discord: https://discord.gg/tksttVC |
|
|
|
|
|
|
|
|
|
|
MultiplayerX 007
Joined: 29 Jan 2006 Posts: 1210 Location: USA |
|
|
|
|
|
|
|
|
|
|
Graslu Agent
Joined: 15 Dec 2016 Posts: 119 Location: Almeria, Andalucia, Spain |
|
|
|
|
|
|
|
|
|
|
Wreck Administrator
Joined: 14 Dec 2005 Posts: 7215 Location: Ontario, Canada |
Posted: Sat May 28, 2022 10:40 am Post subject: |
|
|
Accepting (or purchasing) one for myself would seem hypocritical. If it were a fully finished mod, not requiring more work, it could be nice even as a display piece for the collection, so long as it was a personal commission and not put up for sale. I probably don't have anything worthwhile that fits the bill. |
|
|
|
|
|
|
|
|
|
|
Trevor 007
Joined: 15 Jan 2010 Posts: 926 Location: UK, Friockheim OS:Win11-Dev PerfectGold:Latest |
Posted: Sat May 28, 2022 5:14 pm Post subject: Re: Compatibility |
|
|
MultiplayerX wrote: | He did mention way better mod compatibility and functionality. His board and chip upgrades are improvements on handling the data |
I too have a hard time seeing this as GE mods are already console compatible and flash carts like the ED are NOT emulators - they offer data to the PI that the PI expects.
Upgrades would require work after the PI not before.
Lets just take an extreme example and say he makes an arm CPU emulate GE and pump the overclocked output to the PI, its still limited by the PI datarate.
Lets then say this wasnt a problem, then the bottlenock comes back down to RCP and RAM and the VI.
Trev _________________
|
|
|
|
|
|
|
|
|
|
|
zoinkity 007
Joined: 24 Nov 2005 Posts: 1698
|
Posted: Thu May 25, 2023 3:31 pm Post subject: |
|
|
What Trevor's saying about the CPU/RCP bottlenecking is demonstratable on iQue. Double both clocks, no more issues.
Whoever this person is hasn't done enough research or they're feeding you a line.
*) It's already be verified that the RI refuses to map more than 8MB of rdram. You could map a different type of ram to an address range and use it--with limitations--and existing examples would be SRAM & Aleck64's 4MB. It's a different kind of behavior. This was verified using the RI Probe homebrew, confirming that even after mounted properly on the board it stops iterating devices after 8MB is reached. Organizing it to cheat the size, like having one stretch from 6 -> 10, leaves you with 6MB usable and potentially damaging hardware faults when the last device is accessed.
*) Do you know what Pokemon and endoscopy have in common? Video printers! It uses a video printer to screenshot higher-resolution renders of the scenes during boot. The printer only snapshots analog out, it has no access to memory. If you set the flags high and press reset retail games will run through those super-quickly. The printer interface is actually implemented as a controller pak device. Here's a summary of the interface.
https://pastebin.com/AxALeMUC
You may be confusing it with the unreleased GameBoy Link Cable which did send data to a GB Printer or equally-unreleased GBC Printer.
https://pastebin.com/06VzdT3w
https://pastebin.com/UKFZWEq0
*) You don't need to blow one of the serial ports to add a uart or something. Firstly, a controller pak device would still leave you with a controller and secondly, using one of the four controller ports is the worst way to go about it, it's absolutely going to be asyncronous and there is an example of how badly that works already: Aleck64's SRMVS. The v1.1 of that adds ~6kb of code to try to minimize desyncs and they still occur. Mind you this is a turn-based game.
The correct solution--taken by the later aleck64 uarts and both N64 modems--is to tie the chip's interrupt pin to the cart interrupt line and raise an event. Note the uart version has two dedicated channels, it's pretty cool.
So really there's four better ways to go about this:
1) borrow the cart's eeprom line (the PIF's 5th channel) and use that, then don't complain about not having eeprom or a 5th controller (which totally works, have to make a hack that uses this sometime)
2) use the CIC as an interface to your uart, since it already has pifram access. Basically ride on the implementation of the hash algo.
3) attach and map one to address space with whatever fpga you're using to do the cart's data, since you certainly aren't printing maskroms
4) abort that idea and use USB, like no flashcart owner seems to have done but certainly could do in like 3 days time.
*) If you're using an FPGA/microcontroller to handle communication with another on-board chip with the game, you have a flashcart. There is no repro out there that isn't a flashcart. As soon as you use one, you're roughly halving data access rates and frankly, nobody until now has noticed, it just doesn't affect anything of note. Performance can't be increased via cartridge hardware.
Don't get me wrong though, there's plenty more interesting things you can do from either cart port. There's a vsync signal that can be used for shutter glasses, the audio L/R lines to pipe in external audio, and basically anything addressable can be patched in. Nintendo put whole handheld consoles on a board and pushed their video out to an addressable buffer.
[edit]
The only part of this I'm overly critical about is how they're portraying their repro as anything other than a flashcart, or how it's in any way fundamentally different from other flashcarts. (there's at least two different ways to you can make them--hardware or software driven--and that can make a bit of a difference, but...) That somehow it's fundamentally better than any other option. The whole thing is marketing, and bad marketing at that. _________________ (\_/) Beware
(O.o) ze
(> <) Hoppentruppen! |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|