Latest version: 0.04
You are not logged in.
started new thread to not mix the subjects.
As a start I downloaded the source package and compiled/copied the bootprog and kernel32 myself, but it wouldn't show any files with dir command even though i had copied the GUI.dex program to the floppy. kernel32 wasn't visible either, just got floppy space no files listed.
i then used the emulator package so that i would get all the drivers and stuff that it tries to load, and that seems to work fine! took a while to get into the gui, but it worked at least. suspect it's an older version because it has the older game platform look with wires and stuff. I'll try copying over a newer copy in a moment. only "bug" i could find in this version was that spacepong didn't take keypresses, had to reboot. bochs said the internal keyboard buffer was full and that it ignored keypresses. so some kind of clearing the hardware keyboard buffer in your game version keyboard handler could do it?? as if i recall correctly you have 2 versions of the keyboard handler depending on game support (multiple keypresses at once )?
anyway, while in the gui i selected to start the scrensaver which also worked, the vesagui or whatever it was called however only displayed a white box/screen and quit on any keypress.
as i said, will try again with updated gui files and see if i can find out whats changed.
Offline
The problem at the moment is that, the new and old are not compatible, so mixing can cause problems.
Also theres three ver, the old ver, a ver that uses Dos as boot loader and the latest ver.
The main problem in the new ver, it that it does very little as its trip down to a min.
I am working on add more stuff to bring it back to where the old ver was.
I may in the end go back to the old ver and just clear it up, add better file functions, as it seem to work fine.
The problem with the keyboard is a bug, if you go to realmode and back, (which is fixed now), that needs the keybuff clearing if you return from real mode, once back in pm.
But thanks.
Once i make my mind up i will go full steam, i am coding all new stuff as modules drivers for now.
Last edited by Dex4u (2012-02-06 23:24:45)
Offline
ok, nice. i'll try it more with the new version for now then, not sure if i'll have time tonight but i'll keep you posted. 
Offline
Hi, I've tried debugging the newest version and it's definitely the jump to the GUI that fails at
call dword[GuiLoadAddrVar]
it's just bogus memory, so i do not think that the GUI gets loaded correctly, it sets of an exception right after the jump. what might be the casue of this i have no idea, will see if I can investigate the use of
mov byte[GuiOK],1
maybe it reports wrong or something? otherwise there's quite a bit of the fat and cli/run command code that could be responsible.. 
Offline
omg, so obvious... 
hahahha, i told you before that i always run bochs with 32mb but since it hanged i tried to change to 64mb without any change. well..... you load the gui to 0x4000000 = 64mb. Changing settings to 128mb fixed it straight away! my bad. but an error message about insufficient ram would be nice 
edit: fixed it was a bit premature... i thought everything was fine since it went into fullscreen and the jump went fine, but even after waiting several minutes nothing was seen on the screen, just black. and in the background bochs started complaining about keyboard buffer being full every once in a while again, which it seems to be doing almost every time you switch to VESA? sometimes it still works enough to show the graphics like in spacepong (you just don't get any controls), but not in the gui.
Offline
Thanks for the info, this may need adding to the return from realmode
call remap_pic ;
call unmask_irqs ;
in al,60h ; <****************the read/write have them but int 10h and vesa do not.
Try this new KERNEL32 to replace old.
If it works i will up date code.
Thanks again.
Last edited by Dex4u (2012-02-07 23:43:50)
Offline
Yeah thats much better, everything works fine now! Adding a small check for enough memory and halting with error if it's not over 64mb would also be good though. Btw, have you considered moving it to like 55mb or something slightly lower, since most have either 32, 64 or 128 in that order. Putting it at exactly 64mb rules out everybody that might test on computers or emulators set to that.
Offline
Thanks bubach, i do normal test for enough ram, but i was using dos to boot it when testing and under dos the function does not give more than 1MB of ram.
So i un-high lighted it, than i forgot to add it, when i tidy the code up.
I will re-add and will put gui much lower.
Offline
ok great, also good news it wasn't anything more serious. btw here's one of my routines you could use while starting up in realmode, bios function e801:
;-----------------------------------------; ; get mem ; ; in: nothing ; ; out: eax = mem in bytes, 0 = error ; ;-----------------------------------------; getmem: push dx push cx push ebx xor eax, eax xor ebx, ebx mov ax, 0xE801 xor dx, dx xor cx, cx int 0x15 jnc .cont1 xor eax, eax jmp .end ; failed! :'( .cont1: mov si, ax or si, bx jne .cont mov ax, cx mov bx, dx .cont: cmp ax, 0x3C00 jb .below_16 movzx eax, bx add eax, 0x100 shl eax, 16 ; eax = eax * 65536 jmp .end .below_16: shl eax, 10 ; eax = eax * 1024 .end: pop ebx pop cx pop dx ret
Offline
Thanks, i already have this function thats called in realmode
;======================================================= ;
; Get Ram Size. ;
;======================================================= ;
GetRamSize:
mov ax,0xe801
int 15h
jc @f
movzx ebx,bx
shl ebx,6
movzx eax,ax
add ebx,eax
mov [ExtMemorySize],ebx
call TotalRam
@@:
ret
;======================================================= ;
; TotalRam. ;
;======================================================= ;
TotalRam:
shr ebx,10
inc ebx
mov [TotalMemoryMB],ebx
retI just forgot to test it before load gui high.
Last edited by Dex4u (2012-02-08 23:07:47)
Offline
aha, ok
Offline
Just in case you want to test your or DexOS on real PC, i coded a windows app to put DexOS on USB fob.
As from my tests bochs is very slow compared to real PC.
If you need it let me know, i will upload it to my site.
Last edited by Dex4u (2012-02-09 01:10:57)
Offline
Hi, yes it was terrible with VESA but it's still very nice to have it functional under emulators for clean screenshots and all the lazy bastards not willing to restart between test. *me*
Yeah that would be really nice, how is it doing that, does it work by emulating a 1.44mb floppy on the USB or is that not needed anymore? i haven't looked into usb booting in several years, never even tried it.
anyway would be nice as I could use it to test BOS on real hardware too. what FS is needed, if it's an emulated 1.44mb partition i suspect that fat12 would still be usable, otherwise you need at least fat16 or preferable fat32, right? anyway, would be cool to test my fat12 code on some odd devices later on to see how it handles "non-standard" values on sizes and and stuff, see if I assume as little as possible in my code. need to set up a computer with fat12 on hdd, maybe dust of my old ibm ps/2 in my closet.
Offline
Well USB booting is simple, but you need to do certain things for it to work.
First thing to note, is that like CD it users fdd or hdd emulation or both.
But you can not chose un-less it does both.
For floppy emulation to work, the boot sector must have a BPB, for hdd it does not matter.
Now in the zip you will find the source code and the app its self called "UsbDex.exe", this is the windows App that puts the boot sector on the USB, in window vista or win7 you most run it a addmin.
The other program called "usb_format.exe" is a format app (not made by me), this formats the USB as FAT16 (FAT), this is needed by "UsbDex.exe" as a safety measure, to stop people from formating that main harddrives.
This is done in code so you can mode this to write to any drive formated type.
You may ask why not just format it with windows built in format tool, that because it formats it wrong for our need, as it adds a MBR like a harddrive.
I format it like a big floppy even for fat16 harddrive.
Anyway back to the point, to use it for your OS you need to replace my floppy image with yours and the need to make a harddrive boot sector .bin, that works with fat16.
Replace mine with yours and than re-assemble the code with fasm.
If you use floppy emulation, the USB will be the size of a floppy and you can add stuff in the normal way, but you will only be able to see and use 1.4.
To return it back to normat just format it.
For harddrive you can add remove file just like any other usb and it will be the normal size or the max for fat16.
All not if you test the image thats included in the zip, it the old ver of DexOS, you can just up-date the floppy image and keep the same hdd.bin, just replace all the files in the harddrive folder with the new DexOS files including kernel32.exe.
Anyway any ? just ask.
You can get it here: [edit] removed, just ask to have it reposted[/edit]
Last edited by Dex4u (2012-02-10 20:30:03)
Offline
Ok, thanks. I have downloaded the file and will re-read and try it out later when I find an USB drive with no critical content on it The one I use right now I have all my homepage and OS source on, and it's 16gb so will try to find a smaller one for test purposes.
Offline
Great, and no problem. Also I have to point out that I like what I see so far, with the directory structure and overall cleanup. It's about time I start dividing my sources up in directories too, quite a few additions made since the 0.04 version.
Offline
Are you going to go 64 bit? If so you are going to have to look at E820 to get your memory information.
Offline
I don't think that I'll go 64-bit any time soon. Perhaps I'll use BOS as a development platform for another OS when it's usable for something like that. Also had an idea of supporting switching to 64-bit for programs, while keeping the kernel and main OS 32-bit, almost like how the DOS extenders worked. Well, we'll see.. I might port BOS to true 64-bit too, just won't be until after I get my basic designs and such working for 32-bit - making it easier just to port and not having to worry about design and structure. Either way, I'll add E820 support "soon", and use these older ones as fallbacks. Been meaning to for a while now, but more pressing things to get to first.
Offline
