6 ms·

1984, the Year of the 32-bit Microprocessor (1984)

78 points by indigodaddy 7y ago

Davesjoshin 7y ago
Page 147 shows an advertisement for computers and parts. One of the companies present is a Pied Piper.
- ggambetta 7y ago
  You mean... you mean they figured out time travel tech???
snvzz 7y ago
By the requisites they list, which focus on the ISA, the original 68000 was already a 32bit architecture in 1979, but it would indeed take until 68020 in 1984 for the CPU to have a 32bit bus and for 32bit operations to not be internally split into 16bit ones. I admire the foresight of Motorola in making the ISA itself 32bit from the get go.
- mschaef 7y ago
  > By the requisites they list, which focus on the ISA, the original 68000 was already a 32bit architecture in 1979, Huh? The second paragraph states: "First, let's define our terms. A 32-bit microprocessor has a full 32-bit architcture, a full 32-bit implementation, and a 32-bit data path (bus) to memory." (And then the author spells out what each of those three things means individually.) IIRC, the 68000 missed both the 32-bit implementation and the data path. Interesting to note though, that Intel's later 80386SX product would NOT quality for the article, even though it's a compatible reduction of a chip that does. (The SX version of the product had a 16-bit bus and was physically closer to a 80286 in terms of external hardware interface.)
  - aap_ 7y ago
    There is a difference between architecture and implementation. The 68000 ISA (i.e. the architecture) is 32 bits, the actual 68000 chip is not.
    - Narishma 7y ago
      I don't think anyone said otherwise?
- djmips 7y ago
  According to Sophie Wilson, one of the reasons Acorn decided to go ahead with their own CPU design was the fact that in 1983 the 68000 and other contemporary CPUs were bottle-necked on memory access.
  - cmrdporcupine 7y ago
    Of course within a few years _everything_ was bottle necked on memory access and the advantages of processors that could do memory access in few cycles (like the 6502 or early ARM) doesn't mean much anymore, as CPU speeds easily outstripped memory speeds.
    - aidenn0 7y ago
      Wider memory buses were still less bottlenecked than narrower though. See the transition from 32 to 64 to 128 to 256. POWER9 has an absurd setup which is 192 bits wide at the CPU (2 controllers each with 4 24 bit DMI interfaces), but each DMI has a 256 bit path t memory. https://en.wikichip.org/wiki/ibm/microarchitectures/power9 https://en.wikichip.org/wiki/ibm/microarchitectures/power9
  - snvzz 7y ago
    68000 and 68010 had no icache or dcache. 68010 had a 1 instruction loop cache, which accelerated tight loops considerably, as it wouldn't need to fetch the instruction. Think e.g. a move with a builtin decrement then a branch if not zero.
- hermitdev 7y ago
  When I was in college, studying electrical engineering, we used a 68K (I forget the exact version) in our microcomputers course. In lab, the "computers" we worked on were hand assembled, wire-wrapped from individual chips. Quite the site to look at, especially considering that it fit in the same size as a then standard desktop form. What I do remember is that while 32-bit ISA, the data bus was 16-bit. We had both hardware and software debuggers. The hardware debugger was basically flipping a switch from going from a regular clock to a single step with set of hex displays on the front of the computer that allowed you to see what was on the databus, no internal CPU state. The software debugger allowed you to see CPU registers, display memory. No stack trace. One of our projects was to write a resident monitor, maybe more analogous to a super micro kernel. Because the monitor ran in supervisor mode, while normal code ran in user mode, and our software debugger also ran in supervisor mode, we couldn't use the software debugger for our monitor. We could only use the hardware debugger. I got really good at decoding 68K instructions from reading the hex display while single-stepping. A silly aside from that last comment; We built our monitor on then modern PCs, specifically, I had a laptop running FreeBSD, because it had a 68K emulator available. To get our assembled code to the micro computer, we had to transfer it over a 1200 baud serial connection, and it took around 30 minutes to transfer our monitor before we could even test. So, we heavily utilized the emulator which was nearly instantaneous. We had run all of our tests against the emulator and everything looked good. We were still in lab at around 2AM, and our professor walks in and asks how we were doing. I responded we were doing great, and had just uploaded our latest code to test. Our test on the actual hardware failed spectacularly. Started using the hardware debugger to find out why, and it turned out to be an addressing issue (the instruction was using the default 16-bit addressing instead of the intended 32-bit addressing). It was literally a 1-bit bug. I manually edited the memory and reran and it was fine. There might have also been a jokingly light back-hand across the face of the team member that wrote the routine that failed.
erwan577 7y ago
This byte article does not seems concerned about the choice of endianness (big-endian or little-endian).
- kabdib 7y ago
  Honestly, byte order didn't matter much. There were so many more dimensions of incompatibility available that byte-order didn't enter the picture when you were choosing a processor for a product. Most data was exchanged via files written to floppy disks, and you just wrote conversion utilities (or programs dealt with save formats on the fly).
- magoghm 7y ago
  Endianness matters when you share binary data between computers with different architectures. That didn't happen that often in 1984.
michaelhoffman 7y ago
The ads in this issue for long-forgotten products are amazing.
- indigodaddy 7y ago
  Yes quite a treasure trove I noticed as well. A lot of disk copying services it seemed?
klodolph 7y ago
For some history—the early Macs in 1984 used 24-bit addressing. The 68000 itself had a 24-bit address bus, but the address registers were 32 bits. So you could use the top 8 bits for some extra data, and programs actually did this (including ROMs/system software for early Macs). This meant that your memory would max out at 8 MiB, with the other half of the address space used for something else (ROM?). When System 7 came out, 32-bit addressing became available but not all software was “32-bit clean”. So you could enable or disable 32-bit addressing in the memory control panel. This is similar to the A20 gate on IBM PCs. By 1993 or so the hardware was no longer built to support 24-bit addressing. PowerMacs followed soon after.
- saagarjha 7y ago
  I wonder if we’ll ever have to make today’s software “64-bit clean”.
  - jjtheblunt 7y ago
    Is that what Apple developers were given a several-year advanced notice of, and Catalina now requires such? I recall many people running non 64-bit clean apps complaining about Catalina, which I found curious.
    - wtallis 7y ago
      Apple dropped support for 32-bit applications. That's different from requiring 64-bit applications to stop abusing unused address bits—something that hasn't ever been commonplace for x86-64.
      - zozbot234 7y ago
        x86-64 actually requires that every memory access occur with a "canonical" address, specifically to ensure that everything will be "64-bit clean". That is, even though virtual address space in some cases may be limited to 48 or 56 bits the actual address has to be sign-extended to 64 bits, so everything is "clean". "Abusing" unused address bits is then just a matter of ensuring that any virtual addresses you use are restricted to the appropriate range. "x32" binaries do this in order to ensure that any pointers will fit within 32 bits even on x86-64, for example.
mhd 7y ago
Interesting to read about the NS32k. The only thing I ever heard it used was the Ceres workstation of the ETH Zurich, the native platform of Wirth's Oberon OS.
- cmrdporcupine 7y ago
  Jack Tramiel's Atari Corp. evaluated the NS32k series for use in their Atari ST. They even built a prototype. But the processor had bugs and quality issues and they went with the 68k instead. I understand NS did fix their issues but by then it was too late and it never caught on outside of anything but embedded applications (apparently used in laser printers...)
- rjsw 7y ago
  I had a demo of the Whitechapel Computer Works MG-1 [1] workstation that used it. I knew of but never saw the Acorn systems with that CPU. [1] https://en.wikipedia.org/wiki/Whitechapel_Computer_Works https://en.wikipedia.org/wiki/Whitechapel_Computer_Works
- dfawcus 7y ago
  Acorn Business Computer model 210 aka Acorn Cambridge Workstation (ACW/443) running panos. See http://chrisacorns.computinghistory.org.uk/Computers/ACW.html http://chrisacorns.computinghistory.org.uk/Computers/ACW.htm... or wikipedia.
elwell 7y ago
Paged through some and found an article on Speech Recognition [0]: Most interesting sentence: "Currently, it is not likely that such techniques would be used for domestic surveillance." Philosophical Issues The specter of Big Brother may not be of concern in Western society today, but the evolution of distributed intelligence among machines with speech-recognition capability certainly provides the technical base for monitoring our activities. In fact, the U.S. National Security Agency has developed what may be the world's most advanced speech-recognition algorithms. This system spots keywords in intercepted verbal transmissions from "unfriendly" nations. Currently, it is not likely that such techniques would be used for domestic surveillance. But speech technologists as well as the public must be aware of the potential loss of privacy. [0] - https://archive.org/details/byte-magazine-1984-01/page/n213 https://archive.org/details/byte-magazine-1984-01/page/n213
- stevenwoo 7y ago
  This was five years before a 10000 dollar dedicated speech recognition card would be available for home PC's, I remember when we got one for testing when I was working during college at IBM and it was huge like those double slot graphics cards one can buy today, now we can do the equivalent on our phones - it's hard to predict sometimes how fast or where technology is going to advance.
- wscott 7y ago
  Well, they understood the significance of the year.
- romwell 7y ago
  Emphasis on "currently".
aidenn0 7y ago
This was an interesting year for S-100, and it's reflected in the ads. The writing was on the wall for the S-100 bus on microcomputers (the PC platform was displacing it), so they were pivoting to the high-end (look at the S-100 SBCs designed to be used in larger installations, the way that VME would eventually be used). There's a good mix of ads for both applications in this issue. The standard was eventually retired 10 years later.
AnimalMuppet 7y ago
Ah, what days those were! Expecting the 68020 to be twice as fast as the 68000 at the same clock speed? Wow. Today we get table scraps of improvement. (On the other hand, the baseline is much higher now...)
- snvzz 7y ago
  >(On the other hand, the baseline is much higher now...) Which unfortunately hasn't resulted in a more responsive user experience. Faster CPUs just meant that optimising code got less important. Now, we're stuck with a bloated stack, top to bottom.
  - matheusmoreira 7y ago
    For some reason latency keeps getting worse. https://danluu.com/input-lag/ https://danluu.com/input-lag/
ThomasBHickey 7y ago
I still have one of the original Apollo/Domain (DN300?) motherboards. It has two Motorola MC68000L8 chips on it. It was explained to me that Apollo found they needed both of them to make virtual memory work. 32 bit data width, 16 bit data bus.
- that_jojo 7y ago
  It's worth going into why the two CPUs. Basically, the original 68000 isn't capable of atomically restarting an instruction interrupted during a memory access cycle, and so there's no way to implement a standard MMU. So Apollo just chucked in a slave CPU that would detect the interruption of the master CPU, halt it, deal with any remapping or what have you, and then just completely reset the master CPU.
  - snvzz 7y ago
    Also worth noting that this was solved in 68010 by changing the exception stack frame. On that regard, it's a shame the Amiga released (1985) with a 68000 cpu. Particularly, move from SR became privileged 010+ and thus caused problems when Amiga finally moved past 68000. Those could have been easily avoided by releasing Amiga on 68010 to begin with, which is also a CPU with slightly higher IPC. They compounded the issue by using 68000 again on A500/A2000 (1987), for negligible savings. Of course, this does pale next to the gross mismanagement Commodore did of the Amiga thereon, which ultimately led to Commodore's own demise.
wbhart 7y ago
The Zilog z80000 wasn't introduced until 1986, but was pipelined and was in some respects about 6 years ahead of Intel. Apparently they are still used today in embedded application, though there was one moderately successful machine based on them back in the day.
- dfawcus 7y ago
  I recall learning of the z80000 (via a datasheet) in '88, but never managed to find a machine using it. I know of machines designed and built with the z8000, but I've only heard of the z80000 being used for embedded devices (possibly one main customer?). Are you able to provide a reference to an actual general purpose computer built around the z80000?
acqq 7y ago
From the same BYTE, something even today can be recognized as an absolutely amazing achievement: https://ia600609.us.archive.org/BookReader/BookReaderImages.php?zip=/10/items/byte-magazine-1984-01/BYTE-1984-01_jp2.zip&file=BYTE-1984-01_jp2/BYTE-1984-01_0184.jp2&scale=8&rotate=0 https://ia600609.us.archive.org/BookReader/BookReaderImages.... Turbo Pascal - IBM Pascal - Pascal MT+ Price: 49.95 | 300.00 | 595.00 Compile and Link Speed: 1 sec | 97 sec | 90 sec Execution speed: 2.2 sec | 9 sec | 3 sec Disk Space 16 bit: 33K with editor! | 300K + editor | 225K + editor Disk space 8 bit: 28K with editor! | Not Available | 158K + editor ... Locates Run Time errors directly in source code: YES | NO | NO ---- Extended Pascal for your IBM PC, APPLE CP/M, MSDOS, CP/M 86, CCP/M 86 or CP/M 80 computer features: - Full screen interactive editor providing a complete menu driven program development environment. - 11 significant digits in floating point arithmetic. - Built-in transcendental functions. - Dynamic strings with full set of string handling features - Program chaining with common variables. - Random access data files. - Full support of operating system facilities. - And much more.

78 points by indigodaddy 7y ago

Davesjoshin 7y ago

Page 147 shows an advertisement for computers and parts. One of the companies present is a Pied Piper.

ggambetta 7y ago
You mean... you mean they figured out time travel tech???

snvzz 7y ago

By the requisites they list, which focus on the ISA, the original 68000 was already a 32bit architecture in 1979, but it would indeed take until 68020 in 1984 for the CPU to have a 32bit bus and for 32bit operations to not be internally split into 16bit ones. I admire the foresight of Motorola in making the ISA itself 32bit from the get go.

mschaef 7y ago
> By the requisites they list, which focus on the ISA, the original 68000 was already a 32bit architecture in 1979, Huh? The second paragraph states: "First, let's define our terms. A 32-bit microprocessor has a full 32-bit architcture, a full 32-bit implementation, and a 32-bit data path (bus) to memory." (And then the author spells out what each of those three things means individually.) IIRC, the 68000 missed both the 32-bit implementation and the data path. Interesting to note though, that Intel's later 80386SX product would NOT quality for the article, even though it's a compatible reduction of a chip that does. (The SX version of the product had a 16-bit bus and was physically closer to a 80286 in terms of external hardware interface.)
- aap_ 7y ago
  There is a difference between architecture and implementation. The 68000 ISA (i.e. the architecture) is 32 bits, the actual 68000 chip is not.
  - Narishma 7y ago
    I don't think anyone said otherwise?
djmips 7y ago
According to Sophie Wilson, one of the reasons Acorn decided to go ahead with their own CPU design was the fact that in 1983 the 68000 and other contemporary CPUs were bottle-necked on memory access.
- cmrdporcupine 7y ago
  Of course within a few years _everything_ was bottle necked on memory access and the advantages of processors that could do memory access in few cycles (like the 6502 or early ARM) doesn't mean much anymore, as CPU speeds easily outstripped memory speeds.
  - aidenn0 7y ago
    Wider memory buses were still less bottlenecked than narrower though. See the transition from 32 to 64 to 128 to 256. POWER9 has an absurd setup which is 192 bits wide at the CPU (2 controllers each with 4 24 bit DMI interfaces), but each DMI has a 256 bit path t memory. https://en.wikichip.org/wiki/ibm/microarchitectures/power9 https://en.wikichip.org/wiki/ibm/microarchitectures/power9
- snvzz 7y ago
  68000 and 68010 had no icache or dcache. 68010 had a 1 instruction loop cache, which accelerated tight loops considerably, as it wouldn't need to fetch the instruction. Think e.g. a move with a builtin decrement then a branch if not zero.
hermitdev 7y ago
When I was in college, studying electrical engineering, we used a 68K (I forget the exact version) in our microcomputers course. In lab, the "computers" we worked on were hand assembled, wire-wrapped from individual chips. Quite the site to look at, especially considering that it fit in the same size as a then standard desktop form. What I do remember is that while 32-bit ISA, the data bus was 16-bit. We had both hardware and software debuggers. The hardware debugger was basically flipping a switch from going from a regular clock to a single step with set of hex displays on the front of the computer that allowed you to see what was on the databus, no internal CPU state. The software debugger allowed you to see CPU registers, display memory. No stack trace. One of our projects was to write a resident monitor, maybe more analogous to a super micro kernel. Because the monitor ran in supervisor mode, while normal code ran in user mode, and our software debugger also ran in supervisor mode, we couldn't use the software debugger for our monitor. We could only use the hardware debugger. I got really good at decoding 68K instructions from reading the hex display while single-stepping. A silly aside from that last comment; We built our monitor on then modern PCs, specifically, I had a laptop running FreeBSD, because it had a 68K emulator available. To get our assembled code to the micro computer, we had to transfer it over a 1200 baud serial connection, and it took around 30 minutes to transfer our monitor before we could even test. So, we heavily utilized the emulator which was nearly instantaneous. We had run all of our tests against the emulator and everything looked good. We were still in lab at around 2AM, and our professor walks in and asks how we were doing. I responded we were doing great, and had just uploaded our latest code to test. Our test on the actual hardware failed spectacularly. Started using the hardware debugger to find out why, and it turned out to be an addressing issue (the instruction was using the default 16-bit addressing instead of the intended 32-bit addressing). It was literally a 1-bit bug. I manually edited the memory and reran and it was fine. There might have also been a jokingly light back-hand across the face of the team member that wrote the routine that failed.

erwan577 7y ago

This byte article does not seems concerned about the choice of endianness (big-endian or little-endian).

kabdib 7y ago
Honestly, byte order didn't matter much. There were so many more dimensions of incompatibility available that byte-order didn't enter the picture when you were choosing a processor for a product. Most data was exchanged via files written to floppy disks, and you just wrote conversion utilities (or programs dealt with save formats on the fly).
magoghm 7y ago
Endianness matters when you share binary data between computers with different architectures. That didn't happen that often in 1984.

michaelhoffman 7y ago

The ads in this issue for long-forgotten products are amazing.

indigodaddy 7y ago
Yes quite a treasure trove I noticed as well. A lot of disk copying services it seemed?

klodolph 7y ago

For some history—the early Macs in 1984 used 24-bit addressing. The 68000 itself had a 24-bit address bus, but the address registers were 32 bits. So you could use the top 8 bits for some extra data, and programs actually did this (including ROMs/system software for early Macs). This meant that your memory would max out at 8 MiB, with the other half of the address space used for something else (ROM?). When System 7 came out, 32-bit addressing became available but not all software was “32-bit clean”. So you could enable or disable 32-bit addressing in the memory control panel. This is similar to the A20 gate on IBM PCs. By 1993 or so the hardware was no longer built to support 24-bit addressing. PowerMacs followed soon after.

saagarjha 7y ago
I wonder if we’ll ever have to make today’s software “64-bit clean”.
- jjtheblunt 7y ago
  Is that what Apple developers were given a several-year advanced notice of, and Catalina now requires such? I recall many people running non 64-bit clean apps complaining about Catalina, which I found curious.
  - wtallis 7y ago
    Apple dropped support for 32-bit applications. That's different from requiring 64-bit applications to stop abusing unused address bits—something that hasn't ever been commonplace for x86-64.
    - zozbot234 7y ago
      x86-64 actually requires that every memory access occur with a "canonical" address, specifically to ensure that everything will be "64-bit clean". That is, even though virtual address space in some cases may be limited to 48 or 56 bits the actual address has to be sign-extended to 64 bits, so everything is "clean". "Abusing" unused address bits is then just a matter of ensuring that any virtual addresses you use are restricted to the appropriate range. "x32" binaries do this in order to ensure that any pointers will fit within 32 bits even on x86-64, for example.

mhd 7y ago

Interesting to read about the NS32k. The only thing I ever heard it used was the Ceres workstation of the ETH Zurich, the native platform of Wirth's Oberon OS.

cmrdporcupine 7y ago
Jack Tramiel's Atari Corp. evaluated the NS32k series for use in their Atari ST. They even built a prototype. But the processor had bugs and quality issues and they went with the 68k instead. I understand NS did fix their issues but by then it was too late and it never caught on outside of anything but embedded applications (apparently used in laser printers...)
rjsw 7y ago
I had a demo of the Whitechapel Computer Works MG-1 [1] workstation that used it. I knew of but never saw the Acorn systems with that CPU. [1] https://en.wikipedia.org/wiki/Whitechapel_Computer_Works https://en.wikipedia.org/wiki/Whitechapel_Computer_Works
dfawcus 7y ago
Acorn Business Computer model 210 aka Acorn Cambridge Workstation (ACW/443) running panos. See http://chrisacorns.computinghistory.org.uk/Computers/ACW.html http://chrisacorns.computinghistory.org.uk/Computers/ACW.htm... or wikipedia.

elwell 7y ago

Paged through some and found an article on Speech Recognition [0]: Most interesting sentence: "Currently, it is not likely that such techniques would be used for domestic surveillance." Philosophical Issues The specter of Big Brother may not be of concern in Western society today, but the evolution of distributed intelligence among machines with speech-recognition capability certainly provides the technical base for monitoring our activities. In fact, the U.S. National Security Agency has developed what may be the world's most advanced speech-recognition algorithms. This system spots keywords in intercepted verbal transmissions from "unfriendly" nations. Currently, it is not likely that such techniques would be used for domestic surveillance. But speech technologists as well as the public must be aware of the potential loss of privacy. [0] - https://archive.org/details/byte-magazine-1984-01/page/n213 https://archive.org/details/byte-magazine-1984-01/page/n213

stevenwoo 7y ago
This was five years before a 10000 dollar dedicated speech recognition card would be available for home PC's, I remember when we got one for testing when I was working during college at IBM and it was huge like those double slot graphics cards one can buy today, now we can do the equivalent on our phones - it's hard to predict sometimes how fast or where technology is going to advance.
wscott 7y ago
Well, they understood the significance of the year.
romwell 7y ago
Emphasis on "currently".

aidenn0 7y ago

This was an interesting year for S-100, and it's reflected in the ads. The writing was on the wall for the S-100 bus on microcomputers (the PC platform was displacing it), so they were pivoting to the high-end (look at the S-100 SBCs designed to be used in larger installations, the way that VME would eventually be used). There's a good mix of ads for both applications in this issue. The standard was eventually retired 10 years later.

AnimalMuppet 7y ago

Ah, what days those were! Expecting the 68020 to be twice as fast as the 68000 at the same clock speed? Wow. Today we get table scraps of improvement. (On the other hand, the baseline is much higher now...)

snvzz 7y ago
>(On the other hand, the baseline is much higher now...) Which unfortunately hasn't resulted in a more responsive user experience. Faster CPUs just meant that optimising code got less important. Now, we're stuck with a bloated stack, top to bottom.
- matheusmoreira 7y ago
  For some reason latency keeps getting worse. https://danluu.com/input-lag/ https://danluu.com/input-lag/

ThomasBHickey 7y ago

I still have one of the original Apollo/Domain (DN300?) motherboards. It has two Motorola MC68000L8 chips on it. It was explained to me that Apollo found they needed both of them to make virtual memory work. 32 bit data width, 16 bit data bus.

that_jojo 7y ago
It's worth going into why the two CPUs. Basically, the original 68000 isn't capable of atomically restarting an instruction interrupted during a memory access cycle, and so there's no way to implement a standard MMU. So Apollo just chucked in a slave CPU that would detect the interruption of the master CPU, halt it, deal with any remapping or what have you, and then just completely reset the master CPU.
- snvzz 7y ago
  Also worth noting that this was solved in 68010 by changing the exception stack frame. On that regard, it's a shame the Amiga released (1985) with a 68000 cpu. Particularly, move from SR became privileged 010+ and thus caused problems when Amiga finally moved past 68000. Those could have been easily avoided by releasing Amiga on 68010 to begin with, which is also a CPU with slightly higher IPC. They compounded the issue by using 68000 again on A500/A2000 (1987), for negligible savings. Of course, this does pale next to the gross mismanagement Commodore did of the Amiga thereon, which ultimately led to Commodore's own demise.

wbhart 7y ago

The Zilog z80000 wasn't introduced until 1986, but was pipelined and was in some respects about 6 years ahead of Intel. Apparently they are still used today in embedded application, though there was one moderately successful machine based on them back in the day.

dfawcus 7y ago
I recall learning of the z80000 (via a datasheet) in '88, but never managed to find a machine using it. I know of machines designed and built with the z8000, but I've only heard of the z80000 being used for embedded devices (possibly one main customer?). Are you able to provide a reference to an actual general purpose computer built around the z80000?

acqq 7y ago

From the same BYTE, something even today can be recognized as an absolutely amazing achievement: https://ia600609.us.archive.org/BookReader/BookReaderImages.php?zip=/10/items/byte-magazine-1984-01/BYTE-1984-01_jp2.zip&file=BYTE-1984-01_jp2/BYTE-1984-01_0184.jp2&scale=8&rotate=0 https://ia600609.us.archive.org/BookReader/BookReaderImages.... Turbo Pascal - IBM Pascal - Pascal MT+ Price: 49.95 | 300.00 | 595.00 Compile and Link Speed: 1 sec | 97 sec | 90 sec Execution speed: 2.2 sec | 9 sec | 3 sec Disk Space 16 bit: 33K with editor! | 300K + editor | 225K + editor Disk space 8 bit: 28K with editor! | Not Available | 158K + editor ... Locates Run Time errors directly in source code: YES | NO | NO ---- Extended Pascal for your IBM PC, APPLE CP/M, MSDOS, CP/M 86, CCP/M 86 or CP/M 80 computer features: - Full screen interactive editor providing a complete menu driven program development environment. - 11 significant digits in floating point arithmetic. - Built-in transcendental functions. - Dynamic strings with full set of string handling features - Program chaining with common variables. - Random access data files. - Full support of operating system facilities. - And much more.