Talk:ABC 80

BBC Micro vs. BBC Micro BASIC benchmarks

It would be really nice if someone (maybe the guy who's responsible for the current benchmarks) could whip this up, since BBC Micro is also known to have an efficient BASIC interpreter. 93.182.164.65 (talk) 10:13, 15 August 2009 (UTC)

According to this: http://cpcwiki.eu/index.php/BASIC_Benchmark, the ABC 80 beats the BBC Micro in every test in integer performance and compares favourably against almost all computers in all but the BM8 benchmark in floating-point performance. — Preceding unsigned comment added by 163.244.62.183 (talk) 14:13, 21 July 2016 (UTC)

ABC80 -> ABC 80

This series of computers is in the Luxor documentation consistently named ABC 80, not ABC80. So I will rename this page, and also ABC800, and create a redirection page.

A picture from the ABC 80 manual: http://www2.flickr.com/photos/altemark/128164292/ An ABC 806 manual with loads of pictures showing the ABC<space>number scheme: http://www.student.nada.kth.se/~d94-tan/notes/abc806/abc806.htm

--Regebro 12:52, 17 November 2006 (UTC)

Semi-compiling vs bytecode

Not sure "semi compiling" is the right term, really -- both ABC 80 and 800 used a bytecode-based BASIC, executed by a traditional virtual machine. Not that different from e.g. today's Java JVM and Python, in fact.

To save memory, lines were immediately translated to bytecode when entered, and the compiler then threw away the source code. When a program or line was listed, it was "decompiled" on the fly (the bytecode instruction set contained a few extra "nop"-codes to support reconstruction of comments and explicit parentheses, etc.). Some "copy-protection" mechanisms used carefully manufactured byte code sequences to produce "buffer overflows" in the decompiler to prevent users from looking at the program.

(And yes, BAC files contained byte code, BAS files was plain source code). —Preceding unsigned comment added by 85.119.130.132 (talk) 20:01, 16 July 2008 (UTC)

Horizontal resolution 78 or 80 pixels

According to an anonymous poster "The correct horizontal resolution is 78 [not 80], as the first column of a line can never be used for graphics. Each line starts in text mode and a control character is needed to switch to graphics mode". I do not agree, he would be right if the video display would be based on a videotex chip that enforces the use of serial attributes, but am not convinced this is the case. My opinion of the ABC80s video hardware is that its Videotex compatibility is partly based on software, not completely on (serial attributes using) hardware. I think the hardware simply supplies a 40 x 24 matrix of (Videotex) characters, and software is used to emulate a display with serial attributes. This means that if the software is bypassed serial attributes are not needed, and the first character of a line can also be written to with a graphics symbol, just as any other of all the 960 positions of the screen (just like a TRS-80). So in my opinion the real resolution is 80 (2x40) x 71 (3x24). Can anybody say with confidence that the ABC-80's video hardware relies on serial attributes, or not? As far as I can read in the block schematic on page 4 of this: [1] .PDF the video system is simply linear, and without the complications (or need for) detection of attribute characters. If there is no information saying otherwise I will change the horizontal resolution back to 80 characters in a few days. Mahjongg (talk) 21:08, 12 July 2010 (UTC)

Well, I speak from experience programming the ABC 80 in assembler, accessing the video memory directly. So I don't need to speculate on how the HW works, because I remember it well. The 3x2 graphics cells are indeed implemented in HW, which looks for Videotext-like control codes to switch graphics mode on or off as the video memory is scanned.

You can see the logic for implementing this in the full schematic, included on page 51 in the service manual you referred to. The J3 ROM decodes the control characters, toggling the J5 flip-flop to enter or exit graphics mode (output pins 10 and 11). Through output pin 9, the ROM indicates if a character should be shown as a normal character even in graphics mode. The ROM also has an address bit connected to a sync-related signal, enabling it to clear the graphics mode at the beginning of each line. The H3, H4 and G4 gates are responsible for generating the 3x2 cells, with horizontal pixels shifted out through J6 (while pixels of normal characters are shifted out through J1). Depending on the state of the graphics mode flip-flop (J5) one of these shift registers are selected for video output.

Note that the MSB of each video memory cell is used for indicating whether the character should blink or not (normally used for the cursor) so that bit was not free to distinguish text characters from 3x2 graphic cells. Yet the HW needed to represent the difference between graphics and text cells somehow, and this control character scheme was what they came up with (it is by no means a full Videotex implementation in HW). 83.226.33.111 (talk) 23:28, 12 July 2010 (UTC)

Indeed, the resolution was 78, as the first character is a control character to switch the line to graphics mode. A reliable source for this is "Mikrodatorns ABC" by Gunnar Markesjö. --OpenFuture (talk) 09:09, 13 July 2010 (UTC)

Well, if the ABC 80 is indeed using serial attributes as a hardware feature I concede that the horizontal resolution should be 39 x 2, as the first character in a row is needed to switch to graphics mode. From a hardware POV its very strange that Luxor has chosen this approach, as they did have 8 bit per character, and a monochrome display, so it would be very easy to use bit 7 (msb) to switch between pseudo graphics or text. Actually as pseudo graphics only need 2^6 (64( characters, they even could have used a blinking and a non blinking version (for a blinking cursor). It seems very strange to implement serial attributes in a design with discrete logic when there wasn't an obvious need for it. Mahjongg (talk) 22:17, 13 July 2010 (UTC)

As already explained above, the MSB made the character blink. And although you only need 64 characters for pseudo-chaphics, ascii needs 128 characters, so your solution doesn't work. --OpenFuture (talk) 22:31, 13 July 2010 (UTC)

Yes, it must have been used for a blinking massive character (all 2 x 3 pixels lit), for the cursor. It seems Luxor thought that there was such a big need for blinking characters that the most significant bit of the eight-bit byte for each character had to be offered for it. Nowadays that would seem quaint, but it may have seen logical then. If bit 7 would not have been used for this purpose a serial attribute would have had made more sense, as a 2 x 4 (8-bit) matrix could have been used for the pseudo graphics matrix, increasing the vertical resolution to 96. It seems that having a "hardware cursor" (blinking characters in hardware) was more important than that (or maybe compatibility with Prestels 2x3 system). Other systems just used software to make a cursor blink, but maybe they weren't sure they could handle it with software. Mahjongg (talk) 22:40, 13 July 2010 (UTC)

Compatibility with Prestel (or Datavision as it was called in Sweden) was almost certainly a factor in choosing 2x3 graphic cells. Unless you managed to double the resolution in either direction, more than 2x3 pixels per character cell would have been detrimental to implementing Prestel-like graphics, as it would either result in clearly non-uniform pixel sizes or problems aligning graphics with text. The codes for turning graphics mode on and off in HW could have been chosen arbitrarily, but the codes they actually chose were ones that made sense for Prestel ("Graphics white" and "Alpha white"). Using the MSB for character blinking could be seen as wasteful, but note that inverse video was not supported in any other way, so it would not have been possible to implement this kind of blinking cursor (capable of showing the underlying character at all times) without some sort of HW support. Arguably, using the MSB for inverse video and leaving the periodic blinking to software would have been more flexible (allowing non-blinking inverted text) while probably also simplifying the HW a little. Half of the 2x3 possibilities could then be mapped to character codes 0-31 while the other half could be obtained by inverse video, and you would have got your 2 extra pixels of horizontal resolution as control codes for graphics would now be unnecessary. 83.226.33.111 (talk) 23:18, 14 July 2010 (UTC)

Facepalm. Bit 7 is used by ASCII. You can't use bit 7 to blink, because then you can't have a full ASCII character set. You evidently do not understand the design. Stop trying to start a flame-war about a 30 year old computer of which you know nothing. --OpenFuture (talk) 06:42, 14 July 2010 (UTC)

Why so aggressive? I'm counting from zero, (D0 ... D7) as is common, even in the ABC schematics, so "bit 7" is the most significant bit, unused by ASCII. I'm not "starting a flamewar", but trying to clear up some details from this system that were not know before. If my assumptions of the hardware were incorrect, that doesn't matter to me, I just trying to make sense of it, and yes, I have tried to read the full schematic of page 51 of the service manual to try to determine if serial attributes were implemented in hardware, but the use of small ROM's as logic somewhat obscures the flow of the logic. The ABC80 holds special interest for me, as it was sold in a shop where I once worked as a technician. We also sold the TRS-80 model 1, the Apple ][ and the Italian Olivetti M20, an early 16-bit system with the Z8000 CPU. Mahjongg (talk) 10:00, 14 July 2010 (UTC)

OK, I read it as the 7th bit, which was your earlier suggestion. My mistake. But you still make a lot of weird assumptions about what "makes sense" or not. And blinks can be used for more things than cursors, you know. ;) --OpenFuture (talk) 10:39, 14 July 2010 (UTC)

Numbering bits can be a bit confusing, the earlier mentions of "bit 7" ,as in "so it would be very easy to use bit 7 (msb) ", and " If bit 7" -also- should be read as the most significant bit of the byte, as i explicitly state by adding "(msb)" the first time I mention "bit 7". I have never explicitly talked about any other bit than the most significant bit, maybe not getting that has confused you. Its quite simple, I was designing video systems at that time too, and most of what was "out there" at that time (pre 1978) was extremely primitive, and built with discrete logic, simply a train of dividers to create the timing system, and a linearly read RAM that pumped its contents (either through a font ROM, or directly) to a shift register, and out as a monochrome video stream. Nothing fancy, no "tricks". So when I first saw an ABC80 I assumed that it's video system was also "bare bones", at that time nobody had heard of anything as fancy as a "serial attribute system", I think I hadn't even seen a Videotex system yet. So in my mind the ABC80 was like the TRS-80 but with all eight bits for video RAM (the TRS-80 model 1 managed to use only seven bits by omitting lowercase), and with 40 columns instead of 64, and 24 lines instead of 16 (the TRS-80 used a very simple divider train with only powers of two binary counters). So I assumed that like the TRS-80 it used a part of its coding set for pseudo graphics, and because the ABC80 had a full coding set of 256 codes, I assumed it could incorporate both lowercase and pseudo-graphics in its set. And that support for a "Prestel mode", was later added in software, (like with my own system, that was like a TRS-80 that not only could do 64/32 column, but also do 80/40 column, and that did use software to create Prestel displays (but without double height characters). I never would have thought that the hardware actually used serial attributes which were an unknown concept then. I do know that a lot of the designs at that time were "obsessed" with adding "a blink bit" to characters, for hardware blinking support, something I found a trivial use, as I didn't see the usefulness, except for cursors. But support of hardware blinking was also copied into the Sinclair spectrum and many later systems. Actually the concept of serial attributes was a very smart way to enlarge the capability of the video system, but it was hard to use, as can be seen with the Oric Atmos. It also was more useful in a color video system than a monochrome system. I was puzzled at first why the serial attribute was used for switching between text and graphics, not for other attributes like between blinking and non blinking characters, or reverse video. But if you realize that hardware blinking was probably meant to make the implementation of a cursor easier you understand that serial attributes for blinking wouldn't work well, as the cursor the had to have a "space" (the serial attribute) in front of it, which wouldn't be acceptable for a cursor. Mahjongg (talk) 16:38, 14 July 2010 (UTC)

Yeah, the ABC80 was quite innovative and a very good computer. It was thanks to it's Basic (which is what we today would call byte-compiled) and the clever hardware blazingly fast for being a 3MHZ Z80. (As you can see from the Performance table). It was really a cool little machine. --OpenFuture (talk) 19:38, 14 July 2010 (UTC)

It is indeed correct that ABC 80 used bit 7 for the blink feature, and that graphics mode required hidden mode-switching characters that displayed as spaces. ABC 802, which used an integrated CRTC with dedicated cursor logic, used it for static inverse video. ABC 806 was the only one which could switch video attributes of any kind without hidden characters. HPA (talk) 19:42, 2 December 2015 (UTC)

Used to control industrial equipment

Someone with a bit more technical knowledge then me, perhaps an engineer that have worked with installing them, should write something about their use in Swedish manufacturing industry.

I have been a blue collar worker from the late 80's and forward and when I started out, these computers was used everywhere to control all kinds of industrial equipment. It was kind of fun because I had played with them as a kid, but never expected that they could be used in this manner. The last time I saw one in use was as late as 2000, that one was used to control a metalworking machine. In the early 90's the ABC 80 became hard to get, because a lot of factory and workshop owners had bought up most of what was left of them, to use as spare parts.

They where favoured before other solutions because:

• They where easy to tweak and and very well documented (the famous book made by their creator).
• They where cheap. In 1984 (when I was a kid and I think most of the ABC 80 was deployed by the industry) you could buy something like 20 of them at the same price as one IBM PC. And the IBM PC was very slow and limited in comparison.
• They where more robust then even most special built control computers for the industry and "never" failed. They could be running non-stop for a decade in a really rough environment, without any damp protection or cooling (in environments where other PC:s would have failed instantly when turned on, even with a protective case).

Much Swedish machinery was even built around the ABC 80, not just modified to be controlled by them. The largest one I've seen was an offset printing press. —Preceding unsigned comment added by 81.234.126.82 (talk) 11:13, 2 April 2011 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on ABC 80. Please take a moment to review my edit. You may add {{cbignore}} after the link to keep me from modifying it, if I keep adding bad data, but formatting bugs should be reported instead. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether, but should be used as a last resort. I made the following changes:

• Attempted to fix sourcing for http://www.greentacblog.com/2008/07/ancient-computer.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 05:28, 28 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on ABC 80. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090223103039/http://mess.toseciso.org:80/mess:drivers:abc80:abc80 to http://mess.toseciso.org/mess:drivers:abc80:abc80

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:11, 1 October 2016 (UTC)