FPGA Based Videogame System

[Andromeda Stardust]

Every Analogue Mega SG console will include an unreleased Sega Genesis game: HARDCORE by Digital Illusions from 1994. https://twitter.com/analogue/status/1098975745601204225

Hot-diggity!

 

 

I can't really get into the Turrican games (gets ass handed to self very early on) but I don't mind their inclusion and am happy for the fans who get enjoyment out of it. I feel the same about Megaman and Contra as well. I am more of a classic Shmup fan (from Galaga to Blazing Lazers), and generally prefer run-and-jump platforming style (ie Mario, Sonic) over run-and-gun.

 

Having a free game on the boot menu that you aren't interested in playing doesn't make owning the console any less fun, so I cannot see why anyone would argue for it's omission.

 

I hope we get a free game on the Mega SG but not going to hold my breath.

 

So the alt Ghostly boot menu is technically included on recent firmwares, just locked out unless you bought the Ghostly version? Gotcha.

 

Yes, and the Super NT is more a spiritual successor to the AVS based upon price point and features, than the NT Mini. I think it's plausible the AVS is why Analogue hasn't released a competing price reduced NT yet. Based on social media posts and forums I have read, many people have bought the AVS and Super NT.

 

I gotta admit, not a fan of solid white consoles, but that would look nice sitting next to the white Mega SG.

[Reaperman]

My 8bit do genesis showed up today and is charging now.

For those wondering, the d-pad does press down in the center, mean no rocking your thumb. Kind of a bummer--is there some reason so many 3rd party controllers do this? I've never understood that one.

 

Hopefully the '2.4g' does better in my room that 'bluetooth.' Also hopefully its pretty durable, since the nes30 that came with the nt mini broke on my 3rd try. (it syncs up but no input detected) At minimum, I figure even bluetooth would be more than good enough for the slower-moving buck rogers/starflight/star odyssey I've been wanting to play lately.

 

I'm looking forward to trying this one out. Initial impression of controller ergonomics are *really* good. Minus the d-pad action, it feels a lot like a slightly meatier saturn batwing. It has is the cutest little receiver unit too.

 

I do worry about non-user replaceable batteries, especially if they happen to be lipos (I haven't checked). I'm always a AA fan, so I can pick/update the battery technology, and never have to wait for charging, like I am now.

 

Edited February 28, 2019 by Reaperman

[Toth]

Yeah, I am not sure why d-pads are so hard. All they have to do is make the under side exactly like an nes or SNES controller from back in the day. Even Nintendo screwed up the d-pad with their own Switch Pro controller when all they had to do was use the exact same d-pad they used on the Wii U Pro controller.

Edited February 28, 2019 by Toth

[Reaperman]

So even though the 8bitdo m30 isn't a kevtris product, it's somewhat mega sg related so I'll hijack a little more.

 

In terms of comfort, the m30 is already my favorite genesis controller ever. It's a nice weight and thickness and there's an interesting little texture all over it. After holding it more, I'm reminded of the neo geo pad for overall shape in hand, rather than the saturn pad I expected it to feel like. The button rubber is snappy, control placement is spot on, and it takes zero getting used to. Anybody who is used to the bumps on 'y' and 'b' will find them missing. I didn't think I was in that group, but I must be since I noticed it without looking for it. That aside, the non-rocking D-pad disc is the only real kind of bummer on it, so I guess I'll have to play fighting games with a different controller (more likely a different system), but honestly I like this 8bitdo m30 and am probably going to buy a second one.

 

I tried hard, but could not detect any lag with this controller. Oh, there's lag in my setup--but switching from one controller to another didn't seem to impact it. I suppose the mega sg will probably knock a frame or two off my setup's lag. If lag's there, it's too much work to spot. On my N30 bluetooth, the lag was immediately noticeable. (I'd love to go back and compare, but it's dead) This new controller is certainly not that old n30. I like it, and as luck would have it, I've taken the next five days off to get to know it, and my genesis, a bit better.

Edited March 1, 2019 by Reaperman

[bikerspade]

New firmware for the sd2snes released today. Support for S-DD1. https://sd2snes.de/blog/archives/1049

[Atariboy]

Does that get us down to just one non-compatible game?

 

I seem to recall reading that just two games were unsupported previously. Since we could of course already play the uncompressed version of Star Ocean, I assume Street Fighter Alpha 2 cuts the list in half.

[cacophony]

Does that get us down to just one non-compatible game?

 

I seem to recall reading that just two games were unsupported previously. Since we could of course already play the uncompressed version of Star Ocean, I assume Street Fighter Alpha 2 cuts the list in half.

 

I think there's 5 remaining:

 

ST-011 (1 Game)

ST-018 (1 Game)

SPC7110 (3 Games)

[Atariboy]

Thanks

 

Hopefully that last one happens eventually, since I'm sure there are some fans that would love to play the homebrew translation of Far East of Eden Zero. I imagine accomplishing support for the ST-011 and ST-018 mostly only holds value from being able to say that it can play 100% of the library (Although perhaps some Japanese gamers might disagree).

 

Too bad the ST-018 never had a chance to shine from a graphical perspective. I've been led to believe it was pretty powerful, even more so than the Super FX. But Shogi 2 or whatever it was called only uses it for AI calculations.

Edited March 1, 2019 by Atariboy

[Tanooki]

I thought the ST games were up, if not, they are in the process because the non-PRO unit (the mark1/mark2) can handle everything but the 2 bloated chips that run one game a piece based on Shogi as it's a rather larger AI chip the FPGA can't fit, the others, it's a matter of time. Even the Pro won't be able to handle the Shogi sequel again due to space, so in the end the Mark 3 vs the others will get +1 game when all is said and done and outside of a few people who really love Shogi I don't see this being an issue to get too upset over.

[Forsaken]

Yeah, I am not sure why d-pads are so hard. All they have to do is make the under side exactly like an nes or SNES controller from back in the day. Even Nintendo screwed up the d-pad with their own Switch Pro controller when all they had to do was use the exact same d-pad they used on the Wii U Pro controller.

The Switch Pro was messing me up soooo bad in Tetris99 because of that. I was able to fix it with 5 squares of Kapton tape on the PCB right under the pivot bump on the D-pad, so it's lifted up a bit higher. Now it rocks properly instead of being able to push all four directions at once, and diagonals aren't happening accidentally. It's still not quite as good as a NES or SNES controller, because there's not enough vertical clearance for the opposite side of the D-pad to see-saw up higher than the pivot, but it's much better than stock. Maybe it could be improved further by milling off some plastic somewhere to allow the pivot to be raised higher. 5 pieces of tape was the most I could raise it before it began to jam due to lack of vertical clearance.

 

D-pads seem to require pretty tight tolerances to work right, and are basically a lost art.

[F34R]

The Switch Pro was messing me up soooo bad in Tetris99 because of that. I was able to fix it with 5 squares of Kapton tape on the PCB right under the pivot bump on the D-pad, so it's lifted up a bit higher. Now it rocks properly instead of being able to push all four directions at once, and diagonals aren't happening accidentally. It's still not quite as good as a NES or SNES controller, because there's not enough vertical clearance for the opposite side of the D-pad to see-saw up higher than the pivot, but it's much better than stock. Maybe it could be improved further by milling off some plastic somewhere to allow the pivot to be raised higher. 5 pieces of tape was the most I could raise it before it began to jam due to lack of vertical clearance.

 

D-pads seem to require pretty tight tolerances to work right, and are basically a lost art.

That's how I've fixed my 8bitdo controllers.

[Toth]

The Switch Pro was messing me up soooo bad in Tetris99 because of that. I was able to fix it with 5 squares of Kapton tape on the PCB right under the pivot bump on the D-pad, so it's lifted up a bit higher. Now it rocks properly instead of being able to push all four directions at once, and diagonals aren't happening accidentally. It's still not quite as good as a NES or SNES controller, because there's not enough vertical clearance for the opposite side of the D-pad to see-saw up higher than the pivot, but it's much better than stock. Maybe it could be improved further by milling off some plastic somewhere to allow the pivot to be raised higher. 5 pieces of tape was the most I could raise it before it began to jam due to lack of vertical clearance.

 

D-pads seem to require pretty tight tolerances to work right, and are basically a lost art.

 

 

That's how I've fixed my 8bitdo controllers.

I've read about a similar fix. Did you guys also cover up the inside part of each of the buttons contact areas as well or did you strictly use tape in the center, not button contact area?

 

Like did you do this?:

Edited March 1, 2019 by Toth

[F34R]

Just the tape like in that picture.

[Forsaken]

 

 

I've read about a similar fix. Did you guys also cover up the inside part of each of the buttons contact areas as well or did you strictly use tape in the center, not button contact area?

 

Like did you do this?:

No, I taped where the pivot rests on the board, nothing on the contacts. The problem with the Switch Pro at least is that the pivot is too low, enabling all four directions at once, and ridiculously easy diagonals. Raising it enough makes that impossible. The problem you run into is that they didn't leave much room overhead for the side opposite the one you're pressing down to pivot up, like a see-saw. So if you try to raise it too much, it will jam.

 

The old d-pads were like see-saws, one side goes down, the other side goes up, so if you pushed left, the right goes up, and up/down don't really go anywhere.

 

On these new ones, there little or no overhead clearance, and the pivot is low, when you press left, up/down also go down a little, closer to triggering, and right doesn't move much.

 

The ultimate solution is to raise the pivot, which can be done simply with a durable tape (like kapton) under it on the PCB, and also increase the overhead clearance to allow full "see-saw" action. The latter is much more difficult, and in many cases may not be possible without fabricating a new shell, or somehow getting the PCB to sit lower. And if you make the PCB sit lower, you might cause other buttons to get funky.

[Jurai]

first Amazon reviews for the 2.4ghz version of the 8Bitdo M30 2.4G pad aren't too hot, one person says it constantly loses connection to the receiver, while the other review says the adapter causes games to crash at start, hope it's something they can sort out with firmware upgrades and not a defect that's gonna crop up when the systems roll otu

[Pixelboy]

first Amazon reviews for the 2.4ghz version of the 8Bitdo M30 2.4G pad aren't too hot, one person says it constantly loses connection to the receiver, while the other review says the adapter causes games to crash at start, hope it's something they can sort out with firmware upgrades and not a defect that's gonna crop up when the systems roll otu

Those tests were obviously carried out on old hardware, since the Mega SG isn't out yet. The problems reported by those people who posted on Amazon may stem from the aging console hardware they're using, more than the controller itself. Or maybe not, but just sayin'...

[atmn]

Ikari mentioned that the save state feature with the sd2snes pro would not work on the Super NT, don't know exactly why.

 

My question is, are the hardware on the Super NT the problem, or the FPGA implementation that makes this impossible. Suppose it has something to do with how the APU works, that the flashcard have no idea of what music is playing, it makes this this "separately".
So the sd2snes needs to emulate the APU? Please correct me.

 

Remember I tried an experimental build with the sd2snes with save states, it "worked" but somewhat buggy. Audio did not save the state but that is a known issue that can't be done in the original sd2snes.

[kevtris]

Ikari mentioned that the save state feature with the sd2snes pro would not work on the Super NT, don't know exactly why.

 

My question is, are the hardware on the Super NT the problem, or the FPGA implementation that makes this impossible. Suppose it has something to do with how the APU works, that the flashcard have no idea of what music is playing, it makes this this "separately".

So the sd2snes needs to emulate the APU? Please correct me.

 

Remember I tried an experimental build with the sd2snes with save states, it "worked" but somewhat buggy. Audio did not save the state but that is a known issue that can't be done in the original sd2snes.

It is going to rely on overdriving the SNES bus and force its values onto the data bus while the SPC is trying to also drive the bus. It's basically a bus conflict between the sd2snes and the SPC that the sd2snes probably will always win. I am not sure if it will work properly on every SNES, but it might if it can drive the bus harder than the SPC can on every rev of SNES. The reason it won't work on the snt is because the SPC signals are mainly internal and the FPGA will listen to its internal SPC data before external data.

 

The sd2snes will put the SNES' SPC "to sleep" and then all audio will be done on the cartridge only, feeding the audio data into the cartridge audio input. Even though the internal SPC is put into an endless loop, it will still be outputting data to the bus when the SPC registers are read, since that's done in the hardware itself. The sd2snes will also output data at the same time, causing the bus conflict that it will win usually when games read the SPC registers.

 

This also means the audio quality will be down to the cartridge now, since the internal SPC is no longer being used.

[phoenixdownita]

It is going to r.....

To be fair if it wasn't a colossal PITA the SuperNT could likely implement save states natively (for the game it supports), no?

[Guspaz]

The reason it won't work on the snt is because the SPC signals are mainly internal and the FPGA will listen to its internal SPC data before external data.

 

Would it not be possible to add some mechanism by which the SD2SNES could signal to the SNT that it wants the SPC disabled? Or failing that, provide a manual option to disable the SNT?

[phoenixdownita]

 

Would it not be possible to add some mechanism by which the SD2SNES could signal to the SNT that it wants the SPC disabled? Or failing that, provide a manual option to disable the SNT?

<irony> I believe you already have that, it's the power button </irony>

[Guspaz]

I meant the SPC, obviously, but I don't see an option to edit posts.

[Jurai]

It is going to rely on overdriving the SNES bus and force its values onto the data bus while the SPC is trying to also drive the bus. It's basically a bus conflict between the sd2snes and the SPC that the sd2snes probably will always win. I am not sure if it will work properly on every SNES, but it might if it can drive the bus harder than the SPC can on every rev of SNES. The reason it won't work on the snt is because the SPC signals are mainly internal and the FPGA will listen to its internal SPC data before external data.

 

The sd2snes will put the SNES' SPC "to sleep" and then all audio will be done on the cartridge only, feeding the audio data into the cartridge audio input. Even though the internal SPC is put into an endless loop, it will still be outputting data to the bus when the SPC registers are read, since that's done in the hardware itself. The sd2snes will also output data at the same time, causing the bus conflict that it will win usually when games read the SPC registers.

 

This also means the audio quality will be down to the cartridge now, since the internal SPC is no longer being used.

 

Would it be a fair assumption in that case that we won't likely see the sd2snes savestates functionality (w/ the audio state in tow) working on a SuperNT?

[atmn]

It is going to rely on overdriving the SNES bus and force its values onto the data bus while the SPC is trying to also drive the bus. It's basically a bus conflict between the sd2snes and the SPC that the sd2snes probably will always win. I am not sure if it will work properly on every SNES, but it might if it can drive the bus harder than the SPC can on every rev of SNES. The reason it won't work on the snt is because the SPC signals are mainly internal and the FPGA will listen to its internal SPC data before external data.

 

The sd2snes will put the SNES' SPC "to sleep" and then all audio will be done on the cartridge only, feeding the audio data into the cartridge audio input. Even though the internal SPC is put into an endless loop, it will still be outputting data to the bus when the SPC registers are read, since that's done in the hardware itself. The sd2snes will also output data at the same time, causing the bus conflict that it will win usually when games read the SPC registers.

 

This also means the audio quality will be down to the cartridge now, since the internal SPC is no longer being used.

 

Thanks for the clearification. Always intresting how things work around this.

 

To me it's seems more likely to get save states on the Jailbroken FW playing directly from SDCard rather than supporting it on the SD2SNES.

[bikerspade]

The man behind Raphnet is designing a Sudoku game for the SNES that utilizes the NTT Data controller.