Re: SPI on the User Port ... Mode Hang-Ups.

On Jan 29, 12:34 pm, Jim Brain <br...@xxxxxxxxxx> wrote:
BruceMcF wrote:
But if they have a serial cart, or a PC pretending to be a 1541, or an
Ethernet cart, or they have a cardreader on a PC/Linux box on the net
and use an MMC based sneakernet.

You should take my concerns with a grain of salt. My philosophy
revolves around making new peripherals "appear" like old supported ones
as a highest priority, to minimize at all costs the need to "patch" SW.

Jim

My priority here is allowing a new patch to have as broad a range of
utility as possible. e.g, if the only driver is for ACE, that's fine,
because with the speed of flash RAM access, loading programs from the
internal serial flash RAM in lieu of 1541 gives massively better
responsiveness.

That's why I am planning on hiding the rest of the wedge routine to
download the 4K master load menu utility into high RAM at the top of
the stack page. From there, it can easily load whatever program, and
by presumption any code loaded into the flash RAM will be hacked to
work with the SPI interface.

Indeed, AFAIK, I may be trashing all over the IEC in the middle of
this, so all daisychain serial devices may have to be closed to make
use of these. That's the main reason the SPI/RS232 bridge is the
second priority ... I want to get the UART as the second priority ...
to have some generic means of accessing a PC/Linux box, at high
efficiency, that has been previously pretending to be a 1541, once the
wedge for the SPI interface has been installed.

.