Planetoid and Elite proved that you could do plenty. Planetoid used the full colour 20kB mode and hardware scrolling. Elite used a mixed medium res monochrome mode and low res 4 colour mode. Presumably using 10kB.
For an IDE where you had floppy available, presumably you used teletext graphics (1kB) for the coding, and saved the source code to disk before running so the object code could use any graphics mode it needed.
This was the power of the BBC Micro graphics. A choice of low memory teletext mode and several different pixel-addressable graphics modes.
Sure there were possibilities for trickery with the Spectrum speaker, but any time spent on IRQs serving speaker sound was lost from time spent doing the graphics. In practice it was an either/or. You didn't have games doing anything impressive with sound during gameplay on the Speccy. But on the BBC, it was no problem.
Not as many though. And they were doing the parts of the thing that were NOT programming, that while educational took time away from deep learning of programming.
They programmed them first, then distributed them.
"I'd say that a far greater proportion of the developers were school children then than now." I'd say totally the opposite. There are way more younger developers now than there were back in the day; if for no other reason than because LOTS more households have computers now.
Note the word "proportion" in what I said. That means it doesn't matter that more households have computers now.
BBC Micro owners weren't jealous of anyone. They had it all. Pixel addressable colour graphics, good at scrolling, better than the speccy at isometric (because of lack of attribute clashes). Programmable sound chip.
Better graphics modes too. Colour addressable per pixel in various resolutions, plus a teletext mode that only used 1KB. And commands in the BASIC interpreter to draw on that screen too.
And sound. BBC Micro had 3 channels of tones, plus a white noise channel, all ADSR programmable. Speccy had a single bit attached to a speaker.
Using up 2/3rds of the RAM for graphics was worth it considering it got proper per pixel colours. Speccy games always looked shit because of their per character colour system.
But don't forget there was also the option of Teletext graphics for the BBC Micro which gave coloured text and very blocky graphics in just 1KB.
I know a few ten year olds selling apps on the App Store!!! How is that not even more awesome and impressive than my writing a crossword puzzle generator at the same age?
But there were children selling apps back then too. Only they were doing the full business, accepting mail-order cheques, duplicating to cassette tapes, making the labels and instructions, and mailing them out.
I'd say that a far greater proportion of the developers were school children then than now.
It made Spectrum Basic readable; it ensured that the commands and keywords were always written in full, rather than the shorthand that crept up everywhere else.
The shorthand that other computers had was only for input. Because it was tokenized, listings would always spell keywords in full regardless of how you'd input them.
For example on the BBC Micro you could input: 10 P."Hello World!" and the output would be 10 PRINT "Hello World!"
On the few occasions I used a speccy I found the keyboard to be horribly confusing, with it's multiple functions printed on and around each key.
A tokenizer wouldn't need a few hundred bytes. In those days we coded algorithms like that very efficiently. A few tens of bytes perhaps.
The biggest part of it would be the look up table for the keywords. But that would be needed for output of the listing regardless.
As a point of comparison, the Acorn Atom had a BASIC with a tokenizer, and it's ROM was 8KB versus the Spectrum's 16KB ROM. To be fair though the spectrum was probably just doing it that way for consistency with ZX80 & ZX81. The ZX80 only having 4KB ROM.
The ultimate question is how likely is it that a user of a particular system will get malware or get hacked. Reducing that number is what security measures are all about. If there is a lot of malware around for a system, then obviously users are more likely to get it.
You can argue all you like about the security features of Chubb and Yale locks, but if lots of Chubb locks are bypassed by thieves and virtually no Yale locks are, that would be strong evidence that Yale is more secure.
Programming with tape machines was the real exercise in patience. Kids these days don't know how easy they have it with source files saved in a moment, automatically before each compile. It took us 5 minutes to save to tape. And we had to keep track of what version of what program we stored where on what tape.
If we didn't save before running we risked a crash and losing everything we'd added since the last save. Knowing when to take the risk and when it was time to save was the only way of making progress.
And yet, somehow, programming then was still more fun than today.
For this you'll need Apple to back pedal on some simplification they've made to make their OS more accessible to less technical people. (Like installing application simply by drag-droping an icon from an archive into a system folder. With no privilege asked).
There's no simplification there. It's standard Unix permissions. The normal Application folder is shared between users for read and execute, but you need admin privileges to write there. So only admins can install there. A user can set up their own private Applications folder if they want and install applications there though.
Neither Applications folder is a system folder.
This ability to do drag and drop installs has precisely nothing to do with vulnerability to malware.
You'd do better to restrict predictions of the future to things you know something about.
Wiki says estimates of Conflicker infections were between 9 million and 15 million in Mar 2009. Installed base of PCs was about 1.1 billion then. Which would mean Conflicker had between 0.8% and 1.4% of PCs infected.
The choice that you desire is exactly what you get with Android, with the result of lots of malware - including on the official stores(s).
The safe app store plus the possibility of switching to ghetto stores if you desire it doesn't exist. As least not officially. The closest you can get to it is the iOS App Store + Jailbroken phone.
You're showing your ignorance again. Apple did care about it, and that's what got the rule about asking for user permission before uploading contact details came from. A rule which Path now adheres to, which is why it's still in the App Store.
Android requires that you give consent, since it tells you what permissions the application needs prior to installing it.
It's the wrong time to ask, and the information to make the decision isn't complete enough. For example, these days huge numbers of apps have social components, so permission to access the contacts list is not a warning sign. And at install time the user may only have a hazy idea of the features of the app anyway.
If you're going to have a permission based system, the request for permission should come at the point in time when the restricted resource is about to be used, and should come with an explanation for why.
Even them such permission schemes are of limited utility. If I was a malware creator who wanted access to the contacts list, I'd make sure that the malware was hidden in an app category where access to the contact list was normal.
Positive vetting of apps is a far better scheme for weeding out malware.
The Path app is not malware. It's still on sale on the App Store, and has 5 times as many five star ratings as any other rating, and litterally zero one star ratings. (the possible ratings run from one to five stars).
Email addresses were uploaded simply to facilitate a find-my-friends feature of social networking.
It was a naive implementation, because the same functionality could be achieved simply by uploading hashes of the email addresses. And it was wrong that in earlier versions it didn't explicitly ask the users permission to upload those email addresses.
But there's no evidence of malign behaviour. Only behaviour intended to implement the advertised features.Therefore it's not malign software; it's not malware.
You CHOSE to upgrade your iPhones to the latest iOS version, that iOS version wasn't supported by the version of iTunes you had on your computer, so you CHOSE to upgrade iTunes too.
The fact that one software product is only compatible with certain version numbers of another software product doesn't make for a forced upgrade.
It's only malware if it's doing it for malevolent purposes. If an app is uploading your contacts for the purposes of matching up social graphs within the app to deliver the features the app promises, then that's not malware.
It's poor app design... that is better done by uploading hashes of email addresses rather than actual addresses. But it's not malware.
It's also unacceptable and is against specific App Store rules that now require explicit approval, each time before an app does such a thing. But its still not malware.
What there isn't on iPhone is apps that covertly send premium rate SMS messages. But there is on Android.
Slashdot Mirror
Planetoid and Elite proved that you could do plenty. Planetoid used the full colour 20kB mode and hardware scrolling. Elite used a mixed medium res monochrome mode and low res 4 colour mode. Presumably using 10kB.
For an IDE where you had floppy available, presumably you used teletext graphics (1kB) for the coding, and saved the source code to disk before running so the object code could use any graphics mode it needed.
This was the power of the BBC Micro graphics. A choice of low memory teletext mode and several different pixel-addressable graphics modes.
Sure there were possibilities for trickery with the Spectrum speaker, but any time spent on IRQs serving speaker sound was lost from time spent doing the graphics. In practice it was an either/or. You didn't have games doing anything impressive with sound during gameplay on the Speccy. But on the BBC, it was no problem.
LOL! You're obviously too young to remember. Most 8-bit computer's BASIC was Microsoft BASIC. Commodore BASIC was licensed from Microsoft BASIC.
Nothing to do with Visual Basic, That came more than 10 years later.
Take a look here for confirmation that I'm right.
http://en.wikipedia.org/wiki/Microsoft_Basic
Back in those days Microsoft was actually respected.
Not as many though. And they were doing the parts of the thing that were NOT programming, that while educational took time away from deep learning of programming.
They programmed them first, then distributed them.
"I'd say that a far greater proportion of the developers were school children then than now."
I'd say totally the opposite. There are way more younger developers now than there were back in the day; if for no other reason than because LOTS more households have computers now.
Note the word "proportion" in what I said. That means it doesn't matter that more households have computers now.
BBC Micro owners weren't jealous of anyone. They had it all. Pixel addressable colour graphics, good at scrolling, better than the speccy at isometric (because of lack of attribute clashes). Programmable sound chip.
It was only outdone when the 16-bit era arrived.
Better graphics modes too. Colour addressable per pixel in various resolutions, plus a teletext mode that only used 1KB. And commands in the BASIC interpreter to draw on that screen too.
And sound. BBC Micro had 3 channels of tones, plus a white noise channel, all ADSR programmable. Speccy had a single bit attached to a speaker.
Using up 2/3rds of the RAM for graphics was worth it considering it got proper per pixel colours. Speccy games always looked shit because of their per character colour system.
But don't forget there was also the option of Teletext graphics for the BBC Micro which gave coloured text and very blocky graphics in just 1KB.
I know a few ten year olds selling apps on the App Store!!! How is that not even more awesome and impressive than my writing a crossword puzzle generator at the same age?
But there were children selling apps back then too. Only they were doing the full business, accepting mail-order cheques, duplicating to cassette tapes, making the labels and instructions, and mailing them out.
I'd say that a far greater proportion of the developers were school children then than now.
Of course there was early attempts at DRM back then too.
The BBC Micro for example introduced a file lock in ROM v1.2 (I think) that meant you could only execute a program from tape, not load it for copying.
And commercial games had things like the LENSLOK protection.
It made Spectrum Basic readable; it ensured that the commands and keywords were always written in full, rather than the shorthand that crept up everywhere else.
The shorthand that other computers had was only for input. Because it was tokenized, listings would always spell keywords in full regardless of how you'd input them.
For example on the BBC Micro you could input:
10 P."Hello World!"
and the output would be
10 PRINT "Hello World!"
On the few occasions I used a speccy I found the keyboard to be horribly confusing, with it's multiple functions printed on and around each key.
In fact most BASICs of that period were Microsoft BASIC, including Commodore and TRS-80.
And yes, that and every other BASIC interpreter I've ever heard of stored the program as tokens.
A tokenizer wouldn't need a few hundred bytes. In those days we coded algorithms like that very efficiently. A few tens of bytes perhaps.
The biggest part of it would be the look up table for the keywords. But that would be needed for output of the listing regardless.
As a point of comparison, the Acorn Atom had a BASIC with a tokenizer, and it's ROM was 8KB versus the Spectrum's 16KB ROM. To be fair though the spectrum was probably just doing it that way for consistency with ZX80 & ZX81. The ZX80 only having 4KB ROM.
The ultimate question is how likely is it that a user of a particular system will get malware or get hacked. Reducing that number is what security measures are all about. If there is a lot of malware around for a system, then obviously users are more likely to get it.
You can argue all you like about the security features of Chubb and Yale locks, but if lots of Chubb locks are bypassed by thieves and virtually no Yale locks are, that would be strong evidence that Yale is more secure.
Programming with tape machines was the real exercise in patience. Kids these days don't know how easy they have it with source files saved in a moment, automatically before each compile. It took us 5 minutes to save to tape. And we had to keep track of what version of what program we stored where on what tape.
If we didn't save before running we risked a crash and losing everything we'd added since the last save. Knowing when to take the risk and when it was time to save was the only way of making progress.
And yet, somehow, programming then was still more fun than today.
For this you'll need Apple to back pedal on some simplification they've made to make their OS more accessible to less technical people. (Like installing application simply by drag-droping an icon from an archive into a system folder. With no privilege asked).
There's no simplification there. It's standard Unix permissions. The normal Application folder is shared between users for read and execute, but you need admin privileges to write there. So only admins can install there. A user can set up their own private Applications folder if they want and install applications there though.
Neither Applications folder is a system folder.
This ability to do drag and drop installs has precisely nothing to do with vulnerability to malware.
You'd do better to restrict predictions of the future to things you know something about.
Wiki says estimates of Conflicker infections were between 9 million and 15 million in Mar 2009. Installed base of PCs was about 1.1 billion then. Which would mean Conflicker had between 0.8% and 1.4% of PCs infected.
It's too close to call.
The choice that you desire is exactly what you get with Android, with the result of lots of malware - including on the official stores(s).
The safe app store plus the possibility of switching to ghetto stores if you desire it doesn't exist. As least not officially. The closest you can get to it is the iOS App Store + Jailbroken phone.
As classy as the username implies.
You're showing your ignorance again. Apple did care about it, and that's what got the rule about asking for user permission before uploading contact details came from. A rule which Path now adheres to, which is why it's still in the App Store.
Android requires that you give consent, since it tells you what permissions the application needs prior to installing it.
It's the wrong time to ask, and the information to make the decision isn't complete enough. For example, these days huge numbers of apps have social components, so permission to access the contacts list is not a warning sign. And at install time the user may only have a hazy idea of the features of the app anyway.
If you're going to have a permission based system, the request for permission should come at the point in time when the restricted resource is about to be used, and should come with an explanation for why.
Even them such permission schemes are of limited utility. If I was a malware creator who wanted access to the contacts list, I'd make sure that the malware was hidden in an app category where access to the contact list was normal.
Positive vetting of apps is a far better scheme for weeding out malware.
Well, in country politics terms it'd be more like Sweden, and less like Columbia.
The Path app is not malware. It's still on sale on the App Store, and has 5 times as many five star ratings as any other rating, and litterally zero one star ratings. (the possible ratings run from one to five stars).
Email addresses were uploaded simply to facilitate a find-my-friends feature of social networking.
It was a naive implementation, because the same functionality could be achieved simply by uploading hashes of the email addresses. And it was wrong that in earlier versions it didn't explicitly ask the users permission to upload those email addresses.
But there's no evidence of malign behaviour. Only behaviour intended to implement the advertised features.Therefore it's not malign software; it's not malware.
No one told him to upgrade or lose access to his personal property. If he'd have done nothing he wouldn't have lost access to his personal property.
You CHOSE to upgrade your iPhones to the latest iOS version, that iOS version wasn't supported by the version of iTunes you had on your computer, so you CHOSE to upgrade iTunes too.
The fact that one software product is only compatible with certain version numbers of another software product doesn't make for a forced upgrade.
Reality check: it's a phone, not your life.
It's only malware if it's doing it for malevolent purposes. If an app is uploading your contacts for the purposes of matching up social graphs within the app to deliver the features the app promises, then that's not malware.
It's poor app design... that is better done by uploading hashes of email addresses rather than actual addresses. But it's not malware.
It's also unacceptable and is against specific App Store rules that now require explicit approval, each time before an app does such a thing. But its still not malware.
What there isn't on iPhone is apps that covertly send premium rate SMS messages. But there is on Android.