A GameBoy emulator (GPLv2: gnuboy, ported, tested on K3)

[geekmaster]

Originally Posted by NiLuJe

It still needs a sizeable amount of RAM to build (with GCC / -O2), according to the Gentoo ebuilds (512MB RAM/6GB Disk).

Or a big swap file, if you do not mind waiting all week for it to compile.

Of course, the 512MB RAM thing could get complicated with only 256MB memory address space in the ARM processor, which limits the size of a swap file used in a single process.

[NiLuJe]

Ooh, swap, I'm happy to say I completely forgot about it, even with a 3 * 4GB striped swap on this box ^^ (Yes, I'm really bad at maths when setting up a 3-disk raid10 array, I really didn't intend to end up with so much swap xD).

[geekmaster]

PREVIOUS CONTENTS DELETED (TOO OFF TOPIC).
SUMMARY: Although I have "big" boxes, I still do compiles in my K3 sometimes...

[twobob]

Originally Posted by NiLuJe

Ooh, swap, I'm happy to say I completely forgot about it, even with a 3 * 4GB striped swap on this box ^^ (Yes, I'm really bad at maths when setting up a 3-disk raid10 array, I really didn't intend to end up with so much swap xD).

hahaha possibly the largest swap I ever heard of. I have 680.83 Mb (oops bit of an after thought then) and it's always 99% free.

I sometimes wonder if Slack uses swap at all. perhaps the 8Gb of Ram is overkill?

You could run several OS's in your swap Brilliant

[knc1]

Originally Posted by twobob

hahaha possibly the largest swap I ever heard of. I have 680.83 Mb (oops bit of an after thought then) and it's always 99% free.

I sometimes wonder if Slack uses swap at all. perhaps the 8Gb of Ram is overkill?

You could run several OS's in your swap Brilliant

That was part of a long standing problem in VFS, only fixed a few weeks ago.
Try a 3.4.4 or new kernel.

- - - -

I, and millions of other people, could run MS-DOS in the processor cache with room for user files. Who needs external (to the processor) storage?

[twobob]

Originally Posted by knc1

That was part of a long standing problem in VFS, only fixed a few weeks ago.
Try a 3.4.4 or new kernel.
- - - -
I, and millions of other people, could run MS-DOS in the processor cache with room for user files. Who needs external (to the processor) storage?

3.4.4 rellied 2012-06-22. and I'm still running a 13.1 Kernel from the 90's
(UPDATE OS!)

Noted thanks Knc1

[knc1]

Originally Posted by twobob

3.4.4 rellied 2012-06-22. and I'm still running a 13.1 Kernel from the 90's
(UPDATE OS!)

Noted thanks Knc1

I should most probably back-off from such a positive statement as the one I made.

Disclaimer: It ***should*** have been fixed by recent changes to the VFS code.
But those folks at kernel.org have been known to replace a single bug with a nest of insect eggs.
In that project's defense: the Linux kernel is a BIG program.

But things have improved since the 90's.
There once was a time when you where lucky to get the thing to compile, let alone run.

root@Microknoppix:~# uptime
 08:32:53 up 101 days, 17:04,  5 users,  load average: 0.00, 0.02, 0.05
root@Microknoppix:~# uname -a
Linux Microknoppix 3.0.4 #12 SMP PREEMPT Thu Sep 8 05:27:05 CEST 2011 i686 GNU/Linux

But that short uptime is not the kernel's fault, I had to manually shut down that machine due to circumstances beyound its control (or mine). It would be fair to add 47 days to that report.

[geekmaster]

Here is a new demo of a Nook Simple Touch running PlayStation 1 games using the "NoRefresh" hack. The eink animation is quite usable. We should be able to do this on our kindles too!

I am looking forward to progress on this stuff once we get a good SDL library going on the kindles. The NST is farther ahead of kindle development because it has android built-in (with a much larger android developer base), while on the kindles we have a LOT less native support, so we have to do a lot more to achieve these results.

[twobob]

root@kindle:games> ./prboom

prboom v2.5.0 (http://prboom.sourceforge.net/)
I_SetAffinityMask: manual affinity mask is 1
Could not initialize SDL [No available video device]


And that is me. just one step away from getting that puppy running.

Looks like either manually compiling in aalib support (for quick and dirty), getting SDL page flip to respect eips calls, or possibly welding in the GM code to sdl.

either way. I too am excited about that day.

[hawhill]

Not too sure, but I think the last time I looked, SDL had support for down to 8bpp framebuffers. So the blitting would need a bit of love and hardware framebuffer layers are out of the game. Probably an 8bpp shadow framebuffer plus 4bpp/K5-8bpp dithering blit would be the way to go...

[twobob]

I see 4 bit support listed for SDL in Buildroot.


What? I'm not timewasting!

err okay I'll stop now...
* nostalgia* : D

EDIT: Okay now I'm done

Games pictured did not suffer from ugly FB smear.

Notes on Roms.

Spoiler:

SIDE NOTE: I am the proud owner of all these original handhelds [duplicates and old rares too] and the vast majority of the games, just before anyone whines about me using roms. It's die-hards like us who keep companies like Nin-T in cash throughout our lives...
thanks

[twobob]

config BR2_PACKAGE_QT_PIXEL_DEPTH_4
bool "4 bpp, grayscale"

config BR2_PACKAGE_QT_PIXEL_DEPTH_8
bool "8 bpp, paletted"
default y

hmmmm that's in qt. bugger. wrong again

[hawhill]

Yep, in fact Qt and Microwindows (though nowadays called Nano-X-Window-System, quite interesting and compact framework!) were the only frameworks I've found that had support for 4bpp.

[knc1]

We can build kernel modules . . .
Why not an 8bpp -> 4bpp shim module to add to the stack of several lab126 shim modules?

Yes, I know, there is a difference between being able to build a module and being able to write a module.
It was just a passing brain fart (no pun intended).

[geekmaster]

Originally Posted by knc1

We can build kernel modules . . .
Why not an 8bpp -> 4bpp shim module to add to the stack of several lab126 shim modules?

Yes, I know, there is a difference between being able to build a module and being able to write a module.
It was just a passing brain fart (no pun intended).

There is code in my newtrix demo that does just that. It converts 8bpp 256-gray framebuffer contents into 4bpp content compatible with all eink kindles. Even the 8bpp framebuffer kindles are really just 4bpp, with the upper 4-bits just a copy of the lower 4-bits (required to avoid "unpredictable" results, according to comments in the eink driver gpl code).

My "8bpp to 4bpp dither" code could be extracted from newtrix and squeezed into a shim kernel module. Of course, it could be refined using techniques from later "no dither table" demos.
newtrix demo: http://www.mobileread.com/forums/sho...d.php?t=176802

Beware that converting to 4bpp will still have severe flicker on eink kindles. It would be better to use pure black and white dithering like my other eink demos use (including some in newtrix).