I need some code to help with debugging the kernal.

This code needs to work without font resources or ramdisk resources.
But.. it has to be 32 bit protected mode code.

Maybe something like turning on the pc speaker... or turning pixels on?

How can i do this. I need this to see what code is reached before a crash happens.
Thanks, Wishing

ok.. nevermind.. i found a way to call putpixel

Maybe you could use bochs builtin debugger. BTW: There's no such word: kernal.

yes yes... i know i spell it wrong.. force of habit
a bad one at that...

(maybe thats why noone replies to my posts )

but.. yeah i dont have bochs... i have vmware.. but ive heard it runs uber slow...

its ok though.. ive sucessfully used pixels to debug... can see what code works and when and how etc... theres someonthing really odd about version 77's load feature.... ad who came up with the idea to boot only the kernel from the floppy and the ramdisk from the hdd, in a file named msetup.exe and yet only make a ramdisk to hdd program that saves a .img file names menuet.img ???? so bassically... you can never SAVE your work to the hdd unless you make an image and then convert it somehow by adding 2000 bytes to the begining to simultae the executable file... i find this... more than slightly silly...

Ive been using the meosload system... and kernel 76 beta... i dont even have to use a floppy at ALL.. no floppy boot in under 15 seconds...
I could simply run meosload, dual boot win98se, save my ramdisk over and my work... no wierd conversions, etc... if i had to get files off... i could write to floppy... if i had to update ONLY kernal i could boot from floppy.. and load personal files from hdd...
i think image file is the way to go if ramdisk is going to stay...
can we decide on this for the next version?

Wishing

(i dont mean to sound bitchy... im trying to make honest problem/solution arguments)

The ramdisk is going to stay at least until we get HDD access working properly !
Then, well, it's just a virtual drive ...

please read my post more carefully next time...
i NEVER said anywhere in it i wanted to get rid of the ramdisk...
I simply said i wish there would be a standerd design/format
of the ramdisk itself.. there are many conflict issues currently.
Ramdisk with installer code stuck on begining...(which i think is silly)
or true ramdisk image (ie virtual drive)
Wishing

I appologize for not having understood.

I think the ramdisk will be replaced by HDD.
Virtual drives are not on the TODO list, yet ...

no problem.. i read stuff wrong too...

Well... this is an issue that affects the ramdisk right now...
The ramdisk is a nice feature that i dont think will go away..
why?
well because MeOS is meant to be small... thats the whole idea..
small and portable... floppies allow it to be so.. but floppies are slow.

Haviing HDD access will allow menuet to BE big if its needed to be...
but having the ramdisk keeps the option of being small....
and it only takes up 1.44 megs in ram.. so its no big issue...
The main problem is filename/size discrepancies of the ramdisk images
some ramdisk images are bigger than 1.44 megs.. some are exactly 1.44 megs... some have loaders attached... yet the ramdisk program can only save to pure image files... and the OS can only load from installer+image files


Also... I have created an improvement to meos icons.. the latest version.
It allows icons to be moved effeciently on older kernals that dont have window movement api.
Ill post the source tommoro.