. Will be testing and as needeed redoing my projects.I am very impressed by how well the Pi handles RISC OS so far.
Re: RISC OS on Raspberry Pi
OK I have RISC OS up and running on my RPi . Will be testing and as needeed redoing my projects.
I am very impressed by how well the Pi handles RISC OS so far.
. Will be testing and as needeed redoing my projects.I am very impressed by how well the Pi handles RISC OS so far.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
Re: RISC OS on Raspberry Pi
I have the demo of crystal rainforest kicking around if your interested. Unfortunately I haven't been able to locate a full version except for Windows
Re: RISC OS on Raspberry Pi
Still I should report problems with keyboard response in case of connection through USB hub or KVM switch.
Re: RISC OS on Raspberry Pi
I am sorry (and happy) to say that a RISC OS USB update will have to wait for some one else. Yesterday I recieved my code, and documentation back in the mail UNOPENED. It seems that unfortunately ROOL has no interest in even looking at my submission, they just sent it back months after I sent it.
I guess that this is due to the LETS LOOSE EVERYTHING mentality. It seems that people have forgotten how important a hard copy is. There is no assurance that the internet will always be here, and there is no way to know that the servers will not fail. With out the hard copies everything will eventualy be lost.
I guess that this is due to the LETS LOOSE EVERYTHING mentality. It seems that people have forgotten how important a hard copy is. There is no assurance that the internet will always be here, and there is no way to know that the servers will not fail. With out the hard copies everything will eventualy be lost.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
Re: RISC OS on Raspberry Pi
I don't know what KVM switch you tested with your Raspberry systems. I had been tested successfully with my ConnectPRO USB DDM KVM switches without any problem.Tirpitz wrote:Still I should report problems with keyboard response in case of connection through USB hub or KVM switch.
Re: RISC OS on Raspberry Pi
I got a bit sidetracked.
The RPi is a greate little computer, and RISC OS is the best OS available for it.
USB is unworthy, terible and problem ridden. The stuff I had previously done with USB had been for a few specific devices per implementation, and thus it worked well. USB fails greately when you attempt to over use it, and generalize it. A single host interface handling HID (Human Interface Devices), Networking, Mass storage, and anything else a RISC OS user may have dangling off the end is a very very bad idea.
USB works with a stream of packets, and there are very specific timming requirements for certain things, while the total throughput may be less than a fourth of the total capability of USB, you need to maintain the timing within certain tolerances or risc loosing information. This can be done better than it is currently in RISC OS (I have at least proven that), though no matter what there will be significant issues.
There is a reason that USB stacks on all operating Systems tend to have significant issues, more so when using multiple high or full speed devices, the standard just was not designed to handle these types of situations. There is no way to fix this short of a new standard.
A more ideal multiple device per bus serial bus would do one of two things (and never allow more than 16 devices on a single controler):
1: implement good host driven arbitration (think I2C) with each device being accessed independantly, and no time overlapping (DO NOT USE PACKETS AS A WAY TO ADDRESS DEVICES).
2: Reliably timeslice devices (Explicitly changing devices at the end of a timeslice), making sure that the time slice is big enough before handing off to the next device in the chain, and never have a timeslice excede (TotalTime/16)-(DeviceSelectTime*2) for a 16 device max system, thus making sure that there will always be enough time to service all devices in a reliable way.
The way that USB does things is horrible and way to complex to fit into a small post. Though one of these days, after I get over the frustration of essentialy having my efforts tossed into the garbage, I may do a write up on USB and why some of the issues can not ever be overcome while using the USB standard.
Just look at the difficulties that you encounter with USB in Windows, Linux, Haiku OS, FreeBSD, NetBSD, AROS, Mac OS, Mac OS X, etc. There is a good reason that none of these systems has been able to implement a completely reliable USB stack.
The RPi is a greate little computer, and RISC OS is the best OS available for it.
USB is unworthy, terible and problem ridden. The stuff I had previously done with USB had been for a few specific devices per implementation, and thus it worked well. USB fails greately when you attempt to over use it, and generalize it. A single host interface handling HID (Human Interface Devices), Networking, Mass storage, and anything else a RISC OS user may have dangling off the end is a very very bad idea.
USB works with a stream of packets, and there are very specific timming requirements for certain things, while the total throughput may be less than a fourth of the total capability of USB, you need to maintain the timing within certain tolerances or risc loosing information. This can be done better than it is currently in RISC OS (I have at least proven that), though no matter what there will be significant issues.
There is a reason that USB stacks on all operating Systems tend to have significant issues, more so when using multiple high or full speed devices, the standard just was not designed to handle these types of situations. There is no way to fix this short of a new standard.
A more ideal multiple device per bus serial bus would do one of two things (and never allow more than 16 devices on a single controler):
1: implement good host driven arbitration (think I2C) with each device being accessed independantly, and no time overlapping (DO NOT USE PACKETS AS A WAY TO ADDRESS DEVICES).
2: Reliably timeslice devices (Explicitly changing devices at the end of a timeslice), making sure that the time slice is big enough before handing off to the next device in the chain, and never have a timeslice excede (TotalTime/16)-(DeviceSelectTime*2) for a 16 device max system, thus making sure that there will always be enough time to service all devices in a reliable way.
The way that USB does things is horrible and way to complex to fit into a small post. Though one of these days, after I get over the frustration of essentialy having my efforts tossed into the garbage, I may do a write up on USB and why some of the issues can not ever be overcome while using the USB standard.
Just look at the difficulties that you encounter with USB in Windows, Linux, Haiku OS, FreeBSD, NetBSD, AROS, Mac OS, Mac OS X, etc. There is a good reason that none of these systems has been able to implement a completely reliable USB stack.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
Re: RISC OS on Raspberry Pi
Well I just Got another monitor for my RPi (my last one gave up the ghost), and am now finaly running the 5.21 version of RISC OS.
I must say that I am surprised at how much it has improved as compared to the 5.19 version, though I have only been using it for a couple of hours so I just may have a lucky couple of hours.
I must say that I am surprised at how much it has improved as compared to the 5.19 version, though I have only been using it for a couple of hours so I just may have a lucky couple of hours.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers