User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Putting the RPi in the perspective, looking Retro.

Tue Nov 27, 2018 4:35 pm

This is not about comparison of these with the RPi, or any of that kind of thing. Input is great on this, I hope it may give others some thoughts, as well as anything that can be learned is always good.

This is about what we can learn from the old to help with the new.

I hope that those that are working on Operating Systems and Bare Metal projects for the RPi take a moment to look at the past themselves to better understand where the future could go.

I want only to inspire any developer to look at the past before implementing something new on the RPi, especially if it is an OS. We can learn a lot for the past, especially if writing an Operating System.

Looking at the HW, quickly:
I have been looking at the capabilities of the Raspberry Pi in terms of what the HW provides us. A bit of a bare metal view, though it may put into perspective what we may learn from the past in furthering the Raspberry Pi. The hope is to learn what can be done in, and what has worked well in the past that can be brought up to the RPi, especially in the areas of OS, Games, Graphics applications, and similar. In this I am mostly ignoring the VideoCoreIV for anything other than a FrameBuffer and simple DSP (which is a way that we can use the VideoCore well even in bare metal).

Blitter: Of the retro systems being compared only the Amiga and Atari ST/Falcon had Blitter. The DMA controllers of the Raspberry Pi are more than capable of doing most of what the blitter of the past did, and the newer DMA has abilities that Blitter could never dream about. So this is one that has come to a nearly direct evolution of the technology.

Copper: Only the Amiga had a Copper. Today the same thing can be done on the RPi with ease, though differently. This requires a small amount of code on the GPU, though within our limits, to implement the equivalent of a display list, and tell the DMA what to do. Though we only have one horizontal and vertical resolution on screen at a time with the RPi. There may even be other ways to accomplish this trick without the GPU (and without the CPU), I just do not know them yet.

MMU: The Atari TT/Falcon Some Amiga's, and the Acorn Archimedes had and used an MMU. The Raspberry Pi has a good ARM MMU, that is more capable than any of the Archimedes versions, though somewhat limiting compared to the 68040 and some 68030 versions. For just memory mapping and protection we have a great MMU that provides everything we need, we just lost a few nice tricks of the 680x0 series.

Clocks: This is one where all had them, to varying resolutions, and we have more and more choices of resolution. This may seem a bit simple though it is still very important in doing things on computers.

HW Sprites/Blobs: Only the Amiga had useful ones, Archimedes had only one. On the Raspberry Pi we have no hardware sprites at all. Though we have HW that can perform the actions needed to implement sprites with minimal software intervention, and do so as well as the Amiga did with Blobs, though at higher resolutions and higher color depths.

DSP: Only the Falcon had a DSP of the oldies. The Raspberry Pi has both an accessible GPU that can act as a DSP without interfering with graphics, and the VFP/NEON unit that runs asynchronous to the CPU (though does require intervention of the CPU). So this is another area where the RPi has evolved, though this really is useful to any system even though most of the oldies did not have it.

HW Summery: In most areas the capability of the RPi HW is best described as a better Amiga, I bet you did not expect that. The above is short and readable compared to the research that I have done looking at everything, and how it fits into actual real world usage of the systems. So lets look at what this means for the OS, by taking a look at Amiga OS and Atari TOS+MiNT(ignoring the others as they are not so good at fitting even the HW they ran on [other than RISC OS, and it does not really fit using the extra features so well]). Some will note that I left out multiple processors, this was so extremely rare in the 80's that it is not something that most people ever saw in any form.

Amiga OS, TOS+MiNT, and fitting the RPi
When the wars were going between Atari users and Amiga users I was using both, so had a more comparative perspective, noting that each is better at somethings than the other, so it comes down what you want it to do.

TOS+MiNT was an interesting system, in being a sudo-unixish system running a truly lean GUI on top. This is a OS that probably could have done quite well on just about any HW, though it did take advantage of the Blitter on the ST/Falcon. One of the points that was both a strength and weakness of TOS+MiNT is the way it used TRAP instructions to call the OS (think SWI on ARM), as it was a good balance between everything having its own separate trap call (like Mac OS with A-Line ops, or RISC OS with SWI's) and having to few entry points (like Linux kernel today), it made things manageable for maintaining speed (though not as good as the Amiga way). TOS+MiNT was not very good at interfacing to and truely taking advantage of the HW, and its systems for implementing new drivers were somewhat hacky in ways that would make a modern OS programmer cringe (hacky can sometimes be good, though if you remember intercepting interrupts multiple layers deep in TOS+MiNT, yuck).

Now Amiga OS was all about moving base pointers, fiddling with memory in unique ways that were way faster than what the CPU could ever do. And the Amiga hardware kept part of memory to the chipset and part to the CPU, making it so that the CPU had to go through the chip set to access the chipsets RAM (SlowRAM). Does this sound familiar? What about the memory on the RPi? Pretty much the same between the two. And the executable formats (including that of libraries) was great, it was complete, lean, simple to work with, and relocatable (not like the ELF that is not as easy to work with, though still good).

So the Amiga OS does so well, what the features of the Amiga OS that we can learn from, in terms of writing BareMetal or OS software for the RPi?
  • Use HW outside the CPU whenever it will give the CPU more time (excluding the GPU in this statement, for other reasons).
  • Make any entry points to for the kernel minimal in nature (for OS dev).
  • Keep the kernel small minimal and simple, like Amiga Exec.
  • Take advantage of shared address spaces (one reason the Amiga was so fast for a microkernel).
  • Use a lean format for libraries, the is quick and easy to interpret and relocate, though still complete.
  • Do not use special formats for drivers or kernel modules (this is one that got me, recently).
  • Minimize the need for context switches into a privileged CPU mode.
  • Use only a minimal number of scripts to load everything up, though do use Scripts.
  • Use device oriented file system access.
  • Have all devices represented in the same way, including file system devices.
What can we learn from what Amiga OS did wrong:
  • Amiga had no memory protection, as she ran in System mode all the time, we want memory protection.
  • Do not use a file system that imposes limits on growing files within the normal limits of the file system, so no OFS.
  • Provide limits on the programs accessing HW to help prevent conflicts.
EDIT: Added extreme highlight to important part of point.
EDIT2: Removed statement that could have been missleading.
.
Last edited by DavidS on Wed Nov 28, 2018 6:56 am, edited 3 times in total.
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

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 3:39 am

Sorry about the delay in time continuing this. It takes some thought into what belongs to keep it short enough for a post, and not overflowing.

I discussed Amiga OS in the previous post. So let us look at a few more.

It would be kind of redunant to mention what can be learned from RISC OS as many of us use it on the Raspberry Pi, so it is well known what RISC OS provides, and the archetechure of RISC OS is worth studying, there is a lot that was done well in RISC OS.

The original series of versions of Macintosh System Software do have something to teach, as does TOS+MiNT. I am also going to mention some things we can learn from Ancient Unix, some of which is good and has been lost to time with newer n*x systems like Linux.

What Can we Learn From Atari TOS+MiNT:
Atari TOS+MiNT is a decent OS, that has some bases in CP/M, some in Unix, and some in DOS, with a decent GUI included (Digital Research GEM, modified by Atari).

TOS+MiNT shows what can be done in a very small amount of memory, using very little resources, while being written in a high level language, C in this case. It is a complete GUI, a full install (including what is in ROM and on disk) can fit into less than half a MB.

TOS is the base OS, the kernel is replaced by MiNT when MiNT is loaded. MiNT
loads a multitasking capable AES and desktop. The rest of the OS is still in ROM, the ROM can be as small as 192KB.

While TOS+GEM is not very good about interfacing the HW it is good at showing what can be done in a high level language like C, without wasting resources.

In sum what we can learn from Atari TOS+MiNT is:
  • It is possible to make fairly effecient and small binaries, even for system level usage, in a high level language.
  • You can use the lesons of the past in your design (they used DOS, CP/M, and Unix to inspire them).
  • It is worth thinking about how you are going to devide the components of an Operating System.

What Can we Learn From Macintosh System Software:

The Macintosh System Software (as used in 680x0 Macintosh Computers) is mostly dedicated to a graphics library called QuickDraw. Though there is still a complete OS under there, as well as a well thought out GUI.

QuickDraw used some inovative, almost hacky methods to implement graphics support with simple very fast masking of the output. It is the implementation of regions that I speek, and there is a positive thing to learn there. Remember that the fast masked graphics of the early Macintosh were done without even having a DMA, everyhting was done by the M68000 CPU

Now the Macintosh System Software was single tasking, with later versions adding a cooperative multitasker ontop at first as a finder replacement.

One thing unique about how the Macintosh handled files is the use of a seperate data stream to store resources (the resource fork). This was an extremelygood solution to the problem of storing a programs resources. This is one of the best things we have lost to time.

The Macintosh System software was very small, originally consisting of just a 64KB ROM and about 40KB of on disk system software. Though we really should count it from the 128KB ROM, as that is the first to include support for a true higharchal File System (supporting real subdirectories), and about 60KB on disk system software.

In sum what we learn from the Macintosh system software is:
  • It is ok to implement extremely optimized routines. Even if they are a little hacky.
  • If you only intend to have a single supported CPU archetechure it is alright to use assembly language to implement your OS/Baremetal system.
  • For implementing an OS: Give thought to how a programs resources are going to be stored and handled, you may come up with an extraordinary solution, and it may improve performance.
  • Make sure you have a way to patch the system, so that errors can be corrected between releases of components. This is something else they did well.

What Can We Learn From Ancient Unix:
There are two big lessons that Ancient Unix teaches us:
First: it can be a good idea to implement more small programs that are good at doing only one thing each and doing that one thing well than to try to make an all singing all dancing program that attempts to do many things.
Second: It is important to keep the core system small to reduce the opertunity of problems or bugs to creap in.

Unix was largely a reaction to the Multics. Multics was a system that attempted to do everything and provide for every need of the programs, and Multics is well known for being an hard to handle system as a result. Unix was meant to be a simple small system (and used to be such), that provides for what it needs to, and leaves the rest to the programs and libraries on top of it.

As part of making Unix a simple system the philosophy that each program should do only one thing and do that one thing well came natural. This is one thta has been lost on most systems (ironically it still holds on pretty well in RISC OS, which has nothing to do with Unix).
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

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 6:31 am

Haven't we had this conversation before?

Putting things in perspective: the Pi is streets ahead in all ways, by many orders of magnitude, speed, memory, graphics, operating system, application software, networking, device support. Nobody wants to cripple the Pi and go back to the stone age of personal computing.

Those that want the retro experience, as I do sometimes, have emulators or actual hardware recreations or FPGA built systems to satisfy them.

About the only thing I miss is the instant booting of those little ROM based systems. But even that was gone by the time I had an Atari 520 that booted from floppy disk.

By analogy, the Model T Ford was a very popular car in it's day, not many people would want to drive one for regular use now a days (I know, car analogies are terrible)

If you want a lean, mean, simpler, safe, secure, mikro kernel OS I suggest helping out with the Redox OS project: https://www.youtube.com/watch?v=TlTYWDU-mM4

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 6:36 am

Heater wrote:
Wed Nov 28, 2018 6:31 am
Haven't we had this conversation before?

Putting things in perspective: the Pi is streets ahead in all ways, by many orders of magnitude, speed, memory, graphics, operating system, application software, networking, device support. Nobody wants to cripple the Pi and go back to the stone age of personal computing.

Yes it is way ahead, and that is what I said in the first post.

As I stated the idea is not to compare them tit for tat, it is only to show what we can learn from the past.
Those that want the retro experience, as I do sometimes, have emulators or actual hardware recreations or FPGA built systems to satisfy them.

About the only thing I miss is the instant booting of those little ROM based systems. But even that was gone by the time I had an Atari 520 that booted from floppy disk.

By analogy, the Model T Ford was a very popular car in it's day, not many people would want to drive one for regular use now a days (I know, car analogies are terrible)

If you want a lean, mean, simpler, safe, secure, mikro kernel OS I suggest helping out with the Redox OS project
Please read the posts. You made an incorect assumption on the content.
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

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 6:58 am

Perhaps I don't understand what the topic is. I'm assuming it's in the post title "Putting the RPi in the perspective, looking Retro.". In which case I fail to see how my reply is off topic.

If there is a different topic buried in your essays above it might need to be stated clearly.

I gather you are assuming that people building what we have today are not learning lessons from systems of the past. Well, maybe, maybe not.

The OS development I point to is clearly an attempt by people who know their past but at the same time want a system to meet the needs of today.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 7:10 am

Heater wrote:
Wed Nov 28, 2018 6:58 am
Perhaps I don't understand what the topic is. I'm assuming it's in the post title "Putting the RPi in the perspective, looking Retro.". In which case I fail to see how my reply is off topic.

If there is a different topic buried in your essays above it might need to be stated clearly.
Because the subject line can have many meanings the first line of the first post says the first two short paragraphs of the first post say:
DavidS wrote: This is not about comparison of these with the RPi, or any of that kind of thing. Input is great on this, I hope it may give others some thoughts, as well as anything that can be learned is always good.

This is about what we can learn from the old to help with the new.
So this time I believe that you are intentionally baiting me. So I am not going down a bate path here, we all know that learning more and more from the past is good, and we can never know it all, so looking at it from more perspectives is always good.

I am not going to read the rest of your post that I have quoted, as you did not even read the very first paragraph of the opening post, or if you did you are intentionally attempting to bait.
I gather you are assuming that people building what we have today are not learning lessons from systems of the past. Well, maybe, maybe not.

The OS development I point to is clearly an attempt by people who know their past but at the same time want a system to meet the needs of today.
Last edited by DavidS on Wed Nov 28, 2018 7:32 am, edited 1 time in total.
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

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 7:25 am

@Heater:
I was hoping you had some constructive input when I saw that you posted, having thought you would have at least scanned what was said in the first two posts. I did not expect you of all people to completely ignore the content and then reply.

You will note if you do scan it that I ommited many of the more thought about aspects of each system, concentrating instead on the things that people do not so much think about with the operating systems that I am mentioning. You will also note that I gave lists of some things that could potentially be either learned or at least looked at for each, I expect that some will feel differently than I.

I am accustomed to any of your contrary posts at least adding a constructive bit of information based on what is said, so you really surprised me by making a negitive comment without even reading the first paragraph.
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

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 7:29 am

No baiting intended. I have read everything you wrote. Just trying to pin down the point. Perhaps it's clear to everyone else, I'll let them pick it up.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 8:12 am

Please keep it civil.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
Gavinmc42
Posts: 3459
Joined: Wed Aug 28, 2013 3:31 am

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 11:27 am

HW Sprites/Blobs: Only the Amiga had useful ones, Archimedes had only one. On the Raspberry Pi we have no hardware sprites at all. Though we have HW that can perform the actions needed to implement sprites with minimal software intervention, and do so as well as the Amiga did with Blobs, though at higher resolutions and higher color depths.
Section 5 of the Videocore manual is the Tile Buffer.
I read this as the mouse cursor 32x32(16) or 64x64(32).
Is it in effect a single sprite tile buffer?

Comparing the ARM/VC4 against the old computers can also blind you to features the old stuff did not do.
What is the "OpenGL-ES 2.0 Ericsson Texture Compression (ETC1) compressed texture format"?
Requests to run general-purpose programs can also be sent to the scheduler
by a queue written via the V3DPRQPC and V3DPRQUA system registers. These supply the initial PC address and
an optional Uniforms base address for the program.
For specific purposes the V3DQRESVx system registers can be used to exclude individual QPUs from running
one or more of the following types of program: fragment shader, vertex shader, coordinate shader, or general-
purpose program.
To me that means QPU's can also be General purpose ALU's, 48 in total?
In this I am mostly ignoring the VideoCoreIV for anything other than a FrameBuffer and simple DSP (which is a way that we can use the VideoCore well even in bare metal).
I don't think the old retro guys would ignore 24Gflops?
Put tipam's Xmas scene and LdB's OpenGLES together and you get serious baremetal graphics with minor Arm CPU usage.
Very much Retro Demoscene methods but with great graphics those Amiga guys would drool for.
And extendable into a game engine? With or without OS.

Every single point you guys make is valid? And yet it is not.
We are not using old hardware with all the old restrictions of speed, mmu, memory, graphics, single core etc.
So we don't have to use old methods of OS's.

Driving forwards looking in the rear view mirror could steer you up a dead end?
BUT is is a very good idea to map the roads taken so far, to know where we have been.

Do you want to make a better Linux, multitasking, multiuser OS?
Well most Pi's are single user?
Embedded Pi's could be single task?
Pi's can do all this and more, yet Pi's are OLD tech compared to what has/is about to come out.

Is anything learnt on the Pi going to be applicable to Nvidia 256 GPU core TX2 or the new AGX?
What about 1024 core cpus?
Will these need new OS's or will they use kludged plugins to Linux?
Pi's allow us old gen and the next generation of coders to learn about or invent new ways.

Games are now starting to use procedurally generated Worlds.
The latest chess AI program taught itself to play chess in 4 hours.
It won 22 times, drew 78 times and did not lose once against the previous best chess program.

What OS would an AI make for itself?
What rules do we need to define for it?
Do we start by feeding it Socrates, Aristotle and Cicero?
Do we feed it every single law ever made?
Laws are not Principles or Rights.
Laws are mainly rules for human programming to avoid the rogue elements dominating, (some say this has now failed).

Arthur C Clarke had his Robot laws, will they be enough?
I recently came up with my own small Philosophy of life.

Principles -The Planet before People, People before Profits.
Essential Rights - The Right to Clean Air, Clean Water, Clean Food and Shelter.
Rules of Law - Don't Kill, Don't Steal, Don't Lie, Don't mess with our families.

This discussion is really rhetoric about different philosophies of computing.
What do we collectively or as individuals want to achieve with Pi's?
Neo Wiccan - "Anything goes as long as no harm is done"?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Memotech Bill
Posts: 23
Joined: Sun Nov 18, 2018 9:23 am

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 1:08 pm

Arthur C Clarke was a great SF author, but the three laws of robotics were Isaac Asimov

dave j
Posts: 116
Joined: Mon Mar 05, 2012 2:19 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 2:51 pm

DavidS wrote:
Tue Nov 27, 2018 4:35 pm
Copper: Only the Amiga had a Copper. Today the same thing can be done on the RPi with ease, though differently. This requires a small amount of code on the GPU, though within our limits, to implement the equivalent of a display list, and tell the DMA what to do. Though we only have one horizontal and vertical resolution on screen at a time with the RPi. There may even be other ways to accomplish this trick without the GPU (and without the CPU), I just do not know them yet.
The functions of Copper are pretty much redundant. Switching screen modes on the fly is unnecessary when you can have high resolution at 32 bits per pixel. Palette switching to get more colours similarly and palette switching for animation effects aren't necessary when you can update the whole framebuffer every frame.
HW Sprites/Blobs: Only the Amiga had useful ones, Archimedes had only one. On the Raspberry Pi we have no hardware sprites at all. Though we have HW that can perform the actions needed to implement sprites with minimal software intervention, and do so as well as the Amiga did with Blobs, though at higher resolutions and higher color depths.
Dispmanx layers could be used as sprites, although I'm not sure of the limitations on them (how many, etc.). As you point out, the Pi has better solutions for their functionality.

On AmigaOS, this:
  • Take advantage of shared address spaces (one reason the Amiga was so fast for a microkernel).
and this:
  • Amiga had no memory protection, as she ran in System mode all the time, we want memory protection.
are mutually exclusive. It's the reason all attempts to add memory protection to AmigaOS have failed.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 5:42 pm

Gavinmc42 wrote:
Wed Nov 28, 2018 11:27 am
HW Sprites/Blobs: Only the Amiga had useful ones, Archimedes had only one. On the Raspberry Pi we have no hardware sprites at all. Though we have HW that can perform the actions needed to implement sprites with minimal software intervention, and do so as well as the Amiga did with Blobs, though at higher resolutions and higher color depths.
Section 5 of the Videocore manual is the Tile Buffer.
I read this as the mouse cursor 32x32(16) or 64x64(32).
Is it in effect a single sprite tile buffer?

Comparing the ARM/VC4 against the old computers can also blind you to features the old stuff did not do.
What is the "OpenGL-ES 2.0 Ericsson Texture Compression (ETC1) compressed texture format"?
Not so much a feature of VideoCoreIV as it is of the software running on the VideoCoreIV.

Though I did say that it is not about comparing, though more about what can we learn. And it is more about what we can learn from the OS's than from the Hardware. Though looking at how the Hardware has evloved does help maintain perspective.
Requests to run general-purpose programs can also be sent to the scheduler
by a queue written via the V3DPRQPC and V3DPRQUA system registers. These supply the initial PC address and
an optional Uniforms base address for the program.
Thank you for explicetly mentioning that. That is what I meant about using the VC4 as a DSP, or for low level graphics accelleration.
For specific purposes the V3DQRESVx system registers can be used to exclude individual QPUs from running
one or more of the following types of program: fragment shader, vertex shader, coordinate shader, or general-
purpose program.
To me that means QPU's can also be General purpose ALU's, 48 in total?
In this I am mostly ignoring the VideoCoreIV for anything other than a FrameBuffer and simple DSP (which is a way that we can use the VideoCore well even in bare metal).
I don't think the old retro guys would ignore 24Gflops?
Put tipam's Xmas scene and LdB's OpenGLES together and you get serious baremetal graphics with minor Arm CPU usage.
Very much Retro Demoscene methods but with great graphics those Amiga guys would drool for.
And extendable into a game engine? With or without OS.
Not what was meant, though I understand. We do not know how to push pixels out to HDMI without using the VC4's operating system, thus we are limited to having its OS running. Yes we can use it to plot polies, as many have shown.

Though we have a 24GFLOP DSP that can be used for many things. It can be used for 3D Graphics (which yes even the retros used DSP's for), it can be used for sound pre-processing, it can be used for anything else that you would normal DSP, or an extended FPU. We just have way more processing power on it.

Yes we can use it more, that is a big part of the whole point of mentioning it at all. By saying that for that post I am ignoring some of the features of the VC4 was intended to make people really think about what we can do with it. It was not meant to cast it out, it WAS meant to push people to think about it. Remember one of my points is to do as much without using the CPU as possible.
Every single point you guys make is valid? And yet it is not.
We are not using old hardware with all the old restrictions of speed, mmu, memory, graphics, single core etc.
So we don't have to use old methods of OS's.

That was not the point, the point was what can we learn from the past OS's, that can help us better use this extremely high end hardware.
Driving forwards looking in the rear view mirror could steer you up a dead end?
BUT is is a very good idea to map the roads taken so far, to know where we have been.
THAT is the point. This is the map of where we have been. The point of this is more what every history prof says 'those whome forget history are doomed to repeat it'. As well as that history can teach good ways as well.
Do you want to make a better Linux, multitasking, multiuser OS?
Well most Pi's are single user?
Embedded Pi's could be single task?
Pi's can do all this and more, yet Pi's are OLD tech compared to what has/is about to come out.
that is true indeed. Though not that old, the concepts learned will apply moving forward, even as we go into the extreme multicore systems of the present and future. Start with 1 core, learn how to keep things working through multiple cores with 4 cores (locks, locks, locks), and the bases are formed to learn to take it to 512 cores, with the biggest differences to think on being the archetechure.
Is anything learnt on the Pi going to be applicable to Nvidia 256 GPU core TX2 or the new AGX?
What about 1024 core cpus?
Will these need new OS's or will they use kludged plugins to Linux?
Pi's allow us old gen and the next generation of coders to learn about or invent new ways.
The past is always applicable to the vuture, no exceptions.
... ...
This discussion is really rhetoric about different philosophies of computing.
What do we collectively or as individuals want to achieve with Pi's?
Neo Wiccan - "Anything goes as long as no harm is done"?
And there it is. No matter what we do with our RPi we are going to do it better if we remember the past. As well as all the other new systems.

Most on the Raspberry Pi are using Linux in some veriant or another. Linux is a 27 year old OS that is modeled largely after ideas from Unix, Unix is a 48 year old OS that was extremely good for its time. So we are using the past every day. Most of what is done on Linux is done in ways that are very much like the Unix of the 1960's, with many of the same utilities, the same concepts for device filesystems, etc.

And yet you do not think that looking at newer concepts than those on which the most used OS on the RPi is based is worthwhile? Unix is another antique that we still use to this day, in the form of Linux and BSD.
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

User avatar
PeterO
Posts: 4882
Joined: Sun Jul 22, 2012 4:14 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 6:53 pm

DavidS wrote:
Wed Nov 28, 2018 5:42 pm
Unix is another antique that we still use to this day, in the form of Linux and BSD.
How can we take this seriously when you conveniently ignore 27 years worth of improvements ?
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 8:14 pm

PeterO wrote:
Wed Nov 28, 2018 6:53 pm
DavidS wrote:
Wed Nov 28, 2018 5:42 pm
Unix is another antique that we still use to this day, in the form of Linux and BSD.
How can we take this seriously when you conveniently ignore 27 years worth of improvements ?
PeterO
I am not ignoring the progress, in fact I am asking people to look at the progress that we have made so that we can move forward in positive directions. I am only showing that to look at what we have now we need to look at where it came from to start with, and always ask which is beter for what.

How can you promote the progress of Linux while ignoring the same time period evolution and progress of the others? And it is over 48 years of improvement and evolution since Unix first came to life.

Amiga OS continued to evolve until after we had AROS, then AROS has continued to evolve, yet you seem to think it is retro, despite having pretty much the same level of advancement as Linux.

The same for Atari MiNT+TOS, it is still evolving, and easily comparable in abilities (even if many look at it as retro), and it does so in much less memory. Saving memory is always a good thing, especially when done without losing any features, same goes for CPU Cycles.

Then RISC OS is definitely been ongoing, as any RPi user knows. Ok it is a different kind of OS, and you can say both good and bad about it. Though you can say both good and bad about any Operating system.

The old Multitasking GUI that I am omiting is Windows, because it does not fit with learning from at all in my personal opinion.

SORRY, my responce got lost by the forum software.
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

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 8:47 pm

DavidS,
And yet you do not think that looking at newer concepts than those on which the most used OS on the RPi is based is worthwhile? Unix is another antique that we still use to this day, in the form of Linux and BSD.
I'm not sure I understand what you are getting at.

Sure Unix is old. There is nothing in Linux that is much the same as Unix. Except some high level design/usability concepts.

I mean, the idea of the wheel is much older, we still use wheels. Although the way we make them now is very different.

And I'm confused. This whole discussion was started as a plea to remember the past, which is fair enough, but that statement suggests throwing out the old and "looking at newer concepts". Whatever they may be and without suggesting any.

Which brings me back to guys like those developing Redox. They have whole new ways to think about building an OS, what with starting from a safe language and a mikro-kernel. But guess what, in Redox everything is a file, just like Unix!

I'm sure RISC OS, Amiga OS, Atari MiNT+TOS are still being tweaked by some die hard enthusiasts. I cannot believe they are going anywhere.

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 10:29 pm

Heater wrote:
Wed Nov 28, 2018 8:47 pm
DavidS,
And yet you do not think that looking at newer concepts than those on which the most used OS on the RPi is based is worthwhile? Unix is another antique that we still use to this day, in the form of Linux and BSD.
I'm not sure I understand what you are getting at.

Sure Unix is old. There is nothing in Linux that is much the same as Unix. Except some high level design/usability concepts.
That is like saying that there is nothing in a board that is much the same as a flat piece of wood, really.

Ok so the code is new, there are newer ways of doing many things, though much of the overall way much is done is very similar, the influence of Unix is very strong in Linux. And that is for a lot more than just the utilities, shells, etc, the two are closer in relation than seems to be remembered.

You can download the source of bothe OS's now and compare how they do many things. You will likely be surprised at how similar they really are (different C standards). I would recomend looking at ancient Unix System 5 source, as that is still way older than Linux, though is the Unix that seems to have most directly influenced the rest of the world.
I mean, the idea of the wheel is much older, we still use wheels. Although the way we make them now is very different.

And I'm confused. This whole discussion was started as a plea to remember the past, which is fair enough, but that statement suggests throwing out the old and "looking at newer concepts". Whatever they may be and without suggesting any.
I sometimes wonder if you are using an automatic translation to/from a non-english language when reading what I write.

Nothing is suggesting to throw out the old at all. It is saying to integrate the old as much as the newer. And you are quoting a reply to a statement, that the statement helps a little with context.

The point that was also stated three times (different wording) in the opening two posts is: It is always important to studdy the past so that we can do well in progressing into the future, all layers of the past of the field of study that have any level of applicability.

The point of this thread is about looking forward through the lense of the lessons to be learned from the old. I have stated this same thing over and over and it keeps being ignored, or twisted in meaning, how much more clear can I be.
Which brings me back to guys like those developing Redox. They have whole new ways to think about building an OS, what with starting from a safe language and a mikro-kernel. But guess what, in Redox everything is a file, just like Unix!

I'm sure RISC OS, Amiga OS, Atari MiNT+TOS are still being tweaked by some die hard enthusiasts. I cannot believe they are going anywhere.
Weather everything is a file, or everything is a GPIB or whatever abstraction, should not be a big point, the abstraction is a convienience of implementation and use. I personally do not so much like the everything is a file abstraction, perfering the a file is a file a raw device is a raw device and volumes are abstracted in a similar way to devices abstraction (such as used in AROS/Amiga OS, TripOS, and a few others).


There are some very good concepts in the systems that have evolved from Unix, of that there is no question. There are some very good concepts that have come from all of these systems, many releated to how things are handled.
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

User avatar
DavidS
Posts: 4334
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 10:50 pm

You know what, I am tired of posting threads that are meant to be possitive and constructive, and having many come and twist the very clear meaning of what is said into balls contorting it to counter meanings that are often negitive in nature.

I am out of this thread. Have fun tearing it appart and trying to disscourage the meaning of the thread to tatters. I guess I should remove the content of the initial posts, though I will leave them for people that may read what is actually said in them with out tearing it to shreds.


A reasonal expectation for a constructive thread like this would be four or five comments about what is being said, with additional information both pro/con as a start. It is unreasonable to expect the meaning to be twisted backwards by people within the first few posts.

I could see requests of clarity, though not extreme backwards twists on the meaning.
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

jahboater
Posts: 4595
Joined: Wed Feb 04, 2015 6:38 pm

Re: Putting the RPi in the perspective, looking Retro.

Wed Nov 28, 2018 11:34 pm

DavidS wrote:
Wed Nov 28, 2018 10:29 pm
I would recommend looking at ancient Unix System 5 source, as that is still way older than Linux, though is the Unix that seems to have most directly in
UNIX split long ago: Version 7 and then System 5 on one side. BSD (Berkeley Software Distribution) on the other side.
Apples MacOS is based on BSD UNIX as it was about 25 years ago. Solaris was a very good rewrite/copy of System 5.
Now the IEEE OS standard called POSIX is the way to go. And Linux adheres to that.

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Putting the RPi in the perspective, looking Retro.

Thu Nov 29, 2018 12:37 am

DavidS,
Weather everything is a file, or everything is a GPIB or whatever abstraction, should not be a big point, the abstraction is a convienience of implementation and use. I personally do not so much like the everything is a file abstraction, perfering the a file is a file a raw device is a raw device and volumes are abstracted in a similar way to devices abstraction (such as used in AROS/Amiga OS, TripOS, and a few others).
No, the "everything is a file" abstraction is not a convenience of implementation.

The whole Unix idea that "everything is a file" is perhaps the most profound and longest standing legacy of Unix.

Never mind disks and files and volumes and any kind of actual hardware.

The simple idea is that there is some resource that has a some name. No matter what it is, disk, serial port, SPI bus, etc, you can open it by it's name, read and write stuff to it, close it. And, by the way, what you read and write is of the lowest common denominator, characters, that is bytes.

This abstraction seems so simple but it was not obvious to those building systems previously, where it was "obvious" that files on disks should have a record structures and such.

The whole World Wide Web uses the "everything is a file" abstraction with it's URLs.

Heater
Posts: 12974
Joined: Tue Jul 17, 2012 3:02 pm

Re: Putting the RPi in the perspective, looking Retro.

Thu Nov 29, 2018 1:33 am

DavidS,
I sometimes wonder if you are using an automatic translation to/from a non-english language when reading what I write.
That made me chuckle.

I have no automatic translation but I do have to translate from American into English.

:)

ejolson
Posts: 3252
Joined: Tue Mar 18, 2014 11:47 am

Re: Putting the RPi in the perspective, looking Retro.

Thu Nov 29, 2018 7:29 am

PeterO wrote:
Wed Nov 28, 2018 6:53 pm
DavidS wrote:
Wed Nov 28, 2018 5:42 pm
Unix is another antique that we still use to this day, in the form of Linux and BSD.
How can we take this seriously when you conveniently ignore 27 years worth of improvements ?
Wow, 27 years ago seems like just yesterday. I wonder when it will be finished?

From my point of view, the Raspberry Pi is much closer in spirit to the personal computers of the past that ran AmigaOS, OS/9, RISCOS and CP/M than it is to the minicomputers that ran VAX/VMS, AOS/VS and Unix. While the minicomputers were intended to be used as work machines, the Pi is intended to serve an individual's personal needs and interests. In essence the Pi has become the new personal computer. For this reason running a server-oriented Unix-like operating system on the Pi seems odd. While autologin and passwordless sudo help, at the same time, much might be learned by looking in retrospect at operating systems originally designed for personal computing back when there was a greater interest in such things.

jahboater
Posts: 4595
Joined: Wed Feb 04, 2015 6:38 pm

Re: Putting the RPi in the perspective, looking Retro.

Thu Nov 29, 2018 8:55 am

ejolson wrote:
Thu Nov 29, 2018 7:29 am
From my point of view, the Raspberry Pi is much closer in spirit to the personal computers of the past that ran AmigaOS, OS/9, RISCOS and CP/M than it is to the minicomputers that ran VAX/VMS, AOS/VS and Unix.
Yes.

But for me though it still seems odd (and good) that these little machines have a powerful multi-user/multi-tasking OS running on them.

For decades at work I used large computers in distant labs.
Often some kind of UNIX accessed by telnet.

Now I ssh into my headless Pi Zero and it feels much the same from a usage point of view!
Yet I can see this tiny tiny little circuit board that cost $5 in front of me.

User avatar
PeterO
Posts: 4882
Joined: Sun Jul 22, 2012 4:14 pm

Re: Putting the RPi in the perspective, looking Retro.

Thu Nov 29, 2018 9:24 am

ejolson wrote:
Thu Nov 29, 2018 7:29 am
From my point of view, the Raspberry Pi is much closer in spirit to the personal computers of the past that ran AmigaOS, OS/9, RISCOS and CP/M than it is to the minicomputers that ran VAX/VMS, AOS/VS and Unix.
I think that's more to do with the attitudes of the users and the plans of the RPF that any differencies or similarities in hardware or OSes.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23083
Joined: Sat Jul 30, 2011 7:41 pm

Re: Putting the RPi in the perspective, looking Retro.

Thu Nov 29, 2018 10:02 am

DavidS wrote:
Wed Nov 28, 2018 10:50 pm
You know what, I am tired of posting threads that are meant to be possitive and constructive, and having many come and twist the very clear meaning of what is said into balls contorting it to counter meanings that are often negitive in nature.

I am out of this thread. Have fun tearing it appart and trying to disscourage the meaning of the thread to tatters. I guess I should remove the content of the initial posts, though I will leave them for people that may read what is actually said in them with out tearing it to shreds.


A reasonal expectation for a constructive thread like this would be four or five comments about what is being said, with additional information both pro/con as a start. It is unreasonable to expect the meaning to be twisted backwards by people within the first few posts.

I could see requests of clarity, though not extreme backwards twists on the meaning.
Perhaps the reason you get negative comments is that sometimes, what you propose, isn't condusive to positive comments?

What you are asking for, I think, is a return to the simpler OS of the past? To incoporate some of the features of older machines in to newer devices? What you have said is that Linux is a dinosaur, amongst other claims.

Well, the world has moved on. OS's need to deal with much more complicated hardware, and are by necessity, more complex. Linux has done well to keep up with the changes - it has 20 years of development behind it, by some of the best OS engineers on the planet. Graphics HW has moved past the features of the Amiga and devices of 25 years ago, so far past they are incomparable. Harder to use, but the feature set is extraordinary. Everything that could be done on devices like the Amiga in HW can now be (mostly) done in SW due to improvements in processors.

The lessons of those older machines have been learned, and improved upon.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Return to “Off topic discussion”