life extension of old computers thanks to opensource Contiki - CP/M

This is a discussion on life extension of old computers thanks to opensource Contiki - CP/M ; Peter de Vroomen wrote: > In comp.sys.apple2, somebody posted a link to this chip: > http://www.winbond-usa.com/mambo/con...SelectionGuide > > This chip is just WAITING for a port of Contiki, I'd say . Hardly. It's a masked part only (though without reading ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 67

Thread: life extension of old computers thanks to opensource Contiki

  1. Re: life extension of old computers thanks to opensource Contiki


    Peter de Vroomen wrote:

    > In comp.sys.apple2, somebody posted a link to this chip:
    > http://www.winbond-usa.com/mambo/con...SelectionGuide
    >
    > This chip is just WAITING for a port of Contiki, I'd say .


    Hardly. It's a masked part only (though without reading the datasheet I
    can guarantee that it supports external serial ROM also). This chip is
    intended for those multi-game TV games built into a joystick or other
    controller. It is a "me-too" part since Sunplus (a Winbond competitor
    in the toy market) had enormous success with their SNES-on-a-chip. You
    won't be able to buy the part at all without a quantity commitment.

    Having worked with Winbond over a number of years, I can tell you their
    documentation will be grossly incomplete and barely comprehensible,
    their development system will be impossible to acquire without a
    personal relationship, and fiendishly difficult to use once you do
    manage to get it.


  2. Re: life extension of old computers thanks to opensource Contiki

    Peter de Vroomen wrote:

    > And about 'RISC architecture'... Of course these days the differences
    > between RISC and CISC are pretty muddy. A Pentium 4 processor has all
    > the characteristics of a RISC processor, but it still has a CISC


    Dear Peter, I think you mean the i686. Look at the P4 Power-Ratings!
    That Thing cannot be with RISC. Also the i586 Clone AMD XPxxxx... no
    RISC.

    There are some efficient Pentium available, but not the P4 :-)

    (Microopcpode, ISSE3 ---- ****e)

    Well, the EE P4 is exceptionally. But 154W Power Consumption!?

    The Pentium I use, needs about 26W and form in a line, between a
    P4-2600 Standard (and XP2200), up to P4-2800 (XP-2400).
    Memory latency is half as fast, as the fastest 64bit AMD Board and
    faster than some Dual Channel 'DDR' 1600MHz FSB Boards (Standard 32bit).


    I think time is needed, for coding RISC CpU´s. The 680xx is one of the
    best CISC, beside the Z80. IMHO.
    Although, I would say the percentage of Programmer on this world, is
    still higher with 8bit than with 16bit (also many - older
    win3.11/win32s coder etc.), or 32bit. I am not talking about C+ or C++.
    Milking Machine etc.

    Less is more!




    Best Regards,

    Daniel Mandic

  3. Re: life extension of old computers thanks to opensource Contiki

    On 08 Feb 2006 14:08:14 GMT, "Daniel Mandic"
    wrote:

    >Peter de Vroomen wrote:
    >
    >> And about 'RISC architecture'... Of course these days the differences
    >> between RISC and CISC are pretty muddy. A Pentium 4 processor has all
    >> the characteristics of a RISC processor, but it still has a CISC

    >
    >Dear Peter, I think you mean the i686. Look at the P4 Power-Ratings!
    >That Thing cannot be with RISC. Also the i586 Clone AMD XPxxxx... no
    >RISC.
    >
    >There are some efficient Pentium available, but not the P4 :-)
    >
    >(Microopcpode, ISSE3 ---- ****e)
    >
    >Well, the EE P4 is exceptionally. But 154W Power Consumption!?
    >
    >The Pentium I use, needs about 26W and form in a line, between a
    >P4-2600 Standard (and XP2200), up to P4-2800 (XP-2400).
    >Memory latency is half as fast, as the fastest 64bit AMD Board and
    >faster than some Dual Channel 'DDR' 1600MHz FSB Boards (Standard 32bit).


    To me the Pentium is a 8088 carried to the CISC proportions that are
    truly representitive of what happens when you keep the bag on the
    side. Legacy CPU models really hurt.

    Of the CISC CPUs the PDP-11 and VAX far outperformed the 680xx.
    Though the 68000 borrowed on that tech hard and was better than
    a lot of the others.

    >I think time is needed, for coding RISC CpU´s. The 680xx is one of the
    >best CISC, beside the Z80. IMHO.


    Z80 is not CISC it's on the cusp, it's complex but not quite CISC
    and clearly not RISC. Of the 8bitters it represents a highly complex
    cpu but look at the 6809 before saying it was the top. The 6809 has
    all the addressing modes needed to allow for efficiently compiled
    languages.

    In the 8bit world there is a greater mix of RISC like and cpus that
    have CISC like instructions. Most borrow on RISC concept of simple
    instructions that when strung together execute fast but require
    limited resources (registers, ALU or address computation harware).
    The beauty is that they require small die and are easily extended
    with peripherals wither on chip or off depending on era.

    In the world of 8bit RISC the lowly 1802 COSMAC is forgotten and the
    6502 is well known. Both have long lives. However the then
    definition of RISC was reduced instruction set AND instructions that
    only executed in one or two clocks. Most of the more sophisticated
    RISC machines I've happened across and used were easy to program
    by hand but hard to program optimally.

    If you want to see reduced instruction sets and minimalist hardware
    PDP-8, and a lot of the 4bit cpus are good examples to look at. A lot
    of work done with very few transistors (gates).

    >Although, I would say the percentage of Programmer on this world, is
    >still higher with 8bit than with 16bit (also many - older
    >win3.11/win32s coder etc.), or 32bit. I am not talking about C+ or C++.
    >Milking Machine etc.


    Put the words "assembler programmers" in there and yes, once you get
    to bigger platforms assembler is usually a rare thing to see.

    >Less is more!


    Often!

    Allison

  4. Re: life extension of old computers thanks to opensource Contiki

    Daniel Mandic did eloquently scribble:
    > Dear Peter, I think you mean the i686. Look at the P4 Power-Ratings!
    > That Thing cannot be with RISC. Also the i586 Clone AMD XPxxxx... no
    > RISC.



    *sigh*
    Here we go again.
    I really wish you'd stop talking out of your backside like this, you're only
    making a fool out of yourself.

    Pentium 4 AKA i686 *IS* very VERY similar to RISC.
    It's instruction set it CISC but is based on a microcode architecture that
    IS RISC. You just don't program directly in microcode. The chip translates
    the CISC instructions into much smaller RISC steps before they get
    pipelined.

    And power consumption has NOTHING at ALL to do with whether a CPU is CISC or
    RISC.
    --
    __________________________________________________ ____________________________
    | spike1@freenet.co.uk | "Are you pondering what I'm pondering Pinky?" |
    |Andrew Halliwell BSc(hons)| |
    | in | "I think so brain, but this time, you control |
    | Computer Science | the Encounter suit, and I'll do the voice..." |
    ------------------------------------------------------------------------------

  5. Re: life extension of old computers thanks to opensource Contiki

    Peter de Vroomen wrote:
    > I think that 8-bit processors are not really interesting anymore. The only
    > reason to use an 8-bit processor might be that the systems and the processor
    > are so simple, that there is a lot of educational value. Everyone can learn
    > to understand a computer by starting on 8-bit processors.
    >
    > However 16-bit processors are much more interesting. They are hardly any
    > more complicated than 8-bit processors, but they do offer some very
    > interesting extra's. More processing power, more memory, divide/multiply
    > instructions, instructions for structured ASM programming, and even memory
    > management (although often rather crude). All that, while hardly being more
    > complicated than an 8-bit system (software and hardware wise).
    >
    > There is only one 8-bit exception. I agree with David Murray that the
    > DTV/C-one is such an advanced 8-bit system, that it could be worthwile to
    > port Contiki to that.
    >
    > I think that maybe it might be feasible to convert the C-one's design into a
    > 16-bit system with an 68010 processor. Imagine having a 16MHz 68010
    > processor with 2 SID's (stereo through a mixer), 2 enhanced VIC's (two
    > overlayed graphics planes, like the CD-i), 16Mb memory and 16-bit
    > peripherals! And running Contiki. That would be a system that could actually
    > DO something worthwile, other than being educational!


    So you want a system inferior to the Amiga? It's still out there.
    Two channel stereo, up to (I think) 5 graphics planes, multiple screens
    with different color palettes and resolution if you want. 64Mb, 128Mb
    or more of RAM. Can't remember the max RAM you could add, but the CPU
    had a 32 bit address register.
    Granted the original had a 4.77 MHz 68000, but the later versions came
    with a 68020 (not sure of the clock speed). IIRC, the 68010 is no longer
    available. This is a 32 bit chip family, some of the systems had a 16
    bit bus, others a 32 bit bus.
    The processor card slot allowed you to just drop in a 68020, 68030,
    68040, or 68060 card, boot and run. The 68020 and up has multiply
    and divide instructions. And an instruction set that makes it easy
    to write assembler. The 68040 and 68060 have built in math co-processors
    and MMU (memory management unit).

    > Stepping up to 32-bit systems is not worthwile (for running Contiki) imo.
    > The next step in educational value would be something like a 32-bit ARM7
    > processor/core. But the new Minix 3 is probably just too much for Contiki to
    > contend with.
    >
    > PeterV


    The ARM is a RISC design isn't it? Which means it is intended to be used
    with a compiler; assembly coding is not as easy as on a CISC chip like
    the 68000 family.

    --
    Jerry wa2rkn

  6. Re: life extension of old computers thanks to opensource Contiki

    >>>>> "JK" == Jerry Koniecki writes:

    JK> Granted the original had a 4.77 MHz 68000, but the later versions
    JK> came with a 68020 (not sure of the clock speed)

    The most common Amiga models were:

    1985 A1000 68000 7.14 MHz
    1987 A500 68000 7.14 MHz
    1987 A2000 68000 7.14 MHz
    1990 A3000 68030 25 MHz
    1992 A600 68000 7.14 MHz
    1992 A4000/030 68030 25 MHz
    1992 A1200 68020 14.28 MHz
    1993 A4000/040 68040 25 MHz

    --
    ___ . . . . . + . . o
    _|___|_ + . + . + . Per Olofsson, arkadspelare
    o-o . . . o + MagerValp@cling.gu.se
    - + + . http://www.cling.gu.se/~cl3polof/

  7. Re: life extension of old computers thanks to opensource Contiki

    Jerry Koniecki wrote:

    > So you want a system inferior to the Amiga? It's still out there.
    > Two channel stereo, up to (I think) 5 graphics planes, multiple screens
    > with different color palettes and resolution if you want. 64Mb, 128Mb
    > or more of RAM. Can't remember the max RAM you could add, but the CPU
    > had a 32 bit address register.


    I don't know which system you are talking about, but though the 68000
    did have 32-bit address registers, it could only address 16 MBytes of
    memory since it had only 24 address lines.

    > Granted the original had a 4.77 MHz 68000, but the later versions came
    > with a 68020 (not sure of the clock speed). IIRC, the 68010 is no longer
    > available. This is a 32 bit chip family, some of the systems had a 16
    > bit bus, others a 32 bit bus.
    > The processor card slot allowed you to just drop in a 68020, 68030,
    > 68040, or 68060 card, boot and run. The 68020 and up has multiply
    > and divide instructions.


    So did the 68000, the 68008, the 68010 and all the other members of the
    68K family, so what is your point?

  8. Re: life extension of old computers thanks to opensource Contiki

    spike1@freenet.co.uk wrote:

    > And power consumption has NOTHING at ALL to do with whether a CPU is
    > CISC or RISC.


    Yes?

    Well, then there is something wrong with the P4.



    Best Regards,

    Daniel Mandic

  9. Re: life extension of old computers thanks to opensource Contiki

    Daniel Mandic did eloquently scribble:
    >
    >
    > spike1@freenet.co.uk wrote:
    >
    >> And power consumption has NOTHING at ALL to do with whether a CPU is
    >> CISC or RISC.

    >
    > Yes?
    >
    > Well, then there is something wrong with the P4.


    No-one said there wasn't.
    --
    -----------------------------------------------------------------------------
    | spike1@freenet.co.uk | Windows95 (noun): 32 bit extensions and a |
    | | graphical shell for a 16 bit patch to an 8 bit |
    |Andrew Halliwell BSc(hons)| operating system originally coded for a 4 bit |
    | in |microprocessor, written by a 2 bit company, that|
    | Computer Science | can't stand 1 bit of competition. |
    -----------------------------------------------------------------------------

  10. Re: life extension of old computers thanks to opensource Contiki

    In article <43e9c237$0$11067$e4fe514c@news.xs4all.nl>,
    Peter de Vroomen wrote:
    >> Learning to code in ARM assembler is by no means a useless skill, as it
    >> is directly applicable to modern-day engineering tasks.

    >
    >No, of course not, but optimizing for a RISC processor is simply more
    >challenging than optimizing for a CISC processor. If you want to learn
    >assembly, it's best to start with a CISC processor, learn the basics, and
    >then step up to the RISC processor.


    For optimization difficulty, RISC or CISC makes little difference;
    superscalar or not is the big difference, and both CISC and RISC
    machinese are superscalar nowadays. So even leaving branches out of
    it, you have to maintain multiple parallel cycle counts. Add the fact
    that memory access isn't constant (depending on cache) and you have a
    real bear of a problem.

    PowerPC assembler -- or ARM, for that matter, -- is much easier to
    learn than x86 simply because x86 is still a 32-bit patch on a 16-bit
    extension of an 8-bit machine, and its instruction set shows it. The
    paucity of registers doesn't help either, though the direct-to-memory
    instructions do.

    >And about 'RISC architecture'... Of course these days the differences
    >between RISC and CISC are pretty muddy.


    About the only constant in RISC seems to be the lack of memory addressing
    modes for any instructions other than loads and stores. That is, you
    can't do arithmetic or branch based on a memory location.
    --
    There's no such thing as a free lunch, but certain accounting practices can
    result in a fully-depreciated one.

  11. Re: life extension of old computers thanks to opensource Contiki

    Peter de Vroomen wrote:
    >>Learning to code in ARM assembler is by no means a useless skill, as it
    >>is directly applicable to modern-day engineering tasks.

    >
    >
    > No, of course not, but optimizing for a RISC processor is simply more
    > challenging than optimizing for a CISC processor. If you want to learn
    > assembly, it's best to start with a CISC processor, learn the basics, and
    > then step up to the RISC processor.


    Though I tend to agree with your conclusion about learning programming,
    it is an error to think that optimization for a CISC machine is easier
    than for a RISC machine.

    RISC architecture was motivated by advanced compiler writers discovering
    that straightforward use of CISC instructions was *not* optimal. Often,
    much better speed could be achieved by ignoring the storage-to-storage
    forms of CISC instructions entirely, and using, for example, register
    loads and stores to move strings--not at all what the CISC architecture
    suggests is appropriate.

    Further, the procedure linkage instructions provided in CISC machines
    were almost always either too much or too little for the job at hand
    if optimality was the issue.

    In virtually every case where the CISC architect had attempted to
    close the mythical "semantic gap", an efficiency pitfall had been
    created.

    John ****e proposed a RISC architecture precisely to regularize the
    instruction set and match it to the hardware, so that an optimizer, in
    generating code, would have fewer inefficient choices offered!

    The demands that RISC makes of optimization is not combinatorial search
    and simulation of all possible ways of doing a task, but simply the
    repeated application of determinstic algorithms to allocate registers,
    schedule instructions, etc.

    Of course, as things have become more deeply pipelined, superscalar,
    multi-level cached, etc., all machine architectures have become more
    complex to program efficiently...

    > Hand-optimization will allways be needed, and a good programmer can probably
    > optimize the code better than a compiler can. But hand-optimization only
    > applies to small pieces of the code, like Interrupt Service Routines.
    > Generally a program consists of more than just an ISR .
    >
    > And about 'RISC architecture'... Of course these days the differences
    > between RISC and CISC are pretty muddy. A Pentium 4 processor has all the
    > characteristics of a RISC processor, but it still has a CISC instruction
    > set. So does the AVR. The PIC, however, has an instruction set that is
    > really RISC. Very limited, but every instruction is executed very fast.
    > Often you need more than one instruction to accomplish something a CISC
    > processor does in one instruction.


    CISC processors have assumed the implementation character of RISC
    processors, but there is still a huge difference in what can be
    directly expressed in the machne language.

    A CISC assembly language programmer has little recourse but to
    re-compute effective addresses that the RISC programmer would have
    saved in a register for re-use. And the CISC programmer will have
    to allocate some variables to memory that a RISC programmer would
    have kept in the register file.

    These differences make a considerable difference in advanced
    assembly programming on the two styles of machine.

    -michael

    Music synthesis for 8-bit Apple II's!
    Home page: http://members.aol.com/MJMahon/

    "The wastebasket is our most important design
    tool--and it is seriously underused."

  12. Re: life extension of old computers thanks to opensource Contiki

    Peter de Vroomen wrote:

    > It's actually even worse. Most opcodes of modern RISC processors are
    > tailored to some specific high-level language (of course, mostly C or C++).
    > The high-level language compiler can optimize way better for these
    > processors than a programmer can do by hand.


    Actually, there are very few *specific* adaptations to programming
    languages in most RISC architectures. The adaptations, if any, tend
    to be to specific data representations--like IEEE floating-point, or
    null-terminated strings, or, occasionally, to BCD data.

    RISC architectures *should* be based on dynamic frequency, not on
    a catalog of "nice features", and this eliminates most of the
    traditional language-specific opcodes (since every language needs
    load, store, and conditional branch ;-).

    Many of the "decorations" that have shown up in the last ten years
    are related more to simplifying optimization and implementations
    in highly superscalar, deeply pipelined machines--like predicated
    execution and branch hinting.

    > Typically, IF more optimization
    > is needed, the programmer needs to only optimize one or two simple routines.
    > Optimizing the rest of the code by hand just doesn't weigh up against the
    > time it costs.


    This, of course, is generally true, independent of architecture or
    language.

    -michael

    Music synthesis for 8-bit Apple II's!
    Home page: http://members.aol.com/MJMahon/

    "The wastebasket is our most important design
    tool--and it is seriously underused."

  13. Re: life extension of old computers thanks to opensource Contiki

    Matthew Russotto wrote:
    > In article <43e9c237$0$11067$e4fe514c@news.xs4all.nl>,
    > Peter de Vroomen wrote:
    >
    >>>Learning to code in ARM assembler is by no means a useless skill, as it
    >>>is directly applicable to modern-day engineering tasks.

    >>
    >>No, of course not, but optimizing for a RISC processor is simply more
    >>challenging than optimizing for a CISC processor. If you want to learn
    >>assembly, it's best to start with a CISC processor, learn the basics, and
    >>then step up to the RISC processor.

    >
    >
    > For optimization difficulty, RISC or CISC makes little difference;
    > superscalar or not is the big difference, and both CISC and RISC
    > machinese are superscalar nowadays. So even leaving branches out of
    > it, you have to maintain multiple parallel cycle counts. Add the fact
    > that memory access isn't constant (depending on cache) and you have a
    > real bear of a problem.


    Bingo.

    > PowerPC assembler -- or ARM, for that matter, -- is much easier to
    > learn than x86 simply because x86 is still a 32-bit patch on a 16-bit
    > extension of an 8-bit machine, and its instruction set shows it. The
    > paucity of registers doesn't help either, though the direct-to-memory
    > instructions do.


    They don't help if you want to go fast...you just have to find a way
    to trick the CISC-to-microcode translator to do what you really want
    it to do, in spite of the CISC interface. (The fact that the rules
    change from generation to generation makes this quite problematic.)

    >>And about 'RISC architecture'... Of course these days the differences
    >>between RISC and CISC are pretty muddy.

    >
    >
    > About the only constant in RISC seems to be the lack of memory addressing
    > modes for any instructions other than loads and stores. That is, you
    > can't do arithmetic or branch based on a memory location.


    There are a few other things... fixed/regular instruction formats,
    constant instruction execution time, large general register files,
    data aligned on natural boundaries, all instructions implementable
    by a simple combinatoric logic data path, etc.

    -michael

    Music synthesis for 8-bit Apple II's!
    Home page: http://members.aol.com/MJMahon/

    "The wastebasket is our most important design
    tool--and it is seriously underused."

  14. Re: life extension of old computers thanks to opensource Contiki

    Michael J. Mahon wrote:

    > "The wastebasket is our most important design
    > tool--and it is seriously underused."



    You mean my Pentium is a wacky, unoptimized piece of multilevel cached
    CISC (RISC). Downgraded to Milestones like 'ELITE II' or 'Tempest2000'
    to see a bit of digital-art. (Not audible on actual systems)

    You could easy say the RISC is better, but the time is wrong... or not?
    Otherwise (meanwhile) the CISC-Base got their profits, but only to go
    the way back!? hmmm. I am confused.




    Best Regards,

    Daniel Mandic

  15. Re: life extension of old computers thanks to opensource Contiki

    Peter de Vroomen wrote:
    > The ARM is a RISC processor, and RISC processors are not really suitable to
    > hand-coding. Assembly code for a RISC processor needs to be optimized to
    > have it make use of all the advanced features. Unoptimized code is often


    I cut my teeth on Z80 and 6502 and found ARM one of the easiest CPUs
    to learn and the easiest to hand-code and optimise.

    --
    JGH


  16. Re: life extension of old computers thanks to opensource Contiki

    Daniel Mandic wrote:
    > Michael J. Mahon wrote:
    >
    >
    >>"The wastebasket is our most important design
    >>tool--and it is seriously underused."

    >
    >
    >
    > You mean my Pentium is a wacky, unoptimized piece of multilevel cached
    > CISC (RISC). Downgraded to Milestones like 'ELITE II' or 'Tempest2000'
    > to see a bit of digital-art. (Not audible on actual systems)
    >
    > You could easy say the RISC is better, but the time is wrong... or not?
    > Otherwise (meanwhile) the CISC-Base got their profits, but only to go
    > the way back!? hmmm. I am confused.


    Yes, the RISC principles provided both an implementation advantage
    (simple, non-state-machine datapath) and an overall advantage in
    system-level cost-performance (removal of computation from execution
    time to compile time).

    CISC manufacturers, who owned the market, adopted the RISC-style
    datapaths to capture the implementation advantage, and abandoned
    the second advantage.

    -michael

    Music synthesis for 8-bit Apple II's!
    Home page: http://members.aol.com/MJMahon/

    "The wastebasket is our most important design
    tool--and it is seriously underused."

  17. Re: life extension of old computers thanks to opensource Contiki

    jgh@arcade.demon.co.uk wrote:
    > Peter de Vroomen wrote:
    >> The ARM is a RISC processor, and RISC processors are not really suitable to
    >> hand-coding. Assembly code for a RISC processor needs to be optimized to
    >> have it make use of all the advanced features. Unoptimized code is often

    >
    > I cut my teeth on Z80 and 6502 and found ARM one of the easiest CPUs
    > to learn and the easiest to hand-code and optimise.
    >

    Agreed! I learned 65xx machine code back in the 80's from my C=64 and
    C=128... (Which my Apple II using friends kept consulting me about.) I
    picked up some Atmel AVR's, and very quickly wrote assembly language
    applications for my band's MIDI setup. (Metronome, channel router and
    keyboard splitter are the currently used devices.) I never considered
    using a C compiler or a compiled BASIC.

    -Urson Bear

  18. Re: life extension of old computers thanks to opensource Contiki

    > Dear Peter, I think you mean the i686. Look at the P4 Power-Ratings!
    > That Thing cannot be with RISC. Also the i586 Clone AMD XPxxxx... no
    > RISC.


    Well, actually I meant that all instructions are executed in hardware.
    You're quite right about all the rest .

    PeterV



  19. Re: life extension of old computers thanks to opensource Contiki

    > Pentium 4 AKA i686 *IS* very VERY similar to RISC.

    Sorry, but the Pentium 4 is not i686. The Pentium 4 is ia32. The i686 is a
    RISC processor family of Intel. I believe it was meant specially for media
    purposes (audio, video), but I'm not sure.

    PeterV



  20. Re: life extension of old computers thanks to opensource Contiki

    Peter de Vroomen wrote:

    > Sorry, but the Pentium 4 is not i686. The Pentium 4 is ia32. The i686 is a
    > RISC processor family of Intel. I believe it was meant specially for media
    > purposes (audio, video), but I'm not sure.


    I believe you might be mixing up i686 with i860.

    --
    Linards Ticmanis

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast