Loading ...
Sorry, an error occurred while loading the content.

Re: ELFos questions

Expand Messages
  • Allison Parent
    Mike, So you know apparently elf-emulation.com is down or lost it s link as I ve not been able to reach it the past two days. Allison ... NT4)?
    Message 1 of 67 , Dec 1, 2005
    • 0 Attachment

      So you know apparently elf-emulation.com is down or lost it's link
      as I've not been able to reach it the past two days.


      --- In cosmacelf@yahoogroups.com, rileym65 <no_reply@y...> wrote:
      > Allison,
      > The best source of API information is the Elf/OS manual. This is
      > located on my website (http://www.elf-emulation.com/). it is the first
      > file under the section Elf/OS Related Documents. The source code
      > Elf/OS is available from the same page.
      > My emulator is the only one i know of right now that can run Elf/OS.
      > Again, available from my site.
      > Mike
      > --- In cosmacelf@yahoogroups.com, "Allison Parent" <kb1gmx@a...> wrote:
      > >
      > > Mike or anyone else that can answer, please.
      > >
      > > I'm trying to understand ELFos while working to get hardware
      > > running, so some questions.
      > >
      > > I found one rather short text file of ELFos. there is an API list
      > > but, is there a calling procedure for elfos? Stuff like
      > > how data or parameters are passed plus calling conventions.
      > >
      > > Is source for ELFos around? I've found a lot of stuff but none I've
      > > identified as source. The source will help understand elfos.
      > >
      > > What emulator is available that can run elfos (under winders9x or
      > >
      > > More later,
      > >
      > > Allison
      > >
    • Allison Parent
      You made me think about it. So I took some time and did a bit of research. Some of it in my old project files. ... Found a copy of MINOL, 1.75k 8080 Basic.
      Message 67 of 67 , Jan 15, 2006
      • 0 Attachment
        You made me think about it. So I took some time and did a bit of
        research. Some of it in my old project files.

        --- In cosmacelf@yahoogroups.com, Lee Hart <leeahart@e...> wrote:
        > Lee Hart wrote:
        > >> I've found that 1802 programs are usually smaller than their
        > >> equivalent for other CPUs.
        > Allison Parent wrote:
        > > Call be sceptic on that. A lot of the code I've been reading is
        > > bigger. I have seen TB for 8080 that was quite tiny...
        > The smallest 8080 Tiny BASIC I've seen was 1.5k, but took some
        > drastic measures such as all math being hexadecimal, no parentheses,
        > and no operator precedence. 8080 Tiny BASIC with the same features
        > as Pittman's was 2.5k bytes. The 1802 version was 2k bytes.

        Found a copy of MINOL, 1.75k 8080 Basic. Interesting beast in that
        the largest numbers are 255 (decimal) but it did include an array
        with a dual address (H,L). Interesting in the same respect as
        Chip-8 as an example of a small language that is still useful.

        However, when it come to full featured Tiny Basics the 8080 and 1802
        run neck and neck with maybe the 1802 being a few bytes better. One
        has to resort to 6502, z80 and 6809 to do better for size or speed.

        While I expressed disbelief I'm overall still impressed by 1802. I
        looked back at the code I did around 1982 for a smart FDC using 1802
        dma (plus2716/2116/765) design and noticed that while the oddball
        the instruction set is not as inefficient as originally thought. I
        had not looked at it in 20+ years but it's still running. I also did
        an 8085 and 8049 version of same and all run about the same size code
        for and identical task (it had to fit in a 2716).

        > Pittman's opinion was that the 1802 was the most memory-efficient of
        >all the contemporary CPUs. I have to agree; I've done a lot of
        > assembler for both the 8080 and 1802, and the 1802 wins. My IDIOT
        >monitor is just 512 bytes, and that includes a bit-banger software
        >UART. 8TH (a version of FORTH) was under 4k bytes.

        I'd say it runs par though doing it as 8080 required a real attack
        mentality to fit it. Moving to 8085 makes it easier especially if you
        use the ever present but "undocumented" instructions. But, they still
        run close.

        > The 1802 certainly loses on speed, however. It takes more clock
        >cycles to do most tasks, and given that its clock speed is similar
        > to contemporary CPUs (8080, 6800, 6502, etc.), it is always slower.

        I looked at it with a eye to 1980 and it was par with 8080(2mhz)
        and z80 (1.7mhz TRS80). What didn't happen is unlike the 8085 at
        6mhz and z80s (flavors to 33mhz!) the effort to move 1802 to new
        CMOS technologies that give us superfact sub 10ns static rams.
        An 1802 at a mere 2.5x faster (8mhz crystal) would be faster than
        8080 hands down and if current CMOS design were applied there is no
        reason why it could not run at 32mhz(instruction rate of 4MIPs!) or

        I'd state that I stopped using 8080 in 1976 for three reasons.
        Slow, 2mhz wasn't enough. Three voltages and two support parts
        needed due to the 12v clocks and multiplexed status on data lines.
        This is where the 1802 does well, CMOS low power, easy to use
        and it's easy timing. The 8085 and Z80 were much friendlier parts
        that had better features. The small differences between the 8085
        and 8080 are enough to give the '85 enough advantage to make it a
        good part. Better than 1802, in 1980 it's have to say it's only
        on par.

        > The 1802 is more like RISC or microcode; you tend to see certain
        >pairs of instructions frequently used to build more powerful
        > instructions. If you are trying to build "standard" programs,
        >this is a nuisance. But if you can re-think your problem to suit
        >the instruction set, you come out ahead.

        Agreed. When I put on the RISC hat and apply it it does well. The
        big pain of programming it is it's hard to program optimally. For
        1980s compilers the code would likely be very poorly optimized but
        modern cross platform compiler technology would do better. By hand
        it's possible to do well.

        The 1802 stands up well over time. It's in the pack with 8085, Z80,
        6502 and PDP-8 derivitives. Like the PDP-8 the 1802 has a uniqueness
        that makes it worth knowing and understanding.

      Your message has been successfully submitted and would be delivered to recipients shortly.