kevtris

Great! Glad that the fixes worked. I did check it out on the HDMI analyzer so I know the packet is going out right but good that it works out in the wild now.

Firmware 4.3 has been posted. Changes include: * Fixed Front Mission - Gun Hazard. This game did mid-frame HDMA enables and disables. Pocky and Rocky should be fixed too with this since it does that as well. * Fixed Ninja Warriors * Re-fixed the Mecarobot Golf fix, this should fix several random crashes. * Fixed Uniracers 2 player mode, where player 2 hovered above the track. * Partial fix on Front Mission - bottom of text box no longer moves, but the text sometimes does. * Added individual RGB gamma sliders. * Added "straight through" RGB when not using HQX scalers; this should fix the RGB issues people had. These are under the "scanlines" menu. * Linearized the brightness steps for the overall screen brightness (PPU reg 2100 bits 0-3). * Added limited RGB mode checkbox. This is under the "scalers" menu. Also now I am sending out "underscan" flags, and "IT content" flags which should force some monitors/TVs to disable overscan, and any filtering/processing (IT mode). * Super Powerpak fixed - check "use launch system timing" box under the hardware menu if you wish to use one. https://support.analogue.co/hc/en-us

Not really, that clock is what the entire system runs on so I can't change it easily without causing a bunch of other issues. it would no longer be synchronous with the rest of the bus.. which would be a Bad Thing.

It is if you put it into PAL mode (under the hardware sub menu). You can set resolution to a 50fps one (if your tv/monitor supports it) to get zero lag on PAL games. Otherwise it will properly run at 50fps but it will be upscaled to 60fps. This will force it into fully buffered, if you've set it to "zero lag" due to the frame rate mismatch.

you can just hold the reset hot key down as long as you like. that will let you do long presses.

Apparently PAL composite works properly on version 1.7 or earlier so says Great Hierophant. I have not had time to check it out personally. So the fix is to use earlier firmware for now. RGB/component works OK in all versions for PAL, however.

As mentioned earlier, I managed to get the super powerpak to work on the super nt. Bunnyboy lent me two of his personal units but I have to return those, but I got a hold of one to keep so I can make sure it will continue to work on future versions of the firmware. I am not sure how many people have a super powerpak and a super nt, but they can rest easy now. hehe.

It was never complete? what wasn't complete about it? from what I recall, I got all games to work on it. It also supports the FM expansion audio.

it was because ROM chips were expensive. Compressing the graphics saved lots of space, and thus money.

I saw this problem originally and it was because macs love to put some kind of metadata file for everything in the directory. I thought this problem was solved but apparently not totally. I do not have a mac or any way of fixing it though because I cannot reproduce it here.

I think many of those weird random crashes are a result of the "fix' I did for mecarobot golf that is on the 4.1 firmware. I tinkered with the HDMA's and unfortunately it's possible for them to crash the system if things line up just right. ninja warrior just happened to cause it to happen nearly continuously, hence the game crashing if you pause or just let it run a little while. I did fix this bug (and a bunch of others) for the next release but I wanted to fix a few other things and add some new stuff before the next release.

A = start address of the sample. L = length of the sample. The arrow indicates if the sample is looped. straight = not looped, sample plays once. circular = sample is looped. The A/L values are the values written into the DPCM registers themselves. This mainly lets you see if it is changing the sample and if so which one it is by its address. Some tunes will bankswitch DPCM area though so this isn't sure fire always going to be the case, but it just gives you more information to watch while it plays back.

That's how the nt mini does it as well,it loads the core direct off the SD card without writing it to flash.

I forgot to post about this the other day, but I bought one of these dumb things (TV link) off ebay last year and did a bunch of RE work on it. Basically, the way it works is the chip on the right is a supervision chip, but it is not the same as the chip on the handheld system- it is similar, but the frame buffer is different and seems to be designed to be polled by the second TV chip on the left. The chip on the bottom right is a 64K ROM which contains the border graphics (I was going to dump it but haven't had time yet). The other two little carrier glop tops are the two 8K RAM chips that the supervision chip needs like usual. (8K of CPU RAM, 8K of VRAM/frame buffer). The "cartridge" that plugs into the supervision handheld is a lol, and all it does is turn your supervision in a power hungry controller. The ROM on the cartridge simply reads the buttons and sends them in parallel down the cable back to the base unit- you DO NOT even need it to play the games. You can simply send the up/down/left/right/button presses down the wire and it will work fine. I guess they had to justify the use of the supervision handheld *somehow*. lol. The two TTL chips form a johnson counter that divides the 21.47727 (or 26.6Mhz for PAL) down by 5 or 7 to run the supervision chip. Like the super gameboy, the frequency is off (but worse) so pitch of the audio is off, as well. The supervision runs at nominally 4Mhz, so you get either 4.295Mhz in NTSC mode (7.4% fast) or in PAL it will be ~3.8MHz (5.2% slow). The three jumpers near the chips that have two positions configures the johnson counter for the desired divisor. It's been over a year so my memory is a bit hazy now and I can't find the schematic I drew of it. At least one of those solderable jumper pads is to put the video chip into PAL mode. I did find the pinout (mostly complete) of the two chips. The "512D" is the 64K ROM holding the border graphics. CPUxx are the CPU address/data lines which run to the cartridge and the 8K of RAM connected to the CPU. VRAMxx is the video RAM/frame buffer (8K) bus. pinout of 64 pin video chip: 1 - RC network; this pin to three parts to ground: R8, C3, C4 (1K, .1uf, 820pf) 2 - video out 3 - /RST 4 - GND 5 - JP4 (pulled up, no solder to ground) 6 - 15.72KHz square wave 7 - 59.97Hz square wave 8 - JP3 (pulled up, no solder to ground) 9 - VCC 10 - GND 11 - Xin 12 - Xout (21.47727MHz) 13 - some kind of timing signal, appears to be pixel clock? 14 - GND 15 - JP2 (pulled up, no solder to ground) 16 - 59.97Hz square wave 17 - nc 18 - composite synch 19 - 20 - A0 (512D) 21 - A1 (512D) 22 - A2 (512D) 23 - A3 (512D) 24 - A4 (512D) 25 - A5 (512D) 26 - A6 (512D) 27 - A7 (512D) 28 - A8 (512D) 29 - A9 (512D) 30 - A10 (512D) 31 - A11 (512D) 32 - A12 (512D) 33 - A13 (512D) 34 - nc 35 - nc 36 - GND 37 - A14 (512D) 38 - A15 (512D) 39 - D0 (512D) 40 - D1 (512D) 41 - D2 (512D) 42 - D3 (512D) 43 - D4 (512D) 44 - D5 (512D) 45 - D6 (512D) 46 - D7 (512D) 47 - 48 - 49 - CPU #64 50 - CPU #66 51 - VCC 52 - CPU #65 53 - CPU #64 54 - CPU #63 55 - CPU #62 56 - CPU #61 57 - CPU #60 58 - 59 - 60 - 61 - VCC 62 - video 63 - video 64 - video 60 - KC5475C pin #57 61 - KC5475C pin #56 62 - KC5475C pin #55 63 - KC5475C pin #54 64 - KC5475C pin #53 65 - KC5475C pin #52 66 - KC5475C pin #50 67 - KC5475C pin #49 68 - KC5475C pin #48 69 - KC5475C pin #7 70 - KC5475C pin #6 71 - KC5475C pin #13 pinout of cpu: 1 - VRAM A12 2 - VCC 3 - nc 4 - VRAM D0 5 - VRAM D1 6 - VRAM D2 7 - VRAM D3 8 - VRAM D4 9 - VRAM D5 10 - VRAM D6 11 - VRAM D7 12 - button input 13 - button input 14 - button input 15 - button input 16 - button input 17 - button input 18 - button input 19 - button input 20 - CPU D7 21 - CPU D6 22 - CPU D5 23 - CPU D4 24 - CPU D3 25 - CPU D2 26 - nc 27 - CPU D1 28 - CPU D0 29 - CPU A16 30 - CPU A15 31 - CPU A14 32 - CPU A13 33 - CPU A12 34 - CPU A11 35 - CPU A10 36 - CPU A9 37 - CPU A8 38 - CPU A7 39 - CPU A6 40 - CPU A5 41 - CPU A4 42 - CPU A3 43 - CPU A2 44 - CPU A1 45 - CPU A0 46 - WRAM /CE 47 - WRAM /WE 48 - CART /CE 49 - GND 50 - audio out 51 - audio out 52 - nc 53 - VCC 54 - expansion port #5 55 - expansion port #4 56 - expansion port #3 57 - expansion port #2 58 - RV1 wiper 59 - battery low LED 60 - KC5475C pin #57 61 - KC5475C pin #56 62 - KC5475C pin #55 63 - KC5475C pin #54 64 - KC5475C pin #53 65 - KC5475C pin #52 66 - KC5475C pin #50 67 - KC5475C pin #49 68 - KC5475C pin #48 69 - KC5475C pin #7 70 - KC5475C pin #6 71 - KC5475C pin #13 72 - 73 - 74 - /RST 75 - GND 76 - 4.295454MHz clock in from divide by 5 off of 21.47727MHz oscillator 77 - 78 - nc 79 - 80 - 81 - GND 82 - 83 - 84 - 85 - 86 - 87 - 88 - 89 - 90 - 91 - VRAM /WR 92 - VRAM A0 93 - VRAM A1 94 - VRAM A2 95 - VRAM A3 96 - VRAM A4 97 - VRAM A5 98 - VRAM A6 99 - VRAM A7 100- VRAM A8 101- VRAM A9 102- VRAM A10 103- VRAM A11 104- nc

yes it has a composite amp on it. this is because loading on the video pin is critical, and even the 1-2 inch route on the pcb is too much, and it will pick noise up and cause issues. So I have a built in composite amp to compensate.

yes there's some issues with the scanlines; I am going to totally retool how they work in the relative near future when I get the rest of the game bugs handled. I want to get rounded edges and stuff working on it to make it look better.

I dunno, it will probably clip it to limited range.

yeah you are right. I think I have it figured out how to make it report properly so it displays as full range. I have this on the list of fixes to add for the next release so hopefully that will fix the problem for people. Funny how we still can't shake the CRT stigma on HDMI with overscan, interlace, and limited range (to account for synch pulses and such AFAIR). The fix will be to report as "computer" which should clear up the range issues. I am going to add separate rgb gamma sliders so that should quell all the other issues people had with the brightness stuff, and recalculate how the levels are generated. Maybe in the future I will do some testing on various model SNES to get actual voltage levels to see how linear the DACs are (there's four DACs - the three RGB ones and the overall brightness DAC)

I did both, and OPL3 too. The VRC7/YM2413 are both based off the OPL3 core actually.

Dunno, the 68K is probably the worst part. Other than that, I don't think it's as complex as the SNES was but I am sure it has lots of quirks and weird things too. I have done FM before and video so I don't think it will be too terrible or out of that out of the ordinary. The worse part is people wouldn't like if it didn't run sega CD or the 32x, which it most likely wouldn't do. It'd be stock genesis only. That's not to say it wouldn't have expansion for the cd, but it definitely would never support the 32X because it'd need to output analog RGB, then re-capture analog RGB from the 32x for its video overlay. So I suspect the bitching would be epic if I didn't support those things. I could be wrong and it has happened before :-)

People have asked about being able to power the cart only, but unfortunately this is not possible. When power is turned on, the cartridge is powered too. This function cannot be added without a pcb/hardware change. I never envisioned anyone would ever want to turn the power to just the cart off and back on. The sd2snes returns to the menu if you hold reset for 2 seconds or so, and I think super everdrive does as well, which I figured was "good enough" .

The super nt only draws 2.5W during operation, so it does not need active cooling. That picture doesn't really tell much other than where heat is generated- it does not say how much. The scale might only be 10C or 1000C, it just shows the contrast between cooler/warmer and no absolute value of temperature.

in the future I might add an option in the menu to force compatibility. I can "lie" to the game a little and make it think it's a regular controller. The only downside is this function will need to be disabled to use the multitap or mouse on port 1. (port 2 would be unaffected and all the commercial games use the multitap on port 2)

pretty sure this is normal. I found many things that do not like the ntt data pad. they do controller detection, and it returns a different ID from a stock controller. the super gameboy won't see any controller presses at all with one in. I found this highly annoying. the multitap games also hate it too and will not detect it at all as a valid controller.

sure, though honestly they aren't as high of a priority as original releases. I do want to get it to 100% if at all possible.