added panic screen, added versioning mechanism proposal

2019-10-13 11:29:02 +02:00
1 parent 890558213a
commit 5a231c1847
@@ -0,0 +1,6 @@
+// Compute's Mapping the 64, p89
+// 8 character name
+// MEGABAS2 = "MEGA BASIC 2"
+
+	.byte $4D,$45,$47,$41,$42,$41,$53,$32
+
@@ -0,0 +1,9 @@
+All the BASIC routines, for which there are vectors in $0300-$030B, have to be available at their original addresses.
+
+Reason: some autostart software (https://codebase64.org/doku.php?id=base:autostarting_disk_files) override these vectors, so that some point
+to new locations (usually Kernal related), while others points the original BASIC routines. Different techniques modify different vectors
+(while resetting others to original C64 locations), some don't change the vectors at all, but might still put the original
+C64 BASIC addresses there.
+
+For various cartridges this just means disabling their extensions (like new commands); for us that would mean improperly functionning BASIC.
+
@@ -0,0 +1,2 @@
+
+Special case - we need a constant memory location where we can put an ID and a revision string. According to Compute's Mapping the Commodore 64 (page 117) this area is unused - so a perfect place.
@@ -0,0 +1,25 @@
+
+//
+// !!! PROPOSAL ONLY !!! PROPOSAL ONLY !!! NOT FOR USING EXTERNALLY YET !!!
+//
+//
+// Do not change! Locations of the following data should be constant - now and forever!
+//
+// If you want to integrate Open ROMs support in your emulator, FPGA ccomputer, etc. - this
+// is the official way to recognize the ROM and it's revision.
+//
+
+
+rom_revision_basic:
+
+	// $BF52
+
+	.text "OR"                // project signature, after "Open ROMs"
+	.byte CONFIG_ID           // config file ID, might change between revisions
+
+rom_revision_basic_string:
+
+	.text "(DEVEL SNAPSHOT)"  // actual ROM revision string; up to 16 characters
+	.byte $00                 // marks the end of string
+
+__rom_revision_basic_end:
@@ -0,0 +1,2 @@
+
+Special case - we need a constant memory location where we can put an ID and a revision string. According to Compute's Mapping the Commodore 64 (page 213) this area is unused - so a perfect place.
@@ -0,0 +1,39 @@
+
+//
+// !!! PROPOSAL ONLY !!! PROPOSAL ONLY !!! NOT FOR USING EXTERNALLY YET !!!
+//
+//
+// Do not change! Locations of the following data should be constant - now and forever!
+//
+// If you want to integrate Open ROMs support in your emulator, FPGA ccomputer, etc. - this
+// is the official way to recognize the ROM and it's revision.
+//
+
+
+	// $E4B7
+
+	// This vector is to be used by non-Kernal ROMs, if they want to
+	// complain about incompatible ROM releases - don't use it directly,
+	// use a 'panic' pseudocommand with error code (will be passed using .A)
+	// #P_ERR_ROM_MISMATCH - it should remain stable even between releases
+
+#if CONFIG_PANIC_SCREEN
+	.word panic
+#else
+	.word hw_entry_reset
+#endif
+
+
+rom_revision_kernal:
+
+	// $E4B9
+
+	.text "OR"                // project signature, after "Open ROMs"
+	.byte CONFIG_ID           // config file ID, might change between revisions
+
+rom_revision_kernal_string:
+
+	.text "(DEVEL SNAPSHOT)"  // actual ROM revision string; up to 16 characters
+	.byte $00                 // marks the end of string
+
+__rom_revision_kernal_end:
				`@@ -0,0 +1,2 @@`

				`Special case - we need a constant memory location where we can put an ID and a revision string. According to Compute's Mapping the Commodore 64 (page 117) this area is unused - so a perfect place.`