BaS gcc Coding

From Atari Wiki
Revision as of 23:23, 11 April 2013 by Admin (talk | contribs) (Created page with "This text is written by Markus ([http://www.atari-forum.com/memberlist.php?mode=viewprofile&u=21488 mfro]) ==Bas_gcc. What is it?== That's probably best answered if we first ask...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This text is written by Markus (mfro)

Bas_gcc. What is it?

That's probably best answered if we first ask another question: what is the Firebee? Besides targeting to appear as a Falcon-compatible Atari to Atari programs, it's basically "nailed together" from several components otherwise completely foreign to the Atari world:

  • a Coldfire microcontroller (MCF5475). Compatible (code-wise, at least in large parts) to the 68k processors built into the Ataris (with some serious exceptions we need to work around). But not only a processor. Besides CPU, FPU, MMU and caches, a coldfire microcontroller includes a lot of components an Atari enthusiast would rather expect separately on a PCB than included in the processor die:
    • 32KB internal SRAM
    • EMAC - enhanced multiply accumulator which is basically a very fast integer or fixed point multiply unit - comparable to a DSP
    • PCI controller
    • timer and interrupt controller and a programmable serial controller
    • an FEC (the vital part of an ethernet controller)
    • a memory controller providing SDRAM access capabilities
  • a freely configurable FPGA that can be configured to mimic most of the chips in a genuine Atari or at least reroute and translate TOS hardware request to the "real" hardware
  • a PIC microcontroller (used to hold NVRAM content when powered off, controlling switching the Bee off and on). Brings its own code with it.
  • USB controller connected to the PCI bus
  • lots of RAM
  • even more RAM (this time for the video subsystem)
  • ROM (as flash chip)


It's pretty obvious that you can't just put TOS on such a machine and expect it to work out of the box. It can only initialize and control peripherials that were known when it was coded. Most of the above peripherials weren't even invented when it was. On the other hand, there are several components missing that TOS expects and requires to run (blitter, MFP, ACIA, DSP, ...).


That's were BaS_gcc steps in. Besides initializing all the components unknown to TOS to a known state, it programmatically "glues" them together, prepares and provides an execution environment (actually, two, since there are two operating systems to target at) where the target OS can run. Frankly, most of the glue is provided by the FPGA, but even that must be initialized.


When I joined the Firebee project, the BaS was a piece of software coded with the commercial Metrowerks CodeWarrior IDE (mostly in Coldfire assembler). Besides Fredi Aschwanden (who was the original coder), nobody else really understood its inner workings. Since I wanted to learn about the Firebee internals, but didn't want to invest in a commercial compiler/assembler to code open source software, I decided to rewrite the BaS (mostly in C) with the free gcc toolchain. BaS_gcc is mostly finished (with much help from Vincent Riviere) and currently capable to completely replace the original BaS without any lack of functionality.


Certainly, there are lots of ideas to extend its capabilities, one of them providing USB keyboard support for EmuTOS.