RetroBSD

2.11BSD operating system for microcontrollers
It is currently Mon Feb 27, 2017 2:12 am

All times are UTC




Post new topic Reply to topic  [ 86 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Wed Nov 30, 2016 3:18 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1076
Hi Pito,

Hmmm.... Website killed my partially written comment again. e-mail is MUCH better!


So we come back to the old subject of software portability :).

I suppose porting Retro to PIC32mz would be pretty easy, but still sole source. That said, I think it makes sense.

There are many many Linux boards out there. Basically some CPU with DDR. Which one make sense to consider? From here it looks like BBG and friends makes a lot of sense. Big company behind it. Not likely to go away soon. Raspi has a lot of closed or semi-closed stuff around it.

While Linux is said to be open source, it has become much to big and complex for mere mortals to understand.

Even RetroBSD has a pretty complex and hard to understand kernel that could be made MUCH smaller by just making non-necessary parts loaded when needed.

So I think that small and easy to understand should be where our energy is spent.

Where does an FPGA fit? I am not sure.

What are your thoughts and suggestions?

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 5:22 pm 

Joined: Fri May 23, 2014 4:04 pm
Posts: 10
The 8 won't get you much of interest. It was designed to be cheap (the 8S was the first mini under $10K and only around 520 logic gates). It sold in enormous volumes for its period but the 12bit instruction set and some of the hardware design trade offs also mean it's not a very useful machine for things like C or Unix.

It's chief designer went on to build the DG Nova, which is a much saner 16bit machine that at least by the Nova 3 has enough power to run a small Unix OS.

On portability I think the answer is that most of the 2BSD code is fairly portable and actually RetroBSD has fixed a *lot* of the PDP-11isms in the original code, although it's also lost chunks you'd need on any bigger device (eg networking). The 11 is a fairly CISC 16bit machine with wacky layout of 32bit ints, the MIPS is a 32bit RISC device. That's a pretty good spread.

There are some good sources of small apps: The Heirloom project for the old freed up Unix ones. Coherent was freed up although you have to navigate a pile of large disk dumps to extract useful tools. There is also a lot from the various sources archives amd for micros (eg for Fuzix we make use of things like levee to provide vi for 8bit )

I'm a big fan of small and easy, it's one reason for Fuzix rather than trying to work from 2.11BSD/Retro.

Alan


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 7:26 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2392
Location: Rapa Nui
Fuzix on pic32MZ??

_________________
Pukao hats cleaning services


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 9:52 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1076
Hi Alan and Pito and all,

I guess the thing of most interest is 'easily' hooking your low level hardware to the 'web' or network.

LiteBSD has tcp/ip 'built in'.

My comment would be that something like fuzix could be very useful if well documented and has a test suite to insure 'proper' working.

In the PDP days there was a LOT of test software. There were so many subtle ways in which things could be different due to a broken ball bond inside a package, a defective design, etc.

Today is really no different except that all the stuff is inside a chip and so complex that complete testing is only a dream. And has become somthing like 'it seems to work' and people buy it.

That seems to me to by why interpreters like Java are so popular. The interpreter 'instructions' can be more easily tested for some corner cases.

But when the interpreter is designed to have hidden internal 'features' all bets are off. I assume hidden internal 'features' are all over the place at this point.

And internal flash memory makes things MUCH worse since the 'chip' operation now depends on its long term history.

And then there is the issue of custom, one of silicon made to look like commodity silicon.

So I guess that supports software that will run on multiple commodity chips. If it doesn't seem to work OK, change the chip or even the processor version or manufacturer it is running on. And test with different equipment for identical input, output operation.

And so I get back to easy portability. And multiple implementations all 'known' to work. Which is probably more or less of a dream.

I notice that retroforth 12 has an even smaller and more documented kernel.

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Thu Dec 08, 2016 8:56 pm 

Joined: Fri May 23, 2014 4:04 pm
Posts: 10
The uIP stack can be built into a tiny OS and made to look like BSD sockets. There are also cheats like the Wiznet 5100 which can be setup the same way.

As to testability - I've worked on systems that have to be reliable and the answer would be no. At this point in time anyone wanting to write a new testable safe OS wouldn't be writing it in C and would be building it either modularly or in microkernel form to get sufficient isolation for testability and ideally formal proofs to be done of some of the modules. While there a huge gaps in liability law for software, and thus a lot of crap software the moment you actually injure someone criminal liability law applies - which is why safety critical software sucks far less 8)

While it's a blessing to emulator authors, the old machines had lots of test software because they always broke down. Most of that wasn't validation (and probably any validation work is lost in the depths of someones 'top secret' shredder). The big risk with modern processors is not that kind of gate level reliability, it's as you say the complexity of the design. Nobody knows for sure if the CPU is correct for all possible cases or what all the timing patterns are. CPU vendors do enormous amounts of internal simulation and validation to guard against this but a browse of the errata added *after release* for any CPU will show you things escape - and sometimes comparing the original announcement with the product released features gives a glimpse of what went in the CPU but was disabled because it didn't work.

Alan


Top
 Profile  
 
PostPosted: Fri Dec 09, 2016 3:36 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1076
Hi Alan,

Thanks very much for your insightful comments. They are most helpful.

My background is telephony where reliability has a whole different meaning :).

I have been pondering doing a new product and making a hit list of features and things that need to be put in the doneness criteria document.

The software portablility has been kind of a surprise. Past systems have turned out to be mostly done in assembly with some hardware reliability enhancements and have worked flawlessly for years for our customers. Some of whom say our products are as reliable as any. Nice to get that sort of feedback.

I have hoped that something like RetroBSD could be put in as a background job to do the calculations since doing that sort of thing in assembly is a drag.

I have 3 Retro MX breadboards that have been running reliably for some time now so that is hopeful. Getting the clock started seems to be the only real problem. Should I try MZ? And start down to road with that chip? Good question.

Of a half dozen or so of various board type 'computers' I have had one die a hardware death [dead short]. And several that sometimes don't start! This is not a good omen :).

And then what about 'higher level languages'!! Yet another source of the unknown!

Most folks seem addicted to the huge development system with lots of simulation. For me, I would rather suffer with real hardware and be finding real problems :). [I am a low level sort of guy.]

Thanks again. I am listening if you have any further remarks to share. Or maybe even some markets to suggest.

Lots of fun :).

Wiz


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 86 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission