Jump to content




Custom ROM via crafting


84 replies to this topic

#21 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 29 May 2014 - 03:18 AM

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.

#22 KingofGamesYami

  • Members
  • 3,002 posts
  • LocationUnited States of America

Posted 29 May 2014 - 12:54 PM

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

#23 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 29 May 2014 - 12:56 PM

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

#24 Saldor010

  • Members
  • 467 posts
  • LocationThe United States

Posted 29 May 2014 - 05:25 PM

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.

#25 KingofGamesYami

  • Members
  • 3,002 posts
  • LocationUnited States of America

Posted 29 May 2014 - 07:13 PM

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" :)

#26 Xfel

    Peripheral Designer

  • Members
  • 515 posts

Posted 31 May 2014 - 07:41 AM

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.


#27 negamartin

  • Members
  • 46 posts

Posted 05 June 2014 - 03:28 AM

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

#28 Geforce Fan

  • Members
  • 846 posts
  • LocationMissouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension

Posted 06 June 2014 - 04:00 AM

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.

#29 BytePointer

  • Members
  • 17 posts

Posted 19 June 2014 - 06:00 AM

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

#30 Lyqyd

    Lua Liquidator

  • Moderators
  • 8,454 posts

Posted 19 June 2014 - 02:25 PM

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.

#31 Sebra

  • Members
  • 726 posts

Posted 19 June 2014 - 02:28 PM

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

#32 ElvishJerricco

  • Members
  • 803 posts

Posted 20 June 2014 - 06:40 AM

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.

#33 sEi

  • Members
  • 41 posts

Posted 20 June 2014 - 10:26 AM

+1

Would be a nice feature.

/sEi

#34 Konlab

  • Members
  • 595 posts
  • LocationKerbin

Posted 20 June 2014 - 10:40 AM

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.

#35 Sebra

  • Members
  • 726 posts

Posted 20 June 2014 - 01:38 PM

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

#36 Konlab

  • Members
  • 595 posts
  • LocationKerbin

Posted 20 June 2014 - 02:10 PM

But how to call that 'java side'?

#37 apemanzilla

  • Members
  • 1,421 posts

Posted 20 June 2014 - 04:47 PM

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

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

#38 Mr. Bateman

  • Members
  • 98 posts
  • LocationAustralia

Posted 25 June 2014 - 12:05 PM

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.

#39 Sebra

  • Members
  • 726 posts

Posted 25 June 2014 - 09:18 PM

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.

#40 skwerlman

  • Members
  • 163 posts
  • LocationPennsylvania

Posted 27 June 2014 - 01:01 AM

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.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users