I've been pretty sidetracked lately but I finally got around to uploading the code for the Galaga Disassembly Project.
In order to rebuild the code and generate the ROM images for the program, you need to have a build environment with the asz80 assembler and sdcc compiler tools installed.
I've been working on and off on this project since 2001 (mostly off!). In 2001 I disassembled most of the code, primarily using MAME to analyze the code in the emulator and dump it to dis-assembly files. At the time I was building the resulting assembly code with a Z80 assembler that I had modified to support some of the undocumented opcodes. After a few months I moved on to other projects, and the project was not touched for some time.
In 2010 I got interested again after learning about the sdcc compiler. SDCC is interesting in that it targets the C language to many 8-bit micros. It is based on the asz80, which is a very advanced assembler and fairly unique in that it incorporates a linker. With this kind of compiler capability, I entertained the idea of porting the Galaga code to C on the original hardware Z80 architecture, but dropped that plan when I got interested in building C programs in gcc-m68k on the Genesis. I did a little work re-writing the Galaga code on the Genesis, but I doubt that will ever get completed. I've been looking a bit at SDL lately so maybe that's the direction I'll go.
The Galaga code is pretty fascinating in my opinion. Ideally I would have it translated to C, while preserving the structure and data organization as much as possible. We'll see what happens!
Thursday, August 9, 2012
Wednesday, July 25, 2012
Spice It Up
I do not go around trying to pass myself off as a EE, but embedded software development does require a fair amount of knowledge in electronics and I thought it was high time to brush up on my circuit analysis skills ...a professional improvement activity! We have a PSpice license at my work, but it is usually needed by our EE for working on the board layout. I went looking for an alternative and discovered LTspice. Sadly this is only available for Windows, but it is free, and seems to provide fairly complete SPICE functionality in a GUI environment. I thought I'd make a few notes from my learning activities.
The following circuit is extracted from the fueling controller for which I write software in my job as a Control Systems Engineer. I thought I understood the function of the circuit, but it caused me considerable grief and wasted time trying to demonstrate the expected behavior in LTSpice.
In the circuit, Vout is connected to the gate of an N-channel MOSFET and the gate voltage is controlled by the 5V signal at Vctl. The non-inverting input of the LM2903 is connected to a voltage reference of approximately 500mV established by the potential divider at the junction of R3 and R4. The inverting input of the 2903 would be connected to the signal Voc, such that the comparator is turned on by the presence of a voltage on Voc in excess of 500mV. The intent is that Voc would be connected to some other diagnostic or protection circuitry, and used to detect when the gate drive to the MOSFET (connected at Vout, not shown) should be disabled because of some kind of fault condition. My understanding is that it is the open-collector characteristic of the LM2903 output that enables this to work as intended. Although the comparator can't drive it's output high (allowing Vout to be 5V when Vctl pulse is high), the 2903 is nonetheless able to pull Vout low when the inverting input voltage exceeds the .5V threshold. In the example circuit, Voc is connected to ground, in order to force the comparator ON for the demonstration.
The output of the circuit is shown in the waveform trace. I believe the open-collector characteristic of the 2903 is not being correctly modeled, preventing Vout from being pulled to 0V when the Vctl pulse goes low. The LM2903 model was downloaded from the ON website.
The following circuit, when simulated, provides the desired behavior. Vout is pulled low by Vctl even though the 2903 output state is high. It uses an LM2903 model downloaded from the Texas Instruments website.
The following circuit is extracted from the fueling controller for which I write software in my job as a Control Systems Engineer. I thought I understood the function of the circuit, but it caused me considerable grief and wasted time trying to demonstrate the expected behavior in LTSpice.
In the circuit, Vout is connected to the gate of an N-channel MOSFET and the gate voltage is controlled by the 5V signal at Vctl. The non-inverting input of the LM2903 is connected to a voltage reference of approximately 500mV established by the potential divider at the junction of R3 and R4. The inverting input of the 2903 would be connected to the signal Voc, such that the comparator is turned on by the presence of a voltage on Voc in excess of 500mV. The intent is that Voc would be connected to some other diagnostic or protection circuitry, and used to detect when the gate drive to the MOSFET (connected at Vout, not shown) should be disabled because of some kind of fault condition. My understanding is that it is the open-collector characteristic of the LM2903 output that enables this to work as intended. Although the comparator can't drive it's output high (allowing Vout to be 5V when Vctl pulse is high), the 2903 is nonetheless able to pull Vout low when the inverting input voltage exceeds the .5V threshold. In the example circuit, Voc is connected to ground, in order to force the comparator ON for the demonstration.
The output of the circuit is shown in the waveform trace. I believe the open-collector characteristic of the 2903 is not being correctly modeled, preventing Vout from being pulled to 0V when the Vctl pulse goes low. The LM2903 model was downloaded from the ON website.
The following circuit, when simulated, provides the desired behavior. Vout is pulled low by Vctl even though the 2903 output state is high. It uses an LM2903 model downloaded from the Texas Instruments website.
Apparently it is "buyer beware" when using 3rd party models in SPICE!
Sunday, June 17, 2012
Definitive Galaga Disassembly Project Created
Finally got around to importing some files to an svn repository on Google Code. I could not get the authentication to go through using svn command line (in Cygwin). Eventually I got it to work in Tortoise SVN ... the winning recipe is copied here for my convenience:
Comment by nbutterworth1953@gmail.com, Jan 10, 2009
Here's how to import your project using TortoiseSVN, the most popular Windows SVN client.
I assume you have created your Google Code (GC) project and it is called PROJECT and that the local source you want import is in a directory tree rooted at SOURCE.
a) Go to your GC home page and select the "Profile" menu - this will give you your UID and then click the "Settings" tab to find your PASSWORD - this is not the same as your gmail password.
b) In Windows explorer, right click n your SOURCE directory to get the Tortoise context menu and choose "Import..." This will pop up a dialog asking for the repository url. Enter the following:
https://PROJECT.googlecode.com/svn/trunk
c) You will be prompted for a userid & password - enter UID and PASSWORD described above.
Your project should now be uploaded to the GC repository. From now on you can use the Tortoise repo-browser and other tools to access it via the url above.
We'll see if it generates any interest....
Comment by nbutterworth1953@gmail.com, Jan 10, 2009
Here's how to import your project using TortoiseSVN, the most popular Windows SVN client.
I assume you have created your Google Code (GC) project and it is called PROJECT and that the local source you want import is in a directory tree rooted at SOURCE.
a) Go to your GC home page and select the "Profile" menu - this will give you your UID and then click the "Settings" tab to find your PASSWORD - this is not the same as your gmail password.
b) In Windows explorer, right click n your SOURCE directory to get the Tortoise context menu and choose "Import..." This will pop up a dialog asking for the repository url. Enter the following:
https://PROJECT.googlecode.com/svn/trunk
c) You will be prompted for a userid & password - enter UID and PASSWORD described above.
Your project should now be uploaded to the GC repository. From now on you can use the Tortoise repo-browser and other tools to access it via the url above.
Thursday, May 3, 2012
PICOS18 on dsPIC
Porting application code to a new processor, the dsPIC33EP64. The present code base is from the dsPIC30, and we have a brand new board design.
Working from Code Example CE443, a simple demonstration of the Timer 1 interrupt, I could verify the operation of the board with the scope. Adding some extra test leads to the board is very necessary, as the chip pins are much too fine for probing! Any new PIC requires some time fiddling about with the configuration "fuses" to get the basic chip configuration straightened out. In this case, a matter of setting up for an external crystal with PLL, and also setting the specific pins for the ICD debugger.
I am actually running the dsPIC version of "PICOS18" and have now verified that all the basic OS timing.
Having now got the board alive and working, I now need to get the ECAN device driver setup, and then the board will begin to resemble something with slightly higher function than a mere brick!
Working from Code Example CE443, a simple demonstration of the Timer 1 interrupt, I could verify the operation of the board with the scope. Adding some extra test leads to the board is very necessary, as the chip pins are much too fine for probing! Any new PIC requires some time fiddling about with the configuration "fuses" to get the basic chip configuration straightened out. In this case, a matter of setting up for an external crystal with PLL, and also setting the specific pins for the ICD debugger.
I am actually running the dsPIC version of "PICOS18" and have now verified that all the basic OS timing.
Having now got the board alive and working, I now need to get the ECAN device driver setup, and then the board will begin to resemble something with slightly higher function than a mere brick!
Wednesday, March 7, 2012
More MegaDrive MegaFun
Last post was my notes for the build-your-own-Sega-Genesis-gcc-cross-compiler. Alternative is a pre-built kit if you are running on Windows. This one is actually much more than just the toolchain, as it is a library built around an SDK which has been in the works for a while.
Even though the sgdk is hosted in Windows, it is way easier to work with in Cygwin because the whole DOS environment is such an unwieldy piece of crap.
Now, after unzipping the download, run the following commands in your Cygwin shell:
export PATH=$PATH:/cygdrive/d/mYJUNK/sgdk/bin
cd /cygdrive/d/mYJUNK/sgdk/sample/cube_flat
make GDK="d:/mYJUNK/sgdk" -f ../../makefile.gen
The GDK environment variable will be propagated into the makefile. Note that it uses the DOS letter, but Unix-style forward slashes.
One clever thing about this is how he used make wild-carding to use the same makefile for all the examples.
Now, go get Quest for Money and compile it. This is a very nice game with beautiful graphics and sound layers, with all the source code included and detailed descriptions of how it was developed. Thanks to Shiru for promptly answering my questions!
Even though the sgdk is hosted in Windows, it is way easier to work with in Cygwin because the whole DOS environment is such an unwieldy piece of crap.
Now, after unzipping the download, run the following commands in your Cygwin shell:
export PATH=$PATH:/cygdrive/d/mYJUNK/sgdk/bin
cd /cygdrive/d/mYJUNK/sgdk/sample/cube_flat
make GDK="d:/mYJUNK/sgdk" -f ../../makefile.gen
The GDK environment variable will be propagated into the makefile. Note that it uses the DOS letter, but Unix-style forward slashes.
One clever thing about this is how he used make wild-carding to use the same makefile for all the examples.
Now, go get Quest for Money and compile it. This is a very nice game with beautiful graphics and sound layers, with all the source code included and detailed descriptions of how it was developed. Thanks to Shiru for promptly answering my questions!
Friday, March 2, 2012
--target=m68k-elf
More nerd-notes. Setting up m68k cross compiler in gcc under Cygwin to build some code for Sega Genesis.
I installed the dgen Genesis emulator in the MinGW environment by building it and SDL-1.2.15 from sources. I am interested in experimenting with using the GNU debugger, with the Genesis emulator as the target, by integrating dgen with the modified Musashi 68k core.
Building the m68k-gcc may be a problem in MinGW - my gcc build for --target=m68k-elf failed with errors on 'pipe' 'fork' 'sleep' 'fcntl' etc. I don't know enough about MinGW to know if there is a workaround. It could be that I need to download newer sources for gcc ... I am using binutils-2.20.1.tar.bz2 and gcc-core-3.4.6.tar.bz2. Why? because I did this about 2 years ago in Ubuntu and those were the files that worked for me then.
Alternatively, I should be able to run the m68k tools in Cygwin. My first binutils build in Cygwin blew up, but one update fixed it.
Here's a link to the setup that I followed, abeit with the file versions identified above, and changed coff to elf.
In addition, I found that the code I was building needed some standard C libraries and headers ... more on that later. I had a copy of newlib-1.12.0.tar.gz laying around so I built that with the same settings as binutils and gcc, i.e.
cd newlib-1.12.0/ ; ./configure --prefix=/usr/local/m68k --target=m68k-elf
So having done all that, the build is very close to complete, but there is one more error:
/usr/local/m68k/m68k-elf/lib/m68000//libmvme135.a(lseek.o): In function `lseek':
/cygdrive/d/tmp/m68k_cyg/newlib-1.12.0/m68k-elf/m68000/libgloss/m68k/../../../.././libgloss/m68k/../lseek.c:28: undefined reference to `__errno'
I hunted around for a second and did not find a tight solution, so I simply improvised and added the necessary definition to one of the C files in my sources:
int __errno;
... and now the make completes!
I installed the dgen Genesis emulator in the MinGW environment by building it and SDL-1.2.15 from sources. I am interested in experimenting with using the GNU debugger, with the Genesis emulator as the target, by integrating dgen with the modified Musashi 68k core.
Building the m68k-gcc may be a problem in MinGW - my gcc build for --target=m68k-elf failed with errors on 'pipe' 'fork' 'sleep' 'fcntl' etc. I don't know enough about MinGW to know if there is a workaround. It could be that I need to download newer sources for gcc ... I am using binutils-2.20.1.tar.bz2 and gcc-core-3.4.6.tar.bz2. Why? because I did this about 2 years ago in Ubuntu and those were the files that worked for me then.
Alternatively, I should be able to run the m68k tools in Cygwin. My first binutils build in Cygwin blew up, but one update fixed it.
Here's a link to the setup that I followed, abeit with the file versions identified above, and changed coff to elf.
In addition, I found that the code I was building needed some standard C libraries and headers ... more on that later. I had a copy of newlib-1.12.0.tar.gz laying around so I built that with the same settings as binutils and gcc, i.e.
cd newlib-1.12.0/ ; ./configure --prefix=/usr/local/m68k --target=m68k-elf
So having done all that, the build is very close to complete, but there is one more error:
/usr/local/m68k/m68k-elf/lib/m68000//libmvme135.a(lseek.o): In function `lseek':
/cygdrive/d/tmp/m68k_cyg/newlib-1.12.0/m68k-elf/m68000/libgloss/m68k/../../../.././libgloss/m68k/../lseek.c:28: undefined reference to `__errno'
I hunted around for a second and did not find a tight solution, so I simply improvised and added the necessary definition to one of the C files in my sources:
int __errno;
... and now the make completes!
Tuesday, February 7, 2012
Invincibility in Galaga
It's simple.... just disable the periodic task at address 0x05EE in the "slave" CPU ('sub' Z80 in MAME). That routine handles the collision detection, so if it isn't executed, the evil-mongers can shoot and ram you till doomsday with no effect. Rebuild the code and voila...
Subscribe to:
Posts (Atom)