Re: BeamRacer is coming… request for comments

From: Rainer Buchty <rainer_at_buchty.net>
Date: Tue, 2 Jun 2020 15:27:46 +0200 (CEST)
Message-ID: <alpine.DEB.2.22.394.2006021432150.2804_at_office>
On Tue, 2 Jun 2020, silverdr_at_wfmh.org.pl wrote:

> Thank you. We're considering the options we have at hand and the most 
> probable one is that we shall move this register to $3e as simple 
> shifting of the range by one or two is not feasible. This means we'll 
> have to drop the plans we had for $3e/$3f but hey, you can't have 
> everything (where would you put it?), can you? ;-)

If you want to free the $d03x range, maybe an approach similar to the 
mode registers of the 2681 DUART is suitable.

Right now, you spell out DLIST and ADR0/1 as 16-bit registers, directly 
accessible as LSB/MSB. To my understanding of the register description 
(which might be wrong, of course) those addresses however only become 
valid with subsequent strobing accesses, either to DLSTROBE (for DLIST, 
that also can be triggered by the next occuring frame) or to PORTx (for 
ADR0/1).

So what could work is making DLIST and ADR0/1 just 8-bit register 
windows that automatically advance, i.e. the first write to such an 
address register sets the LSB, the second one the MSB; similarly, if you 
want to read the addresses, i.e. first read delivers the LSB, second one 
the MSB.

Forceful reset of this sequence (e.g. going back from LSB to LSB instead 
of advancing to MSB) could be applied to reading DLSTROBE or PORTx (or 
using that currently unused bit 6 in the control register).

Alternatively, you could go for a uniform ADRL/H register set that gets 
interpreted as ADR0 or ADR1 depending on whether STEP/PORT0 or 1 are 
accessed afterwards. Probably even less hassle than the above scenario 
which would introduce a different programming logic, but would add 16 
flipflops (for buffering ADRL/H prior to storing it in ADR0 or ADR1) to 
the design instead of just 3 (for the LSB/MSB pointers). Not sure how 
maxed out the CPLD already is.

Rainer
Received on 2020-06-02 16:00:03

Archive generated by hypermail 2.3.0.