Personal 040 Development Software by Greg Tibbs 1 November 1991 This archive contains four programs and their source code to do various things with a 68040 equipped machine. These programs are called FastROM040, MMU040, and ROMSPLIT1 and ROMSPLIT2. All the programs are compiled in SAS C or A68K assembler. They are all CLI-style programs. FASTROM040 FastROM040 remaps the Kickstart ROM to 32 bit Fast Memory. The memory management address translation tables are set to support the Progressive Peripherals & Software 040 card for the A3000. The MMU setup supports all internal A3000 motherboard RAM, ZorroII space, Local Bus RAM, and partial ZorroIII space. Approximately 25 percent of the 4 Gig address area is declared invalid and will cause some form of address exception if a spurious write or read is made to/from these areas. The only option to FASTROM040 is CACHEZ2. If all you have in ZorroII space is RAM, you can invoke the CACHEZ2 option. Most 68040 owners will have a hard disk controller and as such should NOT invoke this option. A future revision of this program will examine the expansion card lists and turn caching on only if it is public memory. Other 68040 accelerators, including those for A2000s whose on-board RAM lives in a compatible area should work (If it doesn't lock up, it worked!). All areas except the lowest 16MB area that are not invalid are made Copyback Cachable. Other utilities, such as CPU, may or may not interfere with the FASTROM040 remap and should be carefully tested for compatibility. Progressive's CPU040 appears safe and can be used to turn the data and instruction caches on and off. It's copyback enable button however only affects addresses reserved for ZorroIII address space and turning copyback mode back on restores everything properly. ZorroIII I/O cards, should there be any, will probably not work without re-writing this program due to caching enabled in the ZorroIII autoconfig area. A future version of this program with much larger address translation table requirements may fully support the ZorroIII area. The 040 has a simple three level tree structure. To keep things simple, I pruned the initial table down to one branch which represents the lowest 32 Mb, which includes the A2000 area. All other branches of the root table are declared invalid. The tranparent translation registers (mTTx) will allow reclaiming most RAM without the need for massive tables. The one valid entry in the first level (root) table points to another table of 128 pointers which each in turn point to tables of page descriptors. Each second level entry represents 256K. Unfortunately the 68040 does not have early termination, but only has invalid termination. Since I only care about the lowest 16MB, I declare the upper 64 pointers invalid. Each of the remaining 64 second level pointers point to individual 32 entry page description tables for a total of 2048 page descriptors. In the program this took 8K (4 bytes per entry); I jammed all the page desription tables together in one memory area so they could be set up with a minimum of code. Each page descriptor represents 8K of physical address space. The last 64 page descriptors in the page descriptor table relocate the Kickstart ROM. Personally I am quite disappointed with the 040 MMU. It is of entirely different design than the 68030 MMU or the 68851 PMMU. The assembly listings had to have all the 040 opcodes hand assembled. First, there isn't early termination of table searches. This means that every time the 040 tries to address an area it does not have in its address translation cache, it has to abort the current bus cycle, perform three reads from the tables to get the proper translation and then restart the bus cycle with the translation. Early termination could have allowed most areas to be read within one read access instead of three. The second area that is disappointing with the 040 MMU is that table sizes are fixed to 4K or 8K per page descriptor. You could go up to 32K per entry with the 68030, meaning smaller tables and faster loading of the ATC. Finally the biggest problem is that there is no way to separate Instruction space from Data space. There were bits that could be set in the 030 and 851 tables that allowed separate tables to be used to separately control the data versus the instruction caches on a page by page boundary. Only by cleverly programming the transparent translation registers can you obtain a separation of cache function over the same physical area. Progessive's initial setup for the 040MMU uses the two Data Tranparent Translation Registers and one of the two Instruction Transparent Translation registers. This setup enables the instruction cache for the entire 68040 address space and copyback cache mode for all but the lowest 16Mb of the 040 address space for the data cache. The lowest 16MB is nondatacachable serialized because of the I/O areas, custom chip registers, and chip ram. This setup is the fastest to all areas except it doesn't allow for relocating the ROMs. When both the translation table and transparent translation registers are enabled, the 040 only performs a table search if it is not first found by the translation registers. The transparent translation registers may overlap, in which case the lower register overrides the upper. The Translation registers are named ITT0, ITT1, DTT0, DTT1. I needed four of each type of register (data and instruction) to make a perfect map, but alas, there are only two of each type. MMU040 MMU040 prints out most of the 040 registers relating to the MMU. The outputs are in Hex and you need the Motorola MC68040 User's Manual to interpret them. I develped this utility to help debug FastROM040. Requires AmigaDos 2.04 because I rely on the exec falg to indicate the 040. ROMSPLIT & ROMSPLIT1 ROMSplit and ROMSplit1 take the Kickstart file located in your devs: directory and creates two files in RAM: called KickRom0 and KickRom1 which are binary equivalent to what you need to make EPROMs that are required by the A3000 68040 accelerator manufacturers. ROMSplit stores the data in Motorola byte ordering and ROMSplit1 stores the data in Intel byte ordering. I have found the BP Microsystems EP-1140 EPROM programmer will read the files generated by ROMSPLIT1. Additional details on the procedures to make 2.04 or later ROMs are in the file HOW2MAKEROMS.DOC. ETC. Some of the code contained in these programs was taken from SetCPU V1.4 by Dave Haynie which was released into the public domain. In similar spirit, this 040 specific code is also released into the Public domain with no restrictions whatsoever. Use these programs and this code at your own risk. I accept no responsibilites or liabilities for its behavior in any way. However, if this program works (or doesn't work) on your 040 machine, drop me a line telling me your results. Good Luck! Greg Tibbs CIS 73767,456 bix gbtibbs