> "Randomly reading from various memory addresses might give the modern programmer some concern about security holes, maybe somehow reading leftover data on the bus an application shouldn't be able to see. On the Apple II, there is no protected memory at all though, so don't worry about it!"
Funnily enough, protected memory (sort of) arrived with the Apple III a couple of years later in 1980 and it was met with complete disdain from the developer community ("Stop trying to control my life, Apple!").
Apple III ROM, hardware, and kernel memory wasn't meant to be directly accessible from the application's address space. The purpose was to increase system stability and to provide a backward-compatible path for future hardware upgrades, but most users and developers didn't see the point and found ways around the restrictions.
Later, more-successful systems used a kinder, gentler approach (please use the provided firmware/bios interfaces please).
Some other hardware features were very good for the time. It gets a lot of heat for the initial reliability issues, but they were eventually solved. They also limited the Apple ][ emulation to 2+ features, so no 80 columns, and that was probably a mistake. On the other hand the good features were:
- Profile hard disk (but would have been better if you could boot from it).
- Movable zero page, so the OS and the application each had their own zero page.
- As mentioned, 80 column text and high resolution graphics.
- Up to 512k addressable RAM, either through indirection or bank switching.
It was probably the most ambitious 6502 based computer, until the 65816 based IIgs came along. And SOS was better than ProDOS.
I remember going to Computerland circa 1981 and they had an Apple /// that they refused to demo for anyone because they were afraid it would burn up. Whatever else might have been wrong about the ///, the /// just plain didn't work reliably.
AFAIK, the ///+ solved most of the problems with the ///, but it failed so badly in the market I’m still looking for one to buy for a reasonable price (I want to try to make it do 384x560 graphics, arguably possible with its interlaced mode).
There's no way a 6502 machine could have beat Z-80 based CP/M machines for business. Not only did the 6502 lack many addressing modes, but it had hardly any registers so you'd struggle even to emulate addressing modes. There was a "direct page" of just 256 bytes that you hypothetically could use to store variables but fitting that into the memory model of languages like C where locals are stack allocated or should look like they are stack allocated is tough.
It was almost impossible to write compilers for languages like Pascal and FORTRAN for the 6502 without resorting to virtual machine techniques like
The latter was atrociously slow and contributed to the spectacle of professors who thought BASIC was brain-damaged advocating terrible alternatives. Commodore added a 6809 to the PET to make a machine you could program in HLLs.
The Apple II was a wildly popular business machine by any measure. Visicalc was an Apple app.
Everyone knows the 6502 is a lousy compiler target particularly if all you understand about compilers is 'what C expects', or at least they did once that became relevant. Those of us there at the time weren't harping on HLL support, since people weren't writing their apps in a HLL but in asm, even on the Z-80.
The big issue with the 6502 is being unable to pass lots of parameters on the hardware stack, but that's all there is to it - one approach was to create a parameter stack independent - you'd just push the size of the called memory space to the hardware stack, using 3 bytes per call for up to 256 worth of parameters and local variables.
I remember seeing C on CP/M circa 1984, the Z80 had compiled BASICs, multiple Pascal implementations including Turbo Pascal although assembly was common. It was still common by the late 1980s on the 8086 platform.
A lot of Apple IIs, mine included, got Z-80 coprocessors for running CP/M. The Z-80 card was, IIRC, the first Microsoft hardware product. Alongside with the Videx 80-column card, it was the most popular expansion for the Apple II plus computers in Brazil as I grew up.
I ran my II+ in dual-head mode, with a long green phosphor monitor on the Videx and a color TV on the main board output.
The /// did have a nice OS -- the perhaps unfortunately named SOS, which was an improvement over the original Apple DOS and was the basis for ProDOS which replaced Apple DOS on the 64K and greater Apple II models.
I've always wanted a force-sensitive keyboard; the harder you hit a key, the more urgently it handles it. Auto-bolded text? Priority of a CLI command proportional to how hard you hit return?
Microsoft did experiment with that some time ago, but the /// was simpler - it was two switches, one actuated at one pressure and the other requiring more force to actuate.
Funnily enough, protected memory (sort of) arrived with the Apple III a couple of years later in 1980 and it was met with complete disdain from the developer community ("Stop trying to control my life, Apple!").
Apple III ROM, hardware, and kernel memory wasn't meant to be directly accessible from the application's address space. The purpose was to increase system stability and to provide a backward-compatible path for future hardware upgrades, but most users and developers didn't see the point and found ways around the restrictions.
Later, more-successful systems used a kinder, gentler approach (please use the provided firmware/bios interfaces please).