small LOAD cleanup

c64/kernal/iostack/f49e.interop

@@ -0,0 +1,2 @@
+This is a well-known address of a heavily used Kernal routine, it has to be the same so our ROM is compatible.
+

c64/kernal/iostack/f49e.load_int.s

@@ -0,0 +1,12 @@
+
+//
+// Note: Although the vector at $330 points to $F4A5, the Kernal jump table points to $F49E
+// (see also Mapping the C64, page 76). By experimenting I have discovered that $F49E performs
+// indirect jump via ($0330) vector, after setting MEMUSS.
+//
+
+LOAD_INT:
+
+	sty MEMUSS+1
+	stx MEMUSS+0
+    jmp (ILOAD)

c64/kernal/iostack/f4a5.interop

@@ -0,0 +1,8 @@
+All the Kernal routines, for which there are vectors in $0314-$0333, 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 (custom IRQ routine, custom STOP routine, etc.), while others points the original Kernal 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 Kernal addresses there (for example, if the file overrides keyboard input buffer and screeen memory).
+
+For various cartridges (like IDE64) this just means disabling their extensions; for us that would mean improperly functionning Kernal.

c64/kernal/iostack/f4a5.load.s

@@ -0,0 +1,54 @@
+//
+// Official Kernal routine, described in:
+//
+// - [RG64] C64 Programmer's Reference Guide   - page 286
+// - [CM64] Compute's Mapping the Commodore 64 - page 231
+// - IEC reference at http://www.zimmers.net/anonftp/pub/cbm/programming/serial-bus.pdf
+//
+// CPU registers that has to be preserved (see [RG64]): none
+//
+
+
+	// Expects that SETLFS and SETNAM are called before hand.
+	// $YYXX = load address.
+	// (ignored if SETLFS channel = 1, i.e., like ,8,1)
+	// If A=1 then VERIFY instead of LOAD.
+	// On exit, $YYXX is the highest address into which data
+	// will have been placed.
+
+	// XXX add VERIFY support
+
+LOAD:
+
+	// Are we loading or verifying?
+	sta VERCKK
+
+	// Store start address of LOAD
+	lda MEMUSS+0
+	sta STAL+0
+	lda MEMUSS+1
+	sty STAL+1
+
+	// Reset status
+	jsr kernalstatus_reset
+
+#if CONFIG_MEMORY_MODEL_60K
+	// We need our helpers to get to filenames under ROMs or IO area
+	jsr install_ram_routines
+#endif
+
+	// Check whether we support the requested device
+	lda FA
+
+	// Try IEC - legal device numbers for LOAD are 8-30
+	// Device numbers above 30 can not be used as IEC (see https://www.pagetable.com/?p=1031),
+	// as the protocol combines device number with command code in one byte, above 30 it is
+	// no longer possible. Original ROMs show ILLEGAL DEVICE NUMBER error only for devices
+	// 0-3; our implementation is more strict here
+
+	cmp #$1F
+	bcs !+              // >= 31  
+	cmp #$08
+	bcs_far load_iec    // >= 8
+!:
+	jmp lvs_illegal_device_number

c64/kernal/iostack/f5dd.interop

@@ -0,0 +1,2 @@
+This is a well-known address of a heavily used Kernal routine, it has to be the same so our ROM is compatible.
+

c64/kernal/iostack/f5dd.save_int.s

@@ -0,0 +1,12 @@
+
+//
+// XXX Note: something unusual was done with LOAD routine - although the vector at $330 points to $F4A5,
+//           the Kernal jump table points to $F49E (see also Mapping the C64, page 76). By experimenting
+//           I have already discovered that $F4A5 performs indirect jump via ($0330) vector, but it must
+//           be doing a little bit more - not sure yet, what. Something similar is done with SAVE.
+//
+//           This has to be clarified.
+//
+
+SAVE_INT:
+    jmp (ISAVE)

c64/kernal/iostack/f5ed.interop

@@ -0,0 +1,8 @@
+All the Kernal routines, for which there are vectors in $0314-$0333, 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 (custom IRQ routine, custom STOP routine, etc.), while others points the original Kernal 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 Kernal addresses there (for example, if the file overrides keyboard input buffer and screeen memory).
+
+For various cartridges (like IDE64) this just means disabling their extensions; for us that would mean improperly functionning Kernal.

c64/kernal/iostack/f5ed.save.s

@@ -0,0 +1,13 @@
+
+//
+// Official Kernal routine, described in:
+//
+// - [RG64] C64 Programmer's Reference Guide   - page 293/294
+// - [CM64] Compute's Mapping the Commodore 64 - page 231/232
+// - IEC reference at http://www.zimmers.net/anonftp/pub/cbm/programming/serial-bus.pdf
+//
+// CPU registers that has to be preserved (see [RG64]): none
+//
+
+SAVE:
+	STUB_IMPLEMENTATION()

c64/kernal/iostack/f6ed.interop

@@ -0,0 +1,8 @@
+All the Kernal routines, for which there are vectors in $0314-$0333, 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 (custom IRQ routine, custom STOP routine, etc.), while others points the original Kernal 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 Kernal addresses there (for example, if the file overrides keyboard input buffer and screeen memory).
+
+For various cartridges (like IDE64) this just means disabling their extensions; for us that would mean improperly functionning Kernal.