Home
The primary goals of the project are to:
- Be a plug-in board requiring no soldering on the Falcon;
- Increase available RAM beyond the 14MB the stock Falcon can be expanded to;
- Be low cost;
- Provide some acceleration;
- Allow the PSU to remain in the case;
- Be open source.
I still enjoy using my Atari Falcon but am frequently frustrated about the limitations of the 14MB maximum that a stock Falcon can address. I often use MiNT running multiple shells and unfortunately, with the absence of virtual memory in MiNT, RAM overhead is tight.
I tried last year running Debian Linux on my Falcon, which is technically capable with even support for the EtherNEC-style network adapter I have, but the kernel wouldn't even fit in memory. The latest I could get to boot was a kernel from 2000 which was too old to support the EtherNEC.
The Atari TT shares the same processor as the Falcon, but could support 10MB 'ST-RAM' (the same as the Falcon's) but an additional 256MB of 'TT-RAM'.
The Amiga 4000, using a slightly inferior CPU could be upgraded to over 512MB (and later over 1GB).
What's going on and what can I do about it?
The Falcon contains a full Motorola MC68030 CPU. This is a 32 bit processor with a programmable MMU. It has 32 address lines to allow it to address each individual byte of up to 4GB of memory. It has 32 data lines to allow it to transfer four bytes (a long-word) with every clock cycle. It has versions available that can run at up to 50MHz and is able to perform one memory transfer for every three clock cycles, allowing it to transfer around 60 MB per second. This would be quite impressive in a 1992 machine.
Unfortunately, the Falcon can only work with around 10MB of data per second, and in reality far less, because of physical limitations in the design. Atari saved the full 32 bit computer implementation for the TT. The Falcon is, physically, limited.
Firstly the Falcon's CPU is only 16MHz. The processor onboard is capable of 25MHz. The TT's ran at 32.
Secondly the Falcon's data bus is only 16 lines wide. Half the data bus is simply not connected meaning memory transfer into and out of the CPU take twice as many cycles as they need to. The CPU is already half the speed of the TT so all memory transfers take 4 times as long.
Thirdly the Falcon's address bus is only 24 lines wide. The 'top' 8 lines of the address bus are again, simply not connected. The theoretical maximum memory range the Falcon's CPU can address is 2^24 bytes: 16MB.
Everything else on the Falcon's board is memory mapped -- that is it's assigned an address in that range for the purposes of the CPU communicating with it. We can't therefore have 16MB RAM (although virtually all 14MB boards really are 16MB boards). 512KB is used by the ROM, 128KB is allocated for the cartridge port, 576KB is set aside for the expansion port and the top block of memory is used for that device IO.
We could, by putting some logic onto the Falcon's internal expansion connector use the 576KB allocated to the expansion slot, plus even dig up a few blocks of address space sat idle between other blocks, but the most we could ever hope to expand the Falcon's memory by would be a measly 1.3MB.
We need to open up those address lines.
- We could solder eight wires onto the unconnected address line pins then, in combination with the expansion header, provide a memory pack?
The Falcon's CPU is a ceramic surface-mounted QFP (quad flat package) with forty pins per inch pitch. Each wire would have to around half a millimetre wide and that would be a very hard soldering job, prone to failure, shorting the pins or worse. Falcons are expensive these days. This doesn't seem a great option, especially as this would only address the memory issue.
- We could fabricate some kind of plug to go over the top of the CPU -- like the Vampire cards in the Amiga 600 do. This would expose both the address and data pins allowing both more and faster memory.
This is a nicer idea, but the 68000 PLCC chip in the A600 has half the pin pitch and there exist sockets to fit these already. Furthermore the CPU on the Falcon is nestled in between the two expansion headers, the COMBEL chip and a series of resistor packs making access and board design difficult. Alignment would be critical and at that pin pitch, I can only see expensive accidents.
- We're going to have to offload the processor.
This is the starting point. The onboard processor is a dead-end. It's speed restricted and it's physically unconnected. Let's turn it off and use an external CPU on our board.
If you're going to build a board with an external CPU and big wodge of extra memory (we call it Alt-RAM), that wheel has already been invented. The CT60 does all of that, plus it replaces the 68030 with a really fast 68060. Just buy one of them?
The CT60 is clearly the gold standard for Falcon expansion boards. It's the Falcon expansion board Harrods would sell. But the CT60 has two and half things going against it.
- It's expensive. The board itself is expensive, the chips to put on it are expensive. It is lovely, though.
- It's big. The board requires the space the PSU occupies, meaning the PSU has to move.
- It's a 68060. It's a Falcon, but it's not a Falcon030. I really quite like the 030 part.
Please do buy a CT60! I'd buy one if I could justify it to the wife.
We build a Falcon-expansion-bus pluggable card that carries its own 68030.
It takes control of the machine on start up, runs normal TOS4.04 or EmuTOS and should able to do all the things the stock Falcon can do.
This gives us all the advantages of the full 32 bit data and address busses and allows us to control its speed. We can run the processor at a multiple of the on-board clock speed for quicker processing and we can allow access to extra Alt-RAM.
It does mean we will have to negotiate with the on-board CPU to take over the Falcon and we'll have to learn how to drive the Falcon from the very strange expansion connector it provides.
Copyright 2020 D Henderson.