Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bogdanontanu

Pages: [1] 2
Sol_Asm / Re: Error creating unicode string
« on: July 08, 2018, 04:16:48 PM »
Hi kaiser,

There is a new version released: v0.36.76 that fixes this issue / bug with UTF-8 Chinese unicode stings

Sol_Asm / Re: Error creating unicode string
« on: July 07, 2018, 11:35:35 PM »
String subscription source code
Code: [Select]

/*86*/ numerror du "Định dạng số hexa khng đng",0
/*87*/ formaterror du "Lỗi cấu trc",0
;numerror du "num error",0
;formaterror du "input error",0
formatfilein du "input file error",0
formatfileout du "output file error",0

Returned error code
Code: [Select]
**Error** PartCopy.asm(86) DU, empty string: ịnh dạng số hexa không đúng
**Error** PartCopy.asm(87) DU, empty string: ỗi cấu trúc

Thanks for the example, this will be fixed fast.

Sol_Asm / Re: Error creating unicode string
« on: June 22, 2018, 12:26:59 AM »
Hi Bogdan.
When I declare a unicode string, an error occurs with the utf-8 format
Code: [Select]
**Error** PartCopy.asm(35) DU, empty string: ịnh dạng số hexa không đúng
**Error** PartCopy.asm(36) DU, empty string: ỗi cấu trúc
Hope you can fix it soon

Do you have an example source code that creates this error?
What was the "du" string?

Sol_Asm / Re: jump short
« on: June 20, 2018, 10:03:49 PM »
I want to make a partition for the floppy. This makes it easier for me to manage files and code.
So the task of bootload (512 bytes) is to load a file "BOOT" up to start phase 2

Hi keiser,

A partition for the floppy is kind of unusual. You can have files on a floppy. But usually there is no partition on a floppy.
A HDD does have a partition table and one or more partitions.

It is OK to arrange your files like that.

However it might be a task that is too complicated for the first 512 bytes.
I guess that it can be done for FAT12, maybe even for FAT32. I doubt it can be done for NTFS.

Anyway it will be complicated and cumbersome to try and fit a real filesystem read in 512 bytes :D

I still think it is better to read some stage 2 code in and then let that stage 2 code implement a filesystem and read files from boot floppy or boot HDD if you want to.

Just my personal opinion of course ;)

You are free to try. I have heard that some people have succeed in doing this.

However I personally would not do it.
It is IMHO too complicated to fit good (bug free) filesystem reading code in just 512 bytes or less ;)

Sol_Asm / Re: jump short
« on: June 18, 2018, 02:08:57 PM »
Hello sir Bogdan.
I'm having trouble with my bootloader code.
The code size after the build exceeds 512 bytes.
You can optimize jump functions in 16bit mode
Code: [Select]
je label ; 4byte "0F 84 XX XX"
je short label ; 2byte "74 XX"

Code: [Select]
jmp label ; 3byte "E9 XX XX"
jmp short label  ; 2 byte "EB XX"

If you can provide or add the following functions in 16bit mode
Code: [Select]
ljmp segment:offset ; jmp segment:offset

mov {reg},[es:{reg}] ; mov ax,[es:di]
mov {reg},[ss:{reg}] ; mov ax,[ss:di]


Hi kaiser,

Thanks for checking this,
I will check it out and see if I can improve the size of the 16 bits encodings.
I will also add the missing long jump and cmpsb instructions.

I also have bootloader code in Solar_OS (same 512 bytes) and I have managed to fit the code in there.

However I did not try to add all the code in there.

The general advice here is to simply load a 2nd stage boot loader code with a bigger size.

For example in my boot loader I load 24 sectors for 12Kilo bytes right after the boot loader.
And then I jump to that code ;)

This way I avoid trying to stuff all the boot loader code in the first 512 bytes

Sol_OS / Re: Started Solar_OS x64 development
« on: May 10, 2018, 02:20:54 AM »
But there is a lot of debugging going on in the background:


Sol_OS / Started Solar_OS x64 development
« on: April 05, 2018, 10:31:47 PM »
Hi all,

I have (re)started Solar_OS x64 development.

Things are progressing fast and nice.
Still in full ASM mode. Using Sol_Asm as the compiler.

Here is a screenshot from today:


I have x64 setup (paging), interupts, mouse and keyboard working already.
Plus some text and Sprite/Icons drawing ;)

Solar_OS x64 version should be ready fast

General Discussion / Re: Olavo de Carvalho
« on: April 21, 2017, 09:33:36 PM »
Hi  mineiro,

Yes I am ok, thanks for asking.
Just a lot of work and study as you can guess.

Thanks for the hint. I will check him if I have the time ;)

Sol_Asm / Re: The LARGEADDRESSAWARE option
« on: September 26, 2016, 11:28:25 PM »
Hi Vortex,

Yes, I will add this option

Thank you for the attached example ;)

Sol_Asm / Re: writing to data or bss section variables
« on: August 13, 2016, 05:44:39 PM »
Hi mineiro,

There is a new Sol_Asm version that fixes some of the issues with MOV reg,[r12] or MOV reg,[r13] issues

Sol_Asm / Re: writing to data or bss section variables
« on: August 13, 2016, 09:50:24 AM »
I will also be interested to see how you generated a .so  file with sol_asm ;)

Sol_Asm / Re: writing to data or bss section variables
« on: August 13, 2016, 09:36:44 AM »

You have said on other topic about ideas to be implemented on linux side, well, I have some ideas.
On windows side, sol_asm offers a way to import functions from dinamic libraries (.dll). DLL's are just MZ files being Pe,Pe+, ... , and this type of file depending how it's configured can generate .exe, .dll, .sys, .scr, ... .
On linux side and object file it's an ELF header, an executable it's an ELF header, a dinamic library it's an ELF too, a module (driver) too, just fields change. The only exception is a static library that is just a concatenated of object files. So, I think that sol_asm can have options to generate an executable or a dinamic library.

I have sucessfully created a dinamic library example using sol_asm, appears that 'public' and 'export' have same meanings, I'm still checking.
A suggestion is change lin64 to cdecl, and by checking command line (-elf switch) know if calling convention is to 32 or 64 bits. But it's just a suggestion. Linux have as solid base C language.

Again, 10x

Hi mineiro,

Yes those are good ideas.

In the short run I want to find most bugs and miss features of code or relocations generation for x64  / ELF64 / COFF64 because this part was less tested by me.

In the long run I plan to make sol_asm able to directly generate ELF32/64 executable and directly import from .SO on Linux 32/64 files just like sol_asm can do this on windows and PE32/64 files.

I also plan to make it able to link / import directly from static lib files and perform linking. I might also write a separate linker.

I was thinking to rename / alias "lin64" calling convention to "lnx64".
However I like to allow mixing of calling conventions inside the same file. This mixing is not very usefully in windows/linux where the ABI is enforced by the OS but it might be fun for my own OS.

I am not a big fan of lin64 or win64 x64 fastcall kind of calling conventions and I like to have options available ;)

A -fpic kind of option is maybe also needed for easy .SO generation (or at least a warning that code is not position independent)

I guess that I will also need to add PLT and GOT handling in Linux.

Sol_Asm / Re: writing to data or bss section variables
« on: August 11, 2016, 09:31:02 PM »
Hi mineiro,

I will check this also ;)

Sol_Asm / Re: writing to data or bss section variables
« on: August 01, 2016, 11:12:44 PM »
Hi mineiro,

There is a new version here:

It fixes a lot of relocations issues for ELF64 / Linux

Pages: [1] 2