Interesting what even a single e-mail can do.
Turns out I didn't update my e-mail address on these pages since I moved my account over to the UCLA Linux Users Group system. Also checked for dead/incorrect links. No real update to the codebase itself.
Minor revisionist (*cough*) editing of this page.
I've resumed development on my home machine.
But I lost my DSL connection (change of residence).
It's not coming back until November :(
BTW, I really have to insert a plug for
Quake III: Arena
and the class-based modification to it,
Weapons Factory Arena.
Summer flew by really quick with so much fun...
2000.11.02
2000.10.20
2000.06.19
Spending time to help on Hover Carnage.
Timer device turned out to be buggy this whole time, and has been thusly debugged. Many of the opcodes needed some touch-up because they were checking for 12-bit overflows incorrectly.
So, after finding my web page being the first search result on both Google and AltaVista, I gave my friend witten the green light to announce PHFC on Freshmeat. Nothing earth-shattering has happened since...
Started to implement interrupt handling. It appears to work flawlessly, but has not been checked against the original CUSP. It has only been tested on keyboard so far, but theoretically the other devices should work just as well. However, Lubarsky's Law of Cybernetic Entymology suggests that this is not so, and a full test suite is needed just to be sure of correctness.
phfc-0.22.tar.gz
Wow. Two releases in one day.
Biggest thing is that the memory protection/locking actually does something.
Namely, causes the CUSP CPU to shut down, dropping you back to the emulator
screen with a stopped CUSP machine.
Although '?' will bring up a basic help screen, not all keys are listed in
there.
Memory protection (read protect) is '-', while memory lock (write protect)
is '='.
The memory browser will show a symbol between Location and Content to indicate
protection state: '-' read-protect, '+' write-protect, '=' both.
I figured I may as well put up brain-dead instructions for *one* of the tests.
tape1.csp: 'make', 'cd test', '../src/spasm/spaz tape1.csp',
'../src/phfc/phfc', 'o', 'tape1.obj', 'P', 'hello.txt', 'r', 'q',
'cat hello.txt'.
It should say ``Hello, world.''.
phfc-0.21.tar.gz
Of note is that I've fallen sick.
Sore throat, lots of coughing, very thick mucus, and jammed sinuses.
IOW, I'm bed-ridden.
Which means lots of time at the keyboard.
That's supposed explain why it's been only a day since the last release.
Of significance is the debugging of the keyboard and changes in the
key-handling of the curses frontend.
This allows the "stuff a key into the CUSP keyboard buffer while CUSP isn't
really running" capability in the original CUSP emulator.
Also added are test scripts in the test/ directory.
These get compiled by SPASM to produce OBJ files that get loaded into PHFC.
Press 'o' to load the object by name, then 'P' or 'T' to load printer file or
tape file as appropriate.
Documentation is still lacking.
Most significant, the tape drive and printer have been debugged to work.
Source code re-organization.
All relevant source code under src/ directory, under relevantly named
subdirectories.
Major ad-hackery in the curses frontend in order to get tape mounting and
printer outputs working.
It's very rudimentary, but minimally functional.
The UI is horrendously bad.
It's intended to make fundamental holistic emulator testing possible.
To view other useable keys, type the very obscurely bound '?'.
This is not going to be the final UI.
But, the way software project tend to go, the key bindings may not be
overhauled until way later...
Sheesh. For the nth time... don't know what happened, but the file
was in Makefile.am so it should have already been there.
I fear I have little time to work on PHFC now.
Between being hired by UCLA (CS dept.) to work on and re-do the
CS webpage, and working on the redux
of CSUA's devel machine, there
really is little time left for me to do much else.
Oh, and smash coursework in there.
Compared to the other things demanding my time, it seems that completing
PHFC would benefit the fewest [people].
Thus, it goes on the back-burner.
New tarball, version 0.17
Discovered "make distcheck".
Too bad my home machine is too slow to actually do it.
Much hacking to reduce opcodes implmentation into what I considered a decrepit
form of Lisp, but with a very very minimal use of punctuations.
(It took two weeks!)
Incidentally, this happened to be a form favorable to shell commands.
Thus, a bash script is used to convert from the simple desription file into
Your Favorite Pet Language(TM); C in the case of PHFC.
Note that GNU bash version 2 or greater is required.
Earlier version of bash will not work; they lack the array implementation.
Also included a blt-ish function to the CRT.
This was intended to speed up drawing in the curses frontend, but it actually
wound up slowing down everything.
As it turns out, it wasn't ncurses at fault; it was my stupid unoptimized
drawing routines (clear, redraw everything, clear, redraw everything, etc.)
I still left in the blt usage just to show what I was headed for, but the
``regular'' code uses the old clear-all-redraw-all routine.
Still no ANSI checking done during compile.
Make it work first, then break it ;)
Another note to self: Make sure the tarball works on an entirely
different machine.
version 0.16a
(The difference is that just quote.c was taken out of src/Makefile.am)
Oh, yeah, my other concern about using glib
was that it may break the goal of using ANSI C for the emulator core.
Yay, school quarter is just starting to end (procrastinating on upcoming
final exams).
I finally got work on a bit of PHFC.
I'm not releasing source often enough, but here's something worth hacking on:
version 0.15.
The assembler and machine emulator are packaged together in one tarball.
Although packaged together, the file/directory layout is rather odd.
This is a direct result of having developed the emulator and the assembler
seperately.
Fooey.
PHFC now uses glib (not to be confused with
glibc, which is a functionally different library).
However, only two objects from glib are actually used.
Because of this, I may decide to write those parts from scratch, instead of
heaving a 200KB library down users' throats.
Or rip those sections out of the glib tree :)
Most systems based on GNU, Linux, or the free BSDs will normally have glib
already installed, though.
I suppose it will come down to whether I use more of glib or not.
The undoing of machine state is fully functional (finally).
The original purpose was to trace the behavior of this emu and the original
CUSP.EXE, so at a discrepency, I can go backwards in the execution flow and
check what's different.
As a side effect, it's also useful for debugging CUSP programs, instead of the
CUSP emu itself.
There's a gargantuan chunk of comments (600 some lines) in regpool.c that is
rendered irrelevant due to the amount of hacking to get undoing to work
properly.
What threw me off was that left bit-shifting by a negative number (foo <<
-4) does not shifts right by four, but instead shifts left by the
modulo with max bits; in the case of Pentium (my devel box), this meant a left
shift of 28 (= 32 - 4).
Almost no work has been done on the assembler (SPASM).
Thus, it is as inflexible as before.
Printer and data tape are emulated, however the filenames attached to the
emulated devices is unchangeable as yet.
To change the filename during use means having a UI (user interface) element
for it.
But that means a UI needs to be made first...
The school quarter has just started. Before I lose time...
source to the incomplete emulator is available:
phfc-0.10.tar.gz.
It starts, it runs, it can only read from a file called
test.obj, so rename whatever CUSP object files to that and run.
It can also browse memory, edit memory content, and undo CPU states,
but you can't edit the CPU registers (yet).
SPASM has been integrated into the source tree (but not the emulator itself),
but it still works as standalone, inflexible as ever, but it's been renamed
spaz to avoid namespace collisions.
One of these days, the emulator going up via CVS on
linux.ucla.edu.
In the meantime, you can trying tracking what I'm doing through my
finger information. It's also linked here:
finger.project.cusp.
The assembler (SPASM) is functional.
It does its job, but is very inflexible in what it can do.
Here it is:
SPASM v0.09
2000.05.18
2000.05.18
2000.05.17
2000.05.11
2000.05.03
2000.04.22
2000.04.14
2000.03.22
2000.03.19
Note to self: Before uploading a {new|any} tarball release, make sure that
it can actually compile after unpacking...
version 0.16
2000.03.19
2000.01.12
1999.11.18
PHFC homepage
Contact info:
Frederick Lee <phaethon@linux.ucla.edu>