8 replies to this topic

[Wookie]

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

[gravitone]

Wookie, on Fri Nov 13, 2009 11:23 AM, said:

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.

[Wookie]

gravitone, on Mon Nov 16, 2009 11:56 AM, said:

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

[Wookie]

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

[ThomH]

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)

[Wookie]

ThomH, on Sat Jan 9, 2010 12:57 PM, said:

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

[Wookie]

ThomH, on Sat Jan 9, 2010 12:57 PM, said:

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...t/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 by Wookie, Tue Jan 12, 2010 2:39 PM.

[ThomH]

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.

[Wookie]

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...lakit/wiki/Home

--wookie