- vcf-midatlantic - lists.vcfed.org

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

Perhaps I asked the wrong question...
by Evan Koblentz 21 Jan '17

21 Jan '17

After posting my assembly-for-newbs question, it occurred to me that perhaps I should be asking this instead: with no experience other than LOGO and then BASIC, which (period 1980s) language should I learn next? Was it normal to go from BASIC directly to assembly (is BASIC enough preparation), or were people better off getting some in-between experience with a language such as Pascal or something else? Keep in mind that my natural aptitude is liberal arts, not math. :)

31 125

cross platform coding for the Apple ][
by Dan Roganti 21 Jan '17

21 Jan '17

Anyone have some success with getting the right tools to set a workflow for building cross platform coding on the Apple ][ ? I found some tools already which I hope someone can give us some advice to build a practical workflow. While helping Evan on his robot project, the traditional method of coding directly on the vintage platform becomes a burden when trying to collaborate over the phone, email or online. Because you can't see what's on their screen and you can't share the screen online as with today's desktops. No amount of chit-chatting to summarize the code without looking at it directly is going to help. For the moment, he wants to work with Applesoft Basic, and perhaps later once the bugs are worked out and the project is running, then dive into some 6502 assembly. In the past, because it's simply not practical to do that, I once had Evan and Jeff shine their phone's camera over the computer screen during a video conference to help debug the code, it worked :) But I suggested they get one of those goose-neck mounts to hold the phone or webcam so they can type faster Now I recommended that we change to the cross platform coding because it helps to share the code, share the work, especially when it comes time to debug any problems while we collaborate on this project from long distances. And these situations happen often on a new project, with new hardware, etc. So it becomes practical over the phone, email or online. I do this already with my C64 assembly coding project to collaborate with Jeff and others at long distances. But now I'm not sure if my google-foo has lots of static for this Apple ][ topic because I never had so much trouble finding enough info, versus the time when I had to setup one for my C64. It did take some time, but mostly to get familiar with the software tools out there which is specific to that machine. Then after it just took some time to iron out the steps between each tool. For the Apple ][ this is what I found so far 1. Editor = I think any editor would suffice here, maybe there's one specific for the Apple][ ? 2. Disk Imager = AppleCommander[jav], CiderPress[win], Ominvore[win], DiskBrowser[win] 3. Emulator = AppleWin[win], LinApple[nix]---> both are the same port 4. Floppy emulator = ADTPro[jav] via serial port Now these tools work as described, but there's still some glitches in the workflow problem#1, I can open any disk image with the tools mentioned. But then when I try to extract the Basic file on my desktop, the tools give you 2 choices, either the original Apple format, or text format. The original format is so you can later import the file to the disk image. But then it's not possible to edit the file cause I can't locate an editor which can view the file in the first place. And the viewer in the disk imagers don't let you edit file. problem#2, With AppleCommander, i can extract the Basic file. It's always exported as a text file. But then it insert extra CR's on every line. I can edit the code. then import the file back into the disk image. I can verify the code is good when I view this in the disk imager. And then I load this into the emulator. But when I list the file, there's always some glitches with extra lines of garbage text, either at the beginning or end, maybe in the middle. So we can do the basic things[summary], load disk images, make disk images, view files in the disk images, extract files from the disk images[not 100%], But then, we can't successfully import the files from the desktop with the Basic code, into the disk images for the emulator or live hardware, even though the viewer in the disk imager verifies its there and readable, the listing viewed in the emulator shows the glitches This is what we're facing and we like to find somebody that can give us advice on this ------------------- For the C64, I use Assembly coding. It became easier to build a practical workflow. I just use an editor, then a script for the Assembler to build the code, the symbol table, listing file, even a debug listing for the emulator, so I can set breakpoints on the labels from the code when debugging, and even the image file so I can add it to the disk image. Then there's a 2nd tool to build the disk images for the Commodore systems. And then a very powerful emulator called VICE, which handles every single computer made by Commodore -- to load the disk images for testing/debugging the code. And the same disk image is stored on a SD card to load into the C64 hardware for live testing. For Assembly coding, it's only 5 tools for cross platform coding on the C64 Plus there are some other tools which you use in parallel, for creating graphics, sprites and sound effects, and SID music 1. Editor 2. Assembler = DASM 3. Disk Imager 4. Emulator = VICE 5. uIEC = SD card floppy For those that use Basic coding, it's even simpler. Lots of people have been very progressive in building powerful coding tools for the Commodore scene. So there's one called CBM studio. This replaces #1, #2, and #3. 1. CBM studio 2. Emulator = VICE 3. uIEC = SD card floppy Some use the CBM studio for Assembly coding. But as you know with Assemblers, not all are compatible, because of their syntax style. So I try to avoid stuff like that. Because on one project, I tried to rewrite this network game, it was coded using DASM and I wasn't about to edit 100's of lines of code in a dozen files just for that, I had enough work ahead of me already, so I just kept using my editor and that assembler. ----------------------------- And there there's always the issue that many of the tools are not built for multiple desktop platforms. I don't fault the developers for this. Because there are some very good and powerful software tools for all aspects of the machine, for graphics hardware, sound hardware, etc, not just assembly coding. So I just keep using tools like VMware to run the different tools. You have to give lots of credit to the many people who devote so much time to building these tools. Because it really promotes a wide avenue for other people to use these to get very creative. I noticed there are always multiple types of people, this is just one example. People who know how to build the right tools for you, and people that get very creative by using the right tools. Example, If you want to build your own house, you like to find the right tools, rather than getting the "forge and anvil" to build your tools -- which can already be done better by those experts who devote their time -- so you can spend more time being creative on your house design. Dan

5 11

A neuroscientist analyzes a 6502.
by Derrik Walker v2.0 20 Jan '17

20 Jan '17

Interesting read ... http://www.economist.com/news/science-and-technology/21714978-cautionary-ta… - Derrik Derrik Walker v2.0, RHCE dwalker(a)doomd.net "Those UNIX guys, they think weird!" -- John C. Dvorak

4 3

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

20 Jan '17

On Fri, 1/20/17, Dave McGuire via vcf-midatlantic <vcf-midatlantic(a)lists.vintagecomputerfederation.org> wrote: > If you want a really nice Forth workstation, pick up a nice > SPARCstation-IPC or -IPX and just don't boot it! ;) I should take one of my IPCs and dedicate it to that :) Come to think of it, maybe that's what I should do for VCF this year: a Forth exhibit. I should easily be able to have 3 or 4 different Forths running on a table. At a quick thought, I should be able to have it running on a 6809, a 68HC11, a SPARC, and an LSI-11. I had been thinking about doing a follow-up to last year's ENIAC exhibit but was worried that might be too repetative. BLS

5 4

Sucessful workshop January 14&15, 2017
by Jeffrey Brace 20 Jan '17

20 Jan '17

Just wanted to write a quick e-mail to thank all those who attended the workshop. It was another successful workshop. It was a good idea to have the workshop in the bigger space. It accommodates more people. A lot of things got fixed and there was a lot of sharing of knowledge and expertise. Here are some phones from my iPhone which are raw, unedited and not the best quality (sorry I forgot to bring my Nikon): https://drive.google.com/drive/folders/0B9SJLfGXYiG5LS1hMU8yX19fQWM?usp=sha… If anyone wants to chime in on what the worked on, their progress and what they need to work on next. -- Jeff Brace - ark72axow(a)gmail.com

2 1

the programmer's desk
by Jeffrey Jonas 20 Jan '17

20 Jan '17

I inherited most of the stuff from my dad's desk: coding pads, flowchart template, reference cards, books, periodicals, computer specific rulers and thingies. The only electrical thing on a programmer's desk back then was the lamp! Maybe a calculator for working out address offsets. I'd say Gesswein is the most likely to demonstrate using a PDP8 coding pad and hand-coding the assembler, then TOGGLING IT INTO THE FRONT PANEL (he probably can do most of that in his head by now!) The KIM, SYM and such made it a LITTLE easier with hexadecimal keypad & 7-segment LEDs. Alexander Pierson: > At the same time I was wrestling that, > I did a historical paper on Pascal. > In the process of researching it, > I think that was the first time I was exposed to the concept > of writing out a program by hand with pencil and paper > before entering it onto a computer. That's what I learned back in high school. A process that's served me well. THINK OUT the program first. PLAN all the tests to have confidence it really works. Niel Cherry's reply confirmed the merit of that work flow. And it let me work at home, away from the computer center. Keypunches were shared machines. You didn't compose at the keyboard. You minimised time at the machine by planning everything in advance, punch the cards as fast as possible and submit the job. > That blew my mind, seeing as never thought of a time > before text editors and glass terminals. It was an important turning point: from machine time being rare and valuable to people-time being more important. > I'm so used to instant gratification of finding syntactical errors > and compiling at the drop of a hat. Which is a more productive use of your time & attention. Be grateful! Mike Loewen: > Welcome to the early 1970s. Colleges and high schools were still using punched card batch in 1977 and afterwards. The infrastructure was there: rooms of keypunches that only needed outlets vs. expensive terminals (the ADM3a was "cheap" at just under $1,000) and data lines for each terminal. > Write your FORTRAN program down on coding forms: That's EASY compared to RPG II where every card type was a different format that was extremely column sensitive. > Then head to the keypunch room and punch your deck. > Take it to the dispatch area and submit your job to the dispatcher. Movies kinda show what it was like back then with the closed shop fishbowl-data-center. Only operators were inside to touch the machine. Now with "the cloud", we don't even get to see das blinkenlights and tapes-a-twirling. I still remember feeling so heartfallen when I learned that the FORTRAN "sense lights" might not actually light up anything. That's why I was so happy to use the LGP-21, where sense switches were REAL SWITCHES! > Come back in minutes or hours, depending on the load, Or longer :-9 > and retrieve your deck and printout. > Review the output for syntax errors, keypunch errors and logic errors. > Return to the keypunch room and punch new cards to fix the errors. > Lather, rinse and repeat. You beat me to it! I was about to say the same thing. -- jeffj

2 1

Hoodies arriving soon
by Evan Koblentz 20 Jan '17

20 Jan '17

For everyone who ordered a hoodie recently: they're arriving at our museum on February 1st. ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)3 educational non-profit evan(a)vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation

1 0

terminally sorting cards
by Jeffrey Jonas 20 Jan '17

20 Jan '17

Roganti: > about that same time, we got those new Hazeltine 1500 teminals, > that was really sweet trying out some new code > with the Esc control seqences on the CRT I remember a similar exultation when my school replaced a TTY with an ADM3a featuring lower case and full cursor control! A lot of code had that hard-coded, thus programs being tied to their hardware. That's particularly true of the early hobbyist programs, even with CP/M. Some programs such as WordStar had a configuration program to set the terminal and printer. Even now, Microsoft Windows folks struggle to find drivers for peripherals. Linux is not guiltless but is a lot less brittle thanks to the Unix evolution of termcap and terminfo. > so in school we really skipped over the punch card scene, > it wasn't until my first job did I actually get > my hands on the punched card machines During a consulting assignment on an IBM system 3, I had access to a card sorter and the related sorting trays. That taught me what's now called the "radix sort" and gave me insights into the earier era of accounting machines. A lot of card juggling there, not by the box but by the palette! What hath thou caused us, oh Mr. Hollerith!

1 0