←  Suggestions

ComputerCraft | Programmable Computers for Minecraft

»

Custom ROM via crafting

Saldor010's Photo Saldor010 29 May 2014

View PostKingofGamesYami, 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 ?

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.
Quote

KingofGamesYami's Photo KingofGamesYami 29 May 2014

Yes, but we are crafting our computer differently...
Quote

skwerlman's Photo skwerlman 29 May 2014

Maybe add an option to disable it, but not by default.
Quote

Saldor010's Photo Saldor010 29 May 2014

View PostKingofGamesYami, on 29 May 2014 - 12:54 PM, said:

Yes, but we are crafting our computer differently...

No we aren't. All we're doing is editing the ROM, not changing the actual hardware.
Quote

KingofGamesYami's Photo KingofGamesYami 29 May 2014

View PostJiloacom, on 29 May 2014 - 05:25 PM, said:

View PostKingofGamesYami, on 29 May 2014 - 12:54 PM, said:

Yes, but we are crafting our computer differently...

No we aren't. All we're doing is editing the ROM, not changing the actual hardware.
Well, as I don't see a button in either recipe... Could be separate suggestion "recipe to remove power button" :)
Quote

Xfel's Photo 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.
Quote

negamartin's Photo negamartin 05 Jun 2014

I support :)
Awesome suggestion. Hope dan adds this...
+1
Quote

Geforce Fan's Photo 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.
Quote

BytePointer's Photo 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

View PostXfel, 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.
Yes, these interrupts are mentioned in bios.lua
Quote

Lyqyd's Photo 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.
Quote

Sebra's Photo Sebra 19 Jun 2014

View PostNullByte, on 19 June 2014 - 06:00 AM, said:

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
Too complicated. Computer has no chip inside now, only redstone dust ;P
Quote

ElvishJerricco's Photo 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.
Quote

sEi's Photo sEi 20 Jun 2014

+1

Would be a nice feature.

/sEi
Quote

Konlab's Photo 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.
Quote

Sebra's Photo Sebra 20 Jun 2014

Only LUA side can be changed of course. Java side can be supposed "hardware".
Quote

Konlab's Photo Konlab 20 Jun 2014

But how to call that 'java side'?
Quote

apemanzilla's Photo apemanzilla 20 Jun 2014

View PostKonlab, on 20 June 2014 - 02:10 PM, said:

But how to call that 'java side'?
Same as now.
Quote

Mr. Bateman's Photo 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.
Quote

Sebra's Photo Sebra 25 Jun 2014

View PostROFLCopter64bit, 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.
No. I would not support separating software on "trusted" and "not trusted". ROM / RAM separation is good enough.
If you would be able to change ROM in any way, you would be able to add any quantity of levels of "trust" yourself.
Quote

skwerlman's Photo skwerlman 27 Jun 2014

View PostSebra, on 25 June 2014 - 09:18 PM, said:

View PostROFLCopter64bit, 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.
No. I would not support separating software on "trusted" and "not trusted". ROM / RAM separation is good enough.
If you would be able to change ROM in any way, you would be able to add any quantity of levels of "trust" yourself.
Assuming you had the trust to start. Although implementing trusted software would be pretty hard unless all trusted code were encrypted on disk, since you could just take what made them 'trusted' and move it into some less-than-trustworthy code.
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.
Quote