Keyboard Leds

91 views
Skip to first unread message

X86Novice

unread,
Jan 10, 2016, 8:18:18 PM1/10/16
to BareMetal OS
Hello Ian,
Having problem with turning on Capslock,Numlock leds when running the program on hard disc but works fine on VirtualBox, tried disabling/enabling interrupt (IRQ1) to no avail but the remaining code runs as expected except the leds.
CPU is i3 GigaByte GA-H81M-DS2, O/S Win 10 (recently upgraded from Win7), Emulator is VirtualBox ver 5.0.12 (latest) & BareMetal OS ver 0.6.1

Would appreciate any help from anyone & let me know if more info is needed , thanks & Happy New Year to all. 

Ian Seyler

unread,
Jan 11, 2016, 9:56:25 AM1/11/16
to BareMetal OS
So it works correctly in VirtualBox but not on physical hardware?

Can you provide the code?

-Ian

X86Novice

unread,
Jan 12, 2016, 7:21:02 AM1/12/16
to BareMetal OS
Yes it works on VB but not on BMOS bootable hard disc.
Uploaded 3 files, 2 versions of programs & a ReadMe.txt
Thanks
kbl.asm
kbl2.asm
ReadMe.txt

X86Novice

unread,
Jan 20, 2016, 7:12:03 PM1/20/16
to BareMetal OS
Hello Ian and all BMOS followers,
Sorry for being a pest here, just became aware of BMOS v1 with latest update 2 weeks ago, but got an error compiling ....x86-64\loader\bootsectors\bmfs_mbr.asm, the error messages from nasm are :
bmfs_mbr.asm:77 symbol 'cfg_e820' undefined
bmfs_mbr.asm:229 error: TIMES value -39 is negative

Also downloaded latest update of Pure64 & it comes with its own version of bmfs_mbr.asm of different size compared to the above, I assume the v1 is the one to be used ?
When manually putting v1 together into image file, the order still bmfs_mbr.sys @ 00h followed by Pure64.sys @ 2000h then boot.bin ?, just a guess as there is no build script for win10 version.

Last but not least, the old age question going way back to the thread 17/Feb/2014 (Problems running BMOS on real hardware) specifically in relation to vga scroll and changing character attributes during runtime are still an issue , I read all entries in the hope to crack a solution to the problem but to no avail, all my programs always access 0b8000 directly and all work smoothly on VB & HD except those 2 issues, v1 overcome this problem?

Thanks & Regards.

Ian Seyler

unread,
Jan 25, 2016, 11:56:17 AM1/25/16
to BareMetal OS
I think you are using the BareMetal-kernel code. That isn't ready to be used just yet. Especially the redone BMFS MBR loader that does the jump to 32-bit mode.

I'll give your code a try on my test system this week/weekend.

Writing to the screen is still an issue? Any program should be able to write to direct memory at 0xB8000. However, keep in mind that BareMetal uses its own internal frame buffer and only writes to 0xB8000. Reading from that memory is slow so I use a buffer instead.

-Ian

X86Novice

unread,
Jan 29, 2016, 7:10:58 AM1/29/16
to BareMetal OS
Hello Ian,
Regarding my last post, please ignore although I got it working then realized the package comes with OS directory as well which is what I'm using at the present; however, the issue with direct addressing through 0B8000 I finally (I hope and I think) have figured out its quirks after reading some source codes, the conclusion I've come to is it has something to do with os_screen ?
The past week or so I've been testing my own version of CLI purely on the use of direct access of 0B8000 , what is interesting is the use of STOSQ in respect to RDI pointing to any region of 0B8000-0B8FFF is OK but not MOVSQ in respect to both RSI & RDI being referenced to 0B8000-0B8FFF.
I managed to overcome the issue that MOVSQ only works when Either RSI or RDI points to 0B8000-0B8FFF and the other MUST point to a region of memory  other than 0B8000-0B8FFF , for example... mov RDI, 0B8000h, mov RSI, os_screen then MOVSQ works ! and by that I mean it works on bmos bootable hd !
So for now I'm happy with the compromise because most programs I've written  involve scrolling display.
I'll continue to work on it & will keep you posted,
Regards
Reply all
Reply to author
Forward
0 new messages