Re: Wireless - switchless kernal mod

On Thu, Mar 29, 2018 at 7:12 PM, Mia Magnusson <mia@plea.se> wrote:
>> - I don't want to (and I can't actually with that chosen micro) chase
>> the individual cycles of rom accesses.
>
> Then you need to gate/latch the adress bus pin with CE/OE on the ROM
> socket. Otherwise you will see "noise" from other bus activity.

Yes I'm already doing this.  I'll only sample when /OE is low. My
currently chosen line is A13 on the kernal+basic rom which is actually
a generated signal to select either basic or kernal.

>
>> - I'll not drive the databus
>> - I'll only listen to 1 address bit
>> - That address will be modulated so that receiver will understand
>> sender is active and it's just not out of regular use of the computer
>> (1st problem : pilot sequence)
>> - Pilot sequence will be iterated until receiver is in sync with the
>> sender (2nd problem : syncing)
>>
>> Much like the pilot sequence of loading from tape.
>
> You could trigger it by checking if rom accesses are data read or code
> execution. When executing code the accesses comes far more often while
> data accesses will have longer time between them. The exception is that
> even when executing code there will be a pause when there is a "bad
> line".

With this choice modulation of that A13 signal to the rom is the
easiest part actually. But as you noted the /OE itself could be used
for the modulation part.


>
> Maybe you could make the 6510 CPU run patched code in some place of the
> ROM area, but read accesses that's obviously data read instead of code
> execution could still read back the expected contents.

My initial aim is to run this code on ram, getting it loaded via a
special kernal program or externally is a choice. Currently I'll
experiment with loading that program externally.

>
> With a circuit that replaces a combined kernal+basic rom (later C64,
> and afaik all C128 in C64 mode) you could perhaps use the "MICROSOFT"
> obfuscated string in basic rom near the arithmetic table?

You mean accessing that data in a way that creates a pattern for the
attiny to understand? Sorry I didn't understand this.

>
> Or maybe that won't work. It takes atleast two accesses to really
> detect code execution (and atleast three if a bad line happens between
> the first and the second) and the standard content of the rom must
> atleast be somehting that won't hang the CPU (or jump too far outside
> the ROM) when executed.

Disabling the screen solves the problem of badlines but in my case I'm
not trying to achieve a high communication throughput and VIC stealing
certain cycles should not prevent me sending say a few bytes in 1-2
seconds.

>
> Any other area that's purely data in ROM would also work, but as you
> want to be able to switch between all kinds of KERNAL ROMs it must be
> something in the BASIC rom, otherwise it might only work on some ROMs.
>
> This would be a nice solution since you could jump to the rom selector
> firmware simply with a SYS statement. No need to load any special
> software or similar.

There was one suggestion of using a separate slot for the kernal
selector for what you are suggesting. That could be done but it might
interfere with certain cartridges which expects certain behaviour on
start of the c64.

In my case it will be a process like this,

1. If there is no communication no kernal switch will occur.
2. If special program is loaded and attiny is told to switch kernals
attiny will switch to it. Since switcher code would be on ram it will
reset the c64 and the actual switch will take place.
Bonus : Switcher program could have checksums of known kernals and
could scan each slot for these known kernals to enumerate and name
them.