Custom ROM via crafting
Saldor010 29 May 2014
KingofGamesYami, on 29 May 2014 - 02:59 AM, said:
+1 support, amazing idea. Especially the preventing of disk-booting.
Would this also override control+s and control+r ?
Would this also override control+s and control+r ?
I don't think it should. In my opinion, pushing control+s/r, is pushing the power button of the computer. I don't think any program should be able to disable that.
Saldor010 29 May 2014
KingofGamesYami 29 May 2014
Well, as I don't see a button in either recipe... Could be separate suggestion "recipe to remove power button"
Xfel 31 May 2014
CTRL-S and CTRL-R are handled by the mod itself, these two never get close to lua code. so, even by rom editing, this part of computer behaviour can't be changed.
Edited by Xfel, 31 May 2014 - 07:43 AM.
Edited by Xfel, 31 May 2014 - 07:43 AM.
Geforce Fan 06 Jun 2014
1 word: yes.
To be honest, this is a very sense-making suggestion. Like he said, you make the computer, shouldn't you be able to control how it runs?
Another thing is that this could be used to protect your program so that they cannot be modified or deleted.
To be honest, this is a very sense-making suggestion. Like he said, you make the computer, shouldn't you be able to control how it runs?
Another thing is that this could be used to protect your program so that they cannot be modified or deleted.
BytePointer 19 Jun 2014
Maybe you could craft a microchip, be able to put a custom ROM on it, then put it in a new special kind of computer! Maybe called 'Custom Computer'? ;P
Yes, these interrupts are mentioned in bios.lua
Xfel, on 31 May 2014 - 07:41 AM, said:
CTRL-S and CTRL-R are handled by the mod itself, these two never get close to lua code. so, even by rom editing, this part of computer behaviour can't be changed.
Lyqyd 19 Jun 2014
No, Xfel is right. Ctrl-R and Ctrl-S are handled on the Java side and there's nothing the Lua side can do about them.
Sebra 19 Jun 2014
ElvishJerricco 20 Jun 2014
This general suggestion has been asked for since the dawn of time. I've always supported it. And this thread seems to prove that almost everyone wants it. If there's a most requested feature for CC, this is it.
Konlab 20 Jun 2014
But if you craft an edited ROM, there MUST be leaved some main APIs,
I guess for example Redstone API isn't written in Lua.
I guess for example Redstone API isn't written in Lua.
Sebra 20 Jun 2014
Only LUA side can be changed of course. Java side can be supposed "hardware".
apemanzilla 20 Jun 2014
Mr. Bateman 25 Jun 2014
I would like to see this taken one step further, such as maybe fs.flashROM().
It would make programs like this easier to implement, as giving a bootloader direct access to the raw startup and autorun script and change it as need be (Maybe even bios.lua, but it's a last resort ) would make life much easier than relying that the user renamed /startup on their disk to /grubstartup.
The arguments would be a one-time password that the computer gives the user only once, which changes everytime you flash the ROM.
Or maybe, you can only flash it once (or a preset value) like in the OP.
If the user forgets this password, (if it's not one-time only) the user can flash back to default ROM (but other people might use this to exploit holes).
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
It would make programs like this easier to implement, as giving a bootloader direct access to the raw startup and autorun script and change it as need be (Maybe even bios.lua, but it's a last resort ) would make life much easier than relying that the user renamed /startup on their disk to /grubstartup.
The arguments would be a one-time password that the computer gives the user only once, which changes everytime you flash the ROM.
Or maybe, you can only flash it once (or a preset value) like in the OP.
If the user forgets this password, (if it's not one-time only) the user can flash back to default ROM (but other people might use this to exploit holes).
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
Sebra 25 Jun 2014
ROFLCopter64bit, on 25 June 2014 - 12:05 PM, said:
I would like to see this taken one step further, such as maybe fs.flashROM()....
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
If you would be able to change ROM in any way, you would be able to add any quantity of levels of "trust" yourself.
skwerlman 27 Jun 2014
Sebra, on 25 June 2014 - 09:18 PM, said:
ROFLCopter64bit, on 25 June 2014 - 12:05 PM, said:
I would like to see this taken one step further, such as maybe fs.flashROM()....
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
Either way, a method that gives trusted software access to flash the ROM when they really need it would be great.
If you would be able to change ROM in any way, you would be able to add any quantity of levels of "trust" yourself.
I think only the ROM should be allowed write access to itself, leaving it up to the ROM decide whether or not to allow flashing.
Simply giving the ROM write privileges to itself allows it to implement a trusted/untrusted scheme, so I don't think there needs to be one by default.