RE: userport: C64, Plus4, others?

Ack sorry, I was just trying to have fun with seeing how hard it was to
put clear intentions into another language.  :)  I figure how often do you
get an answer from a yank in Hungarian or Googarian or whatever that was.

I did expect better from the reverse translation, the first attempt was
almost unrecognizable which was kinda funny.  Something about my chair
wears shorts.

-----Original Message-----
From: owner-cbm-hackers@musoftware.de
[mailto:owner-cbm-hackers@musoftware.de] On Behalf Of Gábor Lénárt
Sent: Friday, March 09, 2012 4:52 PM
To: cbm-hackers@musoftware.de
Subject: Re: userport: C64, Plus4, others?

On Fri, Mar 09, 2012 at 11:47:30AM -0600, Jim Brain wrote:
> On 3/8/2012 3:33 AM, Gábor Lénárt wrote:
> >What HiZ is? I guess it's high impedance, am I right? As being
> >Hungarian I am not sure about the English notion of things sometimes,
> >sorry about it.
> Yes, it's high impedance.  It allows multiple items to exist on a bus.
> Bil's response gives more detail, and he's better to respond on this
> topic than I.

Ehh, it seems I generated some traffic with this. To be clear: I know what
it means (the notion itself and its meaning) but in Hungarian not in
English:
"HiZ", which was never seen by me before :) But for sure, as I know now
that "HiZ" means "high impedance" I know now what it means.


> >Yes, but my idea that always the C64 is the one who must start a
> >transfer regardless of the data direction (read/write). uC won't
> >respond by its own, but C64 requires both of the read/write signaling
> >with another line (maybe PA2 on userport or something like that). So
> >the C64 sets the direction up on CIA, and uC is signaled about the
> >data direction by the C64 so it will know as well about the transfer
> >direction.
> That's fine.  In general, you simply have to ensure that both devices
> (64,uC) are not trying to drive the data lines at the same time.

Yes.

> >Maybe, however I would like to use an uC which has the minimal number
> >of pins as possible (using more ports on uC means more pins), I mean
> >using a DIP version is OK, but I think I have got no skills and tools
> >to solder chips which are not DIP.  Also making a board as a "DIY"
> >style would be quite hard then (for me at least).  I have some
> >experience to build more basic boards/soldering using discrete stuffs
and DIP ICs.
> The ATMEGA16,162,32,644P are all available in DIP40 format, and
> ATMEG28/48/88/168/328 all are in DIP28 package.  And, using 1 IO port
> on the AVR is fine, as long as you ensure only 1 output on the "bus"
> at a time.

Well, yes that's the uC part which is even more "alien" for me :) For
example I am not sure an average uC (like what you mentioned above) has
enough speed to serve an interrupt triggered by eg the PC (low level
active, afaik, but maybe it should be triggerd by the falling edge
instead?) line from C64; since I plan to use interrupts on the uC part, so
the uC itself can do other things meanwhile in the "main program" (not in
interrupt handler). Anyway, never mind, I will also ask my "uC expert
friend here"
before I write too much non-senses here :) It's really interesting on the
DTV though where I guess even 1Mbyte/sec is possible with DTV's DMA but
then anyway since lack of the handshaking, no interrupt service is needed
but some kind of very exact timing instead (or using somewhat slower
"manual"
method to "ack" every bytes).

> >Btw, for starting point I'd like to wire some kind of SD socket, with
> >dual
> >purpose: uC would "boot" its "firmware" from it (there are boot
> >loaders for AVR like this afaik) and also it can be used to
> >read/write data sent/read by
> >C64 too (yes, I know, SD2IEC and like are "better" because they are
"ready"
> >and compatible with a stock machine too - since it uses std IEC bus,
> >but also because of this, it can't be as fast, and also note that
> >having the SD storage is only a part of the project, and not even the
> >primary goal). It's a bit like however as IDE64; it's also not
> >compatible at hw level (it does not using IEC) the compatibility is
> >provided with KERNAL modification (on DTV it's really easy, no need for
additional hardware).
> Yes, bootloaders work well for this (the uIEC bootloader can load any
> firmware image, not just sd2iec, so you can use it if desired).
> But, remember that loading a firmware image on each boot will wear out
> the FLASH area.  It's a large number of cycles, but keep it in mind.

Well, I'm more used to have von Neumann architecture rather than Harvard
:) Isn't it possible to use normal RAM for code with eg an AVR (maybe even
internal RAM, I guess it's possible to use external RAM with uCs with
external bus interface but it implies a rather pin-monster being, hehe)?
So the flash would only contain the boot loader itself. But anyway a
simple
theory: I can store eg a word in my firmware which mean some kind of
"version number". The boot loader can check the version number from the SD
card and the version number flashed by the boot last time. If they are the
same, no re-flashing is needed. Or maybe even some kind of checksumming
which is more accurate stuff. Other possibility is to have a simple button
I have to hold while powering-on the require loading (and flashing into
the
uC) a new firmware.


- Gábor

       Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list