|
|
Nintendo DS News is a News and downloads site for All Nintendo Handhelds and Consoles including the Gameboy, NES, N64, Snes, Gamecube, Wii, WiiU, NDS, 3DS, GBA and Snes, We have all the latest emulators, hack, homebrew, commercial games and all the downloads on this site, the latest homebrew and releases, Part of the
DCEmu Homebrew & Gaming Network.
THE LATEST NEWS BELOW
|
January 19th, 2010, 10:40 Posted By: wraggster
News/release from aquaz
Hello,
I presented RapidFire and Emoticone nearly one month ago, two Palib minigames I have made to see what can be DS development.
Now I present a gameplay demo of Alibis, a game much more ambitious than the previous ones. This could be call a Castlevania-like because of the original principle but in fact the gameplay is very different.
Download and Give Feedback Via Comments
To read more of the post and Download, click here!
 Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
 |
|
|
|
January 19th, 2010, 02:33 Posted By: wraggster
News via http://www.wii-addict.fr/forum/Wiixp...95-t18117.html
Wiixplorer is a file browser for the Wii achieved by dimok and r-win.
(He allows, among other delete homebrew directly from the console as HBC but without its freeze time other that is the case with homebrew Channel.)
As there were 23 rev since it is available it is a long sorry.
QUOTE
r95 - * Fixed Updater. Sorry otherwise you will not be able to update later on anymore.
r94 - * Finally fixed the bug that was causing the SMB to act weird. Now you can enjoy
the nice new speedup of the SMB. Now i can make this the next official revision.
* Fixed loading / saving of settings and other things to USB
r93 - * Added DVD Drive support (thanks joe (FTPii) for his libfst and libiso)
You can copy files / directories from a normal DVD or a WiiDisk now. Just insert a
disk and click the DeviceMenu Button.
* Added the option to load the config file from the USB Device
The app will try to find a config file on SD card first if none is found it will
try finding one on the FAT/FAT32 USB Device. If both searches failed the app
will try to look from Which device it was started and if that Fail the default
is set to SD. I could not test it completly Because of lack of time but i hope
some other people can.
r92 - japanese.lang fixed
R91 - * Language files updated.
r90 - * Added function to libtinysmb Disk to get information on the SMB. Now you can
also see the free and total space on SMB.
r89 - * Changed Properties to a Class
* Added total and free DeviceSpace to the Properties as wished by many. You can
find it if you do a properties of any folder on the device (not there on
Properties of a file)
* Added Properties for Archives also showing Size, CompSize and some more
* Fixed little memory leak from last rev
r88 - * Changed bash file to the autoupdate meta.xml file with revision number and date
* Changed Updater to also download and meta.xml icon.png
* Changed back to network background initialization (it's still buggy though, i
can not figure out yet why is not connecting smb proper)
* Added support 7zip extract now (though to extract filesize is limited by the
Wii's memory Because of the use of ANSI C source. Also big dictionary and
solidblock sizes slow down the extraction process.)
* Added support for RAR browsing.
R87 - * Added support 7zip
* New ArchiveBrowser now added (now you can browse directly through zip and 7zip
files by clicking on them as if they are folders)
* New added one file / folder at a time extracted from an archive (and ExtractAll
like before)
* New added RightClickMenu own for the archives containing (Open (not implemented
yet), mining (extracting the selected item), Extract All (extracting all the
items of the archive)
* Changed back to old way with update rXXX.dol
* Made the dynamic RightClickMenu to grow with the number of Choices in it
R85 - * Added TextEditing functions as promised long ago
* OnScreenKeyboard improved. Now you can point to a letter and edit at that
point. Also moving right left with the blinking line editing is possible with
the D-PAD.
R84 - * Lots of fixes and optimizations
* Added new optimizations from libwiigui by Tantric
R83 - First Fixed *
* Now we exit the main function returns 0 instead of exit (0)
R82 - * Too many changes to list here (Check out OOP branch for changelog). Mainly
architectural changes and updates like tinysmb lib and ntfs. Also checkout the
download section for new files for libogc devkitPPC R19.
r81 - * added forgotten files in last rev
r80 - * added meta.xml & icon.png update
* Added a PowerMenu, you can choose between idle or full shutdown
R79 - Fixed the non-working function updateDol
R78 - * Changed the way about the update language, language files are now downloaded
GBAtemp language from the topic. So u can get the last language file available
instead to wait the new svn commit.
* Now when u click on the adressbar in the languagefiles browser, u can change
The language file folder.
* fix compile warning with devkitpro r19
R77 - * Little fix for the "no new update window"
R76 - * Revert back to R70 Because of too many problems with the recent revisions.
(please no more commits till the architectural redesign is done)
* Put R75 to branches for later use (dj_skual you can work in that directory if
you want)
* Changed the way the update is working to keep it DownloadCount googlecode site.
r75 - * Language files updated
* Added a Home Menu (press Home on wiimote and exit select your choice) (perhaps
soon feature linked to the Gui like volume will go in the wiimote button cette
prompt)
* Little modif in the otionbrowser
R74 - [No log message]
R73 - * Language files updated.
* Update Language file added in wiixplorer language in the quick browser
R72 - Reverted Updatepath to WiiExplorer, since that's the path the Homebrew Browser
uses.
Download Here and Give Feedback Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 19th, 2010, 02:29 Posted By: wraggster
CustomizeMii 2.1 released by Leathl
CustomizeMii is a custom channel creator for the Wii.
The .NET Framework 2.0 is required to run this application!
A mono version is available which runs under Linux / Mac OS X (Requires the mono framework to be installed!)
Thanks to icefire / Xuzz for the basic idea of this Application!
And No: This has nothing to do with piracy! It's for creating custom Channels for your Homebrew Apps (like the Homebrew Channel).
Changelog
Version 2.1
Added CustomizeMii Installer (by WiiCrazy / I.R.on)
Fixed rough edges (artifacts) on images (will be fixed automatically)
Replaced the TPL preview window with the one from ShowMiiWads for easier handling
Added loop prelistening to the BNS conversion window (only for wave files)
Added drag & drop ability cause the file dialogs kept bothering me
Improvement in startup speed (thanks shadow1643)
Added creation/last edited time (only for CustomizeMii 2.1+ channels)
Added a button to translate the word "Channel" to every language
Improved detection of required TPLs
Little improvements and fixes
Changed the complex forwarder to be more configurable (choose any path you want)
ForwardMii is now bundled with CustomizeMii
http://wiibrew.org/wiki/CustomizeMii
Download and Give Feedback Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 19th, 2010, 02:24 Posted By: wraggster
News from the HackMi Team:
I have been spending some time on reverse engineering the Nintendo CIC ROMs. The CIC is the “lockout” chip in NES/SNES/N64 cartridges, used to get an iron grip on the market prevent people from copying games. It was manufactured by Sharp and is likely one of their old “one-chip microcomputers”, used in calculators and TV remotes and the like. I couldn’t find a document describing the instruction set it uses (or its architecture!), so I made it all up (combining information from lots of sources: old datasheets, old patents, and the low-res die photographs).
The N64 chips are different, and I haven’t seen a ROM dump of those yet, so all of the following is NES/SNES only.
There is one chip inside the console, and one in every cartridge; the code inside the chip decides what to do based on a pin strap (the console one will be the “lock”, and the cartridge one will be the “key”). The two chips run off the same clock, and they run the same code, so they run in lockstep (sometimes they execute different codepaths, but the code is careful to take the same number of cycles on both paths in these cases). The chips communicate over two wires, one from key to lock, one from lock to key. Both chips calculate what bits they will send, and what the other guy should send; if what they receive is not the same as what they should have received, they panic, and the lock chip resets the console.
Here is the pinout of the CIC:
+------------------+
DATA_OUT <-- | 1 P0.0 +5V 16 |
DATA_IN --> | 2 P0.1 15 | ?
SEED --> | 3 P0.2 14 | ?
LOCK/-KEY --> | 4 P0.3 13 | ?
| 5 Xout P1.3 12 | <-- RESET_SPEED_B
| 6 Xin P1.2 11 | <-- RESET_SPEED_A
| 7 RESET P1.1 10 | --> SLAVE_CIC_RESET
| 8 GND P1.0 9 | --> -HOST_RESET
+------------------+The LOCK/-KEY pin is the strap pin I talked about above. The SEED pin has a capacitor connected to it; the discharge time of that is supposedly somewhat random, the lock chip times it and uses that as a random generator, to decide which of 16 possible streams to generate. It tells the key chip which one it chose.
The lock chip can reset the key chip (pin 10 on the lock is wired to pin 7 on the key), and it can reset the console. The RESET_SPEED pins are used on the 3195 to decide at what speed to “blink” the reset line (it’s connected to a LED as well): about 0.4s, 0.6s, 0.8s, 1.0s each of on/off.
There are dumps of the ROMs here, here, and here. All credits for doing these go to neviksti; thanks!
All the bits in those dumps are inverted (0 vs. 1); if you want to play along with the disassembler I’ll give a link to in a second, you’ll need to fix that; also, that third ROM is 768 bytes, which I don’t handle in my little conversion script, so you’ll need to remove the extra columns (they are empty anyway). Or enhance the script if you want to.
Okay then, here is that disassembler. Usage should be self-explanatory.
This ancient CPU looks mighty strange to modern eyes. Let me try to explain the architecture:
First, it is a 4-bit CPU. Yessir. It has an accumulator register, A, and a secondary register, X, both 4 bits. All RAM accesses are done via a single pointer register B, which is 6 bits; the CIC chip only has 32 nybbles of RAM though. There is also a carry flag, C.
Then, there is the process counter, PC. It is 10 bits, but there are only 512 bytes of ROM (except on the 3195, it has 768). The ROM is divided into banks of 128 bytes. When the CPU increments PC, it never touches the bank number.
Well, “increments”. To save chip area, they didn’t use a binary counter, but a polynomial counter; “incrementing” works by shifting the PC by one bit to the right, and setting the the top bit to 1 if and only if the bottom two bits were the same.
There are no conditional branch instructions; instead, various instructions can skip the next instruction if some condition is true (the instruction still takes time, it just doesn’t do anything). Oh, all instructions take one cycle; except for the two byte instructions, which take two cycles.
Finally, there is a four entry stack for the PC; it’s not in RAM, it is separate.
Now the instruction set:
"skip" means "do not execute next instruction"
"M" means "the RAM nybble addressed by B"
"BL" means "the low four bits of B"
"BM" means "the high two bits of B"
"PN" means "I/O port number BL"
"x.y" means "bit y of x"
00+N adi N "add immediate", A := A + N, skip if overflow (00 is nop)
10+N skai N "skip acc immediate", skip if A = N
20+N lbli N "load B low immediate", BL := N
30+N ldi N "load immediate", A := N
40 l "load", A := M
41 x "exchange", swap A with M
42 xi "exchange and increment", swap A with M, increment BL, skip if overflow
43 xd "exchange and decrement", swap A with M, decrement BL, skip if underflow
44 nega "negate acc", A := -A (two's complement)
46 out "output", PN := A
47 out0 "output zero", PN := 0
48 sc "set carry", C := 1
49 rc "reset carry", C := 0
4a s "store", M := A
4c rit "return", pop PC from stack
4d ritsk "return and skip", pop PC from stack, skip
52 li "load and increment", swap A with M, increment BL, skip if overflow
54 coma "complement acc", A := ~A (ones' complement)
55 in "input", A := PN
57 xal "exchange acc and low", swap A with BL
5c lxa "load X with acc", X := A
5d xax "exchange X and acc", swap X with A
5e ? SPECIAL MYSTERY INSTRUCTION
60+N skm N "skip memory", skip if M.N = 1
64+N ska N "skip acc", skip if A.N = 1
68+N rm N "reset memory", M.N := 0
6c+N sm N "set emmory", M.N := 1
70 ad "add", A := A + M
72 adc "add with carry", A := A + M + C
73 adcsk "add with carry and skip", A := A + M + C, skip if overflow
74+N lbmi N "load B high immediate", BM := N
78+N NN tl NNN "transfer long", PC := NNN
7c+N NN tml NNN "transfer module long", push PC+2, PC := NNN
80+NN t NN "transfer", low bits of PC := NNIt would seem that on the 3195, the sc and rc instructions are swapped, as are the coma and nega instructions.
If you look at the code in the ROMs, you’ll notice something strange with the ldi instructions: sometimes it runs two in a row. Descriptions for similar CPUs say that if you have two or more ldi instructions in a row, all but the first are skipped. The code still doesn’t make sense then; I suspect that this CPU does this skip only if some condition that I do not know yet is true.
This architecture is quite different from what we are used to today, and so it requires quite different programs; I’ll leave it to you to discover all the intricacies yourself though, it’s more fun that way!
I put a commented disassembly of these ROMs here. Some of that is a work in progress.
I hope you all find this as fascinating as I did!
http://hackmii.com/2010/01/the-weird-and-wonderful-cic/
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 19th, 2010, 01:25 Posted By: wraggster
While we’ve been told all of our lives Wiis and trains just don’t mix, they never said anything about Wii Nunchuks. One terribly abused joke later, [Ken] tipped us off about his Wii Nunchuk controlled train set.
By utilizing Digital Command Control (think pulse-width modulation) with an Arduino, he is able to have full control over the trains direction and speed. The other part of the equation is a Wii Nunchuk and adapter. The setup should be pretty self explanatory, but there is an Instructable for those that need more help.
http://hackaday.com/2010/01/18/wii-n...rain-controls/
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 19th, 2010, 00:03 Posted By: wraggster
Nintendo has already been talking up what a Nintendo DS successor might look like, so it wouldn't come as too much of a shock if we saw the device in the near term. That's what EEDAR analyst Jesse Divnich believes, anyway. He has a research note out saying that Nintendo will be releasing a new handheld in the next 15 months, and make the announcement within the next eight months. The reasons are numerous, including the need to bone up on online distribution, rampant piracy, and just the regular march of technology that Nintendo is never unaware of -- just ask the routinely trounced handheld competition. Unfortunately, there's nothing "solid" in this report as far as we can tell, so we'll have to wait for some "unnamed sources" or our cousin's friend's dad's barber to weigh in and tell us how it really is.
http://www.engadget.com/2010/01/17/n...t-too-long-af/
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 18th, 2010, 23:47 Posted By: wraggster
Japanese newspaper the Asahi Shimbun has claimed it did not misinterpret comments Satoru Iwata made recently regarding a new DS.
"The article quoted Nintendo president Satoru Iwata's comment accurately," the paper told Kotaku.
According to the original Asahi Shimbun article Iwata said, "[The new DS will have] highly detailed graphics, and it will be necessary to have a sensor with the ability to read the movements of people playing."
However, Nintendo later said his statement had been misinterpreted.
So who's right and who's wrong? Who knows.
http://www.eurogamer.net/articles/ne...-new-ds-report
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 18th, 2010, 23:42 Posted By: wraggster
A UK resident has been sent down for 12 months after pleading guilty to illegally importing R4 cards.
Yun Can Meng got 12 months for importing not just one or two R4 carts but over 26,500. Chances are he was part of something big and illegal.
The Entertainment and Leisure Software Association's (ELSPA) Crime Unit, Hull City Council Trading Standards Department and the Humberside Police all joined forces to deliver the hammer of justice in Hull Crown Criminal Court.
ELSPA team leader Michael Ralinson said, "Our crime unit is pleased with the outcome of this trial and pleased to see the Court of Appeal's copyright judgement is being robustly enforced. Intellectual property (IP) theft is an important issue for the country's videogames industry - as is protecting it."
http://www.computerandvideogames.com...VG-General-RSS
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 18th, 2010, 21:46 Posted By: Shrygue
via Computer and Video Games
Nintendo has rejected the idea that its new DSi XL is exclusively for older (as in, OAP) gamers - claiming that the handheld will appeal to more people than previous DS iterations.
The increased screen and pen size of the DSi XL have led some to assume that the device is custom made for short-sighted grandmas and grandpas.
But speaking exclusively to CVG, Nintendo senior product manager for DS James Honeywell said:
"It's absolutely not [just for old people]. DSi XL appeals to as many people, if not more, than its predecessors.
"With bigger screens and a larger pen-like stylus it's likely that older users may find the DSi XL easier and more comfortable to use but there are many more people it can and will appeal to.
"Gamers will undoubtedly appreciate the bigger screens so they can experience their favourite and the latest DS titles bigger and in a greater level of detail than ever before.
"We certainly know that a lot of families who play DS together will enjoy the wider viewing angle the DSi XL allows so they can play together at home and the fact the bigger stylus is less likely to get lost down the back of the sofa is another bonus for them."
Check back later in the week for our full interview with James Honeywell - to learn even more about Nintendo's plans for DSi XL.
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 18th, 2010, 21:08 Posted By: wraggster
Nintendo is giving Wii owners 500 free Wii Points - just for helping someone else get their console online.
To get 'em, you just need to enter the Wii Shop, selecting 'Online Ambassador' and entering the Wii number of the person you helped (or, indeed, who helped you).
Both parties will then get the magic free points. Good, eh?
For full details of the promotion, click through here and select 'Connection Ambassador Promotion'.
http://www.computerandvideogames.com...VG-General-RSS
What are you waiting for?
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 23:08 Posted By: wraggster
News/release from spinal
OK guys, here is the first alpha release. Don't expect moonshell2 or anything, most of the features don't work yet, all you have is loading, no favourites, no settings, no information etc.
You will also need to use the windows app to set up the covers, there are thousands of commercial covers in here, plus a handful of homebrew ones.
Download Windows App (42MB)
Download and Give Feedback Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 22:58 Posted By: wraggster
News via http://www.nintendomax.com/viewtopic...318be7d6000f60
http://www.dev-fr.org/index.php?topic=4518.new#new
Copper makes the 2.1 version of "Snowbros DS" which emulates Roma 6 sets to the game Snow Bros. - Nick & Tom and also allows through NIFI play 2 players on 2 DS.
Reminder: Put your roms in zip format. Preferably in a directory named / MAMERoms at the root of your linker.
V2.1: 17/01/2010
* Version compiled with devkit pro libnds R27 and 1.4 + (FIFO optimized)
* Improved routing speed emulation
* Fixed save the state of the emulator (the old files are not compatible)
-------------------------------------------------- ------------------------------
List of supported sets:
-------------------------------------------------- ------------------------------
Snow Bros. - Nick & Tom (set 1)
Snow Bros. - Nick & Tom (set 2)
Snow Bros. - Nick & Tom (set 3)
Snow Bros. - Nick & Tom (set 4)
Snow Bros. - Nick & Tom (Dooyong license)
Snow Bros. - Nick & Tom (Japan)
Download and Give Feedback Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 22:51 Posted By: wraggster
Pate has posted some WIP News concerning his Dos Emulator for DS:
Today I got fed up with the Packed File Corrupt problem, and decided to see if I could handle the required "LOADFIX" functionality automatically within DSx86. I looked at a couple of games that cause this behaviour, and used a hex editor and debugger to see if I can find a pattern in their header that would detect the use of the buggy /EXEPACK linker switch that cause this problem. I found the following things in common with the EXE headers of the problem games:
RelocationItems is zero.
HeaderSize is 0x20 (512 bytes) even though the actual header is only 28 bytes.
Initial SP is 0x0080.
Initial IP is either 0x0010 or 0x0012.
Practically all EXE packers have zero RelocationItems, so that alone is not a sufficient indicator of a buggy EXEPACK code, but I didn't find all of the above header settings in any packed EXE file that don't have the "Packed File Corrupt" problem.
I made a small code change into DSx86 where it detects the above EXE header signature, and allocates 64KB of RAM before allocating the memory for the program and running it. I also added new code to the FreeProcessMemory() code so that when the process exits it checks whether an extra block of memory was allocated and frees that as well when freeing the actual memory of the process. The end result was that the programs that have that EXE header signature only get 580KB of RAM, and don't give the "Packed File Corrupt" message any more.
I might need to adjust this detection algorithm in the future, to check also the start of the actual code (which seems to always be nearly identical to this):
1C59:0012 8CC0 MOV AX,ES
1C59:0014 051000 ADD AX,0010
1C59:0017 0E PUSH CS
1C59:0018 1F POP DS
1C59:0019 A30400 MOV [0004],AX
1C59:001C 03060C00 ADD AX,[000C]
1C59:0020 8EC0 MOV ES,AX
1C59:0022 8B0E0600 MOV CX,[0006]
1C59:0026 8BF9 MOV DI,CX
1C59:0028 4F DEC DI
1C59:0029 8BF7 MOV SI,DI
1C59:002B FD STD
1C59:002C F3 REPZ
1C59:002D A4 MOVSB
1C59:002E 8B160E00 MOV DX,[000E]
1C59:0032 50 PUSH AX
1C59:0033 B83800 MOV AX,0038
1C59:0036 50 PUSH AX
1C59:0037 CB RETF
Detecting this code before actually loading the EXE into memory is slightly more difficult than just looking at the EXE header, so I hope the current change will fix at least most of the problems.
Galactic Battle
I had a plan to work this weekend on adding support for EGA, specifically mode 0x0D (320x200 with 16 colors). Last week I searched for a small game that would use that mode, and I downloaded a couple of games that weren't suitable (had a lot of extra files) until I found Galactic Battle which seemed to be just what I was looking for. It is a small Space Invaders clone that uses mode 0x0D and PC Speaker sounds.
It did have the "Packed File Corrupt" problem, and I didn't have the above fix in the code at that time, but that was easy to work around by starting 4DOS without swapping. Anyways, this Friday I then began working on emulating the 16-color mode. During the last week I had been thinking about ways to emulate this mode, and I did come up with a solution that I thought might work, so I began coding it. I managed to get the code working pretty well already on Saturday, and I took the screen copy above from the Galactic Battle running in DSx86. It was quite playable, perhaps just a little bit slow.
EGA emulation
The 16-color modes are a lot more complex than any graphics mode I have so far supported. MCGA 320x200 with 256 colors is the easiest, as each pixel is simply a byte that is an index to a palette, exactly like the bitmapped background modes in Nintendo DS. The CGA mode was a little bit more complex, as it has 2 bits per pixel, but that was easily handled via a look-up table (LUT).
However, EGA and VGA 16-color modes are a different beast entirely. They use four separate memory planes, a byte in each plane has 8 neighbouring pixels, and each plane contains one bit of the 4-bit color. All these four planes share the same memory address (in segment 0xA000), and the plane that is being read/written is determined by writing a certain mask to a certain EGA/VGA I/O register. Thus, writing for example 4 neighbouring pixels of different colors might need 4 writes to the same memory position, and most likely also four reads and some bit masking so that the other 4 pixels in the same bytes don't get overwritten. A pretty complex scenario to emulate (and especially to do it fast!).
The real EGA has 4 times 64KB planes totalling 256KB of RAM, and I didn't want to spend more than this 256KB of RAM in my emulator. I also didn't want to assign less than this amount of RAM to the EGA/VGA memory, as many games use page flipping and assume that this much memory is available. So, I needed some way to make the memory behave like four different planes of 64KB each, but I also needed a way to blit this fast into the Nintendo DS VRAM, which is organized as 8 bits per pixel (that is, each byte is a separate pixel).
The straightforward method to emulate this might have been to allocate 64KB of RAM for each of the four planes, and use these planes like the original EGA/VGA uses them, each byte contains 8 pixels and the combination of the planes having a pixel set would determine the output color. However, I thought that building each output pixel (while blitting the screen) from a single bit in four different memory locations would pretty much kill the performance. There would be no practical way to use the ldmia opcode to load several words from the source buffer, and splicing each input bit to a separate output byte sounded like a really slow operation as well.
The idea I had during the week was that perhaps I could swap the way the memory is organized in the emulated EGA/VGA memory. I wanted to have all data that is needed to build an output pixel as close together in the source RAM as possible, and I also wanted the source data (when blitting) to have at least some resemblance to the output byte-per-pixel organization. So, I thought that keeping the 4 bits that are used to determine the color together might make everything faster. In the real EGA/VGA it takes 32 bits to contain 8 pixels, and I could also fit 8 pixels into 32 bits (a word) even if I used 4 bits for each pixel. So, in my current implementation each byte is actually a word, and each bit is actually a 4-bit color value.
I use a LUT to convert from an input byte (for example during a write to EGA/VGA RAM using a stosb opcode) to a word, which is then masked with a write mask based on a value written to the EGA/VGA register that controls which planes are accessed when a byte is written to EGA/VGA VRAM.
To make this emulated RAM fast to blit to the screen, I also interleaved the pixel positions so that the 4-bit pixels in a word are organized as 73625140. That allowed me to easily reorganize the word to two separate words containing 4-bit pixels 03020100 and 70605040 (or 8-bit pixels numbered 3210 and 7654) which can then be written to Nintendo DS VRAM. I copied the EGA palette to all the 16 16-color blocks so that I don't even need to clear the extra bits from the bytes, I can write the data as-is like ?3?2?1?0 and ?7?6?5?4 (after a shift right by 4 bits).
This a snippet of the blitting code. I read 4 words and write them to 8 words, as each 4-bits-per-pixel input value is converted to an 8-bits-per-pixel output value:
ldmia r1!, {r3,r5,r7,r9} @ Load 4 words = 4*8 = 32 pixels
mov r10, r9, lsr #4
mov r8, r7, lsr #4
mov r6, r5, lsr #4
mov r4, r3, lsr #4
stmia r0!, {r3-r10}
Here is an illustration of the changed memory layout. Hopefully you can make sense of it, it is pretty difficult to explain clearly.
Memory organization
-------------------
EGA/VGA:
- Pixels in bits of a byte: 01234567 (where leftmost is the highest bit)
- Colors:
- Plane 0: BBBBBBBB (each bit set means the corresponding pixel has a blue component)
- Plane 1: GGGGGGGG (each bit set means the corresponding pixel has a green component)
- Plane 2: RRRRRRRR (each bit set means the corresponding pixel has a red component)
- Plane 3: IIIIIIII (each bit set means the corresponding pixel has an intensity component)
DSx86:
- Pixels in bits of a word: 77773333666622225555111144440000
- Colors in bits of a word: IRGBIRGBIRGBIRGBIRGBIRGBIRGBIRGB
Example 1, setting two middle pixels to bright white:
-----------------------------------------------------
Input byte: 0x18 = 0b00011000 (highest bit is the leftmost pixel on screen)
Write Mask: 0x0F = 0b1111 (all color components active)
Original EGA memory result:
Plane 0 (blue): 0b00011000
Plane 1 (green): 0b00011000
Plane 2 (red): 0b00011000
Plane 3 (intensity): 0b00011000
DSx86 memory result:
Emulated RAM: 0b00001111000000000000000011110000
Example 2, setting the two leftmost pixels to red:
--------------------------------------------------
Input byte: 0xC0 = 0b11000000 (highest bit is the leftmost pixel on screen)
Write Mask: 0x04 = 0b0100 (red color component active)
Original EGA memory result:
Plane 0 (blue): 0b00000000
Plane 1 (green): 0b00000000
Plane 2 (red): 0b11000000
Plane 3 (intensity): 0b00000000
DSx86 memory result:
Emulated RAM: 0b00000000000000000000010000000100
Opcode work
During the week I added many of the missing modrm bytes. I started from the beginning (opcode 0x00 = ADD r/m8,r8) and systematically added every single modrm variation. I am currently at opcode 0x38, all the smaller-numbered opcodes have all their modrm variations handled. This was mostly copy/paste work, as for example all and, or and xor opcodes behave exactly the same, only the actual operation in my opcode handlers differ.
This copy/pasting meant that the size of my CPU emulation source code increased quite a bit. Currently it has 46.507 rows and is about 1.38 megabytes in size. In version 0.02 it had 35.287 rows and was 1.08 MB, so it has grown by over 10.000 rows since then, and I still have a lot of modrm variations to add. I'm starting to worry about possible macro or label limits in the GNU Assembler, but I can of course split the file to several smaller files if needed. I'd like to keep the file as a single entity, though, as it currently has only a few well-defined dependencies to other files.
http://dsx86.patrickaalto.com/DSblog.html
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 22:47 Posted By: wraggster
News via http://www.wii-addict.fr/forum/AnyTi...v4-t18095.html
MrClick we release a new version of DB AnyTitle Deleter. Pourappel is a homebrew based on both the version Sutton and that of Red Squirel.
AnyTitle Deleter DB 1.0 ID replaces the title by their name thanks to the corresponding file database.txt (from the mod Red Squirel) but also thanks to banner.bin file contained in the NAND of the wii which also contains the name for title
QUOTE
1.0 v4
* Checks the first. App file instead of just 00000000.app to allow more names to be found.
* 0x10000 type for TID, it checks the data and content folders. if there is 0 items in the data and only a title.tmd in the content, it puts a TMD! by the name (if the IOS will let it).
* There are 2 flavors, one that just uses the highest IOS counting down from 36 and one that uses 249.
Download and Give Feedback Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 22:42 Posted By: wraggster
Wii Shooting Gallery updated to 2.0 by Arikado
Wii Shooting Gallery is a compilation of eight (8) shooting games. It is most fun when played with the Wii Zapper.
Still Targets
Horizontal Moving Targets
Vertical Moving Targets
Crazy Targets
Crisscross Targets
Teleporting Targets
Hogans New Alley
Wii Shoot In Space
Release Notes
2.0- Game rebuilt from scratch - Final release
http://wiibrew.org/wiki/Wii_Shooting_Gallery
Download and Give Feedback Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 22:27 Posted By: wraggster
TowerDefense 0.92 released by wplaat :
TowerDefense is an classic 2D action game. Protect your base with all kind of defense systems and kill all the waves of enemies. If ten enemies reach the base the game is over. Good luck!
Created by wplaat (www.plaatsoft.nl).
http://wiibrew.org/wiki/TowerDefense
16-01-2010 Version 0.92
GUI:
- Added 6 animated weapons. Thanks Applicant!
- Improve enemy animated sprite frame sequence.
- Improve help and level select screens.
- Lots of other small changes.
Core:
- Weapons now fire on strongest enemy in range.
- Increase bonus money when wave is cleared.
- Increase initial weapon power.
- Decrease weapon prices.
- Added weapon sell functionality with minus button.
- User initials are now default based on Wii nickname.
- Bugfix: Monsters can not be shooted before launch.
- Build game with devkitPPC r19 compiler.
Download and Give Feedback Via Comments
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 22:18 Posted By: wraggster
News via http://www.dolphin-emu.com/news.php
Thanks to skid_au's latest work, F-Zero GX is now playable on the latest revisions of Dolphin. Everything except Story Mode seems to work nearly perfectly.
Check out nosound98's 720P video on YouTube.
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
|
January 17th, 2010, 22:12 Posted By: wraggster
News via http://www.aep-emu.de/PNphpBB2-file-...c-t-14418.html
A new version of Snes9x has been released today. There are binaries available for Windows, Mac OS X and Linux.
The official sites are not updated yet, you can download the emulator from our database.
Read the announcement here: Snes9x v1.52 Announcement
Quote:
The (hopefully) last fix for this release corrects the issue reported by creaothceann and a few issues I´ve encountered myself:
http://download.sessionclan.de/overf...win32.fix4.zip
I´ve also made a special win9x build for sjyune:
http://download.sessionclan.de/overf...-win32.w9x.zip
And here is a list of the fixes:
Code:
fix4:
-selecting "display messages before applying filters" prior to loading any rom could cause a crash
-hq4x and simple4x did not work correctly in DirectDraw and 32bit modes
-selecting filters with different scales for normal/hi-res modes caused incorrect message scaling
-the rom information window was always disabled
fix3:
-avi recording crashed on < vista
-delete key mapping did not work after emulator restart
fix2:
-parts of the window stopped updating when previously covered by other windows (only in d3d mode)
fix1:
-display corruption in Super Metroid/Donkey Kong Country/... due to compiler optimization
Sorry about all the small bugs - it seems I focused too much on the sound changes and thus missed the rest...
http://www.snes9x.com/phpbb2/viewtopic.php?t=4542
To read more of the post and Download, click here!
Join In and Discuss Here
Submit News and Releases Here and Contact Us for Reviews and Advertising Here |
|
|
|
|
« prev
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
next » |
|
|
