BOOLs vs bools

[GoogleCodeExporter]

Since we have a desperate need for space, I was thinking...

BOOL is defined as an unsigned int, or 4 bytes. 
bool (lowercase) is defined as only one byte. 

I was thinking it might be a hoot if we converted all of the BOOLs to bools
for space consideration.

If the "Vanilla" Desmume used BOOLs in the correct way, then it shouldn't
be a problem... Right?

I wanted to get some input before I start to dive in, however. 

Original issue reported on code.google.com by dancinninjac on 28 Mar 2010 at 6:26

[GoogleCodeExporter]

I think we should strip out all the extra crap first that we are not using.  
Even if
there are thousands of global BOOL's it's not going to save you much memory.

Also we should figure out how much memory we need to recover.  I basically only 
have
homebrew roms that aren't too big, if someone would like to test and see what 
the
maximum size we can load right now we can work from there. 

Original comment by iamsca...@gmail.com on 28 Mar 2010 at 7:37

[GoogleCodeExporter]

I got up to around 8mb, but I only own a few homebrews and haven't tested many 
of the
commercial roms, so it could be more.

Original comment by kazuhiro...@gmail.com on 28 Mar 2010 at 7:55

[GoogleCodeExporter]

I've gotten N+ (a 8MB commercial game) to run, but no video. Super Mario 64 DS 
(16
MB) doesn't run, so it looks like there's just over 8MB of space left over for 
games
at the moment.

Original comment by baby.lueshi@gmail.com on 28 Mar 2010 at 9:44

[GoogleCodeExporter]

I've just free'd up 16MB from a typo in the MMU.  So update from the SVN, 
hopefully
this will help us.

Original comment by iamsca...@gmail.com on 28 Mar 2010 at 9:54

[GoogleCodeExporter]

Just tried r53, and Mario 64 DS can boot and run with that revision! You even 
get
video with the hack from r50 removed, although it looks like 3d graphics still 
don't
appear.

(Note that I'm doing these quick test on the Dolphin emulator, so it may still 
be
broken on the Wii itself.)

Original comment by baby.lueshi@gmail.com on 28 Mar 2010 at 9:58

[GoogleCodeExporter]

that's funny using and emulator to run an emulator.

Original comment by iamsca...@gmail.com on 28 Mar 2010 at 10:03

[GoogleCodeExporter]

Just like we had to rewrite a great portion of things just to get 2D to appear, 
we
will probably have to do the same for 3D. Thank you for the report, that is very
exciting information :)

Original comment by castleva...@yahoo.com on 28 Mar 2010 at 10:24

[GoogleCodeExporter]

I just tested Super Mario 64 DS on the Wii to confirm since I also own the 
rom...
Still No-Go for the actual Wii.

Original comment by kazuhiro...@gmail.com on 28 Mar 2010 at 11:27

[GoogleCodeExporter]

@kazuhiroichi I just got around to testing it on my Wii, and I got the company 
logos
to appear (after disabling the hack in r50) but a crash when the 3D star should 
have
appeared. (The stack trace led back to line 650 of gfx3d.cpp, is this because an
earlier edit lowered the number of VERT objects?)

Original comment by baby.lueshi@gmail.com on 29 Mar 2010 at 12:02

[GoogleCodeExporter]

"@kazuhiroichi I just got around to testing it on my Wii, and I got the company 
logos
to appear (after disabling the hack in r50) but a crash when the 3D star should 
have
appeared. (The stack trace led back to line 650 of gfx3d.cpp, is this because an
earlier edit lowered the number of VERT objects?)"

Possibly, I'll look at changing it back.  I lowered due to memory.   I confirm 
that
leaving the hack r50 in screws up the screen for Super Mario 64 DS. But not 
having it
for the homebrew titles does not display the screen correctly.

Original comment by iamsca...@gmail.com on 29 Mar 2010 at 12:16

[GoogleCodeExporter]

Scanff, just add an if() to check the ROM ID. If the ROM ID is "Homebrew" do the
hack. If not, dont do it.

Original comment by castleva...@yahoo.com on 29 Mar 2010 at 12:39

[GoogleCodeExporter]

Yes we could do that but I'm not seeing a work-a-round like that in the windows
version and I'd like to know why :)

Anyway I removed the hack as all the commercial games I tried do not need it. I
logged it as Issue 10.  We can readdress it down the road.

Here an update on games I've tried:

Table Hockey - Works and seems pretty playable, still low fps though
Mario Kart DS - Loads but crashed when you start a game

Original comment by iamsca...@gmail.com on 29 Mar 2010 at 5:38

[GoogleCodeExporter]

Ok, here's an idea, let me know what you think I have an idea of how to do this.

We use the SD card for the ROM data. and create virtual memory from it.  I know 
that
using the SD card as memory sounds slow but the DS is using external media as 
ROM
memory as the main memory is only 4MB, therefore could never store a 32MB game 
in
memory.  Let me know what you think.

Original comment by iamsca...@gmail.com on 29 Mar 2010 at 6:18

[GoogleCodeExporter]

According to good-old Wikipedia, DS carts have access speeds as low as 150
nanoseconds. Does anybody have any numbers on the transfer speed for the Wii's 
SD slot?

Original comment by baby.lueshi@gmail.com on 29 Mar 2010 at 7:10

[GoogleCodeExporter]

Whoops, replace speed with time in that previous comment. Although I'm guessing
access speeds for DS carts are pretty fast, something that might make a small 
buffer
necessary.

Original comment by baby.lueshi@gmail.com on 29 Mar 2010 at 7:51

[GoogleCodeExporter]

Isn't an external Usb Drive faster than a Sd card. Maybe you could use this 
instead of 
the Sd.
Just a suggestion.

Original comment by spam.spa...@web.de on 29 Mar 2010 at 9:25

[GoogleCodeExporter]

Scanff, I love your idea of creating virtual memory. It will definitely be 
faster
than reading from ROM. I'm a little worried about RAM considerations, but 
hopefully
it will work out with room to spare.

Regarding Mario Kart DS, it seems that atm all 3d games crash when 3d stuff is 
done.
Someone please correct me if Im wrong.

Original comment by castleva...@yahoo.com on 29 Mar 2010 at 1:06

[GoogleCodeExporter]

The SD card seems way faster than USB on Wii.  It reality I think USB should be
faster but we are limited by the access speeds from the homebrew tools.

I have to look into it some more.  I'll try and get something going today.

Yes all 3D games will probably crash.  I think  baby.lueshi comment about me 
reducing
the VERT/POLLY counts in gfx3d.cpp is probably the issue.  I don't want the 
increase
the size yet because you can't even load a larger rom, it runs out of memory :) 
Thus
the idea of using virtual mem. for the game data.

Original comment by iamsca...@gmail.com on 29 Mar 2010 at 4:38

[GoogleCodeExporter]

P.S.

I also think Virtual Memory for storing the rom data is a good idea as we don't 
have
any room right now to add a GUI :(

Original comment by iamsca...@gmail.com on 29 Mar 2010 at 4:43

[GoogleCodeExporter]

Correct me if I'm wrong but the Wii can handle Usb 2.0 so it's not limited, 
isn't it?

Original comment by spam.spa...@web.de on 29 Mar 2010 at 4:46

[GoogleCodeExporter]

But is IS limited to how well the homebrew SDK handles it. I have to agree with
scanff that as far as I know the homebrew SDK handles SD/SDHC much faster.

Original comment by castleva...@yahoo.com on 29 Mar 2010 at 4:50

[GoogleCodeExporter]

PS: Scanff: I completely agree with your idea. Please go ahead and implement it 
:)

Original comment by castleva...@yahoo.com on 29 Mar 2010 at 4:51

[GoogleCodeExporter]

About bool VS BOOL, I'm not 100% sure but I think that using 32-bits int 
instead of
8-bit is actually faster on machine which use 32-bits registers (from what I 
noticed,
the compiler usually add some unecessary instructions when using unsigned 
char). It
would be interesting to measure this precisely for PPC but I bet the little 
gain in
memory space you can have (probably less than a few hundred bytes) is not worth 
the
speed difference.

Good job for the port anyway, seems to progress quite fast ;-)

Original comment by ekeeke31@gmail.com on 31 Mar 2010 at 9:01

[GoogleCodeExporter]

I agree ekeeke. Perhaps when (or if) we can get the memory issue under control 
then
we can experiment. 

It was my hope that since c++ has kind of had "bool" ingrained in the standards 
that
the PPC wouldn't require additional cycles to convert it to 32-bits. The "new" 
c++
started in 1998, if I'm not mistaken. That's a pretty long time. You have given 
me
something to research, though. And I'm off!

Original comment by dancinninjac on 1 Apr 2010 at 5:32

[GoogleCodeExporter]

Okay everybody, I'm going to close this issue down. I have found the answer: 

Use "bool" and not "BOOL"

We save 3 bytes, and is more straightforward with our intentions (true or false,
since BOOL can be -1, 0, or 1). This can hinder compiler optimization at times. 

For those of you who fear that using a byte-sized variable would degrade 
performance,
FAR NOT!

After much searching of the official 750FX documentation, I have discovered the
answer: Byte-sized (8), half-sized (16), and word-sized (32) have the same 
latencies
(time) for both load and store operations. 

In short: bools are just as fast and smaller. Win-win! (At least on the Wii, 
this SO
not true with x86 processors!)

Original comment by dancinninjac on 6 Apr 2010 at 12:13

• Changed state: Fixed

[GoogleCodeExporter]

Sorry but I'm not convinced.
I still have additional PPC instructions when using 8-bit variable: I don't know
about memory access latency (and in fact I was not talking about that) but 
loading
8-bits value in PPC 32-bits registers usually add some "cast" instruction (such 
as
low bits masking), at least in my code it does when I look at the assembly 
produced
by gcc.

Original comment by ekeeke31@gmail.com on 6 Apr 2010 at 8:49

[GoogleCodeExporter]

@ekeeke31
PPC has LB, SB for these purposes.
Other thing is then you do: 
u8 _u8 = (u8) _u32. // rlwinm r, r, 0, 16, 32
or
s8 _s8 = (s8) _s32. // extsb r, r

Load/store unsigned byte, halfword and word takes only one instruction. Signed 
byte and 
halfword takes 2 instructions on load: load and sign-extend.

Original comment by AndreyLegchilin on 6 Apr 2010 at 9:03

[GoogleCodeExporter]

Yeah, this was this kind of instruction I was referring to. Guess I wrong then 
and
this does not apply in that case, thanks for the head up ;-)

Original comment by ekeeke31@gmail.com on 6 Apr 2010 at 9:06