Jump to content

    Nintendo DS Wifi Documentation Released!

    Alpha
    By Alpha,

    SgStair's Nintendo DS Wifi Documentation has been released! He's getting very close for a full release of his DSWifi which is a homebrew library for the Nintendo DS to allow developers to add wireless internet support to their applications. He has also won $ 1406.57 of $ 2813.15 from the DS Wifi Bounty. Congratulations Stephen Stair!

    I've completed my initial documentation for the DS wireless system, and it has been accepted to complete the first milestone of the DS Wifi bounty! More to come soon, as I'm working very hard on my TCP stack, so far things are still looking good.

    Non-Wifi Hardware

    General Information

    Related Registers - System control

    Wifi Hardware

    General Information

    Wifi Hardware Overview/Capability

    Wifi I/O Map

    Hardware Init Sequence

    Register Documentation

    Wifi Rx Registers

    Wifi Tx Registers

    Wifi RF/BB Chip Control Registers

    Wifi Other Registers

    Wifi Unknown Registers

    Additional Information

    Wifi Transmit Procedure

    Wifi Receive Procedure

    Wifi Change Channels Procedure

    About the "undefined" data in this document

    Formats/etc

    General Formats

    802.11

    Wifi Formats

    Hardware TX header

    Hardware RX header

     

    »» DS Wifi Hardware Reference

    »» DSWIFI.1EMULATION.COM [Official Forum]

    »» AKKIT.ORG/DSWIFI [Official Homepage]


    64th Note v1.0 beta 21 Released!

    Alpha
    By Alpha,

    We're a day late on this release. :P

     

    6493wk.png

     

    64th Note is a USF plugin for Winamp, based on Project64 1.4 by Zilmar and Jabo and Azimer's HLE Audio Plugin. It requires major CPU and memory resources, 300 MHz and 64 MB are the minimum for the least-intensive USF sets, but requirements vary greatly between sets.

    I fixed that bug Josh and I were discussing that broke games using the alternate FPR access mode, and I also implemented a small workaround for an irritating problem with the DirectSound output plugin, wherein it would cut off the track early (like a half second). It seemed to be due to the size of the buffer, as when I changed it to 333 ms (from 2000ms) that problem went away, so I now don't stop sending data to the output plugin until (Track Length + Max Latency) (max latency being the buffer size, or close to it). I've tested it with the DSound output plugin and also WaveOut, but I haven't tried any of the alternate players (XMPlay, KBM, foobar2k, etc.) yet.

    »» Homepage / Download

    --> http://www.halleyscometsoftware.com/mboard...d=48&showpage=9


    FakeNES October 26 WIP is now available!

    General Plot
    By General Plot,
    News: FakeNES (!) October 26 WIP is now available!

     

    Whats New:

     

        * 10/26/05

        * ALL: Added support for decoding NESticle raw patches. [siloh]

        * ALL: Modified main loop to only consume as much CPU as neccessary (experimental). [siloh]

        * ALL: Added automatic VRAM page buffering (greatly reduces the need for VSync). [siloh]

        * AUD: Implimented 60FPS Audio [siloh]

        * AUD: Overhauled all pAPU buffering code. [siloh]

        * AUD: Vastly improved audio playback code, eliminates skewing of emulation timing (experimental). [siloh]

        * AUD: Removed support for user-defineable audio buffer lengths (fixes some playback problems). [siloh]

        * AUD: Added 'Stereo Mix' mode that produces mono sound while allowing stereo effects. [siloh]

        * AUD: Added audio anti-aliasing. [siloh]

        * AUD: Added audio 'hard sync' option to emulate old pAPU behavior. [siloh]

        * GUI: Added support for custom fonts, loading dialogs/menus into malloc'ed memory, assorted bug fixes, and more. [siloh]

        * GUI: Added unfinished 'Panta' GUI theme. [siloh]

        * GUI: Changed 'Audio > Mixing > Speed' menu title to 'Frequency'. [siloh]

        * GUI: Removed 'Audio > Mixing > Advanced' menu [siloh]

        * GUI: changed 'Reverse Stereo' to 'Swap Channels' to match the configuration file entry. [siloh]

        * GUI: Improved mouse handling. [siloh]

        * GUI: Misc Fixes [siloh]

        * SRC: Renamed 'mouse_sprite' to 'gui_mouse_sprite' to fix API conflict with Allegro-djgpp. [siloh]

        * SRC: Casts are no longer used on lvalues. (for GCC4) [siloh]

        * SRC: Replaced 'yield_timeslice' call with 'rest (0)' and removed support for 'usleep'. [siloh]

        * SRC: Fixed some compiler warnings. [siloh]

        * SRC: Updated copyright notices. [siloh]

     

        * Changed Default Settings: Vid Res: 320x240 -> 640x480

        * Vid Blitter - Automatic -> Stretched

        * Palette - Default -> Modern NTSC

        * Linear Echo - ON -> OFF

        * Audio Filter - LPM3 -> OFF

        * Spatial Stereo - Mode 2 -> OFF

        * Sample Rate - 96000 -> 48000

        * Pseudo Stereo - Mode 2 -> Mode 3

    »» Homepage


    Nicola's MAME Ramblings

    General Plot
    By General Plot,
    Strange that nobody noticed

     

    Check the final level of Fairyland Story ending on MamEnd.

    The background graphics are quite obviously broken in the top left corner! Strange that nobody reported this bug.

     

    Anyway, I've fixed it now.

     

    I've also been studying what the MCU does in that game, and the programmers made some interesting choices.

     

    First of all, the MCU can return data stored in its internal ROM. This is done with short tables that are needed at the beginning of a level, and when you die. More interestingly, the text needed for the continue screen is stored there, and since you can't continue until level 8, it would take some time for a bootlegger to notice the problem. Even more interestingly, the endgame text is stored there, so one would have to play all the 101 levels to get to the protection.

     

    Another wicked part of the MCU protection is that before action starts in a level, the game takes three bytes, performs complicated calculations on them to convert them into an 8-byte number passed to the MCU, and the MCU then performs more complicated calculations, recovers the original bytes and sends them back. A lot of work to essentially do nothing.

     

    Finally, during the final level, the MCU is used to calculate and update the trajectory of the dragon's fireballs. Without the MCU, the dragon doesn't fire. I just have to wonder: why bother? How many people would have reached the final level in the arcades? And would bootleggers have bothered anyway? Figure some player going to the arcade owner and asking for her quarter back because the ending was too easy :P

    »» Homepage (Blog)


Portal by DevFuse · Based on IP.Board Portal by IPS
×
×
  • Create New...