Wireless - switchless kernal mod

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Wireless - switchless kernal mod

nejat76
I can't reply (I tried to both through nabblers and by directly
replying) to the original thread since I registered after the last
mail sent to that thread.

Most of the stuff for the kernal mod targets old c64 boards so I
wanted to take on the 250469 boards on the newest c64 editions. In
these boards kernal + basic is a combined 16K rom.

With a bit of external logic I crammed 7 different kernals and 1 basic
rom into an 27c512 64kx8 bit rom.

https://www.youtube.com/watch?v=mWdeX7mWdNg

The plan is to switch the kernals with the attiny processor on the
attachment board.

The method I chose for doing this is like this,

A program on the c64 carefully modulates a chosen address bit so that
it's certain percentage 1 or 0s for a certain period. Thus it sends a
pilot signal repeatedly for the attiny side to sync and match both the
period and phase of these signal.

The program on the attiny side continously samples one of the address
lines and tries to sync to this pilot signal.

After syncing, which is assumed, c64 program sends the chosen eprom
bank for the selected kernal. Attiny receives this and switches the
kernal.

C64 program is the easiest to write probably. On the attiny side I
don't want to write time critical code. Of course both sides need to
do one unit of work at a roughly constant time. Currently I'm
simulating what I want to do with a multithreaded application on the
pc. One thread for the sending side and another one for the receiver.

Only 4 bits of information will be transferred actually so it doesn't
matter if both sides phase out after that transfer finishes.

The question is, is there any such previous work for an algorithm or
similar for such a syncing job?

Best regards,

Nejat

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

silverdr@wfmh.org.pl

> On 2018-03-28, at 12:18, Nejat Dilek <[hidden email]> wrote:
>
> I can't reply (I tried to both through nabblers and by directly
> replying) to the original thread since I registered after the last
> mail sent to that thread.
>
> Most of the stuff for the kernal mod targets old c64 boards so I
> wanted to take on the 250469 boards on the newest c64 editions. In
> these boards kernal + basic is a combined 16K rom.

[...]

> Only 4 bits of information will be transferred actually so it doesn't
> matter if both sides phase out after that transfer finishes.
>
> The question is, is there any such previous work for an algorithm or
> similar for such a syncing job?

I have one ROMs replacement adapter targeting the narrow boards, devised together with Gerrit some time ago. But it's not yet "switchless" yet. The small project I took on with KiCAD recently is exactly about turning it "switchless", besides other changes. I designed the board but haven't written the software yet. Thus, the answer is "no, I haven't heard of something similar but I am highly interested, as this (or something similar) is what I shall have to invent as well. Of course we could go for the typical approach of using RESTORE key as a switch but it's not really "switchless", is it? ;-)

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

Jim Brain
In reply to this post by nejat76
On 3/28/2018 5:18 AM, Nejat Dilek wrote:
> The question is, is there any such previous work for an algorithm or
> similar for such a syncing job?
Not sure how specific your question is, but there is a project on
Forum64 (I think) that uses a uC to select and load into a FLASH ROM
lots of KERNALs  I can't remember the name offhand (MegaROM, UltraROM,
something like that).  I would assume it uses a similar capability.

Jim

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

Groepaz
Am Mittwoch, 28. März 2018, 17:01:13 CEST schrieb Jim Brain:
> On 3/28/2018 5:18 AM, Nejat Dilek wrote:
> > The question is, is there any such previous work for an algorithm or
> > similar for such a syncing job?
>
> Not sure how specific your question is, but there is a project on
> Forum64 (I think) that uses a uC to select and load into a FLASH ROM
> lots of KERNALs  I can't remember the name offhand (MegaROM, UltraROM,
> something like that).  I would assume it uses a similar capability.

superkernal -> https://www.forum64.de/index.php?thread/74462-projekt-superkernal-24-in-1-kernal-ersatz-extras/

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

It goes against the grain of modern education to teach children to program.
What fun is there in making plans, acquiring discipline in organizing
thoughts, devoting attention to detail, and learning to be self-critical?
<Alan J. Perlis>



Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

Jim Brain
On 3/28/2018 10:06 AM, [hidden email] wrote:
>
> superkernal -> https://www.forum64.de/index.php?thread/74462-projekt-superkernal-24-in-1-kernal-ersatz-extras/
Most likely.  My German is horrid, and my Google-fu must be off this
morning, as I tried to find it.

Hopefully, it is of interest to the OP's question.

Jim


Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

silverdr@wfmh.org.pl

> On 2018-03-28, at 17:16, Jim Brain <[hidden email]> wrote:
>
> On 3/28/2018 10:06 AM, [hidden email] wrote:
>>
>> superkernal -> https://www.forum64.de/index.php?thread/74462-projekt-superkernal-24-in-1-kernal-ersatz-extras/
> Most likely.  My German is horrid, and my Google-fu must be off this morning, as I tried to find it.
>
> Hopefully, it is of interest to the OP's question.

The problem is that it seems like the beginning of the thread is not there?

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

nejat76
In reply to this post by silverdr@wfmh.org.pl
On Wed, Mar 28, 2018 at 1:50 PM,  <[hidden email]> wrote:
>
>
> I have one ROMs replacement adapter targeting the narrow boards, devised together with Gerrit some time ago. But it's not yet "switchless" yet. The small project I took on with KiCAD recently is exactly about turning it "switchless", besides other changes. I designed the board but haven't written the software yet. Thus, the answer is "no, I haven't heard of something similar but I am highly interested, as this (or something similar) is what I shall have to invent as well. Of course we could go for the typical approach of using RESTORE key as a switch but it's not really "switchless", is it? ;-)
>
> --
> SD! - http://e4aws.silverdr.com/
>
>

Well yes, seeing the original thread posted by Jim Brain my first aim
was to make it completely wireless & switchless. It's a tedious
process involving unsoldering a chip and trying to accomodate another
one with a header and stuff, still finally it becomes a clean mod. I
had 3 switching mechanism on my mind.

1. Using an acceloremeter (Had problems with this one on the attiny firmware)
2. Using hall sensors and magnets to switch kernals. It defeats the
purpose of being wireless but at least you won't be drilling the case
for this. and it would be user friendly to switch kernals by using
specifically crafted magnet arrays put on the c64. Haven't tried this
yet.
3. Using a separately loaded program to switch kernals (the topic of
this initial post)

Regards,

Nejat

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

nejat76
In reply to this post by Groepaz
On Wed, Mar 28, 2018 at 6:06 PM,  <[hidden email]> wrote:

> Am Mittwoch, 28. März 2018, 17:01:13 CEST schrieb Jim Brain:
>> On 3/28/2018 5:18 AM, Nejat Dilek wrote:
>> > The question is, is there any such previous work for an algorithm or
>> > similar for such a syncing job?
>>
>> Not sure how specific your question is, but there is a project on
>> Forum64 (I think) that uses a uC to select and load into a FLASH ROM
>> lots of KERNALs  I can't remember the name offhand (MegaROM, UltraROM,
>> something like that).  I would assume it uses a similar capability.
>
> superkernal -> https://www.forum64.de/index.php?thread/74462-projekt-superkernal-24-in-1-kernal-ersatz-extras/
>
> --
>

I saw SuperKernal it's really a nice project. I think,  if I'm not
mistaken by the looks of it,  it does it's job by completely emulating
the rom. I'm trying to use a different approach with different
hardware specs and with different goals. 8-16mhz attiny85 with bare
minimum program flash along with 27c512 rom.

- I don't want to (and I can't actually with that chosen micro) chase
the individual cycles of rom accesses.
- 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.

Regards,

Nejat

smf
Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

smf
I wouldn't use a pilot tone, I'd use a technique similar to
https://en.wikipedia.org/wiki/1-Wire#Communication_protocol

Pick three lengths

a. start receiving (start receiving if it's idle, or restart receiving
if not)

b. shift in a 0 bit (don't do this if idle)

c. shift in a 1 bit (don't do this if idle)

Include an address, to allow the same mechanism to be used for other
things (like a sid switcher).

And a checksum to protect against false positives or receive errors.

Generate the pulses using loops that are located at addresses with that
address bit set or clear. The lower the address line you use, the more
useful it will be. SID would require a4 or lower, 6526 (although I can't
think of what you'd use it for) would be a3. You may need to run time
generate code for sending the entire packet.

On 28/03/2018 20:04, Nejat Dilek wrote:

> On Wed, Mar 28, 2018 at 6:06 PM,  <[hidden email]> wrote:
>> Am Mittwoch, 28. März 2018, 17:01:13 CEST schrieb Jim Brain:
>>> On 3/28/2018 5:18 AM, Nejat Dilek wrote:
>>>> The question is, is there any such previous work for an algorithm or
>>>> similar for such a syncing job?
>>> Not sure how specific your question is, but there is a project on
>>> Forum64 (I think) that uses a uC to select and load into a FLASH ROM
>>> lots of KERNALs  I can't remember the name offhand (MegaROM, UltraROM,
>>> something like that).  I would assume it uses a similar capability.
>> superkernal -> https://www.forum64.de/index.php?thread/74462-projekt-superkernal-24-in-1-kernal-ersatz-extras/
>>
>> --
>>
> I saw SuperKernal it's really a nice project. I think,  if I'm not
> mistaken by the looks of it,  it does it's job by completely emulating
> the rom. I'm trying to use a different approach with different
> hardware specs and with different goals. 8-16mhz attiny85 with bare
> minimum program flash along with 27c512 rom.
>
> - I don't want to (and I can't actually with that chosen micro) chase
> the individual cycles of rom accesses.
> - 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.
>
> Regards,
>
> Nejat
>

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

MiaM
In reply to this post by nejat76
Den Wed, 28 Mar 2018 22:04:46 +0300 skrev Nejat Dilek
<[hidden email]>:

> On Wed, Mar 28, 2018 at 6:06 PM,  <[hidden email]> wrote:
> > Am Mittwoch, 28. März 2018, 17:01:13 CEST schrieb Jim Brain:
> >> On 3/28/2018 5:18 AM, Nejat Dilek wrote:
> >> > The question is, is there any such previous work for an
> >> > algorithm or similar for such a syncing job?
> >>
> >> Not sure how specific your question is, but there is a project on
> >> Forum64 (I think) that uses a uC to select and load into a FLASH
> >> ROM lots of KERNALs  I can't remember the name offhand (MegaROM,
> >> UltraROM, something like that).  I would assume it uses a similar
> >> capability.
> >
> > superkernal ->
> > https://www.forum64.de/index.php?thread/74462-projekt-superkernal-24-in-1-kernal-ersatz-extras/
> >
> > --
> >
>
> I saw SuperKernal it's really a nice project. I think,  if I'm not
> mistaken by the looks of it,  it does it's job by completely emulating
> the rom. I'm trying to use a different approach with different
> hardware specs and with different goals. 8-16mhz attiny85 with bare
> minimum program flash along with 27c512 rom.
>
> - 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.

> - 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".

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.

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?

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.

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.


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

silverdr@wfmh.org.pl

> On 2018-03-29, at 18:12, Mia Magnusson <[hidden email]> wrote:
>
>> 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".

For a short time that can be worked around by temporarily blanking the VIC.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

nejat76
In reply to this post by smf
On Thu, Mar 29, 2018 at 12:26 PM, smf <[hidden email]> wrote:

> I wouldn't use a pilot tone, I'd use a technique similar to
> https://en.wikipedia.org/wiki/1-Wire#Communication_protocol
>
> Pick three lengths
>
> a. start receiving (start receiving if it's idle, or restart receiving if
> not)
>
> b. shift in a 0 bit (don't do this if idle)
>
> c. shift in a 1 bit (don't do this if idle)
>
> Include an address, to allow the same mechanism to be used for other things
> (like a sid switcher).
>
> And a checksum to protect against false positives or receive errors.
>
> Generate the pulses using loops that are located at addresses with that
> address bit set or clear. The lower the address line you use, the more
> useful it will be. SID would require a4 or lower, 6526 (although I can't
> think of what you'd use it for) would be a3. You may need to run time
> generate code for sending the entire packet.
>

The difference between that 1-wire protocol and my case is that in
that protocol at least the master is noise immune. This is not
possible in my case, whatever address line I choose there will always
be previously unknown 1/0 toggles because of normal use of the
computer.

I agree with the loops modulating the address the way you described.
When I created the prototype pcb I devised that address line to be the
A13 signal (not an actual address line but a chip select line
actually) coming to the 16K eprom as the highest address bit. I
thought of putting the sender code below $C000 so that running code
can choose between reading basic or kernal to toggle the address line
to 0 or 1. Along with A13 line /OE signal is also read so only actual
accesses could be sampled.

Actually it's a good idea to calculate the duration of the line being
held low or high but in my case it's not possible to continously drive
this line high or low. The first thing coming to my mind is using the
sum / average of A13 line for constant time periods and adjust the
start and length of that period until the pattern on the sending side
matches the receiver.

It's hard to describe by writing :)

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

nejat76
In reply to this post by MiaM
On Thu, Mar 29, 2018 at 7:12 PM, Mia Magnusson <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

MiaM
Den Thu, 29 Mar 2018 23:20:19 +0300 skrev Nejat Dilek
<[hidden email]>:
> On Thu, Mar 29, 2018 at 7:12 PM, Mia Magnusson <[hidden email]> wrote:
> > 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.

My idea is that you recognize if the 6510 is running code from the ROM
by detecting that it is accessing the rom for two cycles directly after
each other. When this is detected, you check which adress the CPU is
running from. If it is in the area where you find tables for
the SIN/COS/ATN functions (and the obfuscated string MICROSOFT!) you
can be sure that this is no normal code path of either the standard
roms or any existing C64 software. In that case you switch in a special
rom which has a few NOPs in this area, and then has code that
reinitializes all C64 hardware to a known state (i.e. like the startup
procedure in a standard KERNAL), displays a ROM selection menu, and
when the user selects a ROM the code reads from one in a group of
adresses that tells your hardware which ROM to select. Then the code
jumps to $FFFB which your hardware detects by feeding a JMP instruction
and after that your hardware switches to normal mode, i.e. letting the
6510 see the selected ROM and hides all special selection code.

It would probably require some programmable logic instead of, or in
addition to, the microcontroller.

The nice thing about this is that you could have the menu system buildt
in, just starting it with a SYS statement in basic no matter which ROM
is already selected. (The only special case exception is if you also
allow switching different BASIC versions and some version actually has
real runnable code in the area where the standard BASIC has data).

Btw I haven't checked how the tables actually looks like in a real C64
BASIC rom, but in the source code from Microsoft it seems like there
are nothing that could be interpreted like some kind of jump ($*0
opcodes) or freeze the CPU (a bunch of the $*2 opcodes), so there is a
high chance of this to actually work.

In theory you could do the same thing with tables in KERNAL but that
won't be reliable if you want to have different KERNALs where some
might have code where another have data.

Btw if you do this, you could also use it to extend the maximum amount
of ROM, i.e. jumping to certain places trigger switching between
different ROM images. This is btw used in disk/microdrive interfaces for
Sinclair ZX Spectrum. They detect a jump to the "syntax error" handler
and switches in an expansion rom instead of the standard rom, and then
the standard rom i switched back by detecting code running at some
other addresses. So my idea isn't exactly new, Sinclair thought about
it back in the 80's :)

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

smf
Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

smf
In reply to this post by nejat76
On 29/03/2018 20:44, Nejat Dilek wrote:

> The difference between that 1-wire protocol and my case is that in
> that protocol at least the master is noise immune. This is not
> possible in my case, whatever address line I choose there will always
> be previously unknown 1/0 toggles because of normal use of the
> computer.

The protocol I described will reject invalid data and will restart when
valid data is received. So nothing in the past should make a difference.

No matter how complex you make the starting mechanism, you should make
sure it can detect that during receipt of a message.

> Actually it's a good idea to calculate the duration of the line being
> held low or high but in my case it's not possible to continously drive
> this line high or low.

Do you have space for a latch?

Do you have asynchronous serial on the cpu? It might be a crazy idea,
but you may be able to use the chip select as the serial clock and have
the address line as the data.



Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

nejat76
On Fri, Mar 30, 2018 at 10:28 AM, smf <[hidden email]> wrote:

> On 29/03/2018 20:44, Nejat Dilek wrote:
>
>> The difference between that 1-wire protocol and my case is that in
>> that protocol at least the master is noise immune. This is not
>> possible in my case, whatever address line I choose there will always
>> be previously unknown 1/0 toggles because of normal use of the
>> computer.
>
>
> The protocol I described will reject invalid data and will restart when
> valid data is received. So nothing in the past should make a difference.
>
> No matter how complex you make the starting mechanism, you should make sure
> it can detect that during receipt of a message.
>
>> Actually it's a good idea to calculate the duration of the line being
>> held low or high but in my case it's not possible to continously drive
>> this line high or low.
>
>
> Do you have space for a latch?

Actually I've already built the prototype pcbs and there is not much
space left for a dip ic.

http://www.commodore.gen.tr/forum/index.php?action=dlattach;topic=14781.0;attach=23319;image

Of course the design can be changed and space could be created using 3
pin smd and gates instead of using 14 pin dip 7408 chip.
But I want to experiment this hard situation instead of making it
easier :) A bit of masochism :)

>
> Do you have asynchronous serial on the cpu? It might be a crazy idea, but
> you may be able to use the chip select as the serial clock and have the
> address line as the data.
>

Attiny85 has USI, which is SPI if you support it with software I
guess. Checking the /OE line in a tight loop and sampling the address
line is somewhat a software SPI slave solution actually. Bus on the
C64 is practically 2Mhz because of interleaved 6510 and VIC accesses.
The questions is: would attiny85 properly cope with clock signals of
<500ns. It's worth a try. Then it's a matter of determining the byte
boundary of an actual transfer and adapting to it.

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

nejat76
I found a slow, simple and realtime code free solution.

I'll use /OE line as an interrupt source to the Attiny85 (8 or 16mhz).
Whenever /OE goes from high to low it will cause an interrupt. I'll
measure the time between each interrupt.

Each access either Kernal or Basic will cause an interrupt on attiny85.

Say to transmit 0101 I'll access Kernal (instruction should cause only
on read) in following order,

Access - Start of tranmission
delay 200us
Access
delay 400us
Access
delay 200us
Access
delay 400us

Receiving side will try to receive a byte if timing requirements are
met, if not met then it will discard it.

Once properly launched sender program will not access basic or kernal
when it's not communicating, as such receiver will be in a clean
state. To prevent accidental communication sender will send an
initialization string (FOO or something) and then a command.
Of course, for now the command will be just the index number of the
kernal to switch to.


Regards,

Nejat

ps1: I've previously used this exact method in one of my projects.
Interestingly it only occured to me today that I could use it here too
:) (now I reread the 1 wire protocol, actually it is very similar)
ps2: After initialization, interrupts could be detached and spi slave
transfer method could be used to increase the throughput. (no
functionality comes to my mind though)

Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

Jim Brain
On 4/1/2018 5:15 PM, Nejat Dilek wrote:
>
> Receiving side will try to receive a byte if timing requirements are
> met, if not met then it will discard it.
I know the ATMEL8 uCs have an external interrrupt pin that ties to the
timer.  When activated, it automatically stores the current timer value
and then calls the IRQ routine.  If your ATTINY has it, I'd recommend
using it.
>
Jim

Reply | Threaded
Open this post in threaded view
|

RE: Wireless - switchless kernal mod

Baltissen, GJPAA (Ruud)
In reply to this post by nejat76
Hallo Nejat,


> The program on the attiny side continously samples one of the address lines and tries to sync to this pilot signal.
> After syncing, which is assumed, c64 program sends the chosen eprom bank for the selected kernal. Attiny receives this and switches the kernal.

I beg your pardon but isn't this a bit far sought? What about piggybacking a 6526 on top of an existing one? With a 74LS139 you can either demirror one of the existing 6526s, VIC and/or SID. (Or use IO1 or IO2 to address it but then you'll lose some functionality).

The biggest advantage of this solution IMHO: there is only one CPU you have to program for, thus only one source of possible trouble.


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org




De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
smf
Reply | Threaded
Open this post in threaded view
|

Re: Wireless - switchless kernal mod

smf
On 03/04/2018 07:31, Baltissen, GJPAA (Ruud) wrote:
> I beg your pardon but isn't this a bit far sought? What about
> piggybacking a 6526 on top of an existing one? With a 74LS139 you can
> either demirror one of the existing 6526s, VIC and/or SID. (Or use IO1
> or IO2 to address it but then you'll lose some functionality).
> The biggest advantage of this solution IMHO: there is only one CPU you have to program for, thus only one source of possible trouble.

You lose that mirror address, so you could end up with compatibility issues.

Plus you can't just unplug the rom and insert the module, you have to do
other work.



12