kevtris

We've been doing a lot of "waiting" and not much "Seeing" though. I'm real curious to see the bottom of that board, and what this board plugs into.

Yeah guess they really do have 14 layers. I hate to wonder how much that cost to fab. If there's just a 484 ball BGA and little else on the bottom (i.e. bypass caps, some level translators and other misc stuff) then it's about 8 layers too many. If there's an SoC on the bottom then about 4-6 layers too many. Getting the board down that thin and that many layers must've been a bank breaker. If it's just development I guess it's fine though.

Here's a little marked up picture from that video they posted. This is all just wild-ass guesses so take with a grain of salt. The 240 DIMM connection on the bottom edge seems to be right, though. Not sure why they put those .1" headers so close to the BGA chip like that, it would make routing a huge pain since those pins go all the way through the board, impeding the routing of any signals that have to go by there. The BGA chip appears to be 484 balls which is one of the common sizes of package for the cyclone series of FPGAs. The total lack of connectors is still fairly odd to me, just power, the DIMM 240 edge, and the two connectors for what I suspect would be the adapters. Compare that DIMM 240 edge with a typical computer DIMM: The cuts in the sides for the locking mechanism and the voltage key cutout are present. Using a DIMM socket would make sense from a financial standpoint for testing, since it's high speed / high density. But this means this board obviously plugs into something else, which most likely has the SoC "brains" and A/V outputs. It would probably not be a good idea for production, though. The DIMM formfactor is 133mm wide, and one of those .1" headers is 12 pins, which would be 1.1" or 28mm wide. Counting pixels, the header is about 185 pixels wide while the dimm edge is about 883. The pic is at a slight angle so there will be some error, but this gives a ratio of 4.77:1. The actual measurements (133mm/28mm) is 4.75:1. So this is a fairly good match, considering the angles involved and the potatocam quality. Edit: I was thinking about their 14 layer claim and I think it's gotta be a mistake. The DIMM-240 is 1.2mm thick or so, which is not enough thickness for a 14 layer PCB. The thinnest typical 14 layer board I could find was 2.36mm, so either they are going to have a rude awakening when this won't plug into a socket, or the layer count is wrong, or they somehow have some different connector that can accept a PCB over 1mm thicker than usual. The absolute thinnest PCB possible in 14 layers would be composed of 27 layers: 14 copper foil layers and 13 layers of "prepreg" which is the fiberglass material. The thinnest commonly available prepreg I could find was 0.09mm thick. 13 layers of this is 1.17mm which is nearly the full 1.2mm thickness, not counting the copper layers. 1/2 ounce copper is 0.017mm thick, so 14 of those adds another .238mm, for a total of 1.408mm. Most board places would rather make the board as separate 2 layer PCB sections and then laminate those with the prepreg, which is easier and cheaper and is why a typical board would be thicker than this theoretical minimum. It miiiight be possible to get 14 layers in 1.2mm using exotic materials, but the cost would be stratospheric.

maybe. If so, it sounds expensive. Having level translators on the main board (and RAM, etc) would make a lot more sense from a cost perspective. The adapters should be "dumb" pin converters and little else; just enough hardware to interface to the carts/controllers. The board they showed seems to be just some kind of development board without any form of audio or video on it which is what has me scratching my head. I don't see a defined purpose that it serves in its current form. Granted, not being able to see the bottom means there could be more useful parts there but without any connectors of merit on the top I am not so sure. Guess we gotta wait until more info comes out to know for sure.

I am not sure what the pcb is for actually. I looked very closely at it and can identify most of the stuff on it. There's what looks like a 240 pin DIMM end on the front edge of the PCB, which has the same cutouts. i.e. the edge locks and the cut in the middle for orientation. This board definitely plugs into something else. The large chip could be an FPGA; it's not an SOC since those have missing balls to assist in routing, and there's no memory present on the board (unless it's on the bottom). There are a bunch of switching power supplies on the right, and several .1" headers it looks around the BGA footprint itself. I assume the two connectors in the upper left is for the cartridge/controller adapters to plug in. Other than a possible JTAG and power connector there doesn't seem to be much else on the board. Granted there could be more parts on the bottom that aren't visible but so far I am not really sure what the point of this PCB is that couldn't be done with an existing FPGA dev board (if the large BGA is indeed an FPGA). The level translators might be in the adapters I guess. I can say one thing for this project though- this is far more hardware than the retro vgs/coleco chameleon or the ataribox has shown to date!

I want to know why they needed 14 layers to route it now. Seems 8 too many. The production cost on that has to be pretty insane too.

Looks like we hit 10000 posts! I didn't think the thread would get this big, but there it is. Thanks all!

nope, won't happen. Everything must remain synchronous or it will get ugly fast. Sorry 'bout that

It runs between the cartridge port and the expansion port. It's an input on the super nt, so this won't hurt anything. I am not 100% sure of the purpose, but I suspect just a general purpose signal that a cartridge can use to communicate with something plugged into the expansion port. Well this is the weird thing. The resonator they use always seems to be 21.47MHz which is the same as the system clock! I am still scratching my head at why they use a separate oscillator that is the same frequency as the system clock. The only thing I can think of is the edge rate or duty cycle or something isn't good enough on all models of SNES/SFC so they made their own secondary oscillator. It also appears that the superFX chip was designed with a crystal oscillator on the chip, but it is broken such that it won't oscillate a crystal or resonator. The crystal oscillator portion of a chip can be real tricky to get right since its params vary depending on process variations and stuff. Even modern stuff is not immune to this problem. Some of the latest PIC micros (the PIC32MZ series) have a broken crystal oscillator and you must use an external oscillator. The clock not being good enough somehow is the only thing I can think of, because they changed the system clock circuit on the SNES several times, starting out with a discrete transistor circuit (similar to the NES) and then tried a 74HCU04 inverter style oscillator. The PAL system has a really nasty clock that has tons of jitter in it because it generates an approximate 21.4MHz clock from a PAL rate crystal using a special "S-CLK" chip. Because they used this oscillator circuit, it makes it relatively easy to boost the clock by simply changing the resonator out with a faster resonator or crystal.

re: the extra pins, the Super Powerpak uses the entire B bus pins- I think it is the only cartridge that does. It uses it to map the SDRAM when writing to it using 21FFh. I discovered this when getting it to work with the snt. I think something uses every extra pin except for the WRAM enable and the EXPAND pin. So far, I have not found anything using those. Not counting those plug in carts that use the EXPAND pin for video.

The "zero lag" claim means the video is being sent out the HDMI as it is being generated by the PPU. There's no inherent lag in the SNES other than the lag the game itself generates. i.e. how long the game takes to process controller inputs. Running a random game is probably not the best way to test lag. You need a test ROM that will do something like change the screen white/black when a button is pressed to accurately gauge lag, and using a video camera isn't a great way either. Unless it can do 1000+ fps I'd imagine. You can use lower fps but would need to start incorporating some statistical analysis to really figure it out. To do a proper job of it a timer that is started when a button is pressed and stops when light is received along with a test ROM that turns the screen white when the button is pressed is the only real sure way of knowing IMO. This would get you accurate reproducible lag measurements. As for the snt's video path itself, it sends out the video as it is being generated with as minimal lag as physically possible (i.e. the snes and hdmi frames both start together at the top, and lag at the very top will be 0ms. The PPU generates video faster than the HDMI can consume it, so there will be a few ms of lag at the bottom, but it's non-cumulative. It is a fixed amount, because the two frames always start at the same time. The discrepancy is due to the HDMI's vblank being shorter relative than the PPU's. Most/all games read the controller in vblank, but then take the next frame to process it (i.e. the game logic usually cannot be run in the vblank itself) so this is going to introduce a mandatory 1 frame of "game lag" due to the game's processing logic. This will take around 16ms or so. A game taking two frames (30ms-32ms) to process fully might not be out of the question especially if it has a "frame rule" where the player and some objects are updated one frame and the enemies and other objects are updated on the next and then alternate.

yeah but that only runs NES/fami. It won't run any of the over a dozen systems the ntm runs.

there's no need to worry, it can recover if anything goes wrong. I can't show anything since it's writing, other than a flashing light.

yeah sorry not too possible to shorten firmware. Unless you're on dialup though the size shouldn't be an issue.

New firmware for the Super NT should be posted today fairly soon. The following changes have been made: Fixed Unholy Night crash/graphics issue. Fixed the -1 fix again to remove vertical zebra stripes. Fixed high-res colour math issues so Marvelous: Another Treasure Island works now without graphic glitches. Fixed Chrono Trigger crashing on entering save menu. Fixed Rendering Ranger R2 / Targa. Fixed Flashback’s audio buzz when entering inventory. Fixed Arabian Nights audio feedback issue. Changed wording of the checkbox in the cheat codes. It now says “enable checked codes” to reduce confusion. Changed “tools” menu to “cheat codes”. Added a “disable hotkeys” feature under hot keys. This lets you disable all hotkeys and controller auto polling until power is cycled. Fixed “menu bounce” setting so it shows up again. Fixed Tiny Toons Buster Busts Loose audio crash Fixed Batman Returns audio crash Added debugger under “hardware” menu (probably not the most useful for most people but I use it a lot so someone developing a game might find it useful). This rounds out most of the problems people had that I know of. Top Gear 3000 still has an issue as does Front Mission (jumping text) but that should be fixed by the TG3K fix. I will fix these on the next release.

Yeah I was thinking about this actually when I tried the mouse out. I am not 100% sure the best method to do it though. I guess maybe I could "OR" the two controllers together so both of them can control the menu. I would have to detect the type of controller first though to make sure some other peripheral didn't cause issues and possibly make it work with a multitap.

I don't know about a repro, but the original star ocean cart works fine here, I bought one specifically to test it out.

Sure, I just don't really have much to talk about at the moment though. Just doing all that behind the scenes stuff. No one's really asked any questions on the forum here, or if they do they get answered before I can. lol. Not that I am complaining mind you.

Going by the picture, at least now I know why there's a giant bulge on the top. It's so those double stack connectors will fit inside the case. I have to wonder if this is just a stock/standard mobo or dev board inside there. If you were designing a PCB you would most likely not use those "stacker" double height capacitors to get the form factor down. Those are super popular on motherboards and things like the orange pi. I did a bit of poking around on google images but didn't find a lot of things that had the exact set of connectors. It is possible they used some extension cables to get signals to the back though, like the USBs and power. Because only power was plugged in, it is possible they simply glued connectors over the holes and just hooked the LEDs up to the power socket with some resistors too. Kinda like an RVGS with plastic instead of cardboard?

I have been hard at work on a new crop of fixes to the firmware on the super nt. I have fixed pretty much all the outstanding bugs now. Even Rendering Ranger R2 works! The new update has around 10 or so game fixes which clears most of the backlog. It should be out by the end of the week I hope. but no guarantees.

This is the VRC7. It's similar to the '2413. The 2413 is up but I can't find it right now. The ROM is center left on the edge. http://siliconpr0n.org/map/konami/vrc_vii_053982/mz_mit20x/

Actually this wouldn't work- Second Life had a huuuuge amount of on line gambling using Linden dollars. People would convert real money into L$, gamble with it, then cash it back out into real money. Linden Labs made it easy to buy Linden Dollars and then convert it back to real currency with a small fee right through their website. The Linden Dollars were also pegged to the dollar and since L$ was all bought (or nearly all) with actual money, there wasn't a danger of inflation. The US government took a high interest in the massive amount of gambling and Linden Labs quickly announced a ban of all gambling. Just as well, too, since most of the machines were crooked. I know you were probably joking but this exact thing did happen before with a successful ecosystem (vs. a taco-based one, that while it might be tasty, currently doesn't exist).

you can put your patterns into /patterns/ off the card root if you want to keep them out of the root. it will look in /patterns/ first and if not found default to the root.

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

it's pretty messy when you change, so it will force some settings. not much else I can do with a lot of changes and making assumptions on what people think it will do.