I don't know about that - I just got a new processor and everything was fine. None of the other components failed (and I'm still using it now). Luckily I ended up with a faster processor;-)
The processor went bad in a very strange way - every 8th byte or so would become randomly corrupted in the cache. It also depended on the MMU. It was very disconcerting writing code to see stuff change as you ran it!
I plugged in a speaker into the computer while it was on, and the processor blew. It was probably to do with the voltage differences, causing a spike in the PSU.
I can imagine that the Palm may do the same thing, but I'd hope that there would be warnings to tell people to ensure that if they're plugging different things in which are connected to the mains that they'd better make sure everything's off.
Of course, with connectors that earth levels properly, and with spike protection, this shouldn't be an issue.
ISTR that OpenCores were warned not to do an open source ARM compatible processor by ARM. This was probably because ARM is really an IP only company, and if someone comes along and builds their own which is free, then their entire market could collapse.
Then again, the ARM7 processor isn't ARM's latest offering, so they may be lenient.
If you want to know more about the ARM 7 processor, then here is the place to go.
The first Communicator, the 9000i, did not have many features, but did not crash as often as the 9110i which replaced it. My colleagues 9110i needed rebooting more often than a Windows machine (yes, it is possible), so I used the 9000i more.
The 9210 with EPOC should hopefully be a more stable OS; certainly my Psion 5 hasn't crashed, but then I haven't really used it a great deal...
Re:get started on your own project...
on
The LEGO Desk
·
· Score: 1
Having looked at this, does anyonw know why there aren't any blue and yellow blocks available?
It would be better if there was a larger selection available - although I can see the trees being used in some landscape somewhere...
Although the vast majority of RISC OS is 26 bit, parts are in 32-bit already, such as the floating point emulator.
There was talk of a open sourcing RISC OS when Acorn stopped the desktop machine business, but, of course, Pace picked up the pieces. You aren't going to get RISC OS Ltd to release it as open source, because quite a bit of it is owned by Pace.
The ARM10 (v5) datasheet mentions that it is backwardly compatible with ARM7, ARM9 and StrongARM processors, but there is no mention of 26-bit mode even in the ARM7 datasheet (I'm guessing that ARM didn't want people to develop any more 26-bit code, and by not mentioning it, they effectively stopped this). However, if it is to be truly ARM7 compatible, then the 26-bit mode should be present (as it is in ARM7, and StrongARM).
In theory, though, if 26-bit mode isn't present, then with an 800MHz (1000MIPS) processor, and if you could write an emulator that was 20% of the speed, then you'd reach the same kind of level as the current StrongARM processor. I came up with a scheme that I put at about 6% of the speed, and another independant person thought would be 60% of the speed, but it hasn't been proven yet.
Of course, you could have a dual processor machine - one processor would have 26-bit support, and run all the old applications (and some of the kernel), while the new processor would run new applications at significantly faster speeds. This can be emulated now by switching between 26 and 32 bit modes on the fly.
On my display, I have one pixel with stuck red. Under normal use, I don't really notice it. If I'm watching a film, or something, then it can be irritating. However, with smaller pixel densities, you would notice dead pixels less and less as their physical size decreases.
Certainly the Inspiron 7500 that I have does, and I run Linux on a daily basis (and I'm using it right now).
The ethernet card took a while (30 mins) to get working, but everything else works fine. And that includes the suspend to disk, which really surprised me. The only thing lacking is the DVD player;-)
The BBC micro had a virtual screen resolution of 1280x1024 - it had a number of different screen modes (colour depths, resolutions), but the graphical modes all had a virtual resolution of 1280x1024. This meant drawing a line (in BBC BASIC) from the bottom left to the top right was always:
MOVE 0,0: DRAW 1279, 1023
(Yes, (0,0) was bottom left, as opposed to top left)
Slashdot Mirror
I don't know about that - I just got a new processor and everything was fine. None of the other components failed (and I'm still using it now). Luckily I ended up with a faster processor ;-)
The processor went bad in a very strange way - every 8th byte or so would become randomly corrupted in the cache. It also depended on the MMU. It was very disconcerting writing code to see stuff change as you ran it!
I plugged in a speaker into the computer while it was on, and the processor blew. It was probably to do with the voltage differences, causing a spike in the PSU.
I can imagine that the Palm may do the same thing, but I'd hope that there would be warnings to tell people to ensure that if they're plugging different things in which are connected to the mains that they'd better make sure everything's off.
Of course, with connectors that earth levels properly, and with spike protection, this shouldn't be an issue.
Okay, so there appears to have been an Amiga and a Sega version...
Do I remember correctly that Westwood had it available for free download some time back, or am I going mad?
ISTR that OpenCores were warned not to do an open source ARM compatible processor by ARM. This was probably because ARM is really an IP only company, and if someone comes along and builds their own which is free, then their entire market could collapse.
Then again, the ARM7 processor isn't ARM's latest offering, so they may be lenient.
If you want to know more about the ARM 7 processor, then here is the place to go.
"Yup, it's wet today again"...
If you want an MPEG, then see microwavestuff.com...
The first Communicator, the 9000i, did not have many features, but did not crash as often as the 9110i which replaced it. My colleagues 9110i needed rebooting more often than a Windows machine (yes, it is possible), so I used the 9000i more.
The 9210 with EPOC should hopefully be a more stable OS; certainly my Psion 5 hasn't crashed, but then I haven't really used it a great deal...
It would be better if there was a larger selection available - although I can see the trees being used in some landscape somewhere...
There was talk of a open sourcing RISC OS when Acorn stopped the desktop machine business, but, of course, Pace picked up the pieces. You aren't going to get RISC OS Ltd to release it as open source, because quite a bit of it is owned by Pace.
The ARM10 (v5) datasheet mentions that it is backwardly compatible with ARM7, ARM9 and StrongARM processors, but there is no mention of 26-bit mode even in the ARM7 datasheet (I'm guessing that ARM didn't want people to develop any more 26-bit code, and by not mentioning it, they effectively stopped this). However, if it is to be truly ARM7 compatible, then the 26-bit mode should be present (as it is in ARM7, and StrongARM).
In theory, though, if 26-bit mode isn't present, then with an 800MHz (1000MIPS) processor, and if you could write an emulator that was 20% of the speed, then you'd reach the same kind of level as the current StrongARM processor. I came up with a scheme that I put at about 6% of the speed, and another independant person thought would be 60% of the speed, but it hasn't been proven yet.
Of course, you could have a dual processor machine - one processor would have 26-bit support, and run all the old applications (and some of the kernel), while the new processor would run new applications at significantly faster speeds. This can be emulated now by switching between 26 and 32 bit modes on the fly.
On my display, I have one pixel with stuck red. Under normal use, I don't really notice it. If I'm watching a film, or something, then it can be irritating. However, with smaller pixel densities, you would notice dead pixels less and less as their physical size decreases.
Certainly the Inspiron 7500 that I have does, and I run Linux on a daily basis (and I'm using it right now).
The ethernet card took a while (30 mins) to get working, but everything else works fine. And that includes the suspend to disk, which really surprised me. The only thing lacking is the DVD player ;-)
The BBC micro had a virtual screen resolution of 1280x1024 - it had a number of different screen modes (colour depths, resolutions), but the graphical modes all had a virtual resolution of 1280x1024. This meant drawing a line (in BBC BASIC) from the bottom left to the top right was always: MOVE 0,0: DRAW 1279, 1023 (Yes, (0,0) was bottom left, as opposed to top left)