Minidash is a useful tool allowing fast development on hard disk-less machines with short cycles Reboot=>Receive(FTP/HTTP)=>Run=>Edit.

Book mark changelog and check it often:
http://minilgos.perso.sfr.fr/minidash/changelog.txt

If change log gets too big, changes will go there:
http://minilgos.perso.sfr.fr/minidash/archivelog.txt

Files:
http://minilgos.perso.sfr.fr/minidash/miniconf.zip
http://minilgos.perso.sfr.fr/minidash/minidash.zip (v0.0)
http://minilgos.perso.sfr.fr/minidash/casyntax.txt

Hi,
tried this on my dell Optiplex.
I only got a black screen with the letters "GCNS"
Any idea what went wrong ?

Graphic Card Not Supported

Happens if :
Vesa 2.0 or above BIOS not found
800x600 modes 113h 114h or 115h not found (16 bits per pixel up to 24 bits per pixel)
32 bits linear addressing not possible (this last option is independant from Vesa version)

If it's an old or limited graphic card (chipset on motherboard probably) that may explain it.

There is also the case I've not really thought about of a laptop that allows only 1024x768.
In that last case, I can try a change. But why a laptop could not display a small 800x600 area?

If you can run msdos from a bootable floppy disk or cdrom we can also try to see how your BIOS responds if we interrogate Vesa to see available modes, etc... There should be some program on internet to do that.

I've eventually other solutions for VGA 16 color... but that really stinks nowadays... I mean not being able to display a nice jpeg picture with all colors.
So I kinda dropped this 16 color alternative (which works on all pc for sure).

http://minilgos.perso.sfr.fr/pc0/vesainfo.zip

It's a small 16 bits real mode msdos program that lists :

- physical available memory addresses ranges
- vesa version in bios
- graphic card name
- graphic modes (only 113h 114h 115h, usually only 2 of these modes exist)
- physical address of frame buffer (for 32 bits linear addressing)

Launch it under msdos (can't work under windows). It should give us the reason why you got the GCNS message.

(I'm not willing to abandon 32 bits linear addressing... it's so sweet!)

I realize I may have forgotten 12Eh (800x600 32 bits per pixel)
Maybe you have this mode and not the others...
I can add it if needed. We really need to know the list of Vesa modes you have.

I couldn't try the small program as I couldn't start in msdos.
but
Meanwhile I tested it on another computer and I get another error message :
"Packet driver init failed"
"Press B or X"
What went wrong with this computer ?

Currently pc0_demo.zip supports these network adapters (do you have one of these on the pc?) :

PCI (1317,0985) : SMC 1244TX (www.smc.com)
PCI (1106,3106) : D-link DFE530TX (www.dlink.com.tw)
PCI (1186,1300) : D-link DFE528TX (www.dlink.com.tw)
PCI (10EC,8029) : Realtek 8029 (www.realtek.com.tw)
PCI (10EC,8139) : Realtek 8139 (www.realtek.com.tw)
PCI (10B7,9200) : 3Com 3c905cx-txm (www.3com.com)

Personally, I only use Realtek 8139, so I recommend it. I've added a few others in order to not piss off other main manufacturers... But problem with other manufacturers is that they change their chipsets all the time... Realtek maintains the same chipset for a long time now, which is sweet for driver stability.
Cost is under 9 US$ for sure.

We have to be realistic. Having an instant boot able to pull a boot code over ethernet needs an immediate running packet driver. Trying to support all existing network drivers is nuts when choosing one is so cheap.
Normally Realtek 8139 has won 70% of the market I've heard. So, many will be covered already and others will have to throw out a very very few coins to comply. Also check the device_id and vendor_id of all your network adapters since there are many brand names that in fact, use Realtek 8139 chipsets. All brand name-less adapters are Realtek 8139, I guess. However packet drivers can be replaced in .dsk file if they are small .com's and accepting either "0x61" or "/I 0x61" as parameter (interrupt number).

Of course you can say that excludes laptops since they don't have PCI slots. But all this project is about a cheap but upgradable PC under a TV in a living room... Laptop is quite expensive for that kind of usage and not really friendly when it comes to upgrade the graphic horse power... However pcmcia network adapter SMC 8036TX should work with pc0_demo.zip (just for testing).

I have a sis 900 fast ethernet pci adaptor, so i guess it won't work.

If you find the msdos .com packet driver, we can try. Just point the link to it and I can replace one of the other packet drivers with it, in the .bin image. But if it doesn't work at first try, let's give up. I have to focus on nv40 driver now.

Miniconf utility created (link added in first post of this thread).
It will be used later to customize minidash cdrom image with your favorite ip configuration.
Possible choices:
- static IP (and mask,gateway,dns) or dynamic IP (thru DHCP)
- ftp or http for the bootloader path
- with or without username & password for the bootloader path (basic authentication)
See the file readme.txt for more details.

You can create minidash cdroms customized for each member of your family.

Minidash v0.0 released!
Can be configured with Miniconf.
For now, just downloads boot code and displays it on screen.
(v0.1 will execute it with interpreter engine, later)

Here is a beta of Minidash v0.1 for PC0 platform, so you can play with canonic assembler samples a bit...

http://minilgos.perso.sfr.fr/pc0/pc0_beta.zip

The return value of your boot code affects the global behaviour of Minidash:

0 : Download boot code again and execute it immediately
(This value makes minidash execute your boot code in a loop. The advantage of this is that you don't even need to reboot the PC0 machine to try a new version of code. Just update boot file and see result. Reboot only if bad crash occurs. Note that all cpu and fpu exceptions should be trapped nicely, so crashes will be avoided and explanation messages will appear. However, current version doesn't manage well to resume execution after a cpu or fpu trapped exception, so you will have to reboot. If a debug mode is active in the text area where problem occurs, you will get the line number)

1 : Minidash will quit
(On consoles, that will make you return to system/dashboard menu. Not implemented yet)

2 : Power off machine
(Not implemented yet)

Error value (0xee??????) : Displays explanations messages, then displays "Press enter when you are finished editing boot file", then waits for 'enter' key.
(Happens when an exception is trapped, a user or engine error is triggered or a syntax error is detected)

Native code address (any value >2 and different from 0xee??????) : Move code and jump to it
(Not implemented yet. If your boot file is just a native code boot loader, after allocating a memory buffer and filling it with your native code program, you will compel Minidash to jump to it. On pc0, since we are still in real mode, code will be copied to 0070:0000 and CPU will jump to that address. That means your code must be address independant. Developpers willing to port XBMC may start trying to have reactos nt kernel clone boot on PC0 that way and init a ram file system...)

After months of study and modding... it seems that homebrew on vulnerable 360 (I spent a lots of my free time water cooling and installing infectus) and regular PS3 (nice work done by other coders at ps3dev) are progressing well... I hope to release minidash v0.0 for these platforms before end of year...

Once it's done, I will push forward minidash version for pc0,
but also for xb1, ps2, 360 and ps3 at the same time.

v0.0 does nothing , but you know, it's the first step that costs the most...

It's possible I put wii, nds and psp in the same "holiday water-downed bag".
i.e I will consider them as lesser machines, consuming less power, that can receive water-downed version of homebrew for vacation time. You transfert your saved game, you go on holiday and when you return, you transfert back.

It's possible wii homebrew (not gc homebrew) will just be a flash file you access through Opera... Because it seems that support for wiimote through opera exists. Actually I find GC homebrew a bit lame because it can't support wiimote at all... Also wii could just be considered portable since it consumes only 17 watts. It's not so hard to mount it into something able to draw power from a car or solar panels, or something like that. Therefore, we just need a way to see how to re-use Opera for (legal) homebrew purpose... I will think more about it...

Recent discovery made by Ironpeter and Glaurung on PS3, about direct RSX access for homebrew, is also interesting for PC0 platform, assuming we target GeForce 7300 or GeForce7800 graphic cards.
RSX chipset is similar to those and progress made in direct programming of this chipset on PS3 may help me to make faster progress in the graphic card chipsets understanding.

About the Wii, the more I think about it, the more I think about the Wii as a graphic and sound card for PC0... Sounds silly, but if you want remote support right from the Wii, internet channel is the (cheap) way to go. Recent release of hullbreachonline and wiideo center allow to think that a PC0 may act as a web server for the Wii and supply graphic and sound through streaming. It can come from a movie or a virtual screen updated by homebrew code (runnong on PC0 side). It would turn to zero the troubles to find a PC compatible graphic and sound card...

Would it only work on a Wii or will it use a standard that other devices that display streaming media are able to use?

On another matter, would it be possible to use the Boot From LAN function that most newer bioses have to load the pc0 software instead of booting it from a CD rom? It seems like it would be an easy way to update the program without having to burn a cd everytime there's a change. Plus it's less hardware required to run on the PC0 machine. (Not that CD drives are hard to come by)

I haven't studied at all LAN boot or bios flash methods. They probably work of course.

About CD burning, CD-RW works... so...
That's really the easier solution, compatible with all drives accepting El Torito standard. Now once it's done and with more time, everything is possible. Also physical CD acts like a physical key to boot machine, when you divide login password in two parts, one on CD and one in your mind. If you keep CD with you and machine is stolen, your online data is even safer (Pwd stays with you. The half one on CD and the half on in your head).

About using another machine (wii) as graphic display and sound device :
Surely standard streaming protocol, since we have to do it in a clean way so the Opera browser accepts it. Just like Wiideo center does... I strongly suggest everyone to try Wiideo center at least once. Installation is incredibly simple : you unzip files somewhere, you open port 8080 on firewall, and you click exe. Then you can browse your PC hard disk through your Wii to play media files... Amazing...

Anyway I haven't finished studying GPU's on all platforms I'm targetting (360 recently finished thanks to tmbinc, and PS3 starting thanks to IronPeter and Glaurung). Once this is done, I will be able to figure out some unified library and then the real fun will start... (i.e you take a crappy old PC, and you can play on network against friends, playing on their next-gen console with same homebrew title... Maybe not with same graphic details level, but definitely same gameplay. I'm interested in doing Netrek 3D)

The fact that more and more opengl es 2.0 compliant devices are spawning is very interesting...
(1.1 had fixed-function pipeline. Note that guys at www.opengles-book.com have done a very smart thing : they created, for their iPhone samples, a 2.0 shader that implements the entire 1.1 fixed-function pipeline! So, someone like me, more interested in starting studying opengl es through v2.0 will just have to consider v1.1 as a subset of v2.0 and keep that shader in mind. Very smart!)

To make it clear Minidash is an http/ftp client that allows to access and interpret files that are both at the same time source and binary code written in CAS language (Canonic assembler). But that's only half of it. Other half is some unified API. About graphics, adopting open gl es 2.0 API functions will have many advantages. They seem to be simple enough for fast coding, but graphic result is great even on small devices! Shaders is the little something that makes graphics really shine and make you think it's running really on a 'next gen' hardware (even if lacking some horsepower compared to 360 or ps3). It allows transparencies, reflections, polish-effect, metallic-effect, etc... Quite something! (compared to older cards or even the current wii! -current wii has only a fixed-function pipeline-)

So I will try this roadmap (for addition of open gl es 2.0 compatible api functions) :

1) minidash for iphone 3Gs/ipod 3G/ipad (because of my job, i'm over-equipped with apple stuff)
2) minidash for zune hd (may be urgent because next firmware may crush the potential of current openzdk)
3) minidash for windows -and maybe snow leopard too- (using directly open gl es 2.0 emulators libraries)
4) minidash for pc0+7300GT (eh... because that was the original goal of this whole forum!)
5) the rest of the platforms written in the minidash changelog

I've tried 8500GT and 9600GT models and I got disappointed. The 9600GT requires too much extra power plugs (I gave up since I didn't want to redo again my whole pc), and the 8500's fan did horrible noises at boot time whereas card was brand new! -I guess my MB doesn't supply enough current at boot time for its motor- (I kept it a while in order to finish Mass Effect 2 on pc, but I put back my beloved fanless 7300GT asap). I'm really too much fond of silence and my 2Ghz cpu is enough for me. Just investing in thermal paste and a big silent cpu fan was all I needed. My Gigabyte 7300GT is good enough for open gl es 2.0 -I guess- and having a big metallic mass instead of a fan makes it perfectly silent. I won't start a race tu run after every graphic card model that will go out, that would be insane.

So there is a decision to make and I think the first main graphic level of unified api will be a subset of open gl es 2.0. There will be probably some lower level (for pc0 without good graphic card) and higher level (for ps3's and 360's), but I will start with this intermediate level that will reduce enormously coding time on platforms already compatible at hardware level with it. For overpowerful graphics in high res it's wiser now to rely on 360's and ps3's... They have become so cheap... Also I would like to invite (through specific tutorials and automatic graphics generators api) homebrewers to focus on story, text, etc... instead of technical performance, in order to have more adventure games that take long time to finish than mere technical demos...

For inputs I will imagine a way to draw an half circle with 1 finger at bottom of vertical touch screen or rotate 1 joypad's thumb in the upper half or move mouse along that half circle on screen, for camera rotations management, and just a straight vertical touch from bottom to top for triggering an action, in order to use a common way to control homebrew on all platforms. I find more enjoyable to use a device the vertical way with just one hand to hold it and one thumb to interact with it.

Finally got some holidays...

My first attempts to play with OpenGL ES 1.1 and 2.0 on iPhone/iPod and 2.0 on Zune HD are very encouraging. The enlighted Dragon demo from zuneboards is perfect for my study purpose...
On iPhone side, I could find on internet a way to remove the xib from project created from OpenGL ES application template and this template is nice since it detects if device supports or not 2.0 and executes different code for each case. I will try, this week, to publish some port of Initial Fantasy demo for Zune HD and iPod/iPhone/iPad (3D rendering loop, able to read .3ds file, that displays a starfighter or a biplane) like I did for xb1, ps2 and 360.

By using the 2.0 shaders simulating the 1.1 fixed function pipeline I should be able to create a strong identical 3D graphics behaviour of some unified API among these platforms : iPhone (all models), iPod (all models), iPad, Zune HD, Xbox 1, Windows, Mac, PC0, 360, PS3(fw<2.10) and maybe PS2 and Wii too. (The study of Windows Open GL ES 2.0 emulator will surely help for PC0)

(Good thing with Mac is that iPhone SDK is free and includes iPad/iPhone simulator that doesn't, in fact, emulate accelerated graphics : it really displays hardware accelerated graphics! It probably works like the OpenGL ES Windows emulators, it just translates calls -I've tested with iPhone SDK 4.0.1 on iMac-. In other words, it's not even necessary to create a specific Mac binary... iPad simulator fills easily whole screen. Also if you force code to believe 2.0 is not supported, it emulates perfectly 1.1 too!)

I will try to see how many vertice/frame at 60Hz each platform can do.
(With 1 light, so far, we know score is 330K for xb1, 250K for ps2 and 3M for 360. Small devices should do less than that, but who knows... Maybe there is some surprise to discover...)

My holidays are finished. Here are the scores :

Max number of vertices/frame at 60hz (no lighting) :
(i.e if you decide your scene is to be rendered at 30hz, this is half the max number of vertices you can draw in your scene, but remember that 3 vertices in a triangle list draws a triangle whereas 1 vertex in a strip list draws a triangle, so it all depends how you organize your mesh, to gain an additional triple factor)

1) 100K for powerful apple devices : iPhone 3GS, iPod 3G (64Gb), iPad
2) 20K for zune HD
3) 12K for weak apple devices : iPhone 3G, iPod 2G (8Gb, some 32Gb)

(woah! ultra-light iPod 3G is like half a ps2 or one third of xbox1!)

Sources (read main.* file for instructions about how to deploy/compile) :

http://minilgos.perso.sfr.fr/zun.zip (zune hd)
http://minilgos.perso.sfr.fr/iph.zip (all apple device models)

(forgot to write that additional needed frameworks are QuartzCore and OpenGLES but they should come from the template. forgot to write that the shaders files have to be moved from targets/(app)/compile... to targets/(app)/copy... so Xcode doesn't try to compile them. They are read at runtime)

(textured biplane with 90K vertices, with per-pixel lighting on zune)

(turn zune left or right to change light orientation, like in enlighted dragon)

I withdraw what I said about iPhone/iPad simulator, there is too much speed loss (tops around 85K in iPad simulator), so a specific Mac OS version is required to get top speed on Mac OS.

I might have soon the opportunity to spend time (for work) learning java, especially associated to OpenGL ES 2.0 libraries on platforms BlackBerry Torch and Android 2.2 (Xperia Play). I will try to port the 3D biplane sample to these two platforms, publish source and measure performances. No ETA.

Because of my job I made a lot of progress in learning how to code for Android platform.

So a 3D sample for android will certainly be released soon. Can't give a precise ETA though.

A sample for BlackBerry Torch has less priority since market seems to divide itself massively between iOS and Android products, but there are so many similarities between Android and BlackBerry os, it can happen too.

When I've finished 3D samples for important os'es (last one is Android for sure). I will redo an update round for minidash.

There is also a project of some little online MMORPG running on pc (maybe pc0 too), ios and android, running in my head, maybe based on minidash. They are clearly the 3 OS'es to focus on, in the immediate future.