oberonstation vs. a $9 computer
Lars: It is sort of funny that one can use the low price as an argument. How much do you value your time? Let's say it is $5 per hour, way below minimum wage. How much time will you spend on getting anything done with any piece of hardware, be it Arduino, RPi, Beagle Bone, or Oberon Station? Are you going to achieve anything meaningful in less than 10 hours? If so then I will consider hiring you for $50 per hour. The low price does indeed matter if you will use the hardware in a finished product. They are talking of a disposable computer. If you are going to basically throw it away after a single use (provided that you environmental soul lets you do it), then indeed $9 matters. But if you are going to do any development or experimentation with the HW, then you will likely spend hundreds of hours doing so. Then it does not matter if you invest $9, $90, or even $900 into your hardware. Almost any such amount is dwarfed by the cost of your time. Oberon Station is a development platform. The valid question is "development of what?". The initial dollar investment in the development hardware is not that important in this case. W.
The oberon station is tempting, but with Raspberry Pi at $35 or the C.H.I.P computer for $9.00... that has USB, and WIFI that works like any wifi, the oberon station is really priced way out of the market. If the oberonstation was around $50 more people would buy. How can you possibly compete with the C.H.I.P. for $9.00.
Lars, Perhaps you could choose a cheaper FPGA - such as the Altera iCE40 series ($7) and a couple of 512K x 16 SRAMs at $13.35. Then there's the FT2232 at $6.69, and then something like a FTDI Vinculum to act as USB host at $3.99. A 2.25" x 4" 4 layer board will be about $10 from China - but MOQ is 5off. Then there's about $5 to $10 of assorted other components like the connectors, voltage regulator, LEDS, microSD card. So we are up to almost $65 and you haven't even placed a single component. Add another 25% for assembly. What about programming and testing? Right, board built, untested for $81.25. Do you need to make a profit on this? Now you just have to port the risc 5 across to the Altera iCE 40 - which should take a good FPGA engineer about a week..... Alternatively you could run Oberon under Linux on a Pi or a chip, or perhaps just order a $3 PS/2 mouse online. Enjoy........ On 8 February 2016 at 18:12, <skulski@pas.rochester.edu> wrote:
Lars:
It is sort of funny that one can use the low price as an argument. How much do you value your time? Let's say it is $5 per hour, way below minimum wage. How much time will you spend on getting anything done with any piece of hardware, be it Arduino, RPi, Beagle Bone, or Oberon Station? Are you going to achieve anything meaningful in less than 10 hours? If so then I will consider hiring you for $50 per hour.
The low price does indeed matter if you will use the hardware in a finished product. They are talking of a disposable computer. If you are going to basically throw it away after a single use (provided that you environmental soul lets you do it), then indeed $9 matters. But if you are going to do any development or experimentation with the HW, then you will likely spend hundreds of hours doing so. Then it does not matter if you invest $9, $90, or even $900 into your hardware. Almost any such amount is dwarfed by the cost of your time.
Oberon Station is a development platform. The valid question is "development of what?". The initial dollar investment in the development hardware is not that important in this case.
W.
The oberon station is tempting, but with Raspberry Pi at $35 or the C.H.I.P computer for $9.00... that has USB, and WIFI that works like any wifi, the oberon station is really priced way out of the market. If the oberonstation was around $50 more people would buy. How can you possibly compete with the C.H.I.P. for $9.00.
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Ken, you are very close to the actual numbers. A few comments: * The iCE40 series is not an option - too small both in cell count and pin count. Even the Xilinx Spartan6 in 144 QFP package wont have enough pins so you have to go BGA which will increase the assembly cost. * You have to build at least 100 boards to get a reasonable assembly cost, which will tie up something like $10000 in capital. If you are lucky you will sell all of the boards or you will get stuck with unsold inventory. * The assembly house typically have a one-time setup cost (stencils, p&p programming etc.) at typically around $300 (or $3 per board if you build 100). * PayPal or the credit card processor will take about 3% cut or about $3 for a $100 board * Don't forget packaging materials like shipping box, padded bags etc. * There will be some non-functional boards. What if a board gets lost or damaged in shipping, who will pay for that? * You need to build prototypes to make sure the design is good before starting production. Components and PCBs for the prototypes will cost you $500 - $1000 and those boards really can't be sold. * You need to put in several man-weeks of design time to make it happen. So hopefully it's quite clear that selling a board like Pepino LX9/1MB that will run Oberon RISC5 right out of the box for $99.95 is not driven by a desire to make money but rather an effort to make such a board available at a reasonable cost so that others have the opportunity to venture into the world of Oberon RISC5 and FPGAs in general. For more info about Pepino LX9/1MB see http://saanlima.com/store/index.php?route=product/product&product_id=64 Magnus On 2/8/2016 11:18 AM, Ken Boak wrote:
Lars,
Perhaps you could choose a cheaper FPGA - such as the Altera iCE40 series ($7) and a couple of 512K x 16 SRAMs at $13.35.
Then there's the FT2232 at $6.69, and then something like a FTDI Vinculum to act as USB host at $3.99.
A 2.25" x 4" 4 layer board will be about $10 from China - but MOQ is 5off. Then there's about $5 to $10 of assorted other components like the connectors, voltage regulator, LEDS, microSD card.
So we are up to almost $65 and you haven't even placed a single component. Add another 25% for assembly. What about programming and testing?
Right, board built, untested for $81.25. Do you need to make a profit on this?
Now you just have to port the risc 5 across to the Altera iCE 40 - which should take a good FPGA engineer about a week.....
Alternatively you could run Oberon under Linux on a Pi or a chip, or perhaps just order a $3 PS/2 mouse online.
Enjoy........
On 8 February 2016 at 18:12, <skulski@pas.rochester.edu <mailto:skulski@pas.rochester.edu>> wrote:
Lars:
It is sort of funny that one can use the low price as an argument. How much do you value your time? Let's say it is $5 per hour, way below minimum wage. How much time will you spend on getting anything done with any piece of hardware, be it Arduino, RPi, Beagle Bone, or Oberon Station? Are you going to achieve anything meaningful in less than 10 hours? If so then I will consider hiring you for $50 per hour.
The low price does indeed matter if you will use the hardware in a finished product. They are talking of a disposable computer. If you are going to basically throw it away after a single use (provided that you environmental soul lets you do it), then indeed $9 matters. But if you are going to do any development or experimentation with the HW, then you will likely spend hundreds of hours doing so. Then it does not matter if you invest $9, $90, or even $900 into your hardware. Almost any such amount is dwarfed by the cost of your time.
Oberon Station is a development platform. The valid question is "development of what?". The initial dollar investment in the development hardware is not that important in this case.
W.
> The oberon station is tempting, but with Raspberry Pi at $35 > or the C.H.I.P computer for $9.00... that has USB, > and WIFI that works like any wifi, the oberon station > is really priced way out of the market. If the > oberonstation was around $50 more people would buy. > How can you possibly compete with the C.H.I.P. > for $9.00.
-- Oberon@lists.inf.ethz.ch <mailto:Oberon@lists.inf.ethz.ch> mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Dear Oberoners, I've been asked a couple of questions about the RISC.img SD-Card image downloadable from http://projectoberon.com for the FPGA RISC5 Oberon systems. (If you can, please post questions publically rather than emailing me privately - otherwise I have to assume it's a private matter which is more time-consuming to deal with - if I can ever get to it - and doesn't benefit others.) The RISC Oberon system boots from an SD-Card and uses it as its file system. This filesystem is much simpler than common contemporary filesystems such as FAT, FAT32, NTFS, exFAT, EXT4 etc. and is not in any way compatible. (On the original Ceres, the backup floppy disk format was very close to the FAT12 format, but with an altered directory to cope with long filenames, which were not in those days supported on FAT). It would have been easy to make the RISC5 Oberon filesystem (including its reserved area for the bootfile) begin at offset 0 from the beginning of the SD-Card. This would have dedicated the SD-Card to Oberon use, but simplified the bootloader. Or alternatively, the Oberon filesystem could have perhaps been stored as a file in the FAT filesystem on the SD-Card, making it much more accessible to utilities running on other computers. But this convenience would have come at a high cost: it would have made the bootloader much more complicated, and given many more possibilities for distracting problems in development. In the end, it was decided to place the Oberon filesystem at a fixed offset from the beginning of the disk. This was a trivial change to the bootloader, keeping it easily-understandable and within one block ram (BRAM) of the FPGA. This meant that FAT-compatible data structures, and a reasonable-size and perhaps useful (256MB) FAT partition could still exist at the beginning of the disk. If this FAT partition has nothing in it, it compresses very well and therefore does not significantly increase the RISC.img download time. The MBR partition id for the Oberon filesystem was chosen as 0FFh, because the ids are historically rather a free-for-all and the filesystem is not exactly the same format as any that have gone before, even the ETH PC-based Oberon filesystems. 0FFh is clearly an arbitrary value, and also was only used by others for private data structures rather than for filesystems which were interoperable amongst systems. Note that a lot of the motivation for this was defensive. For example it makes it more difficult for the Oberon filesystem to be destroyed when the SD-Card is inserted in a Windows system. When submitting some early additions to Peter de Wachter's RISC emulator https://github.com/pdewacht/oberon-risc-emu for emulated RS232 file transfer which he kindly incorporated, I also included a quick check on startup which allows the use of a disk image which only contains the Oberon file system (called .OBERON.FS in the Windows binary distribution of the emulator which I put on http://projectoberon.com). This check is for the magic number 9B1EA38DH (FileDir.DirMark) which is at the beginning of the root directory sector. Oberon uses a "parity" scheme for sector numbers, making all of them divisible by 29, so the first usable Oberon sector, number 29, begins at SD-Card sector offset 80002H. This slightly odd value comes from the fact that SD-Cards have 512-byte sectors, but Oberon uses two of these (1K) for each Oberon sector, and that sector 0 is not used. So if you are using a nice operating system and you know what you are doing (because it allows dangerous commands such as dd) you can extract the Oberon file system from the image with a command like (262145 = 40001H = 80002H * 512 DIV 1024) dd if=RISC.img of=.OBERON.FS obs=1024 ibs=1024 skip=262145 and you can even (sudo) write it directly back to a real SD-Card with something like dd if=.OBERON.FS of=/dev/disk1 obs=1024 ibs=1024 seek=262145 The name .OBERON.FS was chosen to make it look like a system file, which would be totally destroyed if someone opened it and saved it with a text editor, for example. Hope that's useful! Cheers, Paul
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Paul Reed Sent: Saturday, 13 February 2016 9:55 PM To: ETH Oberon and related systems Subject: [Oberon] RISC.img format
So if you are using a nice operating system and you know what you are doing (because it allows dangerous commands such as dd) you can extract the Oberon file system from the image with a command like (262145 = 40001H = 80002H * 512 DIV 1024)
dd if=RISC.img of=.OBERON.FS obs=1024 ibs=1024 skip=262145
and you can even (sudo) write it directly back to a real SD-Card with something like
dd if=.OBERON.FS of=/dev/disk1 obs=1024 ibs=1024 seek=262145
I use a similar technique on Windows (I assume that is what you were referring to as a not so nice operating system?) using a dd tool which I downloaded from: http://www.chrysocome.net/dd I use it for backing up Project Oberon disk images from an 8Gb MicroSD card onto a PC. Initially I tried this using Win32DiskImager but I couldn't find a way of stopping it from copying the whole 8Gb :( You need to set the 'Run this program as an Administrator' property of dd.exe to access raw physical devices. The command I used was: dd if=\\.\PhysicalDriveN of=ImageName.img bs=1M count=320 --progress This just copies the first 320 MB from the disk which includes the full 64MB Oberon partition. Substitute the device number of your SD Card for N. You can get the number from the list of drives on your system: Administrative Tools > Computer Management > Storage > Disk Management On my system the SD card was shown as Disk 6 so I used if=\\.\PhysicalDrive6. I still use Win32DiskImager to write disk images to the SD cards from a PC as I haven't been able to get dd to work in that direction. If anybody knows how I'd be pleased to hear about it. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com/RISC5
Yes SDs are magically cost-effective. And the problem about finite-life and <even wearing> seems not relevant. I guess they don't have the monsterous software requirement problem that USB has, since they don't need to ID what class of USB they are. Another example of KISS ? Does any of the ETHO documentation describe the SD driver, down to the register level? == Chris Glur.
SD cards are not entirely KISS, but close (or is it MMC that is simple?). Well, if you read https://en.wikipedia.org/wiki/MultiMediaCard https://en.wikipedia.org/wiki/SD_cards you should be satisfyingly confused. Ignoring the multiplicity of standards overlaid onto SD / MMC, you can talk to all cards with a simple SPI port; the only complication is the requirement to go slow until a faster rate is negotiated. Communication is relatively simple once you figure out a consistent way to initialize the card (that works for all the different brands), mostly reading and writing fixed-size 'sectors'. Unlike USB and HDMI, you can use a few FPGA pins directly connected to the port and no proprietary 'black boxes'. Like VGA and PS/2, these are from a simpler time, before businesses blindly followed the Jobsian obfuscation requirements to keep 'consumers' from 'looking under the hood' or 'knowing what they want'. On 02/13/2016 05:55 AM, eas lab wrote:
Yes SDs are magically cost-effective. And the problem about finite-life and <even wearing> seems not relevant. I guess they don't have the monsterous software requirement problem that USB has, since they don't need to ID what class of USB they are. Another example of KISS ?
Does any of the ETHO documentation describe the SD driver, down to the register level?
== Chris Glur. -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Ignoring the multiplicity of standards overlaid onto SD / MMC, you can talk to all cards with a simple SPI port; the only complication is the requirement to go slow until a faster rate is negotiated.
This is a common misunderstanding. In SPI mode there is no need to go slow initially, you can go at full speed right away. The need for slow speed is in SD or MMC mode where the pins are initially open-drain in order to support multiple cards on the same bus. In SPI mode the signaling is always push-pull and you can clock the card at typically up to 25 MHz from the start. See Appendix A in this document http://www.circlemud.org/jelson/sdcard/SDCardStandardv1.9.pdf /Timing specifications // //Design engineers must meet the rise, fall, setup, hold, and other SD Card and MultiMediaCard bus timing specifications. If they want to support MultiMediaCards in their design, the clock speed should be controllable by the host. This is due to the MultiMediaCard's open-drain mode; the MultiMediaCard powers up in the open-drain mode and cannot handle a clock faster than 400 Khz. Once the MultiMediaCard completes the initialization process, the card switches to the push-pull mode. In the push-pull mode the MultiMediaCard can run at the maximum clock speed / Magnus On 2/13/2016 11:12 AM, enso wrote:
SD cards are not entirely KISS, but close (or is it MMC that is simple?). Well, if you read
https://en.wikipedia.org/wiki/MultiMediaCard https://en.wikipedia.org/wiki/SD_cards
you should be satisfyingly confused.
Ignoring the multiplicity of standards overlaid onto SD / MMC, you can talk to all cards with a simple SPI port; the only complication is the requirement to go slow until a faster rate is negotiated. Communication is relatively simple once you figure out a consistent way to initialize the card (that works for all the different brands), mostly reading and writing fixed-size 'sectors'.
Unlike USB and HDMI, you can use a few FPGA pins directly connected to the port and no proprietary 'black boxes'.
Like VGA and PS/2, these are from a simpler time, before businesses blindly followed the Jobsian obfuscation requirements to keep 'consumers' from 'looking under the hood' or 'knowing what they want'.
On 02/13/2016 05:55 AM, eas lab wrote:
Yes SDs are magically cost-effective. And the problem about finite-life and <even wearing> seems not relevant. I guess they don't have the monsterous software requirement problem that USB has, since they don't need to ID what class of USB they are. Another example of KISS ?
Does any of the ETHO documentation describe the SD driver, down to the register level?
== Chris Glur. -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Thanks Magnus! RTFM, as they say. I've wasted a lot of time building speed switching circuits in my life, for no reason! On 02/13/2016 05:35 PM, Magnus Karlsson wrote:
Ignoring the multiplicity of standards overlaid onto SD / MMC, you can talk to all cards with a simple SPI port; the only complication is the requirement to go slow until a faster rate is negotiated.
This is a common misunderstanding. In SPI mode there is no need to go slow initially, you can go at full speed right away. The need for slow speed is in SD or MMC mode where the pins are initially open-drain in order to support multiple cards on the same bus. In SPI mode the signaling is always push-pull and you can clock the card at typically up to 25 MHz from the start.
See Appendix A in this document http://www.circlemud.org/jelson/sdcard/SDCardStandardv1.9.pdf
/Timing specifications // //Design engineers must meet the rise, fall, setup, hold, and other SD Card and MultiMediaCard bus timing specifications. If they want to support MultiMediaCards in their design, the clock speed should be controllable by the host. This is due to the MultiMediaCard's open-drain mode; the MultiMediaCard powers up in the open-drain mode and cannot handle a clock faster than 400 Khz. Once the MultiMediaCard completes the initialization process, the card switches to the push-pull mode. In the push-pull mode the MultiMediaCard can run at the maximum clock speed / Magnus
On Sat, February 13, 2016 12:12 pm, enso wrote:
Unlike USB and HDMI, you can use a few FPGA pins directly connected to the port and no proprietary 'black boxes'.
Like VGA and PS/2, these are from a simpler time, before businesses blindly followed the Jobsian obfuscation requirements to keep 'consumers' from 'looking under the hood' or 'knowing what they want'.
However, USB has simplified products so that we no longer have to run around finding a parallel cable, a printer cable, a serial cable - it's universal. I remember I first rejected USB when it came out as a gimmick. Now look at all the devices that are USB. I was stubborn and purposely bought devices that were not USB, such as my Force RS ACT LABS steering wheel. It had a serial option (not ps/2). You can't ignore the fact that USB has greatly simplified cabling. No longer do we go out and buy bulky wasteful parallel printer cables since serial wasn't good enough (try running a printer off PS/2? why didn't they?). Regarding VGA: what about DVI. Is this obfuscated? One of the reasons they abandoned VGA was because it is analog. Are you arguing for analog over digital? in this case, do you think we should abandon Intel chips and go back to analog computers too, as they may have truly been simpler. After all, intel chips are just black boxes melted together. You can't take a peak into the intel chip like you can an old analog computer... At some point you have to admit that blackboxes can be very useful tools to get where you need to go, such as not requiring knowing absolutely everything about internal combustion engines every time you start you car. Now I know quite a bit about cars, but the question is, should I literally be thinking about every engine movement and physics equation each time I drive my car to get milk, eggs, or spinach (preferably stringy kind).
Lars Did you ever program an Operating System yourself? I agree that USB is nice to "USE" as end-user but not quite as simple to "PROGRAM" as OS developer. Just for your information: - The whole ProjectOberon OS (memory handler, SPI access, display handler, window handler, memory handler, file system, dynamic loading, fonts..) consists of 190kB of source code. - In NativeOberon, USB is implemented. It needs roughly 190kB of source code. Only for USB! br Jörg -----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Lars Sent: Montag, 15. Februar 2016 11:18 To: ETH Oberon and related systems <oberon@lists.inf.ethz.ch> Subject: Re: [Oberon] RISC.img format On Sat, February 13, 2016 12:12 pm, enso wrote:
Unlike USB and HDMI, you can use a few FPGA pins directly connected to the port and no proprietary 'black boxes'.
Like VGA and PS/2, these are from a simpler time, before businesses blindly followed the Jobsian obfuscation requirements to keep 'consumers' from 'looking under the hood' or 'knowing what they want'.
However, USB has simplified products so that we no longer have to run around finding a parallel cable, a printer cable, a serial cable - it's universal. I remember I first rejected USB when it came out as a gimmick. Now look at all the devices that are USB. I was stubborn and purposely bought devices that were not USB, such as my Force RS ACT LABS steering wheel. It had a serial option (not ps/2). You can't ignore the fact that USB has greatly simplified cabling. No longer do we go out and buy bulky wasteful parallel printer cables since serial wasn't good enough (try running a printer off PS/2? why didn't they?). Regarding VGA: what about DVI. Is this obfuscated? One of the reasons they abandoned VGA was because it is analog. Are you arguing for analog over digital? in this case, do you think we should abandon Intel chips and go back to analog computers too, as they may have truly been simpler. After all, intel chips are just black boxes melted together. You can't take a peak into the intel chip like you can an old analog computer... At some point you have to admit that blackboxes can be very useful tools to get where you need to go, such as not requiring knowing absolutely everything about internal combustion engines every time you start you car. Now I know quite a bit about cars, but the question is, should I literally be thinking about every engine movement and physics equation each time I drive my car to get milk, eggs, or spinach (preferably stringy kind). -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
On Sat, February 13, 2016 6:55 am, eas lab wrote:
Yes SDs are magically cost-effective. And the problem about finite-life and <even wearing> seems not relevant. I guess they don't have the monsterous software requirement problem that USB has, since they don't need to ID what class of USB they are. Another example of KISS ?
How do you tell if a card is SDHC (high capacity) or regular SD. How do you tell if it is up to 8GB supported only, or 32GB or 4GB, or 128GB. Isn't this similar to the USB 1.1 vs 2.0 vs 3.0 issues. Maybe not as much of a monster. As for the finite life problem, and the wear down and lost of bits: this is one reason I refuse to do paperless banking, and other fads. Data becomes corrupt very easily unless you make careful backups, which is a chore. Paper, generally does not corrupt, unless there is a fire, or juice is spilled on the paper (real programmers don't drink coffee, I'm afraid).
Thanx Paul for the clarification. I wrote an Oberon program to copy files from or to the RISC.img file. This might be useful for people running eg Linz Oberon (on Windows) or RP de Jong 's RISC emulator on Mac to copy Windows or Mac files "easily" to FPGA ProjectOberon. Please mail me if you're interested. br Jörg
Am 13.02.2016 um 12:24 schrieb Paul Reed <paulreed@paddedcell.com>:
Dear Oberoners,
I've been asked a couple of questions about the RISC.img SD-Card image downloadable from http://projectoberon.com for the FPGA RISC5 Oberon systems. (If you can, please post questions publically rather than emailing me privately - otherwise I have to assume it's a private matter which is more time-consuming to deal with - if I can ever get to it - and doesn't benefit others.)
The RISC Oberon system boots from an SD-Card and uses it as its file system. This filesystem is much simpler than common contemporary filesystems such as FAT, FAT32, NTFS, exFAT, EXT4 etc. and is not in any way compatible. (On the original Ceres, the backup floppy disk format was very close to the FAT12 format, but with an altered directory to cope with long filenames, which were not in those days supported on FAT).
It would have been easy to make the RISC5 Oberon filesystem (including its reserved area for the bootfile) begin at offset 0 from the beginning of the SD-Card. This would have dedicated the SD-Card to Oberon use, but simplified the bootloader.
Or alternatively, the Oberon filesystem could have perhaps been stored as a file in the FAT filesystem on the SD-Card, making it much more accessible to utilities running on other computers. But this convenience would have come at a high cost: it would have made the bootloader much more complicated, and given many more possibilities for distracting problems in development.
In the end, it was decided to place the Oberon filesystem at a fixed offset from the beginning of the disk. This was a trivial change to the bootloader, keeping it easily-understandable and within one block ram (BRAM) of the FPGA.
This meant that FAT-compatible data structures, and a reasonable-size and perhaps useful (256MB) FAT partition could still exist at the beginning of the disk. If this FAT partition has nothing in it, it compresses very well and therefore does not significantly increase the RISC.img download time.
The MBR partition id for the Oberon filesystem was chosen as 0FFh, because the ids are historically rather a free-for-all and the filesystem is not exactly the same format as any that have gone before, even the ETH PC-based Oberon filesystems. 0FFh is clearly an arbitrary value, and also was only used by others for private data structures rather than for filesystems which were interoperable amongst systems.
Note that a lot of the motivation for this was defensive. For example it makes it more difficult for the Oberon filesystem to be destroyed when the SD-Card is inserted in a Windows system.
When submitting some early additions to Peter de Wachter's RISC emulator
https://github.com/pdewacht/oberon-risc-emu
for emulated RS232 file transfer which he kindly incorporated, I also included a quick check on startup which allows the use of a disk image which only contains the Oberon file system (called .OBERON.FS in the Windows binary distribution of the emulator which I put on http://projectoberon.com).
This check is for the magic number 9B1EA38DH (FileDir.DirMark) which is at the beginning of the root directory sector. Oberon uses a "parity" scheme for sector numbers, making all of them divisible by 29, so the first usable Oberon sector, number 29, begins at SD-Card sector offset 80002H. This slightly odd value comes from the fact that SD-Cards have 512-byte sectors, but Oberon uses two of these (1K) for each Oberon sector, and that sector 0 is not used.
So if you are using a nice operating system and you know what you are doing (because it allows dangerous commands such as dd) you can extract the Oberon file system from the image with a command like (262145 = 40001H = 80002H * 512 DIV 1024)
dd if=RISC.img of=.OBERON.FS obs=1024 ibs=1024 skip=262145
and you can even (sudo) write it directly back to a real SD-Card with something like
dd if=.OBERON.FS of=/dev/disk1 obs=1024 ibs=1024 seek=262145
The name .OBERON.FS was chosen to make it look like a system file, which would be totally destroyed if someone opened it and saved it with a text editor, for example.
Hope that's useful! Cheers, Paul
On 2/13/2016 3:24 AM, Paul Reed wrote:
In the end, it was decided to place the Oberon filesystem at a fixed offset from the beginning of the disk. This was a trivial change to the bootloader, keeping it easily-understandable and within one block ram (BRAM) of the FPGA.
This meant that FAT-compatible data structures, and a reasonable-size and perhaps useful (256MB) FAT partition could still exist at the beginning of the disk. If this FAT partition has nothing in it, it compresses very well and therefore does not significantly increase the RISC.img download time.
Another option for transferring data to/from the Oberon system would be to write a lightweight FAT disk access driver in Oberon and load/store files in the 256MB FAT partition that exists at the beginning of the SD card. This would allow any system that can mount the FAT partition to access the files. There are several open-source lightweight FAT access code written in C or C++ for small microcontroller systems (like elm-chan's FatFS, http://elm-chan.org/fsw/ff/00index_e.html or the Arduino SD library, https://www.arduino.cc/en/Reference/SD) that might be used as a starting point for an Oberon version. Magnus
On Tue, February 9, 2016 8:42 am, Magnus Karlsson wrote:
Ken, you are very close to the actual numbers.
A few comments: * The iCE40 series is not an option - too small both in cell count and pin count. Even the Xilinx Spartan6 in 144 QFP package wont have enough pins so you have to go BGA which will increase the assembly cost. * You have to build at least 100 boards to get a reasonable assembly cost, which will tie up something like $10000 in capital. If you are lucky you will sell all of the boards or you will get stuck with unsold inventory. * The assembly house typically have a one-time setup cost (stencils, p&p programming etc.) at typically around $300 (or $3 per board if you build 100). * PayPal or the credit card processor will take about 3% cut or about $3 for a $100 board * Don't forget packaging materials like shipping box, padded bags etc. * There will be some non-functional boards. What if a board gets lost or damaged in shipping, who will pay for that? * You need to build prototypes to make sure the design is good before starting production. Components and PCBs for the prototypes will cost you $500 - $1000 and those boards really can't be sold. * You need to put in several man-weeks of design time to make it happen.
So hopefully it's quite clear that selling a board like Pepino LX9/1MB that will run Oberon RISC5 right out of the box for $99.95 is not driven by a desire to make money but rather an effort to make such a board available at a reasonable cost so that others have the opportunity to venture into the world of Oberon RISC5 and FPGAs in general.
Neither is the Orange Pi One much of an effort to make money, considering it costs $15, and a regular orange pi costs around $20-$30... However, I doubt that the world ever doesn't involve money in it's process. Example: I bet Wirth wrote some books so he could eat food, i.e. use the money from his books to fund his cheese/wine habits, and hopefully spinach soon when he discovers "strings". Really though, I bet Orange Pi one for $15 is still pulling in a small profit so the chinese companies (or whoever makes them) are able to buy food for the factory workers. Everything requires money. Even educational institutions which offer supposed "free education" like Norway, are not free at all. This was discussed by Milton Friedman "there is no free lunch". i.e. Wirth has to eat some how, and the supplier of Oberon station somehow has to eat food, to live. If he dies, he can't ship the product. A lot of people release "Free source code" online, but it's not free at all. It's subsidized by money some how, such as Google paying a developer to work on an "open source" project.
For more info about Pepino LX9/1MB see http://saanlima.com/store/index.php?route=product/product&product_id=64
Thanks, I will study. Regards, Lars Don't worry I'm not a libertarian kook.
Lars, are you a moron or just pretending? No one can _make_ a $9.00 computer. You can sell a computer for $9.00, at a loss, if you are funded by a VC, for instance. It is fashionable for startups to lose money in order to gain market share, and then sell the business to some other moron. However, it's only worth it if the market is more than 300 people. Just go be a visionary somewhere else.
Some schools are more industry oriented, and prepare the students for the real world. The real world uses USB and has long abandoned PS/2,
Yes, the kiddies learn how to *SPELL* u.s.b. and that it's currently popular. Do *YOU* know the inner workings of USB? --- ] Would you please explain what "string" functionality is missing. ] ] Jörg Didn't you read: they've recently confirmed Einstein's <gravity waves>? It's all about black-holes, multiple-universes , string-theory & USB ! == Chris Glur.
On Mon, February 8, 2016 12:18 pm, Ken Boak wrote:
Lars,
Perhaps you could choose a cheaper FPGA - such as the Altera iCE40 series ($7) and a couple of 512K x 16 SRAMs at $13.35.
Then there's the FT2232 at $6.69, and then something like a FTDI Vinculum to act as USB host at $3.99.
A 2.25" x 4" 4 layer board will be about $10 from China - but MOQ is 5off. Then there's about $5 to $10 of assorted other components like the connectors, voltage regulator, LEDS, microSD card.
So we are up to almost $65 and you haven't even placed a single component. Add another 25% for assembly. What about programming and testing?
Right, board built, untested for $81.25. Do you need to make a profit on this?
Yet somehow Orange Pi managed to sell for $15.00... The whole point of orange pi and C.H.I.P. are that you can start creating hardware immediately without hiring all these engineers. Embedded is now "muddy waters". What does embedded actually mean any more, if an orange pi can run a desktop like O.S. on it? Is it even embeddeded, if it's actually a desktop PC that fits almost inside a credit card sized wallet slot.
Now you just have to port the risc 5 across to the Altera iCE 40 - which should take a good FPGA engineer about a week.....
Alternatively you could run Oberon under Linux on a Pi or a chip, or perhaps just order a $3 PS/2 mouse online.
Or buy Orange Pi for $15 and forget about the ps/2 mouse altogether since I have 5 USB keyboards sitting around doing nothing. And run oberon using a oberon linux compiler, or an oberon emulator. All for $15. Now on the other hand, if I purchase C.H.I.P. it's $9 but I have to wait 6 months for it to arrive in the mail. Oberon Station beats it in this sense, as Oberon Station can be shipped immediately. No 6 month wait. C.H.I.P. has also been exposed for selling at a loss. $9 is not the actual price it costs to make chip at a profit. They make the money selling accessories. However, orange pi one at $15 is selling just fine, and has been for years. Or Orange pi for $25-$30 that's not a "one", but the next model up. Do you really think that educational institutions and schools are going to buy a ps/2 system like oberon station for over 100 dollars when they can instead buy Orange Pi and have their students actually learn something about USB, which is used in the industry. Schools prepare kids for the industry, and the industry no longer uses ps/2. Far separated from reality, academics sometimes like to ignore the industry altogether. Some schools are more industry oriented, and prepare the students for the real world. The real world uses USB and has long abandoned PS/2, except for some old systems and terminals that still use it.... I'm guessing there is at least one active Nuclear power plant that still uses a serial keyboard, or a membrane keyboard that uses something much older than ps/2.
On Mon, February 8, 2016 11:12 am, skulski@pas.rochester.edu wrote:
Lars:
It is sort of funny that one can use the low price as an argument. How much do you value your time? Let's say it is $5 per hour, way below minimum wage. How much time will you spend on getting anything done with any piece of hardware, be it Arduino, RPi, Beagle Bone, or Oberon Station? Are you going to achieve anything meaningful in less than 10 hours? If so then I will consider hiring you for $50 per hour.
Ever consider a product, that builds on raspberry pi, or Orange pi, like an MP3 player that is hackable. Most MP3 players are soldered/melted together so you cannot modify them, and cost about $15, or if you want to get ripped off go to Apple and buy one for $200 or whatever the latest iPod costs. Now consider an orange pi or raspberry pi that is literally an MP3 player you can modify and customize to do anything you want. No one is ever going to buy a $150 oberon mp3 player when you can buy an orange pi based on for $50 or less that does way more, and even has USB. OberonStation is simply an academic learning experience like STANDARD pascal and will fade away into obscurity. I am a prophet of sorts, and have predicted such demise before.
The low price does indeed matter if you will use the hardware in a finished product. They are talking of a disposable computer. If you are going to basically throw it away after a single use (provided that you environmental soul lets you do it), then indeed $9 matters.
But the oberonstation is also disposable. You can simply download an oberonstation Emulator and play with it, and forget about buying it altogether... define "disposable". Last I heard, raspberry pis are not in fact disposable at all, considering people still own them from many years ago and still use them, and even resell them on ebay. A truly disposable product is one that has no market value on ebay: search ebay for OberonStation and you get zero results. I.e. a product that has no value: disposable. Tell me what you can actually do with oberonstation that's worth $100 bucks or even $70 bucks, that you can't do with Rasp Pi or Orange pi. An orange pi costs around $15. Why couldn't you simply buy an orange pi, and run an oberon emulator on it, and save $100 or more. Or port oberon over to Orange Pi, not as an educational minimalist project since USB is not something that is as simple as PS/2. But there is something out there called the real world. Rasp. Pi and Orange pi sell millions, while oberon station has zero followers (virtually). A school is not going to spend $100 on a device that has almost zero features, when an Orange Pi costs $15 and cuts the schools' cost down almost tenfold. Oberon is intended for teaching, and even that it has failed at, because the Rasp Pi is more affordable for schools. I supposed a subsidized socialist tax based system could afford to buy 10,000 Oberon Station's if the country had some oil royalties (Norway) to pay the bill. Welcome to the real world where Orange Pi, BeagleBone, and Rasp Pi will literally kill OberonStation in sales and popularity. Not that popularity is the only measure of success, as we all know that C++ and PHP are examples of popular failures.
On Mon, February 15, 2016 12:54 am, Paul Reed wrote:
Tell me what you can actually do with oberonstation that's worth $100 ... that you can't do with [a $35] Rasp[berry] Pi...
Teach. How. It. Actually. Works.
Paul
True, the BeagleBone is competing though since the BeagleBone is more open, and also CubieBoard. It's more of an oranges to grapefruits comparison, not apples. Grapefruits and oranges are very similar, yet have differences. BeagleBone is worth around $50 still more economical than OberonStation. Now I can argue that buying a bicycle is much better than a car since a bike's parts can easily be taught to someone and visualized immediately. Those of us over in the real world, tend to drive cars, and keep pedal bikes as rare toys to use on a saturday. At least bikes haven't faded away into summer obscurity. Some people still ride in the winter.
On Mon, February 15, 2016 2:52 am, I previously wrote:
the BeagleBone is competing though since the BeagleBone is more open, and also CubieBoard.
A way to cut costs on the OberonStation (second version) may in fact be to remove the FPGA, as that may be the costly part. I have not researched this and am speaking in ignorance here. i.e. rasp pi FPGA accessories and boards are quite expensive, yet the rasp pi itself is not so expensive. How come oberon station uses an FPGA, is it for absolute precise control over everything, whereas a fixed circuit would not be as teachable or as controllable? Or FPGA is easier to run oberon on?
-----Original Message----- From: Oberon [mailto:oberon-bounces@lists.inf.ethz.ch] On Behalf Of Lars Sent: Monday, 15 February 2016 8:36 PM To: ETH Oberon and related systems Subject: Re: [Oberon] Apples vs Oranges
How come oberon station uses an FPGA
Because designers of commercial RISC processors have forgotten what the 'R' in RISC stands for.
participants (10)
-
Chris Burrows -
eas lab -
enso -
Jörg -
Jörg Straube
-
Ken Boak -
Lars -
Magnus Karlsson -
Paul Reed -
skulski＠pas.rochester.edu