8-bit Linux?

8-bit Linux?

[Scott Ferguson]

I haven't had time to verify the claims and I'd be interested in what
the list has to say.

http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit


Kind regards

Re: 8-bit Linux?

[Stefan de Konink]

On 28-03-12 02:36, Scott Ferguson wrote:
> I haven't had time to verify the claims and I'd be interested in what
> the list has to say.
>
> http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit

I wonder in terms of cal -y performance how long it would take to 
calculate month boundaries :)

Stefan

Re: 8-bit Linux? [OT]

[Scott Ferguson]

On 28/03/12 12:03, Stefan de Konink wrote:
> On 28-03-12 02:36, Scott Ferguson wrote:
>> I haven't had time to verify the claims and I'd be interested in what
>> the list has to say.
>>
>> http://dmitry.co/index.php?p=./04.Thoughts/07.%20Linux%20on%208bit
> 
> I wonder in terms of cal -y performance how long it would take to
> calculate month boundaries :)
> 
> Stefan
> 

Hmmm, it takes 2 hours to get to a bash prompt.... you could skip the
next 4 hours it takes to load a GUI, um... and I'm just guessing, but
probably about as long as it takes to shave a soapy cat.


Kind regards

Re: 8-bit Linux?

[Chris Cureau]

For what it's worth...I still haven't given up on my dream of Unix on the 6502. :)  I've got a good bit already written that will run on a Commodore 128 and working on a ramdisk for those who have external RAM (or an emulator!)

Blazing 2MHz speeds, no memory protection...and I'd bet it could handle multiple users with the ramdisk once all is said and done. :)

Re: 8-bit Linux?

[Gábor Lénárt]

Hi,

On Wed, Mar 28, 2012 at 07:50:19AM -0700, Chris Cureau wrote:
> For what it's worth...I still haven't given up on my dream of Unix on the 6502. :)  I've got a good bit already written that will run on a Commodore 128 and working on a ramdisk for those who have external RAM (or an emulator!)
> 
> Blazing 2MHz speeds, no memory protection...and I'd bet it could handle multiple users with the ramdisk once all is said and done. :)

Interesting, indeed :) What I wanted once, just for a wild idea (I guess it
would be unusable slow, but just for the "feeling"): using the non-MMU Linux
port (so not elks) eg for Amiga or similar, and write a motorola 68K CPU
"emulator" for the C64 DTV (where 2Mb RAM should be enough for "something" -
and yes, it's not a "C64", maybe with SuperCPU it would have been better)
with minor modifications maybe on the target though.  But with lack of
enough freetime and the "mad" nature of the idea I never tried to do it: it
wouldn't be se useful at all, ELKS would make some sense with "native" port
at least :) :)


-- Gábor
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 8-bit Linux?

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

Gábor Lénárt wrote:
> Hi,
> 
> On Wed, Mar 28, 2012 at 07:50:19AM -0700, Chris Cureau wrote:
>> For what it's worth...I still haven't given up on my dream of Unix on the 6502. :)  I've got a good bit already written that will run on a Commodore 128 and working on a ramdisk for those who have external RAM (or an emulator!)
>>
>> Blazing 2MHz speeds, no memory protection...and I'd bet it could handle multiple users with the ramdisk once all is said and done. :)
> 
> Interesting, indeed :) What I wanted once, just for a wild idea (I guess it
> would be unusable slow, but just for the "feeling"): using the non-MMU Linux
> port (so not elks) eg for Amiga or similar, and write a motorola 68K CPU
> "emulator" for the C64 DTV (where 2Mb RAM should be enough for "something" -
> and yes, it's not a "C64", maybe with SuperCPU it would have been better)

Have you seen Uzi?

http://www.dougbraun.com/uzi.html
http://www.cpmclub.de/zeitung/seite5.htm
http://uzix.sourceforge.net/

It's a SysV Unix kernel for the Z80, intended to run on CP/M machines.
Okay, it's a Z80 and not a 6502, and the 6502 has certain unique issues
with multitasking or running C (non-relocatable/fixed
size/fixed-location stack, ugh), but it might be interesting to look at.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: 8-bit Linux?

[Chris Cureau]

Very interesting!  I'll look a little closer in a bit...

One of the nice things about the c128 is the built in MMU...which allows remapping of page 0 and page 1 (zero page and stack, respectively) at any given moment.  The same thing is possible with the 65816/65265 CPUs, which are the next target.  If you also use the o65 format, you can do software relocation.  There are still limitations of course, but the barriers are lower given those things...

Curiously enough, this thing is what drew me to ELKS to begin with...I figured that a 8088 kernel would be close to what I wanted to do. :)

--- On Wed, 3/28/12, David Given <dg@cowlark.com> wrote:

> From: David Given <dg@cowlark.com>
> Subject: Re: 8-bit Linux?
> To: "linux-8086@vger.kernel.org" <linux-8086@vger.kernel.org>
> Date: Wednesday, March 28, 2012, 11:03 AM
> Gábor Lénárt wrote:
> > Hi,
> > 
> > On Wed, Mar 28, 2012 at 07:50:19AM -0700, Chris Cureau
> wrote:
> >> For what it's worth...I still haven't given up on
> my dream of Unix on the 6502. :)  I've got a good bit
> already written that will run on a Commodore 128 and working
> on a ramdisk for those who have external RAM (or an
> emulator!)
> >>
> >> Blazing 2MHz speeds, no memory protection...and I'd
> bet it could handle multiple users with the ramdisk once all
> is said and done. :)
> > 
> > Interesting, indeed :) What I wanted once, just for a
> wild idea (I guess it
> > would be unusable slow, but just for the "feeling"):
> using the non-MMU Linux
> > port (so not elks) eg for Amiga or similar, and write a
> motorola 68K CPU
> > "emulator" for the C64 DTV (where 2Mb RAM should be
> enough for "something" -
> > and yes, it's not a "C64", maybe with SuperCPU it would
> have been better)
> 
> Have you seen Uzi?
> 
> http://www.dougbraun.com/uzi.html
> http://www.cpmclub.de/zeitung/seite5.htm
> http://uzix.sourceforge.net/
> 
> It's a SysV Unix kernel for the Z80, intended to run on CP/M
> machines.
> Okay, it's a Z80 and not a 6502, and the 6502 has certain
> unique issues
> with multitasking or running C (non-relocatable/fixed
> size/fixed-location stack, ugh), but it might be interesting
> to look at.
> 
> -- 
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ
> ───── http://www.cowlark.com ─────
> │ "Parents let children ride bicycles on the street. But
> parents do not
> │ allow children to hear vulgar words. Therefore we can
> deduce that
> │ cursing is more dangerous than being hit by a car." ---
> Scott Adams
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 8-bit Linux?

[David Given]

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

Chris Cureau wrote:
> Very interesting!  I'll look a little closer in a bit...
> 
> One of the nice things about the c128 is the built in MMU...which allows remapping of page 0 and page 1 (zero page and stack, respectively) at any given moment.  The same thing is possible with the 65816/65265 CPUs, which are the next target.  If you also use the o65 format, you can do software relocation.  There are still limitations of course, but the barriers are lower given those things...

Being able to remap the stack is a big win. Is 256 bytes a realistic C
stack size, I wonder?

I did some work a while back looking at ways of doing C on the 6502 and
the Z80. They both suck, because both processors predate
stack-frame-based languages, and so don't have any useful addressing
modes (like stack-relative addressing).

On the Z80 you have to copy sp into one of your precious 16-bit index
registers, and then indirect each byte individually; at 4 bytes of code
a byte, that's 8 bytes to read a single 16-bit value off the stack!

On the 6502 it's even worse because of that fixed-position stack. Most
compilers maintain their own C stack, with appalling performance
results, of course. But if you *can* use the 6502 stack as the C stack,
you can do something like this...

stackaddr: // in zero page
	dw 0x0100

load_16_bit_value_at_sp_plus_a_into_xy:
	tsx
	stx stackaddr+1
	tay
	ldx (stackaddr), y
	iny
	ldy (stackaddr), y

That's nine bytes, unfortunately, but with luck you may be able to
offset that by much more efficient parameter passing (as you can use
pha/phx/phy to push values onto the stack). Plus, of course, if you were
doing it for real you could arrange that the stack offset starts in Y
rather than A, which would save you a byte.

TBH, I thing the 6502 is such a poor match for C that it'd be better to
compile to p-code (like a more advanced SWEET16); the improved code
density should outweigh the performance issues for most tasks. I did
actually do most of one a while back, with a Z80 interpreter, and had
the ACK compiling to it, at least to a degree... I can dig it out if
anyone cares.

Alternatively you could write your programs in Fortran. The 6502 should
run Fortran quite well.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: 8-bit Linux?

[Gábor Lénárt]

On Wed, Mar 28, 2012 at 05:03:32PM +0100, David Given wrote:
> Gábor Lénárt wrote:
> > Hi,
> > 
> > On Wed, Mar 28, 2012 at 07:50:19AM -0700, Chris Cureau wrote:
> >> For what it's worth...I still haven't given up on my dream of Unix on the 6502. :)  I've got a good bit already written that will run on a Commodore 128 and working on a ramdisk for those who have external RAM (or an emulator!)
> >>
> >> Blazing 2MHz speeds, no memory protection...and I'd bet it could handle multiple users with the ramdisk once all is said and done. :)
> > 
> > Interesting, indeed :) What I wanted once, just for a wild idea (I guess it
> > would be unusable slow, but just for the "feeling"): using the non-MMU Linux
> > port (so not elks) eg for Amiga or similar, and write a motorola 68K CPU
> > "emulator" for the C64 DTV (where 2Mb RAM should be enough for "something" -
> > and yes, it's not a "C64", maybe with SuperCPU it would have been better)
> 
> Have you seen Uzi?

No, and it seems (now as I've google'd a bit) there are some similar tries
what I've described, but it was just an old idea of mine never tried or not
even I checked out if others have similar projects or such.

--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 8-bit Linux?

[Gábor Lénárt]

On Wed, Mar 28, 2012 at 06:20:29PM +0100, David Given wrote:
> Chris Cureau wrote:
> > Very interesting!  I'll look a little closer in a bit...
> > 
> > One of the nice things about the c128 is the built in MMU...which allows remapping of page 0 and page 1 (zero page and stack, respectively) at any given moment.  The same thing is possible with the 65816/65265 CPUs, which are the next target.  If you also use the o65 format, you can do software relocation.  There are still limitations of course, but the barriers are lower given those things...
> 
> Being able to remap the stack is a big win. Is 256 bytes a realistic C
> stack size, I wonder?

Not so much, but it does not a big issue as you can write a C compiler which
does not use "hardware" stack but a software implemented by the compiler
run-time compiled into the result. AFAIK eg with cc65 C compiler for 6502
this theory is used.

> 
> I did some work a while back looking at ways of doing C on the 6502 and
> the Z80. They both suck, because both processors predate
> stack-frame-based languages, and so don't have any useful addressing
> modes (like stack-relative addressing).

On 6502 stack is simply too small for a C like implementation for real in my
opinion. That's why cc65 does not use it, at least only partly. I can't tell
details but afaik local variables etc are allocated on "heap" which is
"normal memory" (not stack), and the "real hardware stack" is only used to
contain return addresses and some misc PHA stuffs to save register.

I guess it's a good idea to read cc65's source, it's quite good C compiler
especially if you consider it's not so easy to write one for 6502.
The cross-platform Contiki can be compiled for C64 with it, so it can't be
so bad :D