nesdev.org

May I ask if fullscreen would be too much to add? A mode that runs fullscreen at 512x448 (2x blocky scaled) would be wonderful and I would donate happily for it.

nothing new regarding improvments, bugs posted in this thread ?

No still no screenshots and such things. For the bugs - I've somehow lost track about what is still wrong. The "donate for update" idea has been rather contraproductive for getting bug reports :-/ the good news is that bug reports for v1.2 will still apply for v1.3 so everybody can see what is wrong with this emu.

May I ask if fullscreen would be too much to add? A mode that runs fullscreen at 512x448 (2x blocky scaled) would be wonderful

Yeah, isn't my personal priority, but should be a must-have feature... it is somewhere on my todo list. Programming it isn't really difficult - but somehow uncomfortable (a bunch of small details to be recursed).

The normal way to go would be somehow scaling the image to the current screen resolution, like 1280x1024 or whatever you have, eventually recursing the SNES aspect ratio. Doing that scaling by software would be endless slow, and my attempts to use hardware accellerated scaling via OpenGL and DirectDraw have been rather disappointing.

The other way would be switching to 640x480 pixel mode, scaling would be faster in that case, but the mode switching would be 2-3 seconds (on my computer at least... maybe better monitors/drivers can be doing it faster... or even slower?) - if you want to frequently switch from one window to another then it'd be useless annoying. Though if you want to play continously for next some hours then a few 2-3 second delays might be acceptable?

On "wide" screens, I think 640x480 pixels would work, but the pixels would become horizontally stretched to non-square ratio, right? In case of the SNES, that might be a "desired dirt effect".

Is the Character Viewers (2bpp, 3bpp, 4bpp, 8bpp) and a few other VRAM viewer stuff fixed yet (1.4)?

SPC needs to be fixed a bit too, but in a lower priority...

nocash wrote:The other way would be switching to 640x480 pixel mode, scaling would be faster in that case, but the mode switching would be 2-3 seconds (on my computer at least... maybe better monitors/drivers can be doing it faster... or even slower?) - if you want to frequently switch from one window to another then it'd be useless annoying. Though if you want to play continously for next some hours then a few 2-3 second delays might be acceptable?

Correct. If I'm going to be playing for 15 seconds at a time, then I'm either debugging or taking screenshots, and in either case, I want window mode.

On "wide" screens, I think 640x480 pixels would work, but the pixels would become horizontally stretched to non-square ratio, right? In case of the SNES, that might be a "desired dirt effect".

A lot of NTSC VDPs have a 5.37 MHz dot clock, such as ColecoVision, NES, SMS, and Super NES. The pixel aspect ratio (PAR) for these is 1.143:1, or exactly 8:7 if Rec. 601 is to be believed. The PAR of a 640x480 video mode on a 16:9 screen is 1.333:1. The ideal mode for a perfect PAR is 560x480 for a 4:3 screen or 746x480 for a 16:9 screen.

And how do you translate from the Super NES's RGB space to the monitor's RGB space? I know the TurboGrafx-16's RGB space isn't a direct mapping due to cost cutting on the encoder (and quite off in several places, I've read), but I haven't investigated that of the Super NES. Do you simulate the encoder and decoder?

tepples wrote:

nocash wrote:The other way would be switching to 640x480 pixel mode, scaling would be faster in that case, but the mode switching would be 2-3 seconds (on my computer at least... maybe better monitors/drivers can be doing it faster... or even slower?) - if you want to frequently switch from one window to another then it'd be useless annoying. Though if you want to play continously for next some hours then a few 2-3 second delays might be acceptable?

Correct. If I'm going to be playing for 15 seconds at a time, then I'm either debugging or taking screenshots, and in either case, I want window mode.

On "wide" screens, I think 640x480 pixels would work, but the pixels would become horizontally stretched to non-square ratio, right? In case of the SNES, that might be a "desired dirt effect".

A lot of NTSC VDPs have a 5.37 MHz dot clock, such as ColecoVision, NES, SMS, and Super NES. The pixel aspect ratio (PAR) for these is 1.143:1, or exactly 8:7 if Rec. 601 is to be believed. The PAR of a 640x480 video mode on a 16:9 screen is 1.333:1. The ideal mode for a perfect PAR is 560x480 for a 4:3 screen or 746x480 for a 16:9 screen.

And how do you translate from the Super NES's RGB space to the monitor's RGB space? I know the TurboGrafx-16's RGB space isn't a direct mapping due to cost cutting on the encoder (and quite off in several places, I've read), but I haven't investigated that of the Super NES. Do you simulate the encoder and decoder?

The option to preserve pixel aspect ratio correctness VS pixel-to-pixel crispness would ideally be open to the end-user of the emulator.

Got the debug message window implemented in no$sns. Now I need an I/O port where I can write the ASCII characters to (so they will be shown in the new window). I could just pick Port 21FFh, which shouldn't be used for other purposes.

But if possible, I would stick with existing "standards". How are other SNES emulators doing character output? What I/O address(es) are they using? Which emulator(s) do support character output? Are there any?

PS. same question also for the NES (in case anybody here knows anything about NES char output).

Just released no$sns v1.4 - http://nocash.emubase.de/sns.htm (it's currently completely freeware, all versions available with and without donations; I am totally broke so it doesn't matter if I don't get money or not).

The debug message character output via port 21FCh is now working. There's also a new 21MHz timer mapped to reading port 21FCh. And the VRAM viewer is now supporting the Tile View pages (with scrollbars to view the whole 64Kbytes of VRAM).

The NSS arcade cabinet emulation is now looking much nicer & does now works with all existing 12 games - with thanks to DogP for datasheet, font-dump, and prom-tests.

And finally - the one thing that everybody has waited for: The Exertainment Bicycle is now emulated - so you can now do all the hot exercising at home (by just pushing your analog gamepad forward) - with thanks to byuu for identifying the exertainment's rs232 chipset.

And finally - the one thing that everybody has waited for: The Exertainment Bicycle is now emulated

Pssh. You know damn well that we've all been dieing to play JRA PAT with an emulated NTT Modem network.

I want to bet on my Japanese horse races, dammit!

Anyway, congrats on the bike support. Did you ever figure out what's stored in the base unit's SRAM chip?

The modem? I thought you wanted http://board.byuu.org/viewtopic.php?p=70939#p70939 the bicycle.
Well, then the modem one, okay. Ah, but that's difficult - english translation of JRA PAT would be very helpful!
At the moment I've no clue if it's using a specific horse-related transfer protocol, or if it's some standard mailbox/terminal protocol.

The other thing I still had in mind would be the Lasabirdie golf club. Does anybody have that thing? Or know where to contact such people? Photo of the interiors would be neat to get an idea how it works.

It uses HBTP, Horse Bet Transfer Protocol.

> The other thing I still had in mind would be the Lasabirdie golf club. Does anybody have that thing?

It's obscenely expensive, like $400 USD+.

> Photo of the interiors would be neat to get an idea how it works.

If I'm thinking of the right one, it's just a motion sensor. Or maybe that was the baseball bat. Meh.

Then one just needs to add OpenNetworkConnection('hbtp://www.jra-pat.com/') to the emulators init function!
Pretty lame that it wasn't emulated yet ;-)

The Lasabirdie has a yellow laser symbol on the golf club, and thus (probably) a series of light sensors in the golf mat.
Rare as it is, I am not hoping for much more tech info than photos. If somebody shows up owning that thing, I could maybe spend a day on making test program that displays the bunch of numbers that it's transferring to the SNES.

byuu wrote:Or maybe that was the baseball bat. Meh.

Speaking of the baseball bat, I have one of those around here somewhere. If you're interested, I could see about a teardown...

Yeah, baseball bat would be also interesting. Though it seems to be quite dumb - just simulating a normal joypad.
As far as I understand, there aren't any direction/position sensors, and reportedly not even speed/strength sensors, and swinging the thing just "pushes" a joypad button. Or are there more features in there?
The biggest secret that I am aware of are the four DIP switches, I would assume that they just allow to map the swing sensor to A,B,X,Y joypad buttons (?)

The TeeV golf club is bit more intelligent - I don't really know how it works - but it seems to be able to sense speed/strenght, and probably also if you've missed the ball, and it appears to generate game-specific joypad signals (via it's game-specific "bios" cartridge).

The Lasebirdie golf club is pretty different: it doesn't simulate joypad signals, and instead it's transferring some special analog stuff, probably with hit/miss, speed/strenth, and maybe even direction information.

I wonder if the time the button is held is proportional to strength. Otherwise it might just be timing of the swing, like baseball in Wii Sports.

Hi nocash,
Don't want to stress you but do you have some news about a new version of no$sns ? some times ago, i posted some features (and bug reports ...) that should be great for no$sns (such as good vram & ram init and snapshot capability).
Continue your great job regarding emulators and as usual, i wil donate for your new update (i did it this day for your new no$gba version, thanks for that )/