Old COBOL standards were based around 80-column punched cards, and columns beyond 71 (or 72) were reserved for line numbers. They were little used, but a numbered deck, if dropped, could be sorted by a collator.
Because of this, some compilers would not parse beyond a certain column (which could be 70, 71, or 72). So, in the interests of compatibility, it ...
Why did the original Apple //e have two sets of inverse uppercase characters?
Simple: To allow lower case inverse letters.
It's all about the clever way Woz arranged the original II's single character set to save in hardware and offer additional functionality. There is only a single character set of 64 characters, showing up 4 times in 256 entry character ...
If you go back a lot before the x86, this technique wasn't unusual at all. In fact, writing programs using printable letters and symbols was pretty much the norm for early computers, except that there was a number of encodings for words of varying bit size, and that encoding was not ASCII.
On the IBM 1401 (1959), a program that looked like
Digital Research produced as one of their early attempts into graphical desktops (on their way to GEM) a basic portable graphics library - GSX. GSX did actually support proportional fonts, both in print and on-screen, and was included with the CP/M support in Amstrad machines running CP/M Plus. GSX was supported by two of DR's own applications, DR Draw and ...
In the old days, I remember we were told to never go beyond the 70'th column in the text editor (the actual value was usually something above 70, but less than 80). [...] If it makes a difference, this was when programming COBOL.
No, it doesn't, as it was more of a feature of the underlaying priciples and standards for handling punch cards. By default ...
I think the following early text editors meet your criteria:
Brian Tolliver’s TVEdit (Stanford, 1965), based on Doug Engelbart’s earlier word processor; see On-line Text Editing: a Survey:
TVEDIT is one of the earliest (1965) time-sharing, CRT-based text editors [12, 22]; it displays many lines of text at electronic speed. The user thus continually views ...
This is an AppleSoft issue where it puts spaces either side of a token.
PET/CBM BASIC (based off the same code base) doesn't do this.
Tokenising ignores spaces, this means it can be difficult on the PET to see some of the problems that the tokeniser can cause.
For example LET AFOR=ONER gets parsed as LET A FOR = ON ER
Which is very difficult to see on a ...
On the basis that a picture is worth a thousand words, I include my scan of a punched card:
As amply described in the other answers, it shows how the columns are visibly marked on the card for different purposes. It makes sense when you see a card. It makes less sense when you're using a computer display or are using paper tape!
Just the first (of many) example of using proportional fonts on Commodore64: https://youtu.be/k2NRlsopoOU?t=441
You couldn't really use a proportional font on the Spectrum because
the colour attributes were one background and one foreground for each
8x8 square. That meant that, practically speaking, each letter had to
be by itself in an 8x8 cell.
It was standard practice on the Sinclair ZX80 & ZX81 to put executable code into a REM statement at the beginning of a BASIC program.
REM statements are, of course, text comments, so this meets the spirit of your requirement for executable ASCII.
The ZX80 (1980) and ZX81 (1981) predate your question about the early 1990s by about 10 years and used the ...
All text is painted as bitmaps.
The highest-resolution built-in mode is 640x200 pixels, so that provides an 80x25 text mode. 80-column modes were used in business software (e.g. DBase II) and even in the CP/M 2.2 and 3.0 OS.
The CPC uses a CRTC6845, which is wired up atypically to create linear scan lines but nevertheless can still hardware scroll in ...
It can be done in any environment that:
Allows the remarking of data files into program files,
Has a loader format that's either primitive enough or all readable
Has a character set (doesn't have to be ASCII) that has a sufficient number of encodings that produce valid opcodes
Has an address space layout that fits the possible encodings
ASCII was designed from the start with usable subsets (for instance an uppercase subset representable with six bits, consisting of the four central columns) and international variants. SHARE (IBM users' group) insisted that all characters needed for PL/I, included the vertical bar, were present in the uppercase subset(*). That was solved by allowing ! to ...
Here is a program I wrote several years ago in AppleSoft for the fun of it. What it simply does is disassemble itself from the tokenized storage into a listing. If you run it, it will look the same as if you did a LIST command.
In general, this gives you all the rules of AppleSoft formatting but in the form of a program :-)
0 REM ** DISASSEMBLE MYSELF
Back in 1986, a company called Berkeley Softworks released a GUI desktop environment called GEOS for the Commodore 64. It was later ported to the Commodore 128, the Commodore Plus/4, and Apple II.
GEOS was obviously inspired by the classic Mac OS desktop. It implements all the basic elements one would expect from such environment, such as a pointer-driven ...
"Character memory" is the bitmapped definitions for each of the characters (e.g. "glyphs") that are displayed in text mode, based on the "character codes" that are poked into the "screen memory".
Depending on which graphics mode you enable, there are several different memory areas that will be accessed by the VIC-II in creating the display. If we only focus ...
The BASIC Programming cartridge for the Atari 2600 displayed twelve characters per line.
The RCA 1802-based VIP used bitmap graphics rather than having a "text mode" as such, but the typical bit map font was five pixels wide on a 64-pixel-wide screen.
No 8-bit computer (back then) did support proportional fonts out of the box, but there where some programs on next every bitmap capable 8 bit computer, I this might as well include the Spectrum.
For the Apple II support was added by Apple rather early. Already the Apple DOS Toolkit included a utility called HRCG or High Resolution Character Generator, ...
I remember doing this on the university mainframe around 1975. This was on an ICL1904S. Note that the 1900 series had been around for more than 10 years at that time. I don't know when the feature came out but it had been around for some time.
You could list out any executable in card reader format. It would produce the executable in 6-bit characters in ...
It's really more of a conjecture, but if it is considered suitable as an answer:
Already in early TECO, the letter q ("quantity") was used to retrieve the value of a register. That might have been the reason to call them Q-registers.
Trying to trace reasons for why things are named a certain way is always difficult; they way this usually goes is that ...
For a slightly interesting twist on this concept, consider Control Data mainframes.
These beasts included not only a CPU, but a "peripheral processing unit" (PPU)1--and the CPU sent commands to the PPU via normal I/O channels.
The CPU was a 60-bit processor that used 6-bit character codes. The PPUs were 12-bit processors, so the CPU sent a stream of 2 ...
The screen character set on the Apple II looks like this:
00-1f: ASCII 40-5f, but inverse text
20-3f: ASCII 20-3f, but inverse text
40-5f: ASCII 40-5f, but flashing text
60-7f: ASCII 20-3f, but flashing text
80-9f: ASCII 40-5f (officially control characters, but displayed as normal text)
a0-bf: ASCII 20-3f
c0-df: ASCII 40-5f
e0-ff: ASCII 20-3f (Apple ][/][+)...
TLDR: TECO uses single-character commands. When extending TECO to
add registers to store numeric values, there was a limited set of
unused characters left for the commands associated with this
functionality. q was chosen as one of these command characters
because it could serve as a mnemonic for "quantity." This led to the
numeric registers being called "Q-...
Depends on your definition of a microcomputer, but e.g. Sharp PC 1210 (and derivatives) had 24 characters per (one) line.
PMI-80 had 9 characters per line, but you might not consider it a true microcomputer.
To elaborate on drawing text on Amstrad CPC and its screen addressing:
The first row of every character position on screen is at the memory address range from &c000 to &c7ff, and thus can be calculated as &c000 + y * 80 + x.
FOR I=&C000 to &C7FF: POKE I, &FF: NEXT
The subsequent lines of every character are &800 bytes apart ...
From my experience, you have two options:
Use a utility called "MacDisk For Windows" from (https://macdisk.com/mden.php) that has a good chance of allowing a PC that is equipped with a Floppy Drive (USB or Otherwise) to read the HFS or HFS+ Formatted Macintosh Disk you have. I've used this in the past with good results.
If you are concerned about using ...
That's the ubiquitous 1.44MB 3.5" floppy. Any modern floppy drive should be able to read it; the hard part is finding software that understands the format -- Mac-formatted disks aren't readable by Windows.
The first thing I'd try is plugging a USB floppy drive into a Mac and reading the disk directly: if you're lucky, everything should just work, and you ...
10 input "some question?"; name$
Will be reformatted as:
10 INPUT "some question?" ; NAME$
That's not quite right (confirmed just now with an emulator). It will be reformatted as:
10 INPUT "some question?";NAME$
i.e. there are no spaces before and after the semicolon.
You can see what the formatting algorithm looks like in C++ in this ...