On 02/06/2020 15:27, Rainer Buchty wrote: > 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, No, not really, as my friend explained. We'd like to move the $30 one out for the reasons you guys pointed out > 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, Programming logic is still adaptable, that's not so much of an issue yet. But... > 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. ... it is maxed out. Moving the CTRL register up and dropping the last two seems like the most viable option for now, as it would release a few resources currently allocated to the undocumented $3e/$3f. Not much but things should fit this way. We'll also think through your suggestion. Sixteen bits is out of question but maybe we can come up with something less costly. Thank you very much!Received on 2020-06-02 17:00:03
Archive generated by hypermail 2.3.0.