Wookie Posted November 13, 2009 Share Posted November 13, 2009 I am now officially renaming NESHLA to be 65HLA. The goal is to refactor and abstract the NES-specific code in NESHLA so that we can add in Lynx-specific code and make 65HLA support both systems/processors. I forked my neshla repo to a new repo for 65HLA: http://www.bitbucket.org/wookie/65hla. I have some people who have volunteered to help work on 65hla to add Lynx support. If you would like to help, you are welcome to. You can clone the repo and send me patches or you can set up a bitbucket account and I'll add you as a writer to the repo. Either way, your help would be greatly appreciated, no matter how small a contribution it is. I'm currently looking for people to test the build process on Mac OS X and Windows/cygwin. If you test it out, please post your results here or send me a private message. --Wookie Quote Link to comment Share on other sites More sharing options...
gravitone Posted November 16, 2009 Share Posted November 16, 2009 I am now officially renaming NESHLA to be 65HLA. The goal is to refactor and abstract the NES-specific code in NESHLA so that we can add in Lynx-specific code and make 65HLA support both systems/processors. I forked my neshla repo to a new repo for 65HLA: http://www.bitbucket.org/wookie/65hla. I have some people who have volunteered to help work on 65hla to add Lynx support. If you would like to help, you are welcome to. You can clone the repo and send me patches or you can set up a bitbucket account and I'll add you as a writer to the repo. Either way, your help would be greatly appreciated, no matter how small a contribution it is. I'm currently looking for people to test the build process on Mac OS X and Windows/cygwin. If you test it out, please post your results here or send me a private message. --Wookie I grabbed the current source using mercurial, Once I have a GCC toolchain running on this box I'll compile and give it a try. As there's many users still using windows here, I'm considering cleaning up the visual studio project files from the original NESHLA and making a build. It's just not really on my priority list right now so it might take a while. Quote Link to comment Share on other sites More sharing options...
Wookie Posted November 16, 2009 Author Share Posted November 16, 2009 I grabbed the current source using mercurial, Once I have a GCC toolchain running on this box I'll compile and give it a try. As there's many users still using windows here, I'm considering cleaning up the visual studio project files from the original NESHLA and making a build. It's just not really on my priority list right now so it might take a while. That would be great if you maintained the Windows compatibility. --Wookie Quote Link to comment Share on other sites More sharing options...
Wookie Posted November 20, 2009 Author Share Posted November 20, 2009 I've begun a massive refactoring effort to abstract the target system specific logic in the 65hla compiler. That means developing an interface that abstracts away all of the NES logic so that I can also create a parallel Lynx implementation. I've already got the preprocessor split and abstracted. There is a set of common preprocessor directives such as #define, #ifdef, etc that stayed in the main compiler. The NES specific preprocessor directives such as #ines.*, #interrupt, etc have been moved into the NES system code. I have also started reorganizing the system specific code into subfolders for each system. There is a NES folder and a Lynx folder. There is a lot of code to move and it will take some time but the 65hla compiler will become a generic HLA (high level assembler) for 6502 machines eventually. --Wookie Quote Link to comment Share on other sites More sharing options...
ThomH Posted January 9, 2010 Share Posted January 9, 2010 On OS X v10.6.2 with the latest Apple developer tools (featuring Xcode 3.2.1) and nothing else installed I first get: thomas-hartes-macbook-pro-15:65hla thomasharte$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating config.h config.status: executing depfiles commands thomas-hartes-macbook-pro-15:65hla thomasharte$ make make all-recursive Making all in src gcc -DHAVE_CONFIG_H -I. -I.. -g -O0 -MT banks.o -MD -MP -MF .deps/banks.Tpo -c -o banks.o banks.c In file included from banks.c:11: compiler.h:25:20: error: malloc.h: No such file or directory make[2]: *** [banks.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Commenting out the reference to malloc.h in compiler.h causes a successful build of 65HLA. The man pages (both BSD and Linux) identify the relevant header file for use of malloc to be stdlib.h, and you're including that already, so I didn't need to add anything. I'm subsequently able to build the example NES game. I downloaded a NES emulator to test and verified it to be a "Hello, World!" app. The version of 65HLA I downloaded was that given by the "get source" link in the top right of http://bitbucket.org/wookie/65hla/. Possibly also helpful, I get the following reported for gcc -v: Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1 --host=i686-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) Quote Link to comment Share on other sites More sharing options...
Wookie Posted January 12, 2010 Author Share Posted January 12, 2010 Commenting out the reference to malloc.h in compiler.h causes a successful build of 65HLA. The man pages (both BSD and Linux) identify the relevant header file for use of malloc to be stdlib.h, and you're including that already, so I didn't need to add anything. I'm subsequently able to build the example NES game. I downloaded a NES emulator to test and verified it to be a "Hello, World!" app. The version of 65HLA I downloaded was that given by the "get source" link in the top right of http://bitbucket.org/wookie/65hla/. Awesome, I'll remove the malloc.h include. So were you able to build the NES game and get it to run in an emulator? I can't tell from what you posted. NOTE: the support for the Lynx is currently a long ways off. I've been concentrating on abstracting away all of the NES specific stuff behind subsystem interfaces. That way I can make Lynx specific implementations for those pieces and gain Lynx support. I can always use some help. The entire NESHLA compiler was written with just the NES in mind so there is lots of refactoring to do. I've been using the demo NES game as the main test to make sure I don't break NES support as I move stuff around. Thanks for the feedback/bug report. --Wookie Quote Link to comment Share on other sites More sharing options...
Wookie Posted January 12, 2010 Author Share Posted January 12, 2010 (edited) Commenting out the reference to malloc.h in compiler.h causes a successful build of 65HLA. Thanks for the bug fix. I just applied it and checked in the new revision: http://bitbucket.org/wookie/65hla/changeset/ad1d23a6c0fe/ If you want to hack on the code to help out, create a bitbucket account and I'll add you as a writer so that you can push your changes back to the repo. --Wookie Edited January 12, 2010 by Wookie Quote Link to comment Share on other sites More sharing options...
ThomH Posted January 13, 2010 Share Posted January 13, 2010 Sorry for being unclear - I was able to build and run the NES demo app without any hiccups. Looks like a really good tool by the way, I'll look forward to Lynx support. Quote Link to comment Share on other sites More sharing options...
Wookie Posted August 25, 2010 Author Share Posted August 25, 2010 BTW, I abandoned this effort and decided to re-implement NESHLA in Python to make it more portable and easier to hack on. So officially 65HLA is dead. It is replaced with my HLAKit project that I've been working on for the past year. HLAKit is getting pretty close to working. The only thing left is the code generator, which I'm working on now. You can find the HLAKit repo here: http://bitbucket.org/wookie/hlakit I am also maintaining a programmer's manual for HLAKit here: http://bitbucket.org/wookie/hlakit/wiki/Home --wookie Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.