Re: A Christmas Clock
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.
--- In firstname.lastname@example.org, 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)
> 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@...
- --- In email@example.com, Lee Hart <leeahart@...> wrote:
>I am loathe to label the positing of alternative ideas for consideration as a 'devolving' debate. New ideas spark further and better ideas.
> 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.
> > Sometimes a kludge can be more than just a "dirty workaround",Sometimes, but frequently not. Which is why I specifically wrote this instance is 'more than just a "dirty workaround"'.
> > however. This is one of those times.
> Calling something a kludge is like calling something ugly.
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 allowsTHAT 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.
> *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.
* * *
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.