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