> I strongly encourage you to stick an explicit license on it if you want people to study it!
I'm not concerned with lawsuits but allowing people to work with it is a good enough reason to add one.
> (While we were writing this thread, Óscar Toledo G. added a BSD license to BootOS!)
Very cool :)
> t might be more flexible to go the BootOS route of including at least some kind of hex or octal
I think that really depends on the goal of the OS, if it's to be self contained then fair enough, but it kind of limits out of the box usability for a normal user. I think most people would bork at having to type any program they want to use into the terminal each time they boot/test the system.
> …holy shit, you have a scrolling full-screen editor in one sector? This is amazing.
Thanks :) I will at some point improve upon it too, there's definitely some parts that could be better done.
> Also octal input takes less code than hexadecimal input
In terms of amount of code required, I'm not sure. Maybe there is some way to utilize AAA, AAS, DAA or DAS for converting hex to a value with minimal commands. The documentation appears to be quite crappy for these op-codes though, apparently Intel even managed to confuse themselves (which doesn't bode well for their reliable implementation) [1].
The other problem is that re-packing octal input back into raw bytes (for running) will be non-trival, the reason hex is generally used is because it represents a nibble (4 bits) and you can get away with pairs (i.e. OF 3A B7). Octal on the other hand is gonna be messy, you either have 3 octal characters per byte and lose packing density (even more) or you have cases where an octal character contains information for two neighboring bytes.
Right, you aren't the one at risk of lawsuits! You shouldn't be concerned!
I didn't mean to leave out firesystem functionality entirely. Clearly you still need a way to load programs from the disk without typing in a bootstrap program!
I agree that octal is less dense. But it's a lot more readable, because operand fields are isolated in a single digit (usually) and not split across digits and mixed with opcode bits.
> I didn't mean to leave out firesystem functionality entirely. Clearly you still need a way to load programs from the disk without typing in a bootstrap program!
In my mind, if you're going to make assumptions such as having a valid file table, making the assumption you have some basic programs ready to be loaded is not too much of a leap?
By the way, once I've got a filesystem up and running that can load in files greater than 512 bytes, it makes sense then to build a very basic assembly compiler. There's a bunch of tricks one could pull in order to make compiling a single parse deal for relatively large files at the sacrifice of efficiency. I think I could quite easily drop support for half of the 8086 instruction set and still end up with something very usable.
> I agree that octal is less dense. But it's a lot more readable, because operand fields are isolated in a single digit (usually) and not split across digits and mixed with opcode bits.
Are you able to give a small example, I'm not sure I follow the thinking? From what I understand, for each octal character you're representing 3 bits of binary. With two characters you have 6, but you're still short 2 bits for a byte.
As for the filesystem, probably I should explain what I mean in assembly rather than English :)
You definitely don't need half of the 8086 instruction set for a usable programming system. 20 instructions and a few addressing modes is plenty. On the rare occasion you need DAA or ROL you can just use a DB. RPN syntax may simplify parsing.
As for octal, yeah, you need three decimal or octal digits to represent a byte, and the most significant digit can only be 0, 1, 2, or in octal, 3. Detailed notes are in http://www.dabo.de/ccc99/www.camp.ccc.de/radio/help.txt
I'm not concerned with lawsuits but allowing people to work with it is a good enough reason to add one.
> (While we were writing this thread, Óscar Toledo G. added a BSD license to BootOS!)
Very cool :)
> t might be more flexible to go the BootOS route of including at least some kind of hex or octal
I think that really depends on the goal of the OS, if it's to be self contained then fair enough, but it kind of limits out of the box usability for a normal user. I think most people would bork at having to type any program they want to use into the terminal each time they boot/test the system.
> …holy shit, you have a scrolling full-screen editor in one sector? This is amazing.
Thanks :) I will at some point improve upon it too, there's definitely some parts that could be better done.
> Also octal input takes less code than hexadecimal input
In terms of amount of code required, I'm not sure. Maybe there is some way to utilize AAA, AAS, DAA or DAS for converting hex to a value with minimal commands. The documentation appears to be quite crappy for these op-codes though, apparently Intel even managed to confuse themselves (which doesn't bode well for their reliable implementation) [1].
The other problem is that re-packing octal input back into raw bytes (for running) will be non-trival, the reason hex is generally used is because it represents a nibble (4 bits) and you can get away with pairs (i.e. OF 3A B7). Octal on the other hand is gonna be messy, you either have 3 octal characters per byte and lose packing density (even more) or you have cases where an octal character contains information for two neighboring bytes.
[1] https://stackoverflow.com/questions/51710279/assembly-instru...