[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] more about f-romfs


Andreas Romeyke wrote:
> Hello,
> > >
> > > 1.starts at 0x0 (area 0 - /cs0) which is in fact mapped to a ROM as an internal
> > > or external space memory.
> >
> > sure but then, how do you define the ROM address ? Andreas says that this
> > range is defined by a set of registers which must be programmed ...
> > yet another chicken-and-egg problem :-)
> Where is the problem? On 68302 pE. you have the CS0, is this line active,
> the external/internal controller switch to a ROM, With register BR0 and
> OR0 which corresponends with CS0, you define the adress-lines, which are
> represent the external ROM-start and Size.
> With BR1 and OR1 you set and masks the range of a external RAM via CS1,
> ditto BR2 and OR2 the range of external Ports via CS2, the BR3 and OR3 the
> range of internal RAM via CS3 or whatever ou want.
> Remember, on 68302 you have the CS0-3-lines, the adress-lines, which are
> programmable via BR0-3 and OR0-3...

Now it seems clear :
the CPU starts with CS0 (configured as base=0 and mask=-1) and executes
code which modifies this default setting.

> In my opinion we should go the sam way, because it is easy a) to debug,
> b) easy to configure c) easy to implement...
> Where is the problem?

using a fixed, limited set of CS is a potential risk of later
hacks to circumvent this limitation (for example, extending the
number of interrupts of a 68000 is possible but not always clean
and always application dependent).
Furthermore, F-CPU doesn't use a CPU-centric point of view
like in a microcontroller environment. There is a direct
SDRAM interface with a configurable base address but otherwise,
there is no direct connection to the I/O or the booting ROM,
it goes through a generic I/O interface (VCI/AMBA/Wishbone...).

good evening,

> Bye Art1
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/