January 2017 - vcf-midatlantic

Forth exhibit (was Re: Perhaps I asked the wrong question... FORTH)
by Brian L. Stuart 21 Jan '17

21 Jan '17

On Fri, 1/20/17, Jim Scheef <js(a)sdf.org> wrote: > An exhibit on Fourth should explain the stack archtecture and other things > that make Fourth unique (and a write-only language). An excellent topic. Indeed. My initial plan is to have a poster that explains the basic idea of a stack and how a stack language works. Then if time permits, I want to write a little tutorial running on one of the machines running Forth that covers things a little deeper. BLS

2 1

Re: [vcf-midatlantic] C Compilers (was Re: Perhaps I asked the wrong question...)
by Brian L. Stuart 21 Jan '17

21 Jan '17

On Sat, 1/21/17, Dave McGuire via vcf-midatlantic <vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: > Innnnteresting. I've played with clang, and eventually started > asking "what's the point?"...but kenc is something I've never heard of, > and Ken Thompson's toenail clippings know more about programming > languages than I ever will, so I'd like to look at that compiler. > Does/can it target bare-metal ARM7/Cortex-M families? Yes, it does. Now, I'll admit that I haven't played with the packages that are targetted at general use for e.g. Linux. However, someone recently said they were successful in biulding the Pi version of Plan 9 using it. And I did use the version that is packaged as part of Inferno to do an Inferno port to a little ARM box created by Sun Labs. Along the way, I added an output format to the linker so it would directly produce the format the SunSPOT expected. One unusual thing you'll find about these compilers is that the division of responsibility is a little different than is typical. The object files are actually in a form of intermediate code (though not portable between architectures) and the actual code generation is done in the linker. BLS

1 0

Re: [vcf-midatlantic] Perhaps I asked the wrong question... FORTH
by Brian L. Stuart 21 Jan '17

21 Jan '17

On Fri, 1/20/17, Evan Koblentz <evan(a)vcfed.org> wrote: > Do it! Registration is here: There definitely seems to be a lot of interest in a Forth exhibit, so my third appearance at VCF-E will be forth. I just registered it on the VCFed site. For the next month, my time still needs to be primarily ENIAC focused, but that should still give me plenty of time to put together the exhibit I've got in mind. BLS

1 0

link-editor fun and games before virtual memory (was C compiler)
by Jeffrey Jonas 21 Jan '17

21 Jan '17

> The IDE isolated the programmers > from full control of the compiler and its code generation options. Once upon a time, programmers were REQUIRED to understand and sometimes manually configure the link-editor. That allowed for things like load-no-call: load debugging modules/subroutines that were not called anywhere, but were available when debugging. Before virtual memory, there were overlays. The IBM 1130 made that simple with LOCAL (load on call) and SOCAL (system call load on call) directives. But only one was loaded at a time: one load-on-call could not call another. I think the IBM 360 allowed for specifying a tree of nested overlays. When using the PIC18, I had to configure the linker to load my "C" code around the boot loader. 'tis the joy of not using absolute addresses for everything. .csect is the IBM pseudo-op for such things: http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.alangref/… Everyone had their own names for such stuff :-( Anyone who hand-coded assembler did absolute addressing. I worked on a project where the assembler did not generate relocatable code. Everything was absolute addressing, requiring the build-meister to manually map out memory for all modules, storage sections, temporary scratch-pad areas, etc. It was easy to trash memory when anything changed size. -- jeffj

2 1

Re: [vcf-midatlantic] Perhaps I asked the wrong question...
by Devin Heitmueller 21 Jan '17

21 Jan '17

On Jan 20, 2017 7:59 PM, "Neil Cherry via vcf-midatlantic" < vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: On 01/20/2017 01:47 PM, Dave McGuire via vcf-midatlantic wrote: > On 01/20/2017 01:35 PM, Steven Toth wrote: > If you're writing a large software stack, need to integrate with other >> frameworks or libraries, an IDE is the way to go. >> > Not picking on Steven, but on the dislike of most IDEs. One more thing, and it's really at the top of my list since I tend to be very OCD on engineering related things ... it makes a @#$!%^& mess of the code indentation. I almost always know when someone uses an IDE because the code will end up getting some weird identation that no programmer could ever come up with. You can generally tell a programmers preference for the way they code but only an IDE can mess up indentation like that. if(blah) { if (!red) { sub_function(); subfunct2(); } } else { subfunct2(); } (Wow that was painful to type and look at) I'm not arguing for or against IDEs but this isn't really a fair criticism of IDEs. Such formatting issues are usually a difference in an editor's defaults with regards to tabs vs spaces, and it's common when you have any project worked on by users of multiple text editors. Code can look just as crappy in emacs after a vi user comes along and makes changes. There are ways to mitigate such issues through specification of tab/whitespace handling at the file or project level, but they are not uniformly supported by all editors. The real frustration I have is not about what the "right" answer is about tabs but rather that after decades the editors haven't arrived at a uniform standard for specifying the whitespace policy and having all the editors know how to parse and abide by it. In short, I agree with your frustration but an IDE user is just as likely to see their source code mangled by your non-IDE editor of choice. Devin

2 1

Re: [vcf-midatlantic] Perhaps I asked the wrong question...
by Kenneth Seefried 21 Jan '17

21 Jan '17

From: Neil Cherry <ncherry(a)linuxha.com> > >This new is better is what got Wellfeet/Baynetworks in trouble. Instead >of providing an ASCII interface to the command line they went menu (not >terrible) or snmp commands (ARGH!). Later they dropped the menu and went >full Windows GUI. Which was useless when the network as down. > Ahh...Wellfleet's "Site Manager". I'm sure in some Bostonian ivory tower, "everything is an SNMP OID and thou shalt only speak SNMP to it" sounded like a great idea. What they delivered was a steaming pile of bad design choices, wildly inconsistent behavior, poor documentation and crippling bugs (new and different in every release). To this day it's my go-to example of truly awful, how not to do it, user interfaces. I've rarely found one worse. KJ

3 2

Mac 128k M0001 for sale
by Joseph Oprysko 21 Jan '17

21 Jan '17

I'm looking to part with my Mac 128k. Rather than selling it on eBay, I'd rather it go to someone I know will appreciate it. It's fully functional, comes with mouse, keyboard, manual, original boot floppy, Apple Mac carrying case, and external floppy drive. It's the exact same Mac 128k that appears in the Smithsonian Channels "The Real Mad Men of Advertising" which was shot last summer. If you're interested, please email me off list with an offer, I can also send pictures. Thanks, Joe

1 0

simH (was Programming)
by william degnan 21 Jan '17

21 Jan '17

Evan/docents at the museum, Don't forget simH. I really like this platform for OS monitor, DOS, and programming of emulated hardware environments. I have been putting simH on the new gen of single board computers and they work great for demoing by connecting to a serial device. Low power you can run off a battery. I like the Next Thing Co CHIP as well as the Rasp Pi Zero. So cheap! The CHIP is $9.95 and comes with wifi, bluetooth, storage built in. Ready for headless serial port access out of the box. Network and control remotely. For cases that one wants to avoid harming or simply does not have working vintage hardware it works pretty well. For example I Know Corey was talking about attaching the PiDP8 with its simH emulation of PDP 8 OS/8 to a printer for museum demos of.the real PDP 8. There is other hardware in the museum that could be demoed that way, such as the VAX, Altair, SWTPC 6800, Sol20, etc. where running the real thing has proven to be not practical and prone to failure. Bill Degnan twitter: billdeg vintagecomputer.net

1 0

Re: [vcf-midatlantic] Perhaps I asked the wrong question...
by Mike Willegal 21 Jan '17

21 Jan '17

I agree that learning "C" using K&R in a shell might be a good way to start. Installing some kind of language support shouldn't be too much of a problem on any modern system. I'm guessing that GNU "C" comes installed with most Linux implementations. On OS/X you can install Xcode pretty simply. You don't need to use the Xcode IDE, but it is the easiest way to install the GNU tools that you need. I forget details, but while installing, I think you specify install the GNU C extensions. Once installed, you go to OS/X's terminal and type "cc" from there. I use OS/X terminal all the time for cross compiling 6502 or 8008 applications. Those cross compliers are "C" programs which are usually easy to tweak plus I've written a number of "C" language utilites to convert between archaic or unusual file formats. One caution is that modern incarnations of "C" may, by default, enforce some additional type checking restrictions and the like that break the examples in K&R, so it may become difficult for a beginner to figure out why the tutorial doesn't work. In case you want to go whole hog retro, I'll tell you that for a brief while, I made my living programming in "C" on a dual 5 1/4" floppy based Compaq luggable. I can't remember the name of the compiler, but it worked pretty well. We used a standard word processor of the day, perhaps it was WordStar, for source file editing. Not really any more difficult than using a shell in a modern system. Around the same time, I also experimented with a "C" implementation on the Apple II, and, by comparison, it was very clunky. I've been slowly learning to make OS/X applications over the past few years with xCode in Objective C for my SCELBI emulator app. Moving it over to the iPhone and iPad is in the cards. I'll tell you that the learning curve is extremely steep, but once you reach some level of proficiency, the power of the environment starts to get addictive. This is probably heresy on this forum, but I'm temped to say forget assembly and other archaic languages and just learn how to make IOS or Andriod apps. Surprisingly, the skills aren't really all that transferable from one to the other. Some basics are similar, but there is a great gulf of 30 plus years of technology separating the two worlds. Regardless of what approach you take, unless you have an idea of some concrete application that you need to write, it's going to be extremely difficult to become very proficient. Your first step should be deciding upon the end application that you REALLY need to have. regards, Mike Willegal

4 6

C Compilers (was Re: Perhaps I asked the wrong question...)
by Brian L. Stuart 21 Jan '17

21 Jan '17

On Fri, 1/20/17, Dave McGuire via vcf-midatlantic <vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: > Some say there's nothing wrong with that, but there actually is quite > a lot wrong with it. I cut the size of the resultant binary down by > almost 80% by ditching an IDE in a product whose firmware I inherited > several years ago. The code size was important not only because the > program memory space on the processor was nearly full and they > wanted additional features, but also because the firmware updates were (and > are) sent out via the cellular data network. Until I fixed it, a global > firmware update cost about $20,000 to $22,000. Now it's about $3,500 > due to the reduced binary size. Why? The IDE isolated the programmers > from full control of the compiler and its code generation options. In > other words, they discovered "what to click to make a program", and > clicked it. Without learning a damn thing about what they were > actually doing. Amen! Brother. > Nearly all of the world's C compilers, past and current, are command > line systems. And nearly all of them are actually GCC under the covers, > for everything even remotely modern. There are two primary exceptions. First is clang, which is just as big an unmanagable as gcc. The other is kenc. Ken Thompson wrote a new suite of compilers as part of the Plan 9 project. These compilers are also available as part of Inferno. Later they were ported to work on more POSIX-like environments for the Go project, and now a number of Linux and other distributions include packages to install kenc. His compilers are much leaner than the mainstream ones, they have a much cleaner model for cross-compiling, and Ken's taste in extensions makes the ANSI committee look like Philistines. BLS

5 7