This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
Finally managed to restore the ancient power of Clicker: reading your disks' MBR to display the partition type tag (plus loading IDELBA driver on demand). That concludes the parenthesis opened with the rewrite of paging support one year ago !
hmm ... weird enough ... those codes are bios error codes, iirc. 80h is "timeout (not ready)" and 10h is "uncorrectable CRC or ECC error on read" according to RBIL, so if i were you, i'd toss that floppy away and try with a fresh/confirmed one ...
If it still doesn't work, i'll go back to my sources with humility ...
As for the ATA test (on test machines only. Remember, no warranty, cannot be held liable for data loss etc):
1. let the system boot (press <Shift>+<SPACE>, <ESC> and <Shift>+<F4> when requested)
2. call the module manager with <ctrl>+<F5>
3. load testio module
4. when loaded, switch to testio panel with <ctrl>+<F6>
5. run the "readMBR" test case. You should see something like the attached image ...
If testio hangs (when reading or on loading), try shifting to the log with <shift>+<F3> before pressing ENTER
Played around in virtual pc a bit, loaded some blinkenlights applications (console 01 goes wild! ;).
The mbr test seemed to work. A sector-hex-viewer would be fun.
What I like best is the page-debug-viewer, it's just cool :)
But your apps seem to load slowly sometimes (e.g. I loaded the testio module, but it took about a second or two to show up).
mpp.eox3 wrote:
I loaded the testio module, but it took about a second or two to show up
Yup, that's normal: the 'testio' module need to load the whole I/O subsystem first, which in turns load the available bus drivers which scan your hardware ...
In particular, when the ATA busdriver is loaded, it scans ATA bus for devices, and when no device is present, it may require timeouts to discover no device is there, depending on your controller ...
I was looking through your source code (loader.asm) and noticed that the comments suggested something that wasn't the case in the code. Nothing major, in fact may never be a problem but thought I would just let you know anyway.
VIRTUALSTACKSIZE???equ 0x0100 ; v86 got a 512bytes stack
REALSTACKSIZE??????equ 0x0100 ; so does the real-mode
EXCEPTSTACKSIZE??????equ 0x0100 ; exception got a 1K stack
SYSTACK?????????equ 0x1000 ; so does kernel
EXCEPTSTACKSIZE is 512 bytes and your comments say that you intend it to be 1024 bytes.
XStream wrote:
EXCEPTSTACKSIZE is 512 bytes and your comments say that you intend it to be 1024 bytes.
You mean all of the sizes aren't consistant
VIRTUALSTACKSIZE and REALSTACKSIZE are 256 bytes, not 512. EXCEPTSTACKSIZE is 256 bytes not 1 Kb, and SYSTACK is 4 Kb instead of 1 Kb
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
mpp.eox3 wrote:
Played around in virtual pc a bit, loaded some blinkenlights applications (console 01 goes wild! .
The mbr test seemed to work. A sector-hex-viewer would be fun.
What I like best is the page-debug-viewer, it's just cool
Note that if you head to the last page table and use the page-debug-viewer (pressing ENTER over a page), you get a chance to have a sector-hex-view of the MBR
Pype.Clicker wrote:
Note that if you head to the last page table and use the page-debug-viewer (pressing ENTER over a page), you get a chance to have a sector-hex-view of the MBR :P
Ah undocumented cheats.. ;)
I will implement some in my kernel too, activated by some good old C=64 style "POKE 12345,242" commands ;P