Jump to content
IGNORED

FPGA Based Videogame System


kevtris

Interest in an FPGA Videogame System  

682 members have voted

  1. 1. I would pay....

  2. 2. I Would Like Support for...

  3. 3. Games Should Run From...

    • SD Card / USB Memory Sticks
    • Original Cartridges
    • Hopes and Dreams
  4. 4. The Video Inteface Should be...


  • Please sign in to vote in this poll.

Recommended Posts

I was testing my new tv for pal 50hz settings. Booted Super Mario World European in pal hardware mode, zero delay, 50hz 720p/1080p output. Getting stutters and graphical artifacts that I can't really explain, especially when hitting a hint box. I am using jb6.5 firmware if that's any consolation. Where do I go to locate the "cheats" menu? Assuming it is on parity with official fw4.4, this feature should be included, correct?

Interesting... will try it as soon as I get home.

Link to comment
Share on other sites

I was testing my new tv for pal 50hz settings. Booted Super Mario World European in pal hardware mode, zero delay, 50hz 720p/1080p output. Getting stutters and graphical artifacts that I can't really explain, especially when hitting a hint box. I am using jb6.5 firmware if that's any consolation. Where do I go to locate the "cheats" menu? Assuming it is on parity with official fw4.4, this feature should be included, correct?

 

It is obvious. Thing 1 compiled the official firmware, sent it to Analogue. Thing 2 toggled the SD loader, recompiled, and sent it to Smokemonster. Whether Thing 1 and Thing 2 are working in tandem together, I have no idea, but it's a distint possibility.

 

Between Thing 1 and Thing 2 uploading different versions of the same firmware, took less than 12 hours. Thing 2 is either an incredibly talented hacker, or has access to the same resources as Thing 1. Thing 1 has a known identity. Thing 2 is anonomous. Two sides of the same coin? It's a distinct possibility. 8)

I prefer to think of Thing 2 as something totally different because I worry that alternative speculations will only serve to reduce the likelihood that Thing 2 is able to continue what Thing 2 does best.

  • Like 2
Link to comment
Share on other sites

 

I compared a Stunt Race FX and my Star Fox 2 repro. The PCBs are identical except for the Amtel EPROM. I looked up the data sheet for the Amtel and it is 5V. I'm assuming the repro was either a DOOM or a Stunt Race FX cart originally.

attachicon.gifStar Fox 2 Repro.JPG

attachicon.gifAMTEL27C080-15RI.JPG

There is also a fine wire running underneath the Amtel chip. It is easy to miss.

 

Be advised that the Super FX and SA-1 repros all require either an original PCB or a new PCB with the enhancement chip pulled from an original pcb. It is not possible to build FX or SA-1 repros without a donor cart. Also note that they cut the expansion pins off in order to fit it in a repro shell. The extra pins are not utilized in FX games despite their presence on the pcb.

 

Those boards have the exact same SRAM on them, same production dates, so they were probably the same game. Cutting the pcb is just plain idiocy, if anything they should have just taken a dremel to the cart plastic.

 

That said, if the game works, then the're not much to complain about. I wish repros would always come in unofficial colors so people aren't mislead by them.

Link to comment
Share on other sites

First I've heard of this issue. Have you tried reverting to an earlier firmware to see if the problem goes away? That's the first thing I'd try.

 

It could be a firmware bug that was introduced in 4.4 for the type of controllers that you have. You sure you didn't accidentally enable the new NTT Data compatibility mode?

 

 

Exactly what I was thinking as well.

 

 

I reverted to firmware 4.1 and tested againg but didn't fix the issue. NTT Data compat is disabled.

 

I did one thing: set to launch cartridge direct. Did the test with an SD2SNES. Doing this, I can move around with the wired controller plugged into port 2 but didn't work with port 1. My Super NT seems to have a problem with controller port 1 then. I guess I'll have to contact Analogue support.

Edited by kagigod
Link to comment
Share on other sites

A quick question: if I want to make a custom LED pattern for the Super Nt, how do I go about this? (I'd like a simple solid light green.) Is there a freeware program that I can use for this?

Use the rainbow pattern, uncheck the animate checkbox and set your preferred colour using the slider (can't recall its name at the moment). That should work for a solid colour.

 

As for real custom patterns, currently we don't even know what (file-)format the SuperNt expects for the custom pattern. Or do we?

Edited by kwnage
  • Like 1
Link to comment
Share on other sites

A quick question: if I want to make a custom LED pattern for the Super Nt, how do I go about this? (I'd like a simple solid light green.) Is there a freeware program that I can use for this?

you can use the k-pro rainbow pattern, then stop the animation and then use the slider to select the green you like.

  • Like 3
Link to comment
Share on other sites

I may or may not have found a small graphical glitch in Yoshi's Island.

On the famous Touch Fuzzy, Get Dizzy level, if Yoshi looks up while he's "Dizzy" a small portion of the top of the screen flickers white. I'm not sure if that happens on an actual SNES. I've never noticed it before.

Happens on my SFC JR, RGB modded.

  • Like 1
Link to comment
Share on other sites

you can use the k-pro rainbow pattern, then stop the animation and then use the slider to select the green you like.

 

What about custom patterns? Since there is an option to load patterns from SD card, what file format (and syntax) does the SuperNt expect?

Link to comment
Share on other sites

 

What about custom patterns? Since there is an option to load patterns from SD card, what file format (and syntax) does the SuperNt expect?

If I recall at some point Kevtris said it was just a text file containing RGB values in sequence. Or maybe they were BGR, I can't remember. And then named whatever.pattern

Link to comment
Share on other sites

Use the rainbow pattern, uncheck the animate checkbox and set your preferred colour using the slider (can't recall its name at the moment). That should work for a solid colour.

 

As for real custom patterns, currently we don't even know what (file-)format the SuperNt expects for the custom pattern. Or do we?

Yeh, freezing the rainbow is the way to go if you just want a solid color.

 

The pattern file stuff is very simple, but tedious. Open a hex editor, make a new file 768 bytes long, then edit the file with the RGB levels you want in the format RGBRGBRGB.... RGB repeats 256 times for 256 "frames" of animation, and each R, G, and B has 256 levels of PWM from 00 to FF (hexidecimal). So one frame of pure red would be "FF 00 00". Name the file anything you like, with a ".pat" extension, eg. "CustomLED.pat", and leave it in the root of your SD card. When you go to "load custom pattern", the SNT will find it and list it for selection to load. Text editors will not work, you need a hex editor so you see and manipulate the bytes of the file raw.

 

I've already messed around with it, I thought I could make a smoother rainbow than the "k-pro" one. I was humbled, it's harder than it seems! lol

 

Oh and there's a quirk that might confuse some people; there is no gamma compensation applied to these RGB values. So if you put in a value of 0x7F (decimal 127, 50% of 255), you get 50% duty cycle on the LED, it's on half the time, and it's off half the time. But because of the way the human eye perceives light, that doesn't appear to be 50% of the brightness of 100% duty, it looks more like 73% as bright, because the eyes respond to light with a gamma of around 2.2. If you wanted it to LOOK 50% as bright as full-on, you'd need a PWM duty of about 22% or 0x38 (decimal 56). Failure to understand gamma results in trouble getting smooth brightness ramps; if you just bring the PWM duty up in a straight line from 0-100%, the perceptual brightness will seem to jump from zero to well over 50% almost instantly, then very slowly approach full brightness and vice versa. You can see this in like every LED christmas tree light set ever made. Good understanding and calculation of gamma can help you get the perceptual results you want.

Edited by Forsaken
  • Like 1
Link to comment
Share on other sites

 

Those boards have the exact same SRAM on them, same production dates, so they were probably the same game. Cutting the pcb is just plain idiocy, if anything they should have just taken a dremel to the cart plastic.

 

That said, if the game works, then the're not much to complain about. I wish repros would always come in unofficial colors so people aren't mislead by them.

Is anyone aware of some kind of tutorial for making a repro like that with an official PCB and proper EPROM?

Link to comment
Share on other sites

Yeh, freezing the rainbow is the way to go if you just want a solid color.

 

The pattern file stuff is very simple, but tedious. Open a hex editor, make a new file 768 bytes long, then edit the file with the RGB levels you want in the format RGBRGBRGB.... RGB repeats 256 times for 256 "frames" of animation, and each R, G, and B has 256 levels of PWM from 00 to FF (hexidecimal). So one frame of pure red would be "FF 00 00". Name the file anything you like, with a ".pat" extension, eg. "CustomLED.pat", and leave it in the root of your SD card. When you go to "load custom pattern", the SNT will find it and list it for selection to load. Text editors will not work, you need a hex editor so you see and manipulate the bytes of the file raw.

 

Got it, there is no tool for that yet, right? It should be fairly easy to code something that will generate a sequence of RGB values and output that to a file. I might give it a shot when I have some free time...

 

 

Oh and there's a quirk that might confuse some people; there is no gamma compensation applied to these RGB values. So if you put in a value of 0x7F (decimal 127, 50% of 255), you get 50% duty cycle on the LED, it's on half the time, and it's off half the time. But because of the way the human eye perceives light, that doesn't appear to be 50% of the brightness of 100% duty, it looks more like 73% as bright, because the eyes respond to light with a gamma of around 2.2. If you wanted it to LOOK 50% as bright as full-on, you'd need a PWM duty of about 22% or 0x38 (decimal 56). Failure to understand gamma results in trouble getting smooth brightness ramps; if you just bring the PWM duty up in a straight line from 0-100%, the perceptual brightness will seem to jump from zero to well over 50% almost instantly, then very slowly approach full brightness and vice versa. You can see this in like every LED christmas tree light set ever made. Good understanding and calculation of gamma can help you get the perceptual results you want.

 

Yeah, the human eye works in a logarithmic fashion... kinda.

Link to comment
Share on other sites

Yeh, freezing the rainbow is the way to go if you just want a solid color.

 

The pattern file stuff is very simple, but tedious. Open a hex editor, make a new file 768 bytes long, then edit the file with the RGB levels you want in the format RGBRGBRGB.... RGB repeats 256 times for 256 "frames" of animation, and each R, G, and B has 256 levels of PWM from 00 to FF (hexidecimal). So one frame of pure red would be "FF 00 00". Name the file anything you like, with a ".pat" extension, eg. "CustomLED.pat", and leave it in the root of your SD card. When you go to "load custom pattern", the SNT will find it and list it for selection to load. Text editors will not work, you need a hex editor so you see and manipulate the bytes of the file raw.

 

I've already messed around with it, I thought I could make a smoother rainbow than the "k-pro" one. I was humbled, it's harder than it seems! lol

 

Oh and there's a quirk that might confuse some people; there is no gamma compensation applied to these RGB values. So if you put in a value of 0x7F (decimal 127, 50% of 255), you get 50% duty cycle on the LED, it's on half the time, and it's off half the time. But because of the way the human eye perceives light, that doesn't appear to be 50% of the brightness of 100% duty, it looks more like 73% as bright, because the eyes respond to light with a gamma of around 2.2. If you wanted it to LOOK 50% as bright as full-on, you'd need a PWM duty of about 22% or 0x38 (decimal 56). Failure to understand gamma results in trouble getting smooth brightness ramps; if you just bring the PWM duty up in a straight line from 0-100%, the perceptual brightness will seem to jump from zero to well over 50% almost instantly, then very slowly approach full brightness and vice versa. You can see this in like every LED christmas tree light set ever made. Good understanding and calculation of gamma can help you get the perceptual results you want.

I'm planning on making a better version of the K-pro rainbow. The Colors don't seem to fully saturate on them. I know how to use a hex editor but I don't have access to fancy scripts so I'll have to do them by hand. Mine will be hard linear ramps instead of sine waves, and every color will spend one third of the cycle at zero, so no more than two colors active at once. Start with red #FF0000 for index zero and index 255. From index 0 to 85, red will derement by 03 points every frame while green increments by 3 points every frame. The yellow will be more subdued at half/half red green instead of full 100%. Starting at index 85, the index is pure green at 00FF00. From index 85 to 170, green decrements by 3 points every frame and blue increments by 3 points until index 170 where blue is 100% #0000FF. Then from 170 to 255, blue decrements by 3 points each frame, and red increments by 3 points until index 255 where the color wheelvalue returns to FF0000.

 

What you said about gamma is correct. yellow/cyan/magenta will be half/half so they won't be quite as intense as full color but the eyes perceives them slightly brighter than half so my linear scale will make a perfect rainbow imo.

Link to comment
Share on other sites

I still haven't installed the jailbroken fw. With an extensive collection plus an SD2SNES, I simply don't need to.

 

 

....however, if there was an equivalent of COPYNES, I most definitely would. I have a good amount of irreplaceable saves and maybe unique variant carts that I'd love to back up.

I use a retrode for backing up game saves (and dumping SNES ROMs). In fact my SMAS+World cart still has my original game save on it. I should probably back that up before it gets lost forever... |:)

Link to comment
Share on other sites

 

Those boards have the exact same SRAM on them, same production dates, so they were probably the same game. Cutting the pcb is just plain idiocy, if anything they should have just taken a dremel to the cart plastic.

 

That said, if the game works, then the're not much to complain about. I wish repros would always come in unofficial colors so people aren't mislead by them.

Yeah I would have preferred that they kept them in tact. I had a bad experience cutting off pins once (7800 flash cart). It did not end well. Good news is most FX games don't need the extra pins at all (disconnected), so it's a matter of aesthetics really.

 

My Star Fox cart has glob tops and does utilize one of the extra pins for something, possibly the clock? It won't function through a Game Genie whereas Yoshi's Island and Star Fox 2 do.

Link to comment
Share on other sites

I thought I'd give making a little application to create patterns a try

 

oTBuKZU.png

 

Would anyone be interested once it's done? It's not nearly finished yet obviously

You won't get a gradual change in color with those values but it should work nicely. The final 8 frames of red are redundant though and past the 256 limit so it may not read them.

 

My planned improved rainbow palette idea will smoothly transition through every primary, secondary, and tertiary color on the color wheel with a relatively consistent brightness.

Link to comment
Share on other sites

You won't get a gradual change in color with those values but it should work nicely. The final 8 frames of red are redundant though and past the 256 limit so it may not read them.

 

My planned improved rainbow palette idea will smoothly transition through every primary, secondary, and tertiary color on the color wheel with a relatively consistent brightness.

Yeah I screwed up counting. Gotta implement a limit anyways.

Regardless, that's just a mockup. I haven't written then output routine yet or tested anything on the real thing.

I'll see how it goes.

 

/Edit: Got a few test patterns

TestPatterns.rar

Edited by infinest
  • Like 1
Link to comment
Share on other sites

I'm not sure the hackers actually want to look into this, but I'll make a sure summary on some games where the hotkeys are broken on the Hacked firmware.

 

On the game Spriggan Powered no hotkeys work on either JB or the official Firmware.

 

On the game Dynamic Stadium the Hotkeys work in certain moments in the game, and don't work in others.

 

 

Secret of mana is the most odd of them all:

 

JB but through SD2SNES you can summon the menu in all situations unless P2 opens his inventory. If he does, then P1 can't access the menus.

 

But on the Jailbreak you need to open your inventory for the hotkeys to be usable.

 

Reinforcing: The behaviour is different when the game is side-loaded through the SD browser or loaded through SD2SNES.

 

Now to me this is just a curiosity. Not sure people are interested in seeing this "fixed". I personally don't care. But this is the behaviour I've observed.

Edited by leods
Link to comment
Share on other sites

Don't know whether this is a bug/glitch or not.

While playing the Kirby Super Star's Megaton Punch mini game, during the scene that shows your Max Megaton Punch score the purple background will flash randomly. I'm am running the Super Famicom cart.

Here's a video I shot to show what I'm talking about. I mean it obviously isn't a game breaking bug or anything, but I thought you'd might like to know anyways.

https://www.youtube.com/watch?v=qo4Dyr-8c6w&feature=youtu.be

Link to comment
Share on other sites

I'm not sure the hackers actually want to look into this, but I'll make a sure summary on some games where the hotkeys are broken on the Hacked firmware.

 

On the game Spriggan Powered no hotkeys work on either JB or the official Firmware.

 

On the game Dynamic Stadium the Hotkeys work in certain moments in the game, and don't work in others.

 

 

Secret of mana is the most odd of them all:

 

JB but through SD2SNES you can summon the menu in all situations unless P2 opens his inventory. If he does, then P1 can't access the menus.

 

But on the Jailbreak you need to open your inventory for the hotkeys to be usable.

 

Reinforcing: The behaviour is different when the game is side-loaded through the SD browser or loaded through SD2SNES.

 

Now to me this is just a curiosity. Not sure people are interested in seeing this "fixed". I personally don't care. But this is the behaviour I've observed.

It would be helpful if you reported this as an issue in github, which is where all the JB issues are tracked. It definitely sounds like something worth fixing so I dont want it to get lost. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...