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 - nuu

Pages: [1] 2 3 ... 140
EverDrive GB / Re: Transfer Pak
« on: June 17, 2021, 10:12 PM »
They would have to squash or cut the screen at least. If the game doesn't use the whole generated video area, cutting it off might not hurt anything.
The SNES can use "windows" to crop the screen on all sides and still have scrolling work. Shadowrun seems to do something like this.

EverDrive GB / Re: Transfer Pak
« on: June 17, 2021, 05:47 PM »
Yes these systems doesn't use square pixels because of the 5.37MHz dot clock used by NES, SNES, PC Engine and all systems that has a video display processor based on the Texas Instrument TMS9918. This includes ColecoVision, MSX and all Sega systems up to Mega Drive. The dot clock (pixel clock) is what determines the width of the pixels because it's how fast the scanline can change colors when scanning a line I believe. The Mega Drive and SNES must speed it up when their respective higher horizontal resolution modes are used (higher vertical resolution can only be done by interlacing).

It's a persistent misconception that circulates on the internet that says that the NTSC NES can only generate 224 lines and the PAL can generate 240 lines. It's false, both can only generate 240 lines, this has been confirmed. And for the SNES both regions can do either 224 or 240 lines depending on what the game developer's needs.
I think people are mixing up the NES and SNES with the Mega Drive. The Mega Drive NTSC and PAL VDP can only generate a 224 and a 240 vertical resolution respectively.

240p is actually an NTSC resolution (480/2=240), the corresponding PAL resolution is 288p (576/2=288), but no version of the NES and SNES can output 288 lines (the SNES can output more using its interlaced mode though).
The developers usually knew that NTSC TVs seldom shows all 240 lines, so they normally don't display anything vital in the overscan area near the edges. For NES games they may even place screen artifacts that are not supposed to be seen in the overscan. This doesn't work well with PAL TVs that always displays all 240 lines due to its higher line count, so there are often garbage at the top and bottom in NES games.

EverDrive GB / Re: Transfer Pak
« on: June 17, 2021, 01:35 PM »
I see you accidentally deleted a "2". The DS of course has a native resolution of 256x192 pixels for both its LCDs. 56 pixels width would be even more narrow than the Gameboy's LCD.

The GBA LCD has a native resolution of 240x160 pixels while NES and SNES (in most modes) both uses a 256x240 pixel resolution (the SNES can have a height of either 240 or 224 in normal modes), and most other 8-bit and 16-bit systems uses something similar (Mega Drive has a 320 pixel wide mode though).

The width of 256 is hardly a problem on the GBA as you can get away with cutting 8 pixels on either side as overscan, but the height is a problem. Even if you cut off a lot of overscan at the top and bottom, 160 lines is very small, and you would probably have to squeeze the screen or modify the game to make sure all vital information is displayed.
It would be better if the GBA LCD's native resolution had at least been 240x192. 240x160 was large for a portable system of the time though. Just compare the Wonderswan and the Neo Geo Pocket.

After they made Super Mario Bros Deluxe (which zooms in on Mario like Richarddragon was talking about) I remeber that there was talk about porting Zelda 1 and 2 to the GBC, but the plan was canceled because of the small native resolution of the LCD (160x144 pixels). Zooming in probably didn't work as well for the two Zelda games as it did for SMBDX.
I think this plan eventually evolved into the Famicom mini/classic series (and the Animal Forest and e-Reader ports) on the GBA.

Porting SNES games (that doesn't use the high rez modes) to DS without squeezing the screen vertically would require cutting off part of the top and bottom, and moving things like the HUD into view if needed. The width is already perfect at 256 pixels.

By the TV's resolution you mean the video game system's output video resolution. A normal CRT TV's native vertical resolution is always 240p/288p or 480i/576i for NTSC/PAL TVs (or actually 525/625 total lines including the invisible ones), and doesn't have a native horizontal resolution due to how it draws the screen using scanlines instead of discrete pixels. But there is something called TVL used to measure a TV's horizontal fineness.

FXPAK (SD2SNES) / Re: FXPAK PRO Real time Clock issue
« on: June 16, 2021, 01:16 PM »
Yes that sounds about right.

EverDrive 64 / Re: How can you put the NES RNG in a known state?
« on: June 16, 2021, 01:13 PM »
The only hardware RNG in the NES is the one used by the APU's noise channel to randomize the waveform and produce white noise sound. Game's can't use this for their RNG so each game must have its own software RNG. This is a simple hack if it needs to be changed, no need to modify the hardware, but I suppose if they use an unmodified cartridge the NES hardware must be modified instead.

What game are they using in CTWC? The original NWC 1990 game seems to use the score of SMB1 as RNG, but I don't know what the normal NES version of Tetris uses.

FXPAK (SD2SNES) / Re: FXPAK PRO Real time Clock issue
« on: June 15, 2021, 10:16 AM »
I have an older SD2SNES and it has also always been quite off. Maybe it's just a cheap RTC chip, or the crystal used isn't very suitable for an accurate RTC?

It's not a big deal, you just have to adjust it once every 6 months or so to prevent it from drifting off too much.

EverDrive GB / Re: Transfer Pak
« on: June 15, 2021, 09:51 AM »
Oh it's like the DS Lite dustcover shell option that my M3 Lite GBA/DS flashcart had. I seldom used it as I wanted to be able to play GBA games on a GBA, and it required some screwing to change shells. The DS Lite dustcover shell is foolproof, you simply can't insert it in a GBA by mistake due to a tab on the side. To make a GBA-sized GB/GBC flashcart foolproof it would need to have the GBA shell with the protruding part which prevents it from fitting in a DMG/GBC and is also used for pushing it out with the thumbs, and have the width of a DMG cartridge so that it hits the GBC mode switch properly when inserting it into a GBA.

Lack of room for the required level shifters is a concern though, as GBC mode operates in 5V while many of the flashcart parts are 3.3V only. Only GBA flashcarts can do without level shifters as GBA mode operates in 3.3V.

It's still a no thanks for me as I prefer to play DMG games on my SGB2, but I understand that some people wants this.

EverDrive GBA / Re: Game compatiblity (X5 vs ODE)
« on: June 14, 2021, 01:10 AM »
They will hopefully add EEPROM128 since they said to fix this in the next update.

EverDrive GBA / Re: Game compatiblity (X5 vs ODE)
« on: June 13, 2021, 10:11 AM »
That's pretty bad. It sounds like something that could be fixed in an update though. It does use FPGA right?

EverDrive GB / Re: Transfer Pak
« on: June 13, 2021, 10:09 AM »
No thanks to a half-sized EDGB. You wouldn't be able to push it out once inserted since the cartridge slot is made for a full-sized cartridge. Even making it a little bit shorter would just make it harder to push out. Gameboy carts has a grove for placing the thumb in when pushing it out, and this space must be adequately large.

EverDrive GBA / Re: Game compatiblity (X5 vs ODE)
« on: June 12, 2021, 11:08 AM »
So just a wrong save type problem.

EverDrive GB / Re: Transfer Pak
« on: June 12, 2021, 10:38 AM »
The libgbpak tool also didn't work for me. I tried to backup the SRAM for Pocket Camera and Pokemon and both gave corrupt SRAM dumps.

you must be right, but still there something that I am not sure. At some point the supergb has to know that is running a specific game (to read the borders) instead of just the kernel.
The Everdrives uses the hardware reset pin to reset the system after loading a game so that the correct border from the game is loaded. Since the game is already loaded into the ROM memory at this point, and the ROM memory isn't cleared when just resetting without cutting the power, the game boots up on the SGB and the border and color data loads.

What the Everdrives needs is a bootable FLASHROM that can be programmed with a game so that it can act like a real cartridge. That would take care of all Transfer Pak and other linking problems that may exist. The GBA flashcart Omega Defenitive Edition and some Neo Geo flashcarts has this feature by removing the SD card or enabling a special mode. This fixes GBA-GC linking and GBA-DS linking which both has the same problem the Transfer Pak has. On the Neo Geo it's more for preventing the player from changing the game himself on an arcade cabinet I think, or maybe for booting into service menus with the game.

Nice! Now it's so much more clear and readable.

EverDrive GBA / Re: Game compatiblity (X5 vs ODE)
« on: June 11, 2021, 07:50 PM »
Does it happen with the clean ROM boot option?

EverDrive GB / Re: Transfer Pak
« on: June 11, 2021, 07:41 PM »
So, from my understanding seems that neither of the EDGB (x3,x5,x7) works with the transfer pak because of the way they flash the rom (it will go inevitable to the menu?). My question is how this is not a problem for using the super Gameboy, and would be possible (at least in theory) to make it work (maybe running some custom code in the ed64?) or is a hard no.
The Super Gameboy contains the real Gameboy hardware (minus LCD, speaker and buttons), and it works just like a normal Gameboy but with a SNES ROM and some hardware that takes care of the interacting with the SNES hardware and video output.
The Gameboy Player works like this too but on the Gamecube. It contains the real GBA hardware (minus LCD, speaker and buttons).

The Transfer Pak on the other hand is no Gameboy, it's just a device that can read and write to the SRAM and read the ROM off the Gameboy cartridge. The Pokemon Stadium games allows you to play the Pokemon games on your N64, but this is just emulation. It dumps the ROM and SRAM and runs it in an emulator on the N64 hardware, not on any kind of real Gameboy hardware.
So obviously there is no way it could read the ROM from the Everdrives since they don't have any (not that can be programmed with a valid ROM image anyway). The Everdrives has RAM or FLASH that you load a game to from the menu. It probably can't be fixed without a redesign of the Everdrive's hardware.

Pages: [1] 2 3 ... 140