My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Showing posts with label forth. Show all posts
Showing posts with label forth. Show all posts

Tuesday, April 9, 2019

BIF-6809 Revived (near fig-Forth interpreter I put together in college)

I ported and modified a fig-Forth interpreter for a couple of my college courses about 30 years ago. It was for the classic 8-bit 6809 CPU, and I was not thinking clearly, so I mothballed it.

Twice.

Anyway, I took time out of my schedule, two and four hours at a time over the last couple of years to resuscitate it. It now seems to be more-or-less as it was before I mothballed it the second time. It functions, you can write and edit code and save it to disk and load it back again. And you can write in assembly language.

Picture of method of booting bif-6809 on an emulator
Booting and testing BIF-6809 on the XRoar Emulator running Disk Extended Color BASIC


It's a bit primitive. Raw disk, no file system. 

And the call protocol is a bit baroque, using the direct-page mode in a way that will conflict with more general uses. 

I hope I can find the time to rewrite it with a more conventional call protocol.

If you missed the link above, you can find it here: https://ja.osdn.net/projects/bif-6809/. (And here is a page for how to get started, and a page to help figure out what to do next.)

I would be happy to hear from anyone who successfully gets it to run on whatever they are running. (Contact me through the project page, please.)

Real Cocos or emulators, it should be just a matter of getting the disk image file bifsource.dsk in the second drive and tools.dsk in the first, and

LOADM "BIF6809.BIN:1"
EXEC &H1300

and, at the static white cursor, such things as

6 LOAD

followed by

0 QLIST

1 QLIST

etc., more in README.TXT and BIFDOC.TXT.

Note that a "Q" screen is a 256 byte sector, where a regular Forth screen is a 1024 block of 4 sectors sitting on a 1024 byte boundary:

Forth
SCREEN
Quick
SCReen
(decimal)
Quick
SCReen
(hex)
byte
offset
(hex)
byte
offset
(decimal)
0000 0 $0000 $0000 == 0

1 $0001 $0100 == 256

2 $0002 $0200 == 512

3 $0003 $0300 == 768
0001 4 $0004 $0400 == 1024

5 $0005 $0500 == 1280

6 $0006 $0600 == 1536

7 $0007 $0700 == 1792
0002 8 $0008 $0800 == 2048

9 $0009 $0900 == 2304

10 $000A $0A00 == 2560

11 $000B $0B00 == 2816
0003 12 $000C $0C00== 3072

13 $000D $0D00 == 3328

14 $000E $0E00 == 3584

15 $000F $0F00 == 3840


Monday, January 5, 2015

What WordPerfect Corp Should Have Done in the 1980s (or, the Reasons They Did Not Hire Me)

A question about running Unix WP 5 on a modern Debian system brought back some ancient memories.

I was at BYU in the mid-'80s, when WordPerfect was becoming the standard word processor. I knew the guy who managed the Macintosh version development for the first several years. Took classes from one of the founders of the company. Etc.

Tried to get a job there. I was headed in a different direction than they were, so they turned me down.

One of Satellite Software International's products was a FORTH language system which I used (not very effectively) as an intern at IBM when I was recovering from a broken engagement in 1986 or so.

(Heh. As I write this, the English wikipedia page on WordPerfect has it as Satellite Systems International, which is a completely different company. The Japanese page has it correct. There's one kind of bit rot.)

My memory is that Dr. Ashton once said, in class or lab, something about early versions of WordPerfect being implemented in FORTH, and that the C code base had a lot of FORTH-isms for quite a while. (This would not be surprising. FORTH, like LISP, is structured well for text stream processing, which is a lot of what made WordPerfect such a successful product.)

If I could have gotten Dr. Ashton's ear --

Never saw Bruce Bastion on campus that I remember, but I did have some opportunities to talk with Dr. Ashton, since I took a class from him. I tried to talk FORTH and the 6809 up to him. Didn't find out about their FORTH language system product until some time after that class. This was just another example of the social, political, market, non-technical stuff going on at the time, and my studied cluelessness.

I daydreamed while doing my homework, about getting into that company and building a "WordPerfect PC" using the 6809 or the 68000. About re-writing, as I assumed, the code in FORTH, and thus making it possible for the customers to add custom modules.

About using WordPerfect and a canonical WordPerfect Personal Computer as a wedge to push a new cross-platform freedom-enabling OS based on constructing a Unix-like system on the foundations of FORTH as a run-time and library model.

I was enamored with FORTH. They were moving the code base for WordPerfect along on standard C.

-- Don't get me wrong. I like C, to play with. It's lacking in certain features to support large projects, and C++ and Java only manage to point their fingers sort of in the right directions.

-- And not that FORTH did/does not need extending to handle some of the things that C handles well. But FORTH has the extensibility that C still lacks. (And I know that extensibility is a two-edged sword, the tendencies of source code to slip away from standards. And I now have an idea how most FORTH enthusiasts have cut themselves carelessly wielding that sword)

I was interested in the cooperative and open models of software development. They were interested in capitalizing their intellectual property.

I was anxious to set up viable opposition to the Microsoft Way. They were interested in a cozy third-party relationship with Microsoft.

I do not understand why anyone would want to voluntarily enter into a relationship with either Microsoft or Intel. It was obvious to me back then, that both companies were hell-bent on pushing their (quite patently false) claims of being the standard, pushing until they had a de-facto monopoly. And anyone who knows history knows the tyranny of monopolies.

Bell Telephone was the only counter-example of a non-evil monopoly, and the only reason they kept their nose (mostly) clean was that the government was breathing down their back.

There seem to be sirens lounging and singing on the rocks of technology --

Technology can be built into systems. (Computers are the archetype of this.)

Systems are great tools for tying customer relationships.

If you can discover it first, keep it secret, get a patent, you can tie your customers to your technology and then you have a guaranteed revenue stream.

It's a siren song.

These kinds of royal grants have been the tools of tyrants in practically every age, and the wedge they form in the social structures of tyranny has proven to be the most effective and destructive tool in undoing the same tyranny.

Unfortunately, innocent bystanders usually get hurt in the wars that result, by the thousands and millions.

That's the reason the US Constitution said "limited time". Temporary stewardship over part of the intellectual and creative commons, derived from the facts of individually-implemented ambition. None of this nonsense about making property out of the social artifacts of the intellectual domain.

No one was supposed to be able to keep control of their inventions and writings their whole lives.

Otherwise tyranny results.

Well, I was disappointed that people who should have been steeped in the traditions of freedom at BYU should be taking their company right into the heart of tyrannical traditions.

And they weren't interested in an idealistic, naive fourth-year sophomore like me.

Now, who's naive?

I guess we all are.

You know, here's the whole reason idolatry is so strictly discouraged in the Bible:
Systems.

The tyrannical pseudo-religious systems that idols represent.

Until we, as a race, become mature enough to quit worshipping systems, I think God will never let us build a proper computer operating system.

Friday, August 8, 2008

Looking Back to Go FORTH

A long, long time ago, back when dinasour mainframes roamed the earth, I was fresh back from my mission to Japan, trying to figure out what all LDS young men just back from their missions are trying to figure out: What do I do now?

But this little rant is less about that and more about one of the things I did. My brother, out of the kindness of his heart, gave me a 6800 prototyping board, I think it was the micro-chroma 68. Basically, it was the Radio Shack Color Computer, but with a 6800 instead of a 6809, or even a 6801. Okay, it was a 6802, but that was just a 6800 with some built-in RAM and ROM.

It's about 4000 miles away, so I can't post a picture, but that's okay. This rant is not so much about that piece of kit, either.

My brother dug up a ROM BASIC somewhere, but I wanted a better language. One of the teachers at the community college suggested FORTH, so I wrote off for the fig-FORTH model implementation for the 6800. The printout did not contain the object dump, so I had to go through the entire assembly listing and add the op-codes that had been abbreviated in the listing. I really did not think much of hand-assembling code at the time, writing it down seemed like more work than looking up the op-codes.

[I once had the insane urge to actually transcribe the source for that 6800 fig-FORTH. For a while, it was linked at forth.org, but they seem to have removed the link now. You can find it in the appropriate sub-directory of my 6800 assembler. Joel -- 2015-03-28]

I was silly enough to not build a floppy disk controller, but I did build a fast cassette tape controller, which was a little bit more reliable than the built-in 300 baud cassete tape controller. So I had some place to store the results after I typed the the entire model in in hexadecimal code. How long did it take? Don't remember, but it did seem like a long time, when I had friends and teachers playing around with the original IBM PCs, Apple ][s, and the like. Not to mention the time I wasted at Radio Shack playing around with the Color Computer demo models.

I don't think I can explain why I didn't just save up the money and get one of those Color Computers, with disk drive, etc. It sure would have saved me some time.

I think.

I played around with the FORTH, worked out the examples in Brodie's Starting Forth, as far as I could without disk drives. The dRAM was actually 64K, and I used a bit on the parallel port to toggle between banks, but I didn't really have the experience to figure out how I could usefully emulate a (very small, very volatile) floppy disk with it. So I was a little stuck on the disk examples. Also, the model provided hooks for implementing multi-tasking, but no actual implementation, so I wasn't able to play with that.

But I did learn enough FORTH to make me very impatient with other languages.

Fast forward to to when I got my associates and transferred to BYU. Found myself at the end of the BS-CS coursework with three class left, the one where you write a simple compiler, the one where you write a simple OS, and an elective. I was still spoiled by FORTH. (Maybe I still am.) Could not resign myself to stupidly hashing through simple closed algebrae and playing stupid register allocation games when I "knew" there was a better way. Kept trying to synthesize something useful from the two diametrically opposed approaches to computer languages, without the experience to know where the boundaries of object orientation were, to see where the difference between closed mathematical objects and infinite tape were always depositing me during my design attempts at random places in my own undefined memory.

Hey, I'm stronger for it. Right?

Anyway, those were my first flunked classes. I had, actually, a low A average to that point. Fortunately, BYU allows you to repeat classes. I took on the OS class first. Finally got up the courage and the wisdom to invest enough money to buy a Color Computer on sale, with Radio Shack's recommended cassette deck. (Yeah, I know about store recommendations, but it was also on sale. I could have saved another five dollars, but I'd have wasted a day running around.) Wrote screen routines and keyboard routines and time routines, and whatever else I could to pass the class.

The elective I chose was software tools. I went ahead and bought a disk drive and Radio Shack's disk-based assembler package, and implemented FORTH on the Color computer's 6809.

Actually, I got OS-9/6809 before I got the more basic assembler, and tried to do the FORTH in the OS-9 assembler, but found myself fighting with trying to make a relocatable FORTH, without fully understanding that I was effectively trying to define an i-code without actually pinning the codes down to specific values.

No, actually, I really did figure that out fairly quickly, but I just couldn't reconcile myself to the solution, you know, the one that put a 64K code limit on classes in early versions of Java -- Make the i-codes an index into an array, put the actual pointers in that array. Cry when you run out of array. Or not, if you never compile that many words.

One other option might have been possible, using self-relative i-codes. Needless to say, Microware's assembler would not assemble such a beast. For some reason, I declined writing an assembler that would. OS-9/6809's pre-ANSI C compiler might have been one of those reasons, or maybe I was just too lazy.

You have a similar problem when you try to use raw C language function pointers as i-codes. Most modern OSses relocate by keeping a list of addresses that need to be fixed up when the code is loaded. You can't help filling borked when you have to implement your own fix-up on an OS designed not to be fixed-up, and the fix-up table is as big as your object.

So I dropped my attempts to do it in OS-9, and went out and got the more primitive assembler software and worked with that. That way, I didn't have to think about relocation issues.

Once I had a simple enough implementation environment, the port was fairly straightforward. Or it should have been. First, assign the virtual registers of the FORTH model to real 6809 registers:

The return stack pointer, RP, was the 6809's call stack pointer, S.

The parameter stack pointer, SP, was the 6809's user stack pointer, U.

The i-code instruction pointer, IP, was the 6809's Y index, but I would sometimes save it off temporarily when I needed two index registers.

I put W on the top of the return stack, if I remember right. A little weird, but it was out-of-the-way, and still accessible.

You might think I'd use DP for the user variable pointer. But that sure was an awkward idea, DP being only the top eight bits. I ended up putting most (all) of the headerless primitive words in the DP and using DP relative jumps to get there, which was not a good idea, either. Oh. I also put the user variable pointer in the DP, too.

I designed the symbol table structure as a nested binary tree instead of using the more typical hashing techniques. That facilitated a certain amount of information hiding, for modularity and other object-ish behaviors.

Then I wrote the primitives, the inner interpreter, the basic parser, the symbol table lookup, the basic math. At a certain point, I had enough primitives that I could have finished off by just typing in the rest of the fig-forth high level model's compiled form. But the teacher wanted to be sure I was not just copying, so I re-wrote some of the stuff where it looked like 6809 object would actually be smaller than the high-level object. Used a kind of stupid-code-trick approach to shifting between high-level object and 6809 object on the fly (mostly stupid because shifting gears is not really a good idea, other than showing the teacher that you understand what it's doing at some level.

Once I had the 6800 model converted to 6809, with my modifications, I copied the fig editor source into a screens disk and had a running system. Source code was about a hundred 60-line pages, the object a bit fatter than I had expected, just over 8K if I remember right.

Then the teacher asked me to document every word in the model, so I did that. By hand. On paper. Don't know why I did it by hand, on paper. I later typed it into a text file, and that is also a part of the download on my site, linked again here, in case you missed it above. (Just what you always wanted, wasn't it?) All of that took me about six months, working pretty much full-time on the project. (Thanks go to my parents for letting me live in their attic for a while.)

[My personal website is now off-line until such time as I can afford $20 a year or so to pay dyn.com or someone else to resolve the url for me on an on-going basis, I guess. See the bif-c link below, and look in the appropriate subdirectory for the source code. -- Joel 2015-03-28]

I ended up passing my compiler class with a compiler written on that FORTH. So my education was all FORTH colored. Maybe that's why I just gave up on the industry about two and a half years ago. Maybe I can do something about it [link added 2 May 2011] while I'm taking a break.