search

0x10cAtlas / AtlasOS

An operating system for DCPU-16.
107 stars 16 forks source link

Add support for Atlas ABI files #18

Closed noxer closed 12 years ago

noxer commented 12 years ago

Currently AtlasOS only loads flat binarys. AtlasOS should load its own format (including libs and ART).

rustyoz commented 12 years ago

a tutorial on how to compile these files is needed

chessmaster42 commented 12 years ago

What is really needed is an assembler that can automatically generate the ART. Right now it's a manual process. You have to create an entry for every point in your code you reference a label instead of a register or constant value.

rustyoz commented 12 years ago

what you mean by an entry point?

chessmaster42 commented 12 years ago

Say you have this line at memory address 0x0010:

SET A, my_text_data

The ART entry is set to the value of the memory location of the label on this line which is actually 0x0011 because the op code is the first word and the label the second word. Then when the program is run it is copied into new memory and the 0x0011 has the program start location added to it so that it points to the correct memory location while running.

rustyoz commented 12 years ago

hmm i get vaguely what you mean, but i still wouldn't be able to write a tutorial. plus i should be concentrating on my university subjects....

chessmaster42 commented 12 years ago

Did alot of code cleanup this evening for process loading. Moved all application loading into one function and fixed the double memory allocation bug.

chessmaster42 commented 12 years ago

I tinkered with the idea of parsing out any words that have the 0x1E or 0x1F op code destination/source values (i.e. [address] or address) that would solve the problem. However we have no way of distinguishing between say data that happens to have that part of the opcode and the actual opcode itself. It would be realtime and fully dynamic and would eliminate the need for the ART but it might corrupt data values that are 0x7E-- through 0x7F-- as well as 0x-1E- and 0x-1F- (where the dashes can be any other hex value for that nibble). One way to make it more accurate might be to check the next word after the alleged opcode and see if the value is smaller than the size of the program and is not an opcode.

I'm going to mess around with automating assembly relocation for JSR and SET PC bytecodes and do what I can to reduce the ART.