06.02.2012 12:25
[#1]
4k intro startup code by Blueberry
Kolejna ciekawostka, dla wymarłych amigowych koderów i naszych teoretyków z forum :)
http://crinkler.net/BlueberryDemoStartup.lha
More oldskool 4k action!
I updated my compact demo startup code to be compatible with OCS Amigas. The exact compatibility/size tradeoff is controlled by an option in the code, with 3 possibilities:
- Mode 2: Only compatible with 68010+ and Kickstart 3.0+. Can run from any display mode. Supports non-zero vectorbase. This corresponds to the previous version.
- Mode 1: Compatible with all CPUs and Kickstarts. Slightly larger because the VBR code is guarded by a processor check and graphics.library is opened in the oldfashioned way (KS 3.0+ has a more compact way of doing this).
- Mode 0: Only compatible with 68000 and Kickstart 1.3 and must run from a PAL screen. This version omits lots of compatibility code and is thus significantly smaller.
Included is a cache flush macro, which behaves differently depending on the compatibility mode. In mode 0, it does nothing. In mode 1, it calls the CacheClearU function if the Kickstart version is 2.04 or higher. In mode 2, it simply calls the CacheClearU function. This makes it easy to create different versions of an intro with different compatibility characteristics (such as an OCS-only 4k version and a compatible larger-than-4k version).
The framework is designed to produce completely relocatable code, so that the MINI option of my cruncher can be used. To keep your code PC relative, use the SECTIONHACK feature and follow these rules:
- When referring to a label in the fast memory section, always use PC relative addressing (except for branches, which are implicitly PC relative). If the label is too far from the code for PC relative addressing, LEA a nearby label and then add the distance between the labels.
- When referring to a label in the chip memory section, read ChipPtr(pc) and then add the distance between ChipPtr and the desired label.
There are examples of these coding patterns in the supplied code.
The update also incorporates a few size optimizations, including the one suggested by sp_.
http://crinkler.net/BlueberryDemoStartup.lha
More oldskool 4k action!
I updated my compact demo startup code to be compatible with OCS Amigas. The exact compatibility/size tradeoff is controlled by an option in the code, with 3 possibilities:
- Mode 2: Only compatible with 68010+ and Kickstart 3.0+. Can run from any display mode. Supports non-zero vectorbase. This corresponds to the previous version.
- Mode 1: Compatible with all CPUs and Kickstarts. Slightly larger because the VBR code is guarded by a processor check and graphics.library is opened in the oldfashioned way (KS 3.0+ has a more compact way of doing this).
- Mode 0: Only compatible with 68000 and Kickstart 1.3 and must run from a PAL screen. This version omits lots of compatibility code and is thus significantly smaller.
Included is a cache flush macro, which behaves differently depending on the compatibility mode. In mode 0, it does nothing. In mode 1, it calls the CacheClearU function if the Kickstart version is 2.04 or higher. In mode 2, it simply calls the CacheClearU function. This makes it easy to create different versions of an intro with different compatibility characteristics (such as an OCS-only 4k version and a compatible larger-than-4k version).
The framework is designed to produce completely relocatable code, so that the MINI option of my cruncher can be used. To keep your code PC relative, use the SECTIONHACK feature and follow these rules:
- When referring to a label in the fast memory section, always use PC relative addressing (except for branches, which are implicitly PC relative). If the label is too far from the code for PC relative addressing, LEA a nearby label and then add the distance between the labels.
- When referring to a label in the chip memory section, read ChipPtr(pc) and then add the distance between ChipPtr and the desired label.
There are examples of these coding patterns in the supplied code.
The update also incorporates a few size optimizations, including the one suggested by sp_.
