Firebee/BaS_gcc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Markus
2020-06-13 11:15:11 +02:00
committed by GitHub
parent 5ce03cdf0f
commit ac008082a3
1 changed files with 6 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
README.md
View File

@@ -44,7 +44,12 @@ From a pure user's perspective (mainly using FireTOS, probably): very little (yo
- BaS_gcc provides "true" ST RAM (as far as possible using the ColdFire's MMU): - BaS_gcc provides "true" ST RAM (as far as possible using the ColdFire's MMU):
The FireBee has two (dynamic) RAM areas: 512 MB of "ColdFire" RAM directly connected to the ColdFire chip and another 128M of DDR RAM attached to the FPGA. With original BaS, the ColdfireRAM is the only RAM you have direct access to and it resides linearily from address 0 to mem end. Original BaS only maps in (one single) window into the FPGA RAM where TOS expects to find its video RAM. The FireBee has two (dynamic) RAM areas: 512 MB of "ColdFire" RAM directly connected to the ColdFire chip and another 128M of DDR RAM attached to the FPGA. With original BaS, the ColdfireRAM is the only RAM you have direct access to and it resides linearily from address 0 to mem end. Original BaS only maps in (one single) window into the FPGA RAM where TOS expects to find its video RAM.
BaS_gcc uses (again, using the ColdFire MMU) full 14 MB of the FPGA RAM as ST RAM and maps the Coldfire RAM as alternate (fast) RAM. This has benefits as well as drawbacks. First, the drawback: it's slower. The video circuit (an extended Falcon Videl, basically) that resides in the FPGA requires to constantly read the video (FPGA) memory to feed video data to the monitor. In the FPGA logic, this feed has priority and only leaves limited RAM bandwidth to the CPU. The more screen memory the FPGA needs to feed (higher video resolutions and bit depth), the slower the FPGA RAM will become. The second reason why it is slower is that access to ST RAM needs to go through the (32 MHz) FlexBus. But as Atari users, we are used to that (it's very similar on a TT, for example).
BaS_gcc uses (again, using the ColdFire MMU) full 14 MB of the FPGA RAM as ST RAM and maps the Coldfire RAM as alternate (fast) RAM.
This has benefits as well as drawbacks. First, the drawback: it's slower. The video circuit (an extended Falcon Videl, basically) that resides in the FPGA requires to constantly read the video (FPGA) memory to feed video data to the monitor. In the FPGA logic, this feed has priority and only leaves limited RAM bandwidth to the CPU. The more screen memory the FPGA needs to feed (higher video resolutions and bit depth), the slower the FPGA RAM will become.
The second reason why it is slower is that access to ST RAM needs to go through the (32 MHz) FlexBus. But as Atari users, we are used to that (it's very similar on a TT or on a Falcon, where RAM bandwidth is also dependend on video resolution).
The benefit: it is more compatible. If you have a TOS program that switches two screen buffers back and forth, for example, BaS has to map in and out FPGA memory pages using the MMU and needs to copy screen contents from Coldfire memory to FPGA memory and back behind the scenes (because your innocent TOS program has prepared the second screen in what it thought was ST RAM which in fact wasn't). While this works (somehow) it will result in strange delays during video address switching. BaS_gcc just does the same as an original Falcon and since all ST RAM is FPGA RAM, there is nothing to copy around. The benefit: it is more compatible. If you have a TOS program that switches two screen buffers back and forth, for example, BaS has to map in and out FPGA memory pages using the MMU and needs to copy screen contents from Coldfire memory to FPGA memory and back behind the scenes (because your innocent TOS program has prepared the second screen in what it thought was ST RAM which in fact wasn't). While this works (somehow) it will result in strange delays during video address switching. BaS_gcc just does the same as an original Falcon and since all ST RAM is FPGA RAM, there is nothing to copy around.
- BaS_gcc enables (fast) networking using EmuTOS + FreeMiNT because it provides the ColdFire MDMA (multi channel DMA) and a suitable FEC driver. This way, you have a fully native OpenSource ColdFire environment without any slowdown through m68k emulation. Of course "legacy" (TOS) programs have to be compiled for this environment or can only used with m68k emulation (https://github.com/vinriviere/68kemu , for example), but if you intend to use the FireBee for new development, this is the fastest setup you can get with full access for all sources compilable with open source toolchains. A true OpenSorce environment. - BaS_gcc enables (fast) networking using EmuTOS + FreeMiNT because it provides the ColdFire MDMA (multi channel DMA) and a suitable FEC driver. This way, you have a fully native OpenSource ColdFire environment without any slowdown through m68k emulation. Of course "legacy" (TOS) programs have to be compiled for this environment or can only used with m68k emulation (https://github.com/vinriviere/68kemu , for example), but if you intend to use the FireBee for new development, this is the fastest setup you can get with full access for all sources compilable with open source toolchains. A true OpenSorce environment.