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

Re: A Christmas Clock

Expand Messages
  • joshbensadon
    Problem. I can t get the 1802 to make white noise. I ve tried a pseudo number generator that shifts a number out to the DF flag and XOR s a constant on DF
    Message 1 of 75 , Dec 4, 2012
    • 0 Attachment
      Problem.

      I can't get the 1802 to make white noise.

      I've tried a pseudo number generator that shifts a number out to the DF flag and XOR's a constant on DF being set. Copies the DF flag to the Q, but it sounds too computer like and not white noise.

      Next, I made a table of 256 random bytes and based on a bit I set/reset the Q as I run through it, sounds better, but definitely not white noise.

      I think you're gonna need to supply the white noise externally.
      Can we mix Q and a white noise generator?

      Next, as you pointed out, the OUT instruction won't work without RAM, but that's ok, you can just wire your output latch as Memory mapped I/O. A write to any address will output the byte.

      I going to push on with the rest of the code while you get the hardware fixed up.

      Cheers,
      Josh






      --- In cosmacelf@yahoogroups.com, Lee Hart <leeahart@...> wrote:
      >
      > On 12/3/2012 5:54 PM, Josh Bensadon wrote:
      > > I want in on this project. Always happy to help out my friend Lee.
      >
      > Thanks Josh! Delighted to have your help!
      >
      > > Interrupts will be tricky since it will limit our use of multiple PC's.
      >
      > Yes, it does. An 1802 interrupt saves P and X in register T. But SAVE is
      > the only instruction to save T; and it saves it in RAM. (This RAM copy
      > is subsequently put back into X and P by the RETurn or DISable
      > instruction at the end of the interrupt handler).
      >
      > Without RAM, R(X) has to point to a byte (in ROM) containing the current
      > values of P and X whenever interrupts are enabled. That's awkward, since
      > OUT instructions need R(X) to point to the data to be output.
      >
      > > Further, it will tax register 1 away from our uses.
      >
      > I don't think this clock will even come *close* to using all the registers.
      >
      > > I would suggest putting everything into a long real time loop.
      >
      > As I think more about it, I think you're right. Don't use interrupts at
      > all. Make the whole program one big loop. It watches a flag line for a
      > rising edge on the 60 Hz input. When found, it increments the time, does
      > one scan of the LEDs, checks for button pushes to set the time or alarm,
      > and makes noises if the alarm has gone off. It has to get all this done
      > in less than 16 msec. Then it goes into a wait loop, watching for the
      > next rising edge on the 60 Hz input.
      >
      > It's straightforward, but more difficult to write. Specifically, it's
      > harder to keep the on-time of every LED the same (so they don't
      > flicker). It's also harder to produce a sound without "glitches" in it,
      > due to the unpredictable time spent waiting for the next 60hz edge.
      >
      > The real appeal of this approach is to "just git 'er done." Christmas is
      > coming. I need to slap something together for now. I can go back and
      > improve it later.
      >
      > > As I see it so far, Register usage is:
      > > 0=PC
      > > 1
      > > 2
      > > 3
      > > 4
      > > 5
      > > 6
      > > 7
      > > 8
      > > 9
      > > A
      > > B.0 = State control for System (sound, display, input EF's)
      > > C.0 = LED Scan
      > > C.1 = Pseudo generator for White Noise
      > > D=Pre scale counter (3600 counts per minute)
      > > E=Real Time
      > > F=Alarm Time
      > >
      > > What am I missing? More to come as the program develops.
      >
      > This could work, though I'd probably use the more traditional
      > assignments. Here's what I had written down (trying to be mnemonic):
      >
      > R0 initial PC, only used during initialization
      > R1 not used (if no interrupts)
      > R2 for X (not a stack, but for I/O. Points to a 256 byte
      > table whose low byte is the same as its address,
      > so you put the byte to be output in R2.0 instead
      > of RAM).
      > R3 PC of main program
      > R4-R9 PCs for various subroutines, temp storage, etc.
      > RA Alarm time
      > RB Bang (pointer to table in ROM to make the sound effects)
      > RC Clock time (current time)
      > RD D and DF temporary storage (often useful)
      > RE
      > RF Frequency counter (counts 3600 60hz cycles for 1 minute)
      > --
      > Ingenuity gets you through times of no money better than money
      > will get you through times of no ingenuity. -- Terry Pratchett
      > --
      > Lee A. Hart http://www.sunrise-ev.com/LeesEVs leeahart@...
      >
    • Kevin
      ... I am loathe to label the positing of alternative ideas for consideration as a devolving debate. New ideas spark further and better ideas. ... Sometimes,
      Message 75 of 75 , Dec 7, 2012
      • 0 Attachment
        --- In cosmacelf@yahoogroups.com, Lee Hart <leeahart@...> wrote:
        >
        > As soon as people start talking about a "best" solution, it usually
        > devolves into arguments. People have different opinions about what
        > "best" means, and what is fashionable at the moment.

        I am loathe to label the positing of alternative ideas for consideration as a 'devolving' debate. New ideas spark further and better ideas.


        > > Sometimes a kludge can be more than just a "dirty workaround",
        > > however. This is one of those times.
        >
        > Calling something a kludge is like calling something ugly.

        Sometimes, but frequently not. Which is why I specifically wrote this instance is 'more than just a "dirty workaround"'.

        Without entering a debate on the definition of 'kludge' (your views may vary), I point to Webster: "a system and especially a computer system made up of poorly matched components"

        As the 1802 instruction set does not provide for math without RAM, I feel this definition is applicable. I do not feel 'poorly matched' implies 'ugly'. The lookup table is an innovative--in fact, MANDATED--solution, as is doing a 1-bit shift and compare. Both are kludges, in my view, necessitated by the 'poor match' of the 1802 and the RAM-less design.

        > Henry Ford would have called our modern car engines "kludges"...

        I would dissent with Mr. Ford on that. Modern auto components are designed to match and perform together as a system. Traditionally, kludge is applied when pieces of disparate systems are assembled to build some system not contemplated by the designer (i.e., a vacuum turned into a leaf blower).


        > [The lookup] table allows
        > *all* the 1802's M(R(X)) instructions to be used. It allows you to not
        > only compare two numbers, but also do math, logical, and OUT
        > instructions. The table is a better solution than individual workaround
        > routines for each of them.

        THAT I heartily agree with! If a design called for use of these multiple instructions I would definitely assert the lookup table is the *best* solution. If only one operation is necessary, not so much, as code space might be the more pressing requirement.

        * * *

        A "HYBRID" SOLUTION:

        I can also imagine a solution using a 16 byte lookup table to compare one nibble at a time. This would be a hybrid between a 256 byte lookup table and the 1-bit shift and compare solution.
      Your message has been successfully submitted and would be delivered to recipients shortly.