SEARCH

https://vintagecomputing.ch/?browseid=5522
  • don't write specs. Users should consider themselves lucky to get any programs at all and take what they get.
  • don't comment their code. If it was hard to write, it should be hard to read.
  • don't write application programs, they pro- gram right down on the bare metal. Application programming is for feebs who can't do systems programming.
  • don't eat quiche. Real programmers don't even know how to spell quiche. They eat Twinkies, Coke and palate-scorching Szechwan food.
  • don't draw flowcharts. Flowcharts are, after all, the illiterate's form of documentation. Cavemen drew flowcharts; look how much it did for them.
  • don't read manuals. Reliance on a reference is a hallmark of the novice and the coward.
  • programs never work right the first time. But if you throw them on the machine they can be patched into working in only a few 30-hours debugging sessions.
  • don't use Fortran. Fortran is for wimpy engineers who wear white socks, pipe stress freaks, and crystallography weenies. They get excited over finite state analysis and nuclear reactor simulation.
  • don't use COBOL. COBOL is for wimpy application programmers.
  • never work 9 to 5. If any real programmers are around at 9 am, it's because they were up all night.
  • don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.
  • don't document. Documentation is for simps who can't read the listings or the object deck.
  • don't write in Pascal, or Bliss, or Ada, or any of those pinko computer science languages. Strong typing is for people with weak memories.
  • know better than the users what they need.
  • think structured programming is a communist plot.
  • don't use schedules. Schedules are for manager's toadies. Real programmers like to keep their manager in suspense.
  • think better when playing adventure.
  • don't use PL/I. PL/I is for insecure momma's boys who can't choose between COBOL and Fortran.
  • don't use APL, unless the whole program can be written on one line.
  • don't use LISP. Only effeminate programmers use more parentheses than actual code.
  • disdain structured programming. Structured programming is for compulsive, prematurely toilet-trained neurotics who wear neckties and carefully line up sharpened pencils on an otherwise uncluttered desk.
  • don't like the team programming concept. Unless, of course, they are the Chief Programmer.
  • have no use for managers. Managers are a necessary evil. Managers are for dealing with personnel bozos, bean counters, senior planners and other mental defectives.
  • scorn floating point arithmetic. The decimal point was invented for pansy bedwetters who are unable to 'think big.'
  • don't drive clapped-out Mavericks. They prefer BMWs, Lincolns or pick-up trucks with floor shifts. Fast motorcycles are highly regarded.
  • don't believe in schedules. Planners make up schedules. Managers 'firm up' schedules. Frightened coders strive to meet schedules. Real programmers ignore schedules.
  • like vending machine popcorn. Coders pop it in the microwave oven. Real programmers use the heat given off by the cpu. They can tell what job is running just by listening to the rate of popping.
  • know every nuance of every instruction and use them all in every real program. Puppy architects won't allow execute instructions to address another execute as the target instruction. Real programmers despise such petty restrictions.
  • don't bring brown bag lunches to work. If the vending machine sells it, they eat it. If the vending machine doesn't sell it, they don't eat it. Vending machines don't sell quiche.
https://vintagecomputing.ch/?browseid=5934
Hah, I might not be the best to explain Amiga history, but I’ll do my best :) Fish disks were the main way to distribute public domain, open source, shareware etc. before the internet was wide-spread. People would send Fred Fish software, and he’d compile them into individual disks that people would copy. Magazines would have lots of companies that would allow you to order copies of these disks etc. He ended up creating over a 1000 disks this way. When cd-roms became a thing, you could order the whole collection on those. Those were strange times :)
Aminet was the most famous ftp-archive for amiga software. It was run by the same guy that made Brainfuck, Urban Müller. Rather than chronologically like fish disks, it was organized by topic, with readme’s for every file. You could upload to a staging area, and he’d put them in place. Much like fish disks, companies would print cd-roms with the latest from aminet for those not hooked up to the internets (or on 56k modems, which was most people).
FILE_ID.DIZ
2023-02-07 10:00:37
https://vintagecomputing.ch/?browseid=6685
  1. Program/file name: Ideally, all uppercase and followed by one space. Carriage returns are ignored in this file.
  2. Version number: In the format "v1.123", followed by a space.
  3. ASP number: Only if an actual ASP member, otherwise ignored.
  4. Description separator: A single short hyphen "-".
  5. Description: The description of the file. The first two lines should be the short summary, as older boards cut off the rest. Anything beyond that should be extended description, for up to eight lines, the official cut-off size. Additional text could be included beyond that but might not be included by the board.
Comment
2023-03-16 16:09:22
https://vintagecomputing.ch/?browseid=7417
The system is very clever and really works. You are faster than you think and the system helps a lot!
https://vintagecomputing.ch/?browseid=9073
Subject:
'Re: VIC-II colors'
From: Robert 'Bob' Yannes
To: Philip
'Pepto' Timmermann
Date: 27.09.1999
I was involved with the development of the VIC-II, however the actual implementation of the design, including the Color
Palette, was done by someone else. I have forwarded your message to him, but it is up to him if he wants to respond.
I can tell you that the design was based on the principle that adding a sine wave of a particular frequency and amplitude
to an inverted version of the same sine wave at a different amplitude produces a phase-shifted sine wave of the same
frequency. The amount of phase shift is directly proportional to the amplitudes of the two sine waves.
The VIC-II used the 14.31818 MHz master clock input (4 times the NTSC color burst frequency of 3.579545 MHz) to produce
quadrature square-wave clocks. These clock signals were then integrated into triangle waves sing analog integrators. The
triangle waves were then integrated again into sine waves (actually rounded triangle waves, but good enough for this
application). This produced a 3.579545 MHz sine wave,
inverse sine wave, cosine wave and inverse cosine wave.
An analog summer was used to create the phase-shifts in the Chroma signal by adding together the appropiate two waveforms
at the appropiate amplitudes. The Color Palette data went to a look-up table that specified the amplitude of the waves by
selecting different resistors in the gain path of the summer. The end result was that we could create any hue we wanted by
looking at the NTSC color wheel to determine the phase-shift and then picking the appropiate resistor values to produce
that phase-shift.
Color Saturation was controlled by scaling the gain of the summer. When we picked the resistor values to determine the
output phase-shift, we also scaled them to produce the desired output amplitude. Luminance was controlled using a simple
voltage divider which switched different pull-down resistors into the open-drain output. We could create any Luminance we
wanted by choosing the desired resistor value.
I'm afraid that not nearly as much effort went into the color selection as you think. Since we had total control over hue,
saturation and luminance, we picked colors that we liked. In order to save space on the chip, though, many of the colors
were simply the opposite side of the color wheel from ones that we picked. This allowed us to reuse the existing resistor
values,
rather than having a completely unique set for each color
I believe that Commodore actually got a patent on this technique. It was certainly superior to the Apple or Atari approach
at the time, as they ended up with whatever colors that came out--ours allowed the designer to freely select Hue,
Saturation and Luminance.
Since all of this was based on selecting different resistor values and resistance varied from chip lot to chip lot, there
was variation from one Commodore 64 to another. It wasn't as bad as it could have been though, since all of the Chrominance
selection was based on resistor ratios, which could be kept constant even if the actual resistor values varied. Luminance
was more of a problem. A trimmer resistor should really have been used to pull up the output. This would have allowed the
Luminance to be adjusted for consistency from unit to unit, however Commodore didn't care enough about consistency to
bother with adjusting each unit
Robert
'Bob'
Yannes
https://vintagecomputing.ch/?browseid=9257
OLIVER Being a pixel guy – the tools were remarkable. We did not have devkit like the Katakis tools or something specified for creating game graphics. I used the editor that came with the Shoot ‘Em Up Construction Kit for sprites, which turned out extremely practical. The Ronny-sprite was created with an C64 editor called Mob-Profi, which provided overlayed hires and multicolour-sprites. The pictures in the intro and end sequence were pixeled in Koala Painter with a joystick, but everything else was more like hacking. I edited the charset with a font editor. The level backgrounds were tile-based maps, so a friend of mine coded one tool for combining 2×2 chars to tiles including the colour – and a second tool for assembling the levelmap like a puzzle game. As setup I had a C128 and Amiga 500 side by side. By the way – there was a TV and a monitor connected to the C128 at the same time, because of the the different video quality and I wanted to be sure that the graphics  looked right on both display types. With our modern mouse or stylus driven tools and those workflow-trimmed programs it is hard to believe that we got things done at all back in the day when we were even lacking fundamentals such as UNDO functionality. However, I have to say that you had full control over the technical specs of the graphics and as a graphic designer you started to think like a coder.
Otherwise, I hardly remember details of the project. At least for the first month, Mario and I were working alongside each other. The intro and the end sequence were finished first. Then it was very intense and determined by crunchtime, the process was sort of first-in-first-out. The progress in code was tied to incoming graphics. Markus composed the new tunes at home far away and we had some issues with the delivery. Nevertheless the whole soundtrack reached us in time and its implementation went smoothly. Still there was no free time at all. In the final weeks weeks it became a kind of competition – like, who needs the least sleep! I also remember that the editing of the levels was pretty chaotic. Three of us worked in shifts and it took much longer than planned.
Oh I almost forgot about the  communication with Virgin. That was the horror for me because I hardly spoke any English back then. David Bishop and I talked English and German mixed, which worked surprisingly well.
https://vintagecomputing.ch/?browseid=3167
Note: 
Question: “What do you think about IBM”
Jobs: “We are ok. They licencsed our NExT-Software”