Using inferno on small screen

13 views
Skip to first unread message

janis

unread,
Jul 15, 2008, 10:12:34 AM7/15/08
to inferno-ds
Dear developers,

I have tried the inferno for Nintendo DS and was really surprised how
it performed.
So I would like (if anybody cares) to add my 2 cents regarding the UI
-

Is it possible to implement it in similar fashion to Mini vMac DS?

http://lazyone.drunkencoders.com/wordpress/

It's slow emulator of old Mac on Ds but really easy to use.

hiro

unread,
Jul 15, 2008, 10:40:37 AM7/15/08
to infer...@googlegroups.com
The UI is not being worked on very much. But I guess there's a lot
which could be improved once the more important stuff is ready.
You should look at the tk modules and try some of your concepts out
perhaps. It's all easily hackable.
Show us what you mean;)

Caerwyn Jones

unread,
Jul 17, 2008, 5:30:47 PM7/17/08
to inferno-ds


On Jul 15, 10:12 am, janis <k0i...@gmail.com> wrote:

> Is it possible to implement it in similar fashion to Mini vMac DS?
>
> http://lazyone.drunkencoders.com/wordpress/
>
> It's slow emulator of old Mac on Ds but really easy to use
.
what aspect of that display is easy to use? the use of the two
screens,
and the size of the keyboard?

Caerwyn Jones

unread,
Jul 17, 2008, 5:39:02 PM7/17/08
to inferno-ds
I don't think tk is the way to go. I'd recommend learning to use the
draw
primitives first. You'll probably end up happier with the results.

I was impressed by how well tk worked on the DS, that it fit into
memory, and was usable.
But I don't think wm and tk is the right UI for this device. Better to
focus on the app
you want, then build a custom UI. I'm trying to use mux and prefab
as the host for apps that just draw directly to the screen, that is,
not using the prefab
toolkit either. (some work in progress screenshots here
http://flickr.com/photos/caerwyn)

hiro

unread,
Jul 17, 2008, 6:06:57 PM7/17/08
to infer...@googlegroups.com

I guess, you're right, but I'm just curious: Couldn't one also mod the
tk stuff to better use the available screen size?

Charles Forsyth

unread,
Jul 18, 2008, 10:05:39 AM7/18/08
to infer...@googlegroups.com
>> But I don't think wm and tk is the right UI for this device. Better to
>> focus on the app
>> you want, then build a custom UI. I'm trying to use mux and prefab
>> as the host for apps that just draw directly to the screen, that is,
>> not using the prefab
>> toolkit either. (some work in progress screenshots here
>> http://flickr.com/photos/caerwyn)
>
> I guess, you're right, but I'm just curious: Couldn't one also mod the
> tk stuff to better use the available screen size?

a reasonable approach might be to state first what your
programs (applications) will need most.
there seem to be a fair number of tk-like graphical gadgets
on my ipod touch, for instance; but there are games there too
which are probably more interested in drawing.
what are the aims for the DS port?

there has been at least one alternative style of Tk implemented
that looked significantly different.
that's why there is <mkfile-$TKSTYLE in libtk/mkfile,
and TKSTYLE set in mkconfig.
TKSTYLE=std is just one possibility.
(not all things in mkfile-std were actually different for the alternative:
only 8 files.)

Salva Peiró

unread,
Jul 22, 2008, 5:37:37 AM7/22/08
to infer...@googlegroups.com
On Fri, Jul 18, 2008 at 4:05 PM, Charles Forsyth <for...@terzarima.net> wrote:
>
> a reasonable approach might be to state first what your
> programs (applications) will need most.
> there seem to be a fair number of tk-like graphical gadgets
> on my ipod touch, for instance; but there are games there too
> which are probably more interested in drawing.
> what are the aims for the DS port?
>

is not that I've been eluding that question,
but I've focused in testing and get more hardware working.

The idea that I've been pursuing is to add hardware/device support
as i felt it was needed and then try/test/debug it to see how it performs,
and based on that decide what to do next.

As an example one of the aims is being able to access the contents of
a inferno/ distribution
either from a sd card using dossrv/kfs or a remote fs served from a
emu instance over wifi.
If that's possible and works well, it would remove the need of having
all the files in devroot,
which would free ram (this could also be improved by using the
available memory expansions).

With storage+networking developing for Inferno on the DS
would become quite sane and seamlessly as it would only require:

1) getting/building a stable isds.nds (from downloads)
2) unpack the inferno/ distribution on a sd card.
3) develop your apps and test them on Inferno's emu
4) place them on the sd card and use them.

Another question that should be answered before thinking about apps
is to decide how to use the upper screen (non tactile)
in a way that remains compatible with the existing Inferno programs.

Anyway it's hard to adventure a deadline for the accomplishment of this goals,

--
salva

David Leimbach

unread,
Jul 22, 2008, 11:12:17 AM7/22/08
to infer...@googlegroups.com
One strategy I've used on the DS with other homebrew apps (not my own but "used" in terms of consumed) is to have a "swap screens" button somewhere, and use that to switch which screen is displayed top or bottom, and then you can have 100% of the screen real estate available with 50% control.  It was effective... used with a sound tracker program, the name of which escapes me now.

Dave

Salva Peiró

unread,
Aug 3, 2008, 12:29:19 PM8/3/08
to infer...@googlegroups.com

after spending a bit of time trying to get storage working on r4ds
it turned out that the partition on the sd card was not properly formated,
formatting it as a FAT16 (using `mkdosfs -F 16 /dev/sda1') fixed the problem.

So it's possible to use a 'local' partition on the sd card
as the root filesystem, with the contents of the Inferno distribution.
This removes the need of having all the files in devroot (RAM), see CONF=dds.

note that for storage the code doesn't use DLDI,
instead it uses the compiled-in support for the specific cards,
DLDI is only used in order to detect the card type which is usually
performed by the dldi-auto-patching loaders.
If there's no dldi-auto-patching use dlditool to patch the .nds file.

--
salva

Reply all
Reply to author
Forward
0 new messages