Welcome, Guest. Please Login or Register
 
The Purple Parade is marching in full stride to the beat of that 'other' drum we all hear, but generally ignore. Wink
Home Help Search Login Register


Pages: 1 ... 3 4 5 
Send Topic Print
Project - Table File Standard (Read 66482 times)
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #60 - Nov 21st, 2012 at 9:08am
 
In case anyone was wondering what the status of this was. None of the consortium of peers I sent the draft to for final review had anything further to say. Before parading it around as official, I thought a few things needing doing first.

First, it needs an implementation. Releasing a spec without also releasing something that uses would doom it to obscurity or my personal use. So, I need to get a full implementation in TextAngel and then release that alongside the standard. Obviously I haven't yet finished TextAngel enough for a release nor do I have a complete implementation of all features of the latest draft in the table engine. There are some complex features and rules there which are time consuming to implement and test. It's all about time and time is always short.

Second, I think it could also use another small edit as I noticed a few typos remaining after not having looked at it in awhile. It might be useful for another set of eyes to do that as well. Lastly, I considered doing a fancier formatted PDF version.

Anyway, the spec itself is still final in content unless I come across some show stopping problem during my implementation in TextAngel. If anybody else is working on an implementation using this specification, by all means let me know how it is going. Smiley

Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
RyogaMasaki
Peasant
*
Offline


I Love TransCorp!

Posts: 6
Re: Project - Table File Standard
Reply #61 - Jan 14th, 2013 at 9:04pm
 
Hello, all. I'm in the process of (re)writing a ROM text dumping application and I plan to implement this table specification.

First of all, I'm not an advanced programmer. This project is actually my way of learning C# and is based on earlier versions I did with VB6 and C++. I was trying to dump the text from the Chrono Trigger proto back then, and I could see a need for an updated and standardized table format. My dumper used some custom codes in the table for formatting output and such, but the table spec you guys have worked out is a much better implementation, imo.

So, having worked with this for the last few days in C#, I have a few questions and comments. I haven't read through every bit of this thread or the one at the main romhacking.net forum, so please forgive me if some of these questions are already answered.

1. The BOM - According to Wikipedia (which I can't link to link to as I'm new to the message board, but they have a BOM entry), the BOM for UTF8 encoding is allowed but is not recommended, since UTF8 always has the same byte order. The table spec recommends its use however. Is there a specific reason for this?

2. Something I've always used in my tables is the # symbol for single-line comments. I understand these aren't really very important, but comments seem like something easy to deal with when parsing the string from the stream. I humbly suggest a way to add comments to tables.

3. End tokens - While it seems obvious that there would only be one end token per table (or per logical table?), the table spec doesn't mention this in particular. Can I assume that there will only be one end token, or should I allow for multiple per table? Also, with end tokens, does section 2.5.2 'inherit' the General Rules of section 2.5? Namely, should end tokens be multibyte? Sorry if this question seems a little stupid, heh.

4. Sect. 2.5.3 - "All tables to be used with switching functionality must include a unique ID line identifying the logical table"
Does this mean that if there are any logical (labeled) tables, that ALL tables must have a label? Currently, my code iterates through the text file until it comes to a normal entry. If there is no current logical table and it didn't find a label, it assumes this is the 'default' table and makes a dictionary for it. It stays in that dictionary until it comes upon a new @ label and creates a new one, etc.

Per the table spec, should there be allowed to be an unlabeled default/main table and then labeled extra logical tables, or should ALL tables be required to have a label?

Thanks for all the work everyone did in publishing this document. It makes things both easier for me and more challenging, as half my work has been done with a usable tbl format and as I have to make everything compliant! Smiley
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #62 - Jan 15th, 2013 at 10:40am
 
Great to know a few people out there have found this useful. I think it's the best text based table spec we will have until we eventually move on to XML tools, spreadsheets, or whatever else becomes the next generation of translation tools.

RyogaMasaki wrote on Jan 14th, 2013 at 9:04pm:
1. The BOM - According to Wikipedia (which I can't link to link to as I'm new to the message board, but they have a BOM entry), the BOM for UTF8 encoding is allowed but is not recommended, since UTF8 always has the same byte order. The table spec recommends its use however. Is there a specific reason for this?


I think that passage got its roots from early specs that did not require UTF-8 only. Thus, if multiple encodings were involved, the BOM signature was preferred. ASCII or other encoding can be difficult to distinguish from UTF-8 without BOM. We wanted to avoid guessing file encoding or needing user specification. I actually still do support a few other common encodings in TextAngel. I never took them out. I thought accepting them would aid in conversion and/or transition to UTF-8 of older tables for users. There are people whom have no idea what UTF-8 is or why they should use it. There are also lazy people who won't try anything new if it's too much work.

You're right, technically that recommendation should not be necessary if we're only dealing with UTF-8.

Quote:
2. Something I've always used in my tables is the # symbol for single-line comments. I understand these aren't really very important, but comments seem like something easy to deal with when parsing the string from the stream. I humbly suggest a way to add comments to tables.


What do you use comments in your table for? I don't think this has been brought up before.

Quote:
3. End tokens - While it seems obvious that there would only be one end token per table (or per logical table?), the table spec doesn't mention this in particular. Can I assume that there will only be one end token, or should I allow for multiple per table? Also, with end tokens, does section 2.5.2 'inherit' the General Rules of section 2.5? Namely, should end tokens be multibyte? Sorry if this question seems a little stupid, heh.


End tokens are like any other entry here. Multiple are allowed. Yes, they inherit the rules of 2.5 for their hex sequences and labels.

Quote:
4. Sect. 2.5.3 - "All tables to be used with switching functionality must include a unique ID line identifying the logical table"
Does this mean that if there are any logical (labeled) tables, that ALL tables must have a label? Currently, my code iterates through the text file until it comes to a normal entry. If there is no current logical table and it didn't find a label, it assumes this is the 'default' table and makes a dictionary for it. It stays in that dictionary until it comes upon a new @ label and creates a new one, etc.

Per the table spec, should there be allowed to be an unlabeled default/main table and then labeled extra logical tables, or should ALL tables be required to have a label?


You only need to label a table with a TableIDString line if there is an explicit table switch entry that uses it. Thus, it would be allowed to have an unlabeled main table and labeled additional tables assuming none of the additional tables had any table switch entries that called the main table (usually wouldn't happen in most games). It's probably best practice to label all your tables though. Additionally, myself and the few others I know that have implemented this table switching stack use labels internally anyway. So, even if you didn't explicitly define one, some kind of default label is given to tables that do not have it.

Quote:
Thanks for all the work everyone did in publishing this document. It makes things both easier for me and more challenging, as half my work has been done with a usable tbl format and as I have to make everything compliant! Smiley


Yes, a table implementation meeting this standard is more challenging and more work because so much additional behavior is now defined. There are more rules and features. I guess that's the nature of standardization though. Without it, everybody rolls their own different table spec to suit their needs. Much behavior is undefined, extended, or outright ignored.
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
RyogaMasaki
Peasant
*
Offline


I Love TransCorp!

Posts: 6
Re: Project - Table File Standard
Reply #63 - Jan 15th, 2013 at 10:46pm
 
As for comments, I've used them for basic metadata, like a source URL or a log of 'version' updates to the file. It could also be used to declare that the file is Table File Spec compliant, so end users are aware of the specifics of the file (i.e. so they don't open a new spec file in Translhexation or something).

Also, I'm working on implementing Table Switching tonight, and I have a question. I initially misread the document, and assumed that all logical tables exist in one table file, in a format like this:

Code:
(start of file)
xx=entry
xx=entry
xx=entry
@NewID1
xx=entry
xx=entry
xx=entry
@NewID2
xx=entry
xx=entry
(End of file) 



Meaning all logical tables exist in one text file, with an unnamed (but named internally) 'main' table, and then named logical tables to branch into.

However, looking closer at the spec ("Support of multiple table files...", "Only a single logical table per table file is allowed"), are you saying that each table file can only hold one logical table? As in, for the above example, there would need to be three files (main and the two branches)? If that is the case, it sort of makes things needlessly complicated when everything can be neatly sorted in one file. Maybe I'm not experienced enough, but I can't imagine a scenario where all the logical tables couldn't be stored in one text file.
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #64 - Jan 16th, 2013 at 9:53am
 
RyogaMasaki wrote on Jan 15th, 2013 at 10:46pm:
As for comments, I've used them for basic metadata, like a source URL or a log of 'version' updates to the file. It could also be used to declare that the file is Table File Spec compliant, so end users are aware of the specifics of the file (i.e. so they don't open a new spec file in Translhexation or something).


It's probably too late to add something like this now unless it was comments on their own line only. Allowing commenting on the same line as an entry would have many implications in parsing, rules, and text sequence restrictions. That's probably out. However, allowing comments on their own line would have little impact.

Quote:
However, looking closer at the spec ("Support of multiple table files...", "Only a single logical table per table file is allowed"), are you saying that each table file can only hold one logical table?


Correct. Majority vote was for allowing only one logical table per table file on grounds of added complexity with almost no gain. In addition to that, your example totally breaks the fact that the table standard does not rely on manual ordering of entries in any way. Your example relies exclusively on manual ordering. Move one of those TableID lines and the encoding changes entirely. Another thing that went into it was ease of upgrading existing software such as Atlas and TableLib. You are probably already familiar with one or the other.  Klarth's (creator of Atlas) had much input on the standard and modifying Atlas to accept the new spec is critical to any real adoption of the standard. A number of things like I've described were considered when that decision was voted on.
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
RyogaMasaki
Peasant
*
Offline


I Love TransCorp!

Posts: 6
Re: Project - Table File Standard
Reply #65 - Jan 16th, 2013 at 8:53pm
 
Nightcrawler wrote on Jan 16th, 2013 at 9:53am:
However, allowing comments on their own line would have little impact.


Yes, sorry, I should have been more clear: the comments I use are on their own line entirely. They cannot be added to the same line as an entry or table ID.

Now, in reply to multi-file tables, I don't want to seem argumentative. I just want to have a firm understanding before I go further with my table code. Take this obviously broken example table, modified from section 2.5.3

Code:
@HIRA        Found an @, check if HIRA already exists in our collection of LogicalTable objects, if not create a new one with that ID, switch Current Table to HIRA
00=あ                Add these entries to the dictionary in the HIRA object...
01=い
02=う
03=[PlayerName]     (This example entry is in the spec in sect 2.5.3 but as far as I can tell it's an illegal entry from [ and ] in the text of a normal entry)
!F8=[KATA],0        Add F8 to Switch list in HIRA object
!F9=[KANJI],0       same for F9
!FA=[SUBSTRINGS],0  same for FA

@KATA               Found an @, check for KATA object, create if none, switch Current Table to KATA
00=ア                 Add to KATA...
08=セ
02=ウ               Order of entry keys doesn't matter,
01=イ                it will check if they exist before adding them,
05=サ                and throw an error if they exist already in this table
09=ソ
04=オ
06=シ
0A=カ
03=エ
07=ス
!F8=[HIRA],0      Add F8 to the Switch list in KATA object
!F9=[KANJI],0     Same for F9

@KANJI            Create KANJI logical table if it doesn't exist, switch Current Table to KANJI
00=亜             Add entries to Current Table...
01=意

@HIRA             Create HIRA if it doesn't exist, switch Current Table to HIRA
03=え              Add to Current Table...
04=お
05=さ
06=し
00=あ              ERROR: entry 00 is already in dictionary of object HIRA, abort reading the file
01=い
07=す
(EOF)            End of file, check through Switch lists of all log. tables and make sure any table references have associated objects, if not, prompt for other table file 




This table file is problematic in several ways, but I want to use it to exemplify how I'm parsing the table. The table finds @HIRA and creates a Logical Table object with its own dictionary and lists keeping track of which entries are control codes, end codes, and table switches. The dictionary is populated with the entries, including F8-FA, which are also added to the TableSwitch list. After reading the entire file, it will check the TableSwitch list and make sure any IDs referenced have a matching Logical Table object. If not, that Table ID was not encountered in the table file. So, prompt the user for another file with the proper Table ID. In that way it supports the spec of multiple files as well as multiple logical tables in one text file. In the case above, it finds KATA, KANJI and HIRA objects but not SUBSTRINGS. It would then prompt the user for a table with an @SUBSTRINGS identifier.

You wrote that my example in the last post "relies exclusively on manual ordering." I'm not certain I understand what you mean by that. The bytes can be in any order inside a logical table, since they are stored as a collection. They must only be unique within that logical table. There is a certain manual order in that the text file is being read sequentially. This is key to how my method parses the file, as it work on the premise of "Work on current table -> find @ -> change current table to new Table ID -> continue work on current table." Basically, could you explain more about what you mean by relying on manual ordering?

I don't mind supporting multiple files for a table, especially if it's to support Atlas/TableLib (neither of which, honestly, I'm familiar with; I only did text hacking on a small number of games, with things like Translhexation and Thingy, several years ago). But I still don't understand how having it one physical file is 'added complexity.' Then again, I've only worked with dumping text. Is there some aspect of reinserting text that plays a part in this compexity that I'm not realizing? Would it be possible to support both multi-file and single-file instead of one or the other exclusively?

Thanks for taking the time to answer my questions. I have a request though. Would you mind sharing any spec compliant tables you have, especially one with table switching? Just to run through my own code and see what happens. I understand if you don't want to share something like that though. Smiley
Back to top
« Last Edit: Jan 17th, 2013 at 5:40am by RyogaMasaki »  
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #66 - Jan 17th, 2013 at 8:37am
 
Yes, I understand how you were parsing your single file containing multiple logical tables.

RyogaMasaki wrote on Jan 16th, 2013 at 8:53pm:
There is a certain manual order in that the text file is being read sequentially. This is key to how my method parses the file, as it work on the premise of "Work on current table -> find @ -> change current table to new Table ID -> continue work on current table." Basically, could you explain more about what you mean by relying on manual ordering?

You wrote that my example in the last post "relies exclusively on manual ordering." I'm not certain I understand what you mean by that. The bytes can be in any order inside a logical table, since they are stored as a collection. They must only be unique within that logical table.


That's exactly the ordering I was talking about. Move '@KATA' and you change the map entirely. There is no manual ordering of any kind required in the current table spec. That was my point.

Quote:
But I still don't understand how having it one physical file is 'added complexity.' Then again, I've only worked with dumping text. Is there some aspect of reinserting text that plays a part in this compexity that I'm not realizing? Would it be possible to support both multi-file and single-file instead of one or the other exclusively?


This is a tall order question. I would suggest you browse through the topic here and over at RHDN for discussions on some of the intricacies of table switching. It is a complex subject, especially when it comes to insertion. In addition, I'd advise taking a look at Atlas to understand what it does and browse the source a bit. This standard was developed over a course of a year or two. I can only tell you what majority voted for and some of the reasons cited that I noted or recall. The rest is in the details spread out over time in the topics or lost in the event discussion was had in PMs.

Atlas
Table Lib

Quote:
Thanks for taking the time to answer my questions. I have a request though. Would you mind sharing any spec compliant tables you have, especially one with table switching? Just to run through my own code and see what happens. I understand if you don't want to share something like that though. Smiley


I haven't needed table switching for the games I've been working on since this was developed. I think you can find some real brain twisting examples in the topic over at RHDN though for table switching. I think some very evil cases were crafted to test with there. Beyond that since, TextAngel does not reflect the latest draft, my current practical tables and my test table do not either. They're hybrid. It's been a messy affair to simultaneously develop a standard, utility, and work on games that utilize both. Constant WIP state until things start to get finished! Smiley
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
RyogaMasaki
Peasant
*
Offline


I Love TransCorp!

Posts: 6
Re: Project - Table File Standard
Reply #67 - Aug 24th, 2013 at 2:53pm
 
Hi again! I posted several months ago about adopting the table spec for a utility I was writing. Well, I've put the first public version up for download, with partial support for Nightcrawler's spec. I'll be continuing to work on the program, with the goal of eventually having 100% support for the table file spec, but I'm releasing a public version for now to get some feedback and bug reports. If anyone gives it a go, I'd appreciate any comments!

You can get it here: sudden-desu.net/dumpster/
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #68 - Sep 1st, 2013 at 12:42pm
 
That's great to hear! Are you planning on releases the source to ROMlib?

Unfortunately Dumpster doesn't even start on my computer. An unhandled win32 exception occurred in Dumpster.exe. (4668).  Sad

What .NET version does it target?
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
RyogaMasaki
Peasant
*
Offline


I Love TransCorp!

Posts: 6
Re: Project - Table File Standard
Reply #69 - Sep 3rd, 2013 at 9:58am
 
Huh, that sucks.. It targets 4.5, I don't think I can make it any lower (easily...) as I'm using some 4.5 stuff. Anyway, it's my first 'real' program so I'm sure I just missed something. What OS are you running?

Yes, I would like to open the source to both ROMlib and Dumpster, and certainly will, but for right now, as a personal project, there's more I want to add and clean up before presenting to the world.
I wrote the code for importing your table pretty early on, back in January and February, then got sidetracked with the graphics and such. Kind of had to just give myself a little refresher, haha. It currently supports control codes, end tokens and standard entries. It parses out named logical tables, but doesn't support the table switching tag ! and does multiple logical tables per one file. It could probably be a bit more strict and of course I want to have a mode for 100% spec compliance; I've just done it 'my way' for the development. Finishing the proper support is up there on the to-do list.
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #70 - Sep 4th, 2013 at 6:24pm
 
That's probably what it is. I only run 4.0. You can probably check for that and/or catch the exception rather than a crash on start-up.

What on Earth are you using that you require from 4.5 for a ROM hacking utility? That's virtually a Windows 8 exclusive release.
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
RyogaMasaki
Peasant
*
Offline


I Love TransCorp!

Posts: 6
Re: Project - Table File Standard
Reply #71 - Sep 6th, 2013 at 12:39am
 
Nightcrawler wrote on Sep 4th, 2013 at 6:24pm:
What on Earth are you using that you require from 4.5 for a ROM hacking utility? That's virtually a Windows 8 exclusive release.

http://blogs.msdn.com/b/dotnet/archive/2012/04/03/async-in-4-5-worth-the-await.a...

The async/await functions. Honestly, they're not 'necessary' on reasonably sized files, so I can make a version targeted at 4 without async, or using the old method.
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #72 - Sep 10th, 2013 at 5:46pm
 
Out of all the ROM hacking applications I've made in .NET, none of them ever required features beyond .NET 2.0 Tongue
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
Kef Schecter
Peasant
*
Offline


I Love TransCorp!

Posts: 1
Re: Project - Table File Standard
Reply #73 - Dec 22nd, 2013 at 11:19pm
 
I'm writing a Python library to implement this standard (and probably support legacy TBL formats too), but I think the table switching feature is, well, a bit nutty. Yes, I see the value of it and I understand why it's there. But it introduces lots of complexity, especially when inserting. It confounds writing an "optimal path" algorithm, and you have to jump through hoops just to recognize when you need to switch tables. While I don't think the feature is a mistake per se -- it's definitely nice to have a standard way to handle the problems this feature is designed to tackle -- I think requiring it for compliance is. Rather, I think it should either be deferred to a 1.1 standard or be made a separate extension to the standard.

As it stands, I currently have no plans to implement this feature in my library.

I also strongly disagree with the idea of forcing each logical TBL to be in its own .tbl file. In my opinion, this is exactly backwards -- each .tbl file should be a complete unit that doesn't require any additional files to work. That way you can load just one .tbl file and be done with it.

I think we should have a place where we can hammer out the standard, including a complete record of arguments for and against everything, and get it to everybody's satisfaction and, perhaps even more importantly, get it beyond a draft that nobody really uses. Maybe it should be on some kind of wiki or something.


Finally, there are a few minor errors in the standard.

In section 2.5:

Quote:
Labels should consist only of digits [0-9A-Za-z].


A-Z and a-z are not digits. It should say "characters".

In section 3.2:

Quote:
!7F=[Dakuten,]-1


Surely the comma should be after the bracket, not before it?

In the same section:
Quote:
When "7F" is encountered in Table 2, so fallback to Table 1 will occur.


This is not grammatical; the "so" should be removed.


4.2 and 4.3 mention "Linked Entries", but this term occurs nowhere else in the specification and it is not clear what it means.
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3304
USA
Gender: male
Re: Project - Table File Standard
Reply #74 - Jan 5th, 2014 at 7:15pm
 
I agree utilizing table switching for insertion can be a complex subject. It's a big part of the additional functionality this standard brings and standardizes. I highly advise reading through this topic where this is discussed in great detail, and how it developed into what it is:

http://www.romhacking.net/forum/index.php/topic,12644.0.html

You should not need optimal path. The rules and limitations put in place toward the end greatly reduced many of the complexities in table path finding. Take a look through the topic linked above. Back-peddling on that now would be defying the majority and cutting a leg out from under it. Even if you did need optimal path, as I was told when I mentioned complexity exactly as you have, why should everyone be held back simply because one guy can't grasp an algorithm? A little harsh I know, but I guess it makes some sense.

Quote:
Correct. Majority vote was for allowing only one logical table per table file on grounds of added complexity with almost no gain. In addition to that, your example totally breaks the fact that the table standard does not rely on manual ordering of entries in any way. Your example relies exclusively on manual ordering. Move one of those TableID lines and the encoding changes entirely. Another thing that went into it was ease of upgrading existing software such as Atlas and TableLib. You are probably already familiar with one or the other.  Klarth's (creator of Atlas) had much input on the standard and modifying Atlas to accept the new spec is critical to any real adoption of the standard. A number of things like I've described were considered when that decision was voted on.


See this passage from a few posts up on why table files were restricted to one logical table per file. There are a number of reasons. Another majority vote that  I can't really back-out on now. However, it is certainly something to be considered (and that I'd probably support) for a 1.1 version later on.

There's nothing left to really hammer out. The content was deemed finalized and already a satisfying compromise amongst the consortium after 2 years of discussion. There's no way a wiki would ever work. You'd never reach a large scale public consensus. That's why hardly anything has ever been standardized in ROM hacking. Just as you come and disagree with pieces of this standard, another would always come and disagree with you. You have to draw a line somewhere or discussion and disagreement goes on indefinitely. At least with a small group, compromises truly can be made and a satisfying conclusion reached. You've already declared you don't want to follow the standard, offer no table switching compromise, so you are really opposing efforts as much as anything.

It's been stuck at draft mostly because I never finished TextAngel and Klarth never updated Atlas. I never wanted to officially release the standard without utilities to to use it or it would probably flop. If TextAngel was released and Atlas was modified, it would most likely certainly succeed. Neither of which has happened yet, so we're in limbo.

Most of the discussion can still be found in this topic and the topic at RHDN. There was other discussion via PMs (that I no longer have now), but I think that was much less so and usually with Klarth regarding Atlas. So, much of it is available to delve into. There so little interest in something like this that I don't think it's worthwhile to do anything special with it. One or two new people per year are interested enough to discuss it.

Thanks for pointing out the errors. I will work on correcting them. Linked Entries are a residual concept from a previous version that does not exist anymore. It was further developed into what is now Control Codes.
Back to top
« Last Edit: Jan 6th, 2014 at 7:55pm by Nightcrawler »  

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
Pages: 1 ... 3 4 5 
Send Topic Print
(Moderator: Nightcrawler)