Looking at the picture of the die, the trace definitely would have gone to the /IRQ polysilicon: The red line on the left is irq_internal (from the frame IRQ and DPCM IRQ); the purple X is where they excised this timer's ability to generate an IRQ. At the bottom left (where the red line ends) is where irq_internal and irq_external are combined.Memblers wrote:Can we be sure this for an IRQ instead of a much less interesting reset?
My best guess is that the 24 bits is because they thought people would use it to make an RTC, by setting it to 1789773 ( = 0x1B4F4D)
I think the bits are out of order, so I'm just going to arbitrarily reverse them. This is the opposite of the sim.
New insights: the bit written to $401F & $08 specifies whether the carry out from each bit in the counter is (Bit) or (Not bit), i.e. count up or count down. (via nodes 34 and 44)
the bits written to $401F & $11 control a 1-of-4 multiplexer (nodes 129, 134, 139, 140, 144) that appear to choose which clock source will be used. The clock sources seem to be a lot bit bizarre. though.
Writing to $401F with $40 high will cause an immediate reload. The value is gradually lost due to dynamic logic (really??)
$401F & $20 seems to hold whether there should be an automatic reload.
This seems to be a bug: the counter can't count when the value in it is nonzero: node 20 = AllBitsLow; inverted to make node 60 = AnyBitsHigh; node 60 pulls node 36 = CountEnabled low.
Code: Select all
$401F: [ELAC DxxC] |||| |||| |||+----+-- Clock enable source (??) ||| |++--- Something as-yet undetermined ||| +----- 1:count up; 0:count down ||+-------- 1:automatic reload when counter reaches 0 |+--------- 1:reload immediately +---------- 1:IRQ enabled (counts regardless)