Suggestion for unscramble_constant_data()

Juergen Buchmueller pullmoll at t-online.de
Fri Jun 15 13:34:09 PDT 2007


On Fri, 15 Jun 2007 21:44:26 +0200
Juergen Buchmueller <pullmoll at t-online.de> wrote:

Replyig to myself is lame, but I just now realized:

> All video updating depends on a single function, which is called by a timer
> at a rate that corresponds to 24 pixel clocks, i.e. 24*50ns.

If we can live with a small error, then if you'd call the
display_state_machine() on every 7th CPU cycle, you'd have 7*170 = 1190ns.

The correct value for 24 pixel clocks is 24/20.16Mhz = 1190.47ns, so
the error is really, really small.

It may be easier and faster to call the state machine from the CPU, than to
always re-insert a timer event into the chain. And it may even be desirable
to keep the events locked onto the CPU cycles to some degree. It doesn't
work for the unload_word(), because 794ns doesn't divide well into 170ns :-P


> /** @brief PROM a63 B6 HLCGATE signal, which enables counting the HLC */
> #define	A63_HLCGATE	0200
It is of course B7 HLCGATE, B6 was already used.

And I also had some leftover "dsp." in front of fifo_in and fifo_out in
the macros. This is because I used a "display_t dsp;" context instead of
separate globals, which for me makes it easier to reset the whole display at
init time without missing a variable.

Now I'm curious to see if you can use this info for Altogether.

I'm back to analyzing the disk sector timing. It seems I got the disk word
timing already worked out, and I'm eager to see the thing booting soon :)

Juergen


More information about the Altogether-devel mailing list