IBM Clown "Easter Egg" - CP/M

This is a discussion on IBM Clown "Easter Egg" - CP/M ; *Tom Lake* wrote on Fri, 07-10-12 19:17: >or HP vs. Texas Instruments calculators to see two examples of inferior >products doing better than superior ones due to skillful marketing. Sorry, but I have to disagree. If anything is marketing hype ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 55 of 55

Thread: IBM Clown "Easter Egg"

  1. Re: IBM Clown "Easter Egg"

    *Tom Lake* wrote on Fri, 07-10-12 19:17:
    >or HP vs. Texas Instruments calculators to see two examples of inferior
    >products doing better than superior ones due to skillful marketing.


    Sorry, but I have to disagree. If anything is marketing hype it's that
    RPN. I could see a bit of a case for polish nation, but the reverse
    stuff is adjusting to limitations of the machine (HP was first) and
    totally against usability. I have always preferred typing formulae as
    nearly as possible the same way I write them down on paper.
    The TI 58 with its magnetic cards was a great machine and so was the 59
    I had before that was extremely expensive at the time.


  2. Re: IBM Clown "Easter Egg"

    Hello Udo,

    Udo Munk schrieb:

    >Unfortunately it is not anymore, it must have been taken out at a much
    >later time by the fileserver admins, because of stricter and stricter
    >copyright laws. I know that it still was on the Vol 5 disk in 1986 from
    >here:
    >http://www.stcarchiv.de/hc1986/10_pdprogrammier.php
    >Don't bother to read, it's a german computer magazine article. Not that
    >interesting, just reviews about public domain software. Vol 5 is mentioned
    >with Eubanks Basic AND with Kildalls 1975 CP/M sources.


    Thanks for your Info.

    Rolf


  3. Re: IBM Clown "Easter Egg"

    On Sat, 13 Oct 2007 11:10:00 +0200, Axel Berger wrote:

    > *Tom Lake* wrote on Fri, 07-10-12 19:17:
    >>or HP vs. Texas Instruments calculators to see two examples of inferior
    >>products doing better than superior ones due to skillful marketing.

    >
    > Sorry, but I have to disagree. If anything is marketing hype it's that
    > RPN. I could see a bit of a case for polish nation, but the reverse
    > stuff is adjusting to limitations of the machine (HP was first) and
    > totally against usability. I have always preferred typing formulae as
    > nearly as possible the same way I write them down on paper.
    > The TI 58 with its magnetic cards was a great machine and so was the 59
    > I had before that was extremely expensive at the time.


    As little kids in school we learn to do the following:

    (11 + 3) * 2

    11
    + 3
    ---
    14 * 2
    ------
    8
    +20
    ------
    28

    That just is 11 3 + 2 *. This is how we think and how machines work. It's
    so simple that almost every little kid can pick this up and understand it.
    Then, when we get some older, we get brain washed and are forced to learn
    the formulae stuff. Just to learn, older again, when building machines to
    deal with that, that the machines work with reverse polish notation much
    more efficient. Well, no problem, we learn to build programmable machines
    and make that machine run through a recursive descent parser, to order our
    formulae mess into the correct order ;-)

    It is not the limitation of the machine, it's how things do work. I was
    lucky and I had a math teacher in school, who pointed this out to us, So I
    learned both.

    Want to know one of my darker secrets and how I kinda abused that? Don't
    know if you ever used the Z80 assembler from z80pack, but have a look at
    this:

    LOC OBJECT CODE LINE STMT SOURCE CODE
    0014 1 1 WRONG EQU 2+3*6
    001e 2 2 RIGHT EQU (2+3)*6
    0000 3 3 END

    The expression parser does descent down only when () are used
    correctly, else it just works from left to right ;-) That assembler is out
    in the wild since 20 years and in all that time ONE! person told me: Udo
    you got that parser done half only. He knew that I had learned to write
    such stuff and that I learned yacc/lex and all that. He knew that I just
    had been too busy to complete it, so he fixed it and gave me the sources
    with a completely working parser. I had a look at his parser, played a bit
    with it.... and then I though.... hehehe... and deleted it.

    Really, I often thought that I have to complete it sometime, but then
    again why? Seems that everyone gets along with that, no complains
    and there always was other interesting stuff to do.

    Pretty interesting hu? I'll leave it alone as it is.... well or maybe not.

    Udo Munk
    --
    The real fun is building it and then using it...


  4. Re: IBM Clown "Easter Egg"



    "Axel Berger" wrote in message
    news:200710131110.a1568@b.maus.de...
    > *Tom Lake* wrote on Fri, 07-10-12 19:17:


    > The TI 58 with its magnetic cards was a great machine and so was the 59
    > I had before that was extremely expensive at the time.


    The 58 didn't have mag cards, only the SR-52 and TI-59 did. That was after
    HP had the
    HP-65 and -67 which both had them.

    TI was always playing catch-up. Where TI made its brilliant move was in
    marketing to
    education.

    Tom Lake


  5. Re: IBM Clown "Easter Egg"

    Udo Munk wrote:
    > s_dubrovich wrote:
    >

    .... snip ...
    >
    >> All FAT does is remove the Disk Map from the FCB and congregate
    >> those in a linked list in a separate area before the Disk
    >> Directory, and Paterson had access to the source to FAT.

    >
    > No that is not all, documentation for FAT12 up here:
    > http://www.patersontech.com/dos/Byte/InsideDos.htm
    >
    > The directory entry looks very different from a FCB and the
    > blocks are keeped in a linked list. A bit more stolen from UNIX
    > filesystems than from CP/M, kinda poor mans UNIX filesystem that
    > is. The FCB in DOS were optional, only needed for CP/M converted
    > applications. The number of FCB's could be configured in
    > config.sys, remember? No FCB's no old CP/M appliaction software,
    > only new DOS software.


    Until DOS 2.0 all DOS file access was via FCBs. There were no
    subdirectories. The addition of hard-disks led to the present-day
    FAT filesystems.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.



    --
    Posted via a free Usenet account from http://www.teranews.com


  6. Re: IBM Clown "Easter Egg"

    Udo Munk wrote:
    (snip)

    > The directory entry looks very different from a FCB and the blocks are
    > keeped in a linked list. A bit more stolen from UNIX filesystems than from
    > CP/M, kinda poor mans UNIX filesystem that is.
    > The FCB in DOS were optional, only needed for CP/M converted applications.
    > The number of FCB's could be configured in config.sys, remember? No FCB's
    > no old CP/M appliaction software, only new DOS software.


    I thought FCBs were DOS 1.x, and file handles came with DOS 2.x,
    with FCBs for back compatibility.

    Somewhere I have the DOS encyclopedia so I could look it up.

    -- glen


  7. Re: IBM Clown "Easter Egg"

    Axel Berger wrote:
    (snip)
    > Sorry, but I have to disagree. If anything is marketing hype it's that
    > RPN. I could see a bit of a case for polish nation, but the reverse
    > stuff is adjusting to limitations of the machine (HP was first) and
    > totally against usability. I have always preferred typing formulae as
    > nearly as possible the same way I write them down on paper.


    If you write them on paper, that might be true.

    I always found RPN much easier if I didn't write it on paper first,
    and most likely even if I did.

    If you don't write it first, you don't know how many ( to put in
    the beginning.

    -- glen


  8. Re: IBM Clown "Easter Egg"

    no.spam@no.uce.bellatlantic.net wrote:

    (snip)

    > Actually the 8080 didn't use a crystal as clock generation was
    > external and delivered as a non overlaping two phase 12V signals.


    > the 8224 was the clock generator and used the 18.mumble mhz crystal
    > to generate 2mhz. Availability and cost lead to most early designs
    > using some form of TTL osc of the two gate variety, 2mhz crystal and
    > oneshots to create the needed timing. Many variations were used to
    > get those TTL based oscillators to behave. The usual problem with
    > that design was either not oscillating at all or taking off at the 2nd
    > or even third harmonic of the crystal mucking up timing.


    I still have "Osborne 4 and 8 bit processor handbook" which
    considers it a three chip processor set.

    > My altair had most of those clock ills. My first pass was replacing
    > the TTL osc with a two transistor design that was stable and provided
    > a clean signal. Second pass was sorting out oneshot timing. Third
    > pass was rip it all up and put down an 8224. I still avoid oneshots
    > to this day from that.


    The SOL uses a LFSR to divide 14.31818MHz by 7 or 5, and uses an
    LH0026 to drive the 8080. The 0026 is an amazing clock driver,
    which seems designed to drive DRAM arrays. It can drive 1.5 amps,
    which should be a lot more than the 25pF of the 8080 clock inputs
    requires.

    -- glen


  9. Re: IBM Clown "Easter Egg"

    On Mon, 15 Oct 2007 01:58:12 -0800, glen herrmannsfeldt
    wrote:

    >no.spam@no.uce.bellatlantic.net wrote:
    >
    >(snip)
    >
    >> Actually the 8080 didn't use a crystal as clock generation was
    >> external and delivered as a non overlaping two phase 12V signals.

    >
    >> the 8224 was the clock generator and used the 18.mumble mhz crystal
    >> to generate 2mhz. Availability and cost lead to most early designs
    >> using some form of TTL osc of the two gate variety, 2mhz crystal and
    >> oneshots to create the needed timing. Many variations were used to
    >> get those TTL based oscillators to behave. The usual problem with
    >> that design was either not oscillating at all or taking off at the 2nd
    >> or even third harmonic of the crystal mucking up timing.

    >
    >I still have "Osborne 4 and 8 bit processor handbook" which
    >considers it a three chip processor set.


    For practical purposes thats true. The 8080 unlike the 8085 or z80
    needed a great deal more hardware support between demuxing
    the status signals and generating the 12V clocks.

    >> My altair had most of those clock ills. My first pass was replacing
    >> the TTL osc with a two transistor design that was stable and provided
    >> a clean signal. Second pass was sorting out oneshot timing. Third
    >> pass was rip it all up and put down an 8224. I still avoid oneshots
    >> to this day from that.

    >
    >The SOL uses a LFSR to divide 14.31818MHz by 7 or 5, and uses an
    >LH0026 to drive the 8080. The 0026 is an amazing clock driver,
    >which seems designed to drive DRAM arrays. It can drive 1.5 amps,
    >which should be a lot more than the 25pF of the 8080 clock inputs
    >requires.


    LH026 was a much better device than open collector 7406 for drving
    clock lines. I have a machine that used that part to drive an 8080
    and the clocks look textbook. It didn't hurt that the timing source
    was a high (18mhz) source driving a digital counter rather than
    oneshots.

    Allison
    >
    >-- glen



  10. Re: IBM Clown "Easter Egg"

    On Sun, 14 Oct 2007 23:49:51 -0800, glen herrmannsfeldt wrote:

    > Udo Munk wrote:
    > (snip)
    >
    >> The directory entry looks very different from a FCB and the blocks are
    >> keeped in a linked list. A bit more stolen from UNIX filesystems than from
    >> CP/M, kinda poor mans UNIX filesystem that is.
    >> The FCB in DOS were optional, only needed for CP/M converted applications.
    >> The number of FCB's could be configured in config.sys, remember? No FCB's
    >> no old CP/M appliaction software, only new DOS software.

    >
    > I thought FCBs were DOS 1.x, and file handles came with DOS 2.x,
    > with FCBs for back compatibility.
    >
    > Somewhere I have the DOS encyclopedia so I could look it up.
    >
    > -- glen


    Maybe, I don't know anymore. Doesn't matter anyway because the FCB was
    used as frontend for applications only. On the disk there was this FAT12
    filesystem.

    Udo Munk
    --
    The real fun is building it and then using it...


  11. Re: IBM Clown "Easter Egg"

    On Mon, 15 Oct 2007 15:13:11 +0200, Udo Munk
    wrote:

    >On Sun, 14 Oct 2007 23:49:51 -0800, glen herrmannsfeldt wrote:
    >
    >> Udo Munk wrote:
    >> (snip)
    >>
    >>> The directory entry looks very different from a FCB and the blocks are
    >>> keeped in a linked list. A bit more stolen from UNIX filesystems than from
    >>> CP/M, kinda poor mans UNIX filesystem that is.
    >>> The FCB in DOS were optional, only needed for CP/M converted applications.
    >>> The number of FCB's could be configured in config.sys, remember? No FCB's
    >>> no old CP/M appliaction software, only new DOS software.

    >>
    >> I thought FCBs were DOS 1.x, and file handles came with DOS 2.x,
    >> with FCBs for back compatibility.
    >>
    >> Somewhere I have the DOS encyclopedia so I could look it up.
    >>
    >> -- glen

    >
    >Maybe, I don't know anymore. Doesn't matter anyway because the FCB was
    >used as frontend for applications only. On the disk there was this FAT12
    >filesystem.


    Exactly, FCBs are supported as an API for FAT12 and FAT16 but not
    FAT32 media. I had occasion to support a system that had to have FCBs
    (DbaseIII) on a PIII/1ghz machine and the solution was to force a
    FAT16 partition and that worked fine for W95, 98se, NT4 and even
    Win2K.

    The underlying filesystem is unimportant so long as the APIs required
    by the application (FCB interface) are there.


    Allison


    >Udo Munk



  12. Re: IBM Clown "Easter Egg"

    On Sun, 14 Oct 2007 23:53:01 -0800, glen herrmannsfeldt
    wrote:

    >Axel Berger wrote:
    >(snip)
    >> Sorry, but I have to disagree. If anything is marketing hype it's that
    >> RPN. I could see a bit of a case for polish nation, but the reverse
    >> stuff is adjusting to limitations of the machine (HP was first) and
    >> totally against usability. I have always preferred typing formulae as
    >> nearly as possible the same way I write them down on paper.

    >
    >If you write them on paper, that might be true.
    >
    >I always found RPN much easier if I didn't write it on paper first,
    >and most likely even if I did.
    >
    >If you don't write it first, you don't know how many ( to put in
    >the beginning.


    Exactly. Also, taking the earlier problem offered by Udo

    (11 + 3) * 2

    Rewrite that as 11 + 3 * 2 and ask a number of
    non-engineering, non-math major people to solve it by calculator or in
    their heads. Ask a mixture of TI and HP calc users.

    From most using TI calcs you will get 28 as the answer. From HP users
    you will mostly get 17 as the answer.

    The correct answer is 17.

  13. Re: IBM Clown "Easter Egg"

    Udo Munk wrote:

    > Want to know one of my darker secrets and how I kinda abused that? Don't
    > know if you ever used the Z80 assembler from z80pack, but have a look at
    > this:


    > LOC OBJECT CODE LINE STMT SOURCE CODE
    > 0014 1 1 WRONG EQU 2+3*6
    > 001e 2 2 RIGHT EQU (2+3)*6
    > 0000 3 3 END


    WRONG?

    Dunno where you went to school but 2+3*6 = 20 (0x14)
    and (2+3)*6 = 30 (0x1E)

    looks to me like both are correct.



  14. Re: IBM Clown "Easter Egg"



    "Jim Jackson" wrote in message
    news:ff5p8a$pcs$1$830fa7a5@news.demon.co.uk...
    > Udo Munk wrote:
    >
    >> Want to know one of my darker secrets and how I kinda abused that? Don't
    >> know if you ever used the Z80 assembler from z80pack, but have a look at
    >> this:

    >
    >> LOC OBJECT CODE LINE STMT SOURCE CODE
    >> 0014 1 1 WRONG EQU 2+3*6
    >> 001e 2 2 RIGHT EQU (2+3)*6
    >> 0000 3 3 END

    >
    > WRONG?
    >
    > Dunno where you went to school but 2+3*6 = 20 (0x14)
    > and (2+3)*6 = 30 (0x1E)
    >
    > looks to me like both are correct.


    Not all assemblers follow the algebraic rule MDAS. Some
    act like cheap calculators and perform the ops in the order
    encountered so 2+3*6 = (2+3)*6

    Tom Lake


  15. Re: IBM Clown "Easter Egg"

    On Wed, 17 Oct 2007 19:53:46 +0000, Jim Jackson wrote:

    > Udo Munk wrote:
    >
    >> Want to know one of my darker secrets and how I kinda abused that? Don't
    >> know if you ever used the Z80 assembler from z80pack, but have a look at
    >> this:

    >
    >> LOC OBJECT CODE LINE STMT SOURCE CODE
    >> 0014 1 1 WRONG EQU 2+3*6
    >> 001e 2 2 RIGHT EQU (2+3)*6
    >> 0000 3 3 END

    >
    > WRONG?
    >
    > Dunno where you went to school but 2+3*6 = 20 (0x14)
    > and (2+3)*6 = 30 (0x1E)
    >
    > looks to me like both are correct.


    Won't tell, school probably was ok, I just messed this up ;-)

    Let's see, parser works from left to right on the equation recursively
    down until end. This is because it needs to see what is coming. Then on
    the way back up it does the calculation, so that would be from right to
    left, in this case 6 * 3 + 2. This is correct in this example, but if we
    reverse the formula then we get:

    LOC OBJECT CODE LINE STMT SOURCE CODE
    0018 1 1 WRONG EQU 3*6+2
    0014 2 2 RIGHT EQU (3*6)+2
    0000 3 3 END

    The recursion is done, parenthesis are higher hierarchy and reduced to a
    value, but otherwise hierarchy of operators is not implemented. The order
    of operations must be brought into the right one, before the parser
    ascends up to calculate the result. Seems to work ok, because most people
    write formulas with parenthesis, to express what they want to get
    calculated.

    Thanks for pointing out my mistake.

    Udo Munk
    --
    The real fun is building it and then using it...


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