Recompile FAT in FAT Engine and Related Stuff Forum

RSS
Email

0 Points

Recompile FAT

Author	Comment
Kimbett	Recompile FAT	Lead	[-]
Posts: 208 2009-02-02 01:43:38 Reply Quote More My Recent Posts	Lionel, (or Scott or Tom if you guys are still around) I am having a horrendous time recompiling FAT 1.21b, Tom's documentation mentions that compiling the sources haven't been tested outside of TIGCC v0.93, so where would I even find v0.93? Have you ever gotten FAT to compile on the latest TIGCC? Thanks. -Jeff
	Remove this ad
Lionel Debroux		#1	[-]
Posts: 3180 2009-02-02 08:28:23 Former Admin Reply Quote More My Recent Posts	> so where would I even find v0.93? Ask Kevin, he's kept all versions of TIGCC since way before 0.93. > Have you ever gotten FAT to compile on the latest TIGCC? No, I've never tried recompiling FAT with the 0.95 or 0.96 series... Something in the 0.94 series didn't work for Thomas (pessimized or plain incorrect code, IIRC), I never investigated on the problem. All I did for 89T support (1.22 Beta), apart obviously from the 89T-compatible launcher code, were backwards-compatible changes, visible to the client: addition of __attribute((__stkparm__)) to function prototypes to maintain backwards binary compatibility of the FAT Engine, while making it possible for client programs to use -mregparm. [EDIT: BTW, why would you like to recompile FAT ? Did you change something in the non-client part of the FAT code ?] Last Edited By: Lionel Debroux 2009-02-02 09:51:05. Edited 1 times.
Kevin Kofler		#2	[-]
Posts: 7177 2009-02-02 11:12:24 Admin Reply Quote More My Recent Posts	Normally TIGCC is backwards-compatible. The FAT Engine may be using some unportable hacks though. (I haven't found anything obviously broken by a cursory look through the source code though.) What's the precise issue you're having when building the FAT Engine with TIGCC 0.96 Beta 8?
Kimbett		#3	[-]
Posts: 208 2009-02-05 05:23:15 Reply Quote More My Recent Posts	Hey guys, Well, I've been looking around for TIGCC v0.93 and FAT 1.22 and come up with nothing. Can any of you help me out? Lionel: I am actually trying to recompile the original FAT sources in order to remove some code that C99 doesn't use (tex maker), and replace it with the FAR more ram friendly Patching system written for C99. If it works, and Tom doesn't mind me releasing the improved engine, I'll write up documentation, craft a few demos and release it. This would also free up a large chunk of code space from C99 client side and would fit within the remaining code space in FAT 1.22. -Jeff
Lionel Debroux		#4	[-]
Posts: 3180 2009-02-05 08:11:18 Former Admin Reply Quote More My Recent Posts	> Well, I've been looking around for TIGCC v0.93 and FAT 1.22 and come up with nothing. Can any of you help me out? http://tict.ticalc.org/downloads/fat.zip contains FAT 1.22 Beta. This link has probably been posted somewhere in this section, but I can't blame you for not digging through the topics. In order to get TIGCC 0.93 for testing purposes, ask Kevin > Lionel: I am actually trying to [...] OK. That makes sense, though it will make Corridor 99 incompatible with other existing FAT Engine clients. From the other topic you created ( http://tichessteamhq.yuku.com/topic/4678 ), I gather that you changed the build system from batchfiles to TPRs. Why ?
Kimbett		#5	[-]
Posts: 208 2009-02-06 00:30:50 Reply Quote More My Recent Posts	Well, the batch didn't work... so, I tried the TPR approach. Interestingly, I get no errors with the TPR after I drag and drop the included C files, but the whole shebang compiles to about 144 bytes... The batch file dies early: C:\Projects\C99\fat>echo Generating FATLIB.DLL ... Generating FATLIB.DLL ... C:\Projects\C99\fat>tigcc -Wall -W -Wwrite-strings -O3 fat.c fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x2754. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x278A. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x28B8. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x28E4. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x2A32. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x2A54. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x2AE0. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x2B16. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x2C3A. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x2C66. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x324E. fat.o: Error: Symbol `TransScalerJumpTable' too far for size 2 reloc at 0x3270. Now, I haven't a clue why this code doesn't work... I'm hoping that by compiling with V0.93 it will simply work and I'll be able to move on to more fruit baring endevours. True, the use of a custom FAT will break compatibility, but it may also become far more useful to current and future FAT users. The amount of RAM consumed by sprites is up to 25% less when used with my texture system. When cached in flash memory, this means it takes less time to load, and consumes up to 25% less flash as well. It'll be worth it.
Lionel Debroux		#6	[-]
Posts: 3180 2009-02-06 08:29:09 Former Admin Reply Quote More My Recent Posts	The error is due to TransScalerJumpTable being stored more than 32767 bytes away from some places of the program that use it. I think the reason why that didn't happen with TIGCC 0.93 is that at the time (GCC 3.x), -O3 optimization didn't blow up size too much. Since then, GCC 4.0 and 4.1 have increased the difference between -Os, -O2 and -O3, to the point that -O3 is barely usable on our embedded platform (despite, IIRC, Kevin reducing the settings of -O3 to limit the impact on size and creating a -O4 option). Before GCC 4.x, TI-Chess used -O3 for the engine. I had to change it to -O2, otherwise the program's uncompressed size (and therefore memory requirements) went up by at least 5 KB, IIRC. Try reducing from -O3 to -O2, and most of all, adding --optimize-code --cut-ranges --reorder-sections -ffunction-sections -fdata-sections --merge-constants -fmerge-all-constants -Wa,--all-relocs to the tigcc invocation: the section reordering will probably help. IMO, we'd better improve the batchfiles (judging by the number of calls to tt* tools, I don't think we can get rid of build scripts completely anyway), and add equivalent *nix building scripts in the process, than switch to TPRs. I switched several TICT projects to TPRs before I noticed / learnt of their drawbacks. Most projects I switched to TPRs aren't hit by the limitations, though I had to contribute an improvement to tprbuilder in order to make TICT-Explorer maintainable. However, between others, TI-Chess wasn't switched to TPRs, because TPRs make it hard to make something as simple as compiling most files with -Os, and one file with -O2.
Kevin Kofler		#7	[-]
Posts: 7177 2009-02-06 21:39:25 Admin Reply Quote More My Recent Posts	To get your TPR to work, you have to uncheck "Remove unused sections" in the linker options. The linker doesn't understand that the sections are used.
Kimbett		#8	[-]
Posts: 208 2009-02-07 17:23:03 Reply Quote More My Recent Posts	Lionel, O3, O2, Os, no matter what I do, I can't get it to not hang up on the TransScalerJumpTable. I would like to be able to compile via command line though, but for now the TPR method is working. Kevin, After some tweaking and not "Removing unused sections" I got it to work perfectly with TIGCC 0.96b8! Os is approximately the same size as when compiled in 0.93. It is about 2K heavier with O2, 4K heavier with O3 though both seem to run the same speed through TiEmu. I need to test on real hardware, but FAT seems to run slightly faster when compiled with 0.96b8 no matter what the O setting. This is definately good progress. I'll keep you posted.
	Remove this ad
Lionel Debroux		#9	[-]
Posts: 3180 2009-03-09 10:31:04 Former Admin Reply Quote More My Recent Posts	Ping ?
Kimbett	Progress	#10	[-]
Posts: 208 2009-03-23 04:10:20 Reply Quote More My Recent Posts	Lionel, Sorry for the silence... guess I was waiting for a good point to stop and make announcements. Well, for starters, I moved about 10K worth of code (entire patching compression) over to the FAT engine DLL. With some breathing room, I fixed a few reckless bugs that had plagued many TI-89 users (a majority of the users!) I also modestly reduced the RAM required to run C99, added some new graphics, pushwalls, quake-style doors (sink-in-slide) and linked triggers (allow an open door to trigger another event... these can be chained together to open entire walls and allow for some nasty surprises) I added a few new cinematics (at least one should bring a chuckle to anyone who frequents this board.) I kept the save-costs-one-life thing that everyone hated, but I added a 1UP to practically every level if you're willing to search for it. The easiest difficulty setting yields this cost. The level count is now up to 20 of the 40 planned. Most of the remaining levels are already made, but will probably be remade to take advantage of the slew of new features. The biggest: Sometimes the computer terminals are required (open doors, dispense keys, etc.) so you won't accidentally bypass important story bits like with the C99 Demo in 2005. At this point, I have about 5K of code space left in the C99exe, and 10K or so left in FAT, but there isn't much left that 'belongs' in FAT. I'd rather keep the changes I make to FAT improve the engine, and not just use the DLL as a storage bin for C99 code. I'll have to ask Tom, but the features I have added would make excellent additions to the engine IMHO as they drastically reduce the amount of RAM and flash graphics consume on the calculator. With this 5K of code left, I still need to separate the menu / cinematics / gameplay systems into their own exe's and chain them together. When I do that, it should have the added effect of further reducing the RAM requirements as the running exe's would be smaller, and I'll be able to take a real look at sound and multiplayer finally. There are many enemies that have existed in the code and graphics for years that haven't seen the light of day until recently, so it's been pretty exciting. I'm not quite ready for beta testing yet, but if anyone wants to try and hunt bugs in the alpha for me email me at destarus04 <at> yahoo <dot> com Thanks, Jeff Oh and I almost forgot, if anyone would like to host a simple website, I'd love to post pictures and other C99 development stuff there. I've actually gotten pretty good at HTML now, just don't have a web domain to post to. Any charitable takers? Last Edited By: Kimbett 2009-03-23 04:14:54. Edited 1 times.
Lionel Debroux		#11	[-]
Posts: 3180 2009-03-23 14:26:13 Former Admin Reply Quote More My Recent Posts	Wow. LOTS of good work, congratulations > I'll have to ask Tom, but the features I have added would make excellent additions to the engine IMHO as they drastically reduce the amount of RAM and flash graphics consume on the calculator. From the list of new features you've given, I'd agree. > Oh and I almost forgot, if anyone would like to host a simple website, I'd love to post pictures and other C99 development stuff there. I've actually gotten pretty good at HTML now, just don't have a web domain to post to. Any charitable takers? TI-FR might do the job, but I don't know the specifics of getting something hosted there. Besides the TI-FR admin, of course, Kevin probably knows, since TI-Gen is now hosted there.
Thomas Nussbaumer		#12	[-]
Posts: 1696 2009-03-24 13:46:16 Admin Reply Quote More My Recent Posts	> I'll have to ask Tom ... IMHO there is not much to ask for. The FAT engine project is otherwise orphaned and of no use to anyone.
Lionel Debroux		#13	[-]
Posts: 3180 2009-03-24 14:01:54 Former Admin Reply Quote More My Recent Posts	Hi Tom Actually, "of no use to anyone" is a bit excessive, given that there's at least another person currently developing a FAT-Engine-based game The person is AaroneusTheGreat, who posted a bit on this board as well, and the topic at http://tifreakware.ath.cx/index.php?showtopic=1042 . (though he lately wrote he's currently struggling with unspecified real life issues, so he doesn't really work on DOA at the moment). I know basically nothing about the FAT-Engine algorithm and implementation. The only changes I ever made to FAT-Engine didn't touch the engine functionality at all: __stkparm__, 89T loading code, and that should be everything I did.
Kevin Kofler		#14	[-]
Posts: 7177 2009-03-29 00:26:38 Admin Reply Quote More My Recent Posts	Basically, to get hosted on the ti-fr.com server, you just need to ask Vince. You'll of course get a subdomain of ti-fr.com as part of it. If you want your own domain name, you'll have to pay for it on your own. As another alternative, you can ask Tyler Cassidy for hosting on the calcforge.org VPS. There too, subdomains are easy to set up for free, if you want your own domain you'll have to pay for it.
Kimbett		#15	[-]
Posts: 208 2009-04-11 20:30:47 Reply Quote More My Recent Posts	Hello all, My C99 project website is finally back up nearly 7 years since C92's website went down. Not much there at the moment, but expect that to change. http://corridor99.tifreakware.net -Jeff
Lionel Debroux		#16	[-]
Posts: 3180 2009-04-12 06:51:38 Former Admin Reply Quote More My Recent Posts	Good to see you've found a home for Corridor 99 at TI-Freakware
	Remove this ad

Next Topic >>

Yuku free message boards

Recompile FAT

Recompile FAT