[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] FreeMiNT for ColdFire: Generic
m0n0 wrote:
Maybe I'm just to confused ;) And I don't want Vincent to repeat
everything he already told about it.
You really seem confused, and told some wrong things, so I will repeat
anyway.
Things are different between the CPU and the additional hardware.
First, the CPU. Let's take the example of the RTE instruction. It
behaves differently between 68000 and 68010+. It behaves in a third way
on ColdFire. So regarding to that RTE instruction, 68000, 68010+ and
ColdFire processors are mutually incompatible. So when you use an RTE
instruction, you have to know what is the actual CPU.
FireTOS is intended to emulate a 68060. So it can run (most) 68060
programs unchanged. This is the case of the current hybrid mintv4e.prg.
It really expects a 68060 RTE instruction. So, by design, FireTOS hides
the underlying ColdFire CPU, including CACR, MMU... but it certainly
does not hide the additional ColdFire and FireBee hardware: Ethernet
interface, serial ports, SD-Card...
EmuTOS for ColdFire does not emulate anything. So nothing is hidden,
user programs can fully access the ColdFire CPU, MMU... and additional
hardware. However, EmuTOS for ColdFire requires Atari compatible
hardware (that was the "contract" of the FireBee). To achieve that, the
FireBee's BaS add a very thin emulation layer. For example, any Atari
software would expect the VBL vector at $70. On the ColdFire CPU, and on
the FireBee as well, the real VBL vector is somewhere else. So the BaS
simply puts a jump at that real VBL vector and jumps to the $70 one.
This is very lightweight, and provide Atari hardware compatibility.
As a summary, if you are running under some CPU emulator, by design the
underlying CPU is not accessible. But this does not affect access to
additional hardware on the board.
Finally, mintv4e.prg will just have to ask a question:
Do I run on FireTOS with an emulated 68060 ?
- Yes, consider we have a 68060 RTE instruction.
- No, consider we have a ColdFire RTE instruction.
Things like this already exists in TOS and MiNT to support the various
680x0 processors.
dBUG has nothing to do with that, it is just Freescale's debugger
allowing developers to launch other things.
Both of them hide the real hardware and put the TOS into an Hardware
environment which looks like the one of the falcon
Nothing hides the real hardware (except the CPU in the case of FireTOS),
thanks to the FPGA the FireBee has *real* Falcon hardware, plus
additional hardware such as USB, AC'97 audio chip, etc.
If you want to access hardware - that's maybe possible. Vincent said:
"just do it as you would do it - it will work"
- I'm not sure what Vincent meant with that - because I would do it as
the Coldfire Manual tells me, but maybe he thought
I would do it as I would do it with my Falcon...
- When you want to access the CPU features, just refer to your CPU (or
emulated CPU) documentation.
- When you want to access some hardware other than the CPU (traditional
Falcon hardware, additional hardware inside the ColdFire
microcontroller, USB...) read the associated manual and just do what you
have to do.
- Maybe the FPGA/BaS remamps memory Registers to the addresses where TOS
expects the hardware - or does it mirror them?
The BaS initializes the MMU to map the I/O area to the standard Atari
places, such as 0x00ff0000 and 0xffff0000. But from a pure ColdFire OS
such as EmuTOS you can remap the MMU, if you like.
- More critical: when running freemint on top of BaS/dbug/Firetos (
whooo,... there is so much low level stuff loading before MiNT )
we don't have access to the Ethernet hardware...
This is another problem. When some TSR software (the BaS, FireTOS,
additional AUTO programs) uses some hardware, there must be some
handshaking to avoid conflicts. This has been the case for ages, for
example the floppy drive. The standard VBL routine access the floppy
drive to stop the motor, so when any low-level software wants to use the
floppy drive it has to set a special semaphore.
About Ethernet and FireTOS' LWIP layer, FireTOS should have an option to
totally disable it when some MiNT driver wants to drive the Ethernet
hardware.
I would just shutdown these LWIP tasks, but freemint kernel has no right
to do that and even if it would, it would need to know how to do that).
Ask Didier to put a function somewhere in FireTOS to turn LWIP off and
you are done.
FreeMiNT with EmuTOS ( totally native, no access restrictions, full
access to hardware - sounds good, 'eh? ;) -
but the EMUTOS code misses a lot which is expected to be there when
FreeMiNT boot's up.... , like MMU setup)
EmuTOS does not lack anything important, if I'm not wrong it has been
designed as a TOS replacement especially to boot FreeMiNT with the
emulators... EmuTOS+FreeMiNT works very well on ARAnyM, it will work as
well on the FireBee.
About the very special case of the MMU, it will be a lot more
complicated. First, the ColdFire MMU is different to everything else.
Then the BaS or FireTOS already use it, some protocol will have to be
established to allow FreeMiNT using it without breaking everything. But
the MMU is a very advanced topic, and not a priority.
Finally, to show things are not so complicated: XaAES quietly uses the
services provided by the kernel, it does not know anything about the
ColdFire particularities (assembler sources are just optimized) or the
FireBee, and it works flawlessy! That will be the same with all the XFS
when XHDI bugs will be fixed on FireTOS, etc.
--
Vincent Rivière