Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
Sign in to follow this  
Solra Bizna

Architecture tagging for EEPROMs - feedback requested

Recommended Posts

EEPROMs do not currently have a means of targeting a specific architecture. All of the OC-ARM EEPROMs I've made have had the following structure:

--[==[actual program data goes in here]==]error"This EEPROM is not compatible with Lua computers"
My ROM mapping code "skips" any --[ followed by zero or more = followed by another [ in the EEPROM. This solution avoids the problem of loading an OC-ARM EEPROM in a Lua computer, but not any other combination. It also takes away 65 bytes that could otherwise be used by the program.

I think we need a more general strategy for architecture-specific ROMs. One way to handle this would be to add a "na" (short for Need Architecture) function to machine.lua, and have non-Lua architecture EEPROMs take the exact form (with no extra spaces):

--[==[actual program data goes in here]==]na"Architecture Name"
Where there can be zero or more =, but the number of = must match on either side. (This allows the number of = to vary on an architecture by architecture or even program by program basis, as needed to prevent the comment from leaking.)

The na function could be as simple as:

function na(arch)
  error("This EEPROM requires a CPU running the "..arch.." architecture.")
This would prevent the Lua architecture from running out-of-architecture EEPROMs, without breaking any existing Lua EEPROMs. The na function might also try calling computer.setArchitecture and rebooting.

Other architectures would then parse the exact structure above, and check that the "Architecture Name" exactly matches their architecture. If it doesn't, they could crash with an error message equivalent to the above. If it does, they map the EEPROM, skipping as many bytes as are in the initial --[==[ block.

The "Architecture Name" would have to be standardized, to prevent problems. For instance, mine would likely be "OC-ARM", while the other ARM architecture might be "OpenArms".

I'd be happy to write this up as an OETF document, but first I'd like to hear how other architecture devs have handled this problem, and get feedback on this idea in general.

Share this post

Link to post
Share on other sites

I prefer the NBT tag approach, and it could possibly have a list of architectures it can handle (e.g. it could be tagged "Lua 5.2;Lua 5.3") and if it doesn't handle the given arch the CPU can autoswitch to the first available arch in the list.

Share this post

Link to post
Share on other sites

The only downside of that is that the "flash" utility would have to prompt for that information (user error party!), or it would have to be stored in the ROM file some other way. I'm open to it, though.

Perhaps something like my original proposal as the storage format, and the "flash" utility can recognize that, strip it, and tag the EEPROM? ROM images that aren't tagged would default to "Lua 5.2;Lua 5.3" for obvious reasons.

Maybe something like:


arch=Lua 5.2;Lua 5.3
Blah blah blah
and after "flash" is done with it, the EEPROM only contains "Blah blah blah" and has its architecture tag set to "Lua 5.2;Lua 5.3".

I like any solution that enables auto-switching of architectures, and at the same time I don't. (I think like wins out, though.)

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.