Rebuilding the CIAs
Scott McDonnell
motherboard. Well, the idea is also to rebuild the CSG/MOS chips in CPLDs
and FPGAs so that I can simplify and shrink the design. Also, I do not wish
to rely on hard to find parts (part of preserving the C64's future!)
Anyway, right now I am redesigning the CIAs, and plan to integrate them into
one chip, tighten thier addressing (so they only use16 addresses locations,
instead of 256), and remove, improve, and re-route portions of it to remain
compatible, but with more modern hardware.
For example, CIA1 is *almost* entirely used for the keyboard and control
ports. By redesigning this CIA, I can map in a serial based keyboard (PS/2?)
to free up pins and allow an external, more modern keyboard. By replacing
the TOD functions with a battery backed RTC, this function may actually
become useful. These are just a couple of examples.
I have already worked out quite a bit of the design, once I get it polished
up a bit, I will be able to program a CPLD and test it. What I would like is
the expertise of those more familiar with the programming side of things to
help me determine what features could be removed without breaking (normal)
compatability. I think I already know the majority of it, but I am far from
an expert in the various software tricks used in the C64.
I wouldn't mind some suggestions for improvements as well. Something like
adding more capabilities to the CIA. Since I am freeing up the 250 bytes
above each CIA, I have some room to add more registers for new features. As
long as it is not normal for software to use the phantom registers (which
would just be silly), we can do whatever we want with them. Since it is
important to leave the CIAs mapped at thier original locations, I cannot
just place them together and add the difference to the Free RAM space.
Granted, it would be free RAM, but the system wouldn't know about it because
of the way it checks for free memory (besides, how much would 500 bytes help
anway?)
Well, that's it. I appreciate the help in advance. This is my first attempt
at requesting a technical discussion since the fiasco a couple of months
ago. I hope it does not turn out like before. Please realize:
I am not asking anyone to hold my hand.
I am not asking for a wish-list (except for the added capabilities, maybe.)
I am asking for expertise on the issues of compatability.
When (not IF) this CIA project is completed, I will be moving on to the
other CSG/MOS chips. I decided to start with the CIAs because for one they
are simpler, and for two they do not have nearly as many zealots behind
them, since they are generic. I expect a flamewar when I get to the SID and
VIC chips, though. :( So, the 6510 is next.
The ROMS will become flash memory and the RAM will become a single chip SRAM
chip. Perhaps once everything is completed, a single-chip C64 design would
be done just to complete the portfolio.
Scott
Matthew Montchalin
|Anyway, right now I am redesigning the CIAs, and plan to integrate them
|into one chip, tighten thier addressing (so they only use16 addresses
|locations, instead of 256), and remove, improve, and re-route portions
|of it to remain compatible, but with more modern hardware.
How much do you plan on selling the upgrades for?
What the heck, it would be cool if you could offer 6522 replacements as
well as 6526's.
And if you could map in an extra register or two around $dc10, maybe
it would be nice to have them decrement down once on phi2 low, and
once on phi1 low? In short, making the timers count down twice as
fast.
Matthew Montchalin
And it might take some work, but if you could get Timer B to trigger
a one-shot on Timer A, where the first was decrementing twice as fast
as the second one, we could do some pretty fancy timing things. In
short, it would be nice to have a second control register where you
could get one timer to decrement twice as fast as the other, and then
have one trigger the other, some fairly interesting timing stuff can
be pulled off.
J.Oppermann
Scott McDonnell wrote:
> I wouldn't mind some suggestions for improvements as well. Something like
> adding more capabilities to the CIA. Since I am freeing up the 250 bytes
> above each CIA, I have some room to add more registers for new features. As
> long as it is not normal for software to use the phantom registers (which
> would just be silly), we can do whatever we want with them. Since it is
> important to leave the CIAs mapped at thier original locations, I cannot
> just place them together and add the difference to the Free RAM space.
> Granted, it would be free RAM, but the system wouldn't know about it because
> of the way it checks for free memory (besides, how much would 500 bytes help
> anway?)
I guess most ppl would run "old" games and SW.
I cannot tell how much these use "shadow-register-addressing" on the 6526, but
as it concerns the "SID-league" I read it's been quite common on the 6581
address-range.
The "worth" of 500 bytes reminds me on what I've read in the anti-cracker book,
where they have put routines into the datasette buffers and all this "naughty"
stuff.
If you really fancy this kind of "efficency" (; I would recommend having it
"configurable", i.e. means to switch it off if it turns out to be incompatable
to many PRGs. But I guess that's too much CPLD space though...
Just being curious as I just start with CPLDs myself. What size of CPLD do you
expect to need for the CIA? I just took an Altera 7032 mainly for a 68020
databus byte addressing and it's already almost out of I/O-pins...
silverdr
> OK, some of you already know that I have been working on a new C64
> motherboard.
I don't recall that but the idea is very much appealing to me. I've been
thinking (only) on that too.
> Well, the idea is also to rebuild the CSG/MOS chips in CPLDs
> and FPGAs so that I can simplify and shrink the design. Also, I do not wish
> to rely on hard to find parts (part of preserving the C64's future!)
That's exactly a very important note.
For quite some time now, I have been dreaming about a C64 board with
much smaller footprint.
> I have already worked out quite a bit of the design, once I get it polished
> up a bit, I will be able to program a CPLD and test it. What I would like is
> the expertise of those more familiar with the programming side of things to
> help me determine what features could be removed without breaking (normal)
> compatability. I think I already know the majority of it, but I am far from
> an expert in the various software tricks used in the C64.
>
> I wouldn't mind some suggestions for improvements as well. Something like
> adding more capabilities to the CIA. Since I am freeing up the 250 bytes
> above each CIA, I have some room to add more registers for new features.
That might be one of the compatibilty breaking factors but I wouldn't
care that much about that.
> As
> long as it is not normal for software to use the phantom registers (which
> would just be silly), we can do whatever we want with them.
I have seen those and similarly silly things in the code already ;-) I
e.g. recall someone pulling out the "$" character with LDA $Exxx from
the KERNAL ROM instead of LDA #'$' to read the directory of the drive.
Of course it broke on my modified ROMset... But I Agree. Let's make it
better and don't really care about the ones who used the phantoms.
[...]
>
> When (not IF) this CIA project is completed, I will be moving on to the
> other CSG/MOS chips. I decided to start with the CIAs because for one they
> are simpler, and for two they do not have nearly as many zealots behind
> them, since they are generic. I expect a flamewar when I get to the SID and
> VIC chips, though. :( So, the 6510 is next.
>
> The ROMS will become flash memory and the RAM will become a single chip SRAM
> chip. Perhaps once everything is completed, a single-chip C64 design would
> be done just to complete the portfolio.
>
Man! Full kudos if... werrr WHEN you finish this! I think some might
even forgive you your topposting habit for a while then ;-)
Zed Yago
As for software-tricks, sometimes Programmers do use the mirrors of
the cia1, to control both cias with one function..
as an example:
; x=$00 for cia1
; x=$10 for cia2
lda $dcf0,x
rts
Viewing the cias as the main input-output chips, i would like to
have..
More cias for connecting an ide drive. (cia2ide)
Instead of using ps/2, usage of usb, but that would probably be better
in something completely different then a cia-replacement ?
Have Fun,
Zed Yago
Scott McDonnell
news:c48p49$2fhhts$1...@ID-67386.news.uni-berlin.de...
> I guess most ppl would run "old" games and SW.
> I cannot tell how much these use "shadow-register-addressing" on the 6526,
but
> as it concerns the "SID-league" I read it's been quite common on the 6581
> address-range.
I'll remember that, thanks.
> The "worth" of 500 bytes reminds me on what I've read in the anti-cracker
book,
> where they have put routines into the datasette buffers and all this
"naughty"
> stuff.
Exactly. And it would still be availible if YOU knew where it was. The
problem
is with the system listing it as availible RAM when it checks free RAM. In
other
words, it would not be in the "cintiguos user RAM."
>
> If you really fancy this kind of "efficency" (; I would recommend having
it
> "configurable", i.e. means to switch it off if it turns out to be
incompatable
> to many PRGs. But I guess that's too much CPLD space though...
Well, once I have the physical replacement, I would like to test it as much
as possile
before committing to a design. The nature of an ispCPLD is that the design
can
be changed once it is installed.
I do fancy that type of efficiency only because it would allow new
peripherals and
perhaps upgraded features (like more colors on screen at once, etc..) when
you
have the extra address spaces. If the system isn't expecting anything but
the mirrored
addresses of the CIA there, then it wouldn't break compatability while
offering new
features to new programs.
>
> Just being curious as I just start with CPLDs myself. What size of CPLD do
you
> expect to need for the CIA? I just took an Altera 7032 mainly for a 68020
> databus byte addressing and it's already almost out of I/O-pins...
Right now, I am only working on hand-drawn discrete logic schematics. I
haven't
calculated the total number of product terms yet. The lack of IO pins is
also
another reason I am looking to simplify the design. I have not yet started
burning any
CPLDs. I know HDL from courses at Uni, but they did not have the equipment
to sythesize a part. I am looking at parts myself right now. By starting out
with the CIA
it gives me the advantage of learning the process while sticking to
something less
complicated. This will also give me an idea how to predict the size of the
part I will
need for the rest of the chips.
BTW, when you say "Databus addressing" are to talking about mapping address
lines
into memory? Kind of like how the PIO port on the 6510 works? If so, you may
want
to learn a bit from a normal PIA, CIA, VIA, etc.. remember that you can do 1
of 2/4/8/16
decoders internal to the CPLD to lessen the burden on I/O pins. Would
increase your
needed gates, but there are a lot more gates than there are I/O pins. If you
are more specific,
I may be able to help more specifically.
You might want to join us here: http://groups.yahoo.com/group/CommieTech/ to
prevent
flooding the group with the discussion.
Scott
Six of DLoC
> OK, some of you already know that I have been working on a new C64
> motherboard. Well, the idea is also to rebuild the CSG/MOS chips in
> CPLDs and FPGAs so that I can simplify and shrink the design. Also, I
> do not wish to rely on hard to find parts (part of preserving the
> C64's future!)
Are you going to make your cores public domain?
S.o.D.
Scott McDonnell
news:4068...@news.inet.com.pl...
> Scott McDonnell wrote:
> > OK, some of you already know that I have been working on a new C64
> > motherboard.
>
> I don't recall that but the idea is very much appealing to me. I've been
> thinking (only) on that too.
That's problem with a thread turning into a flamewar. You remember the
flamewar, but not the purpose of the thread to begin with. :)
I guess I am more tolerant of communication issues, bad english, etc..
because I am an engineer. I need to read and understand complicated
technical material from semiconductor manufacturers that are translated.
I have to learn to deal with it. I cannot just call up the manufacturer and
demand that they learn better english and etiquette. :)
> > Well, the idea is also to rebuild the CSG/MOS chips in CPLDs
> > and FPGAs so that I can simplify and shrink the design. Also, I do not
wish
> > to rely on hard to find parts (part of preserving the C64's future!)
>
> That's exactly a very important note.
>
> For quite some time now, I have been dreaming about a C64 board with
> much smaller footprint.
>
> > I have already worked out quite a bit of the design, once I get it
polished
> > up a bit, I will be able to program a CPLD and test it. What I would
like is
> > the expertise of those more familiar with the programming side of things
to
> > help me determine what features could be removed without breaking
(normal)
> > compatability. I think I already know the majority of it, but I am far
from
> > an expert in the various software tricks used in the C64.
> >
> > I wouldn't mind some suggestions for improvements as well. Something
like
> > adding more capabilities to the CIA. Since I am freeing up the 250 bytes
> > above each CIA, I have some room to add more registers for new features.
>
> That might be one of the compatibilty breaking factors but I wouldn't
> care that much about that.
Right, and I wouldn't care too much if it were an odd program here or there.
But
if it is "normal", then it is pretty important. There is no way to do both a
smaller
original mobo AND add new features, without breaking a little compatability
(though
I am going to try anyway!) As they say, you can't make an omelette without
breaking
a few eggs.
>
> > As
> > long as it is not normal for software to use the phantom registers
(which
> > would just be silly), we can do whatever we want with them.
>
> I have seen those and similarly silly things in the code already ;-) I
> e.g. recall someone pulling out the "$" character with LDA $Exxx from
> the KERNAL ROM instead of LDA #'$' to read the directory of the drive.
> Of course it broke on my modified ROMset... But I Agree. Let's make it
> better and don't really care about the ones who used the phantoms.
>
> [...]
>
> >
> > When (not IF) this CIA project is completed, I will be moving on to the
> > other CSG/MOS chips. I decided to start with the CIAs because for one
they
> > are simpler, and for two they do not have nearly as many zealots behind
> > them, since they are generic. I expect a flamewar when I get to the SID
and
> > VIC chips, though. :( So, the 6510 is next.
> >
> > The ROMS will become flash memory and the RAM will become a single chip
SRAM
> > chip. Perhaps once everything is completed, a single-chip C64 design
would
> > be done just to complete the portfolio.
> >
>
> Man! Full kudos if... werrr WHEN you finish this! I think some might
> even forgive you your topposting habit for a while then ;-)
I think most people have probably forgiven me anyway. We all have our PMS
days. :)
Scott
Scott McDonnell
news:Pine.LNX.4.44.040328...@lab.oregonvos.net...
> Scott McDonnell wrote:
> |Anyway, right now I am redesigning the CIAs, and plan to integrate them
> |into one chip, tighten thier addressing (so they only use16 addresses
> |locations, instead of 256), and remove, improve, and re-route portions
> |of it to remain compatible, but with more modern hardware.
>
> How much do you plan on selling the upgrades for?
I am not considering the commercial aspects right now. I am focused on
getting it done.
Then we'll worry about how much it will cost. More than likely, I would just
offer
the results as open hardware for the sake of preservation. I might sell
parts and such
to those that are unable to do it themselves. Not looking at earning a
living from it.
>
> What the heck, it would be cool if you could offer 6522 replacements as
> well as 6526's.
Would only be a hop, skip, and jump from a 6526 design to do a 6522. But,
I am not planning to offer these as "replacements" in the sense that they
will
be plugged into an existing board. That just adds limitations that I am not
willing to deal with. However, with daughter boards, there shouldn't be any
reason someone *couldn't* do it that way. Most of these chips will be PLCC
or PGA packages, completely breaking away from DIPs (higher pin density,
smaller footprint.) Look at the C65 motherboards for examples.
Of course, there are already generic PIAs from motorola and others that
can do the trick with a bit of re-wiring. The 6821 is an example.
>
> And if you could map in an extra register or two around $dc10, maybe
> it would be nice to have them decrement down once on phi2 low, and
> once on phi1 low? In short, making the timers count down twice as
> fast.
To count frequency? I will need you to clarify a bit, because as I
understand
you now, that ability is already present.
Scott
Scott McDonnell
"Zed Yago" <yi...@2nybbles.com> wrote in message
news:f5e16757.04032...@posting.google.com...
> "Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in message
news:<SVO9c.119292$1p.1684256@attbi_s54>...
>
> As for software-tricks, sometimes Programmers do use the mirrors of
> the cia1, to control both cias with one function..
>
> as an example:
> ; x=$00 for cia1
> ; x=$10 for cia2
>
> lda $dcf0,x
> rts
Interesting point. Though, it may not turn out to be too much trouble
to add a hook for CIA1 at that address to maintain that ability. I will
keep that in mind for the testing and final design. It would probably look
kind of frankenstien as a memory map, but keeping upgrades in the
space already considered I/O space by the C64 would allow retaining
compatability while adding features. That's the plan anyway!
>
> Viewing the cias as the main input-output chips, i would like to
> have..
> More cias for connecting an ide drive. (cia2ide)
> Instead of using ps/2, usage of usb, but that would probably be better
> in something completely different then a cia-replacement ?
More CIAs would be easily possible. But yeah, it would be better to
add other hardware more suited for these purposes at the freed up
I/O addresses. The intention of the final design is to have mass storage
features like a HDD or CF flash that handles/translates DOS calls. I am
not sure how this will be pulled off, yet, though. One step at a time. :)
USB for the keyboard? You have a good point. Though, it would be
best to have an implementable custom keyboard anyway, so whatever
interface we wanted would be possible. Again, to maintain compatability
I would need it to be mapped at CIA1 and handle the normal calls to the
keyboard and reply as expected by firmware.
Anyway, I am sticking as close to the original C64 as possible initially.
After
that works, then I (and others) can look at ways to expand it even further
while retaining compatability. Modern technology offers some pretty incredib
le
possiblities compared to what Commodore had to work with at the time. No
need to break compatability too much to offer a newer platform.
Compatability is my MAIN design requirement, everything else is secondary.
>
> Have Fun,
> Zed Yago
I intend to! This entire project is my way of merging my two favorite
hobbies
and interests: Electronic Engineering and Commodore computers. I didn't go
to school to be an engineer only for the money and stress (I could make as
much
doing construction!) : )
Scott
RajW
<devi...@NOSPAMexcite.com> wrote:
>> |Anyway, right now I am redesigning the CIAs, and plan to integrate them
>> |into one chip, tighten thier addressing (so they only use16 addresses
>> |locations, instead of 256), and remove, improve, and re-route portions
>> |of it to remain compatible, but with more modern hardware.
Just curious (and I have done no research on this) are there any other
pre-made chips out there that are similar in function or compatible
with the 6526/6522's??
/*Raj*/
silverdr
>>>OK, some of you already know that I have been working on a new C64
>>>motherboard.
>>
>>I don't recall that but the idea is very much appealing to me. I've been
>>thinking (only) on that too.
>
>
> That's problem with a thread turning into a flamewar. You remember the
> flamewar, but not the purpose of the thread to begin with. :)
Yup. Might have happened. ;-)
[...]
> I am going to try anyway!) As they say, you can't make an omelette without
> breaking a few eggs.
That's more or less what I wanted to say but it seems that you know
perfectly well what a good balance between compatibility and new
features is.
Anyway, please keep it up! I (and probably many others) would very much
love to see you succeeding on that!
Scott McDonnell
news:Xns94BB521C2E5...@63.223.5.254...
Six,
I was replying with that info (in another post) while you were typing
your question. But yes, sort of (how else could I claim to be "preserving"
the C64?) I intend to offer up everything: schematics, source code, cores,
etc..
for free. I might make a buck or two putting a kit together for those that
cannot do it themselves, however. This just might help me buy some equipment
to offer more things in the future or might help recoup some of the time
I will be spending (months of free time, I am sure.) But, ultimately, I
can't think
of anything I would rather do with my free time, so I am doing it as a
"lavoro di amore."
I might protect myself only with a license that allows me to be the only
person
to offer anything for sale, for a limited time. But, everything would still
be free
to those for personal use. I am not familiar with open-source licensing yet,
but
I think this is considered GPL?
So, not really "public domain" but free to those that can build for
themselves
or thier buddies.
Of course, I am not really at a point to start worrying about that. Gotta
have
something first before I worry about how I will offer it. But, yeah, it is
NOT
my intention to make this a commercial venture. And DEFINITELY not my
intention to 'close source' this so that it disappears with me!
Scott
Scott McDonnell
"RajW" <r...@intelc64.net> wrote in message
news:poag60pc3q5orr4pr...@4ax.com...
Raj,
You probably already read this by now, but I mentioned in another reply,
the 6821 PIA by motorola is very similar to the 6522. This is CMOS
compatable, so it makes it a more likely candidate for a replacement
than an 8255 for example. There are lots of chips similar in function,
since the VIAs are essentially generic parallel port interfaces.
However they all will differ in pinouts, register selection, power
requirements,
and the added features. For example, I do not know of a chip which has
the TOD, timers, and UART included. Just about everything else in the 6526
(that's why I said it was more similar to a 6522) is present in those other
chips.
The CIA is a specialty chip (because of the extra features, while the VIA
is fairly generic. You could replace the CIA with the generic components
but you would have to deal with the extra features externally somehow.
Look for: peripheral interface adapter, parallel port controller, etc..
Generically, all these chips do is offer two ports of configurable inputs
and outputs with all the required buffers, drivers, and latching. On the MPU
side, they offer register selection inputs to support being placed in the
memory map. This feature is no more than a 1-of-(something) decoder.
The decoder enables registers (flip-flops) to store or present data used
by the other circuits. The R/~W signal configures a tri-state bi-directional
buffer/driver.
Anyways, it is not a complicated device. It was pretty much a standard
by the time Commodore got to it, and like the other CSG/MOS chips,
were taken from experiences working at Motorola.
The PIO on the 6510 is actually just one port of a peripheral interface
adapter. It would be extremely simple to convert a 6502 to a 6510
by adding a similar circuit to the bus mapped at $0000 and $001.
I have not looked too far into whether this is the ONLY difference,
mainly because 6502s are almost as difficult to find as a 6510.
When I get that far, I will probably take a free 6502 IP core, add
the required circuits for the PIO, and then look at the rest of the issues.
Right now, a big issue is that many 6502 implementations do not have
the BCD instructions or illegal opcodes. So that will have to be worked
out, as well.
Then again, I might just try to start from scratch. In the overall picture,
all the chips could become quite different since I am not really looking
at 'replacements' but rather clones. As long as the inputs and outputs
work as expected by software, firmware, and other external hardware,
it doesn't really matter much ~what~ is in-between.
Scott
Scott McDonnell
"Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in message
news:UxW9c.27490$gA5.387350@attbi_s03...
And timing/cycle counts, too of course.
Scott
Matthew Montchalin
|> And if you could map in an extra register or two around $dc10, maybe
|> it would be nice to have them decrement down once on phi2 low, and
|> once on phi1 low? In short, making the timers count down twice as
|> fast.
|
|To count frequency? I will need you to clarify a bit, because as I
|understand you now, that ability is already present.
Timers A and B are each 16 bits wide. At 1 mhz, they do their job
well enough. But it would be nice if you could tie them together
so you have a 32 bit wide timer, and then allow for the possibility
of 2 mhz operation, we could do so much more.
Matthew Montchalin
If the prospect of 2 mhz operation seems to bore you, consider what
a new C-64 motherboard could do if it had an upgraded VIC chip with
a doubling of its dot-clock, and 32 bit wide timers in the CIA's...
MagerValp
SM> Interesting point. Though, it may not turn out to be too much
SM> trouble to add a hook for CIA1 at that address to maintain that
SM> ability.
Seeing how mirroring is a side effect from the PLA address decoder,
why would the VHDL description of the CIA need to bother with it?
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
Corin Talkobt
>>>>>>"SM" == Scott McDonnell <devi...@NOSPAMexcite.com> writes:
>
>
> SM> Interesting point. Though, it may not turn out to be too much
> SM> trouble to add a hook for CIA1 at that address to maintain that
> SM> ability.
>
> Seeing how mirroring is a side effect from the PLA address decoder,
> why would the VHDL description of the CIA need to bother with it?
>
Features I'd like to see on an "enhanced" 6526. Not all are needed but
if you're gonna be mucking around w/ it anyway... Some of these would be
useful to the C=, others would be useful for hardware, in general.
- In addition to the time of day clock, have a date register which is
automatically updated based upon the time of day clock.
- Have the date register & time of day clock be able to be battery /
static ram backed up.
- Allow scaling of the processor clock from 0.1 to 4 times to control
how often they "tick".
- Allow addition of another serial port register.
- Allow remapping the keyboard lines to support the emulation of a
regular keyboard with a PS/2 one (software enablable or hardware sensed
enabled )
- Same as above but allow emulation of a 1351 mouse w/ a PS2 one
(software enablable or hardware sensed enabled).
-
White Flame (aka David Holz)
> I wouldn't mind some suggestions for improvements as well. Something like
> adding more capabilities to the CIA.
It would make me quite happy if you could add a real RS232 option to the
"serial port" functionality.
--
White Flame (aka David Holz)
http://www.white-flame.com/
(spamblock in effect)
White Flame (aka David Holz)
news:nf0ac.71780$zP2....@bignews5.bellsouth.net...
> - Same as above but allow emulation of a 1351 mouse w/ a PS2 one
> (software enablable or hardware sensed enabled).
The 1351's position information comes through the SID's POT registers; only
the mouse buttons go through the CIA. If you want a PS/2 mouse seen
transparently to a C64 as a 1351, the brunt of the emulation would need to
be at the SID registers.
Besides, there's already a PS/2 to 1351 converter. :) Google for micromys
"ps/2" adapter; there's a couple of websites selling it.
Axell
>I wouldn't mind some suggestions for improvements as well. Something like
>adding more capabilities to the CIA. Since I am freeing up the 250 bytes
>above each CIA, I have some room to add more registers for new features. As
>long as it is not normal for software to use the phantom registers (which
>would just be silly), we can do whatever we want with them. Since it is
>important to leave the CIAs mapped at thier original locations, I cannot
>just place them together and add the difference to the Free RAM space.
>Granted, it would be free RAM, but the system wouldn't know about it because
>of the way it checks for free memory (besides, how much would 500 bytes help
>anway?)
>
>
As a suggestion, hide your new registers under the CIA phantom
registers. Add some toggle feature that
switches between your new improved CIA registers and the old phantom
registers for compatibility mode.
By doing this you might alieviate expierences such as some of the Vic
IIe register problems expierenced with the 128.
Matthew Montchalin
|As a suggestion, hide your new registers under the CIA phantom
|registers. Add some toggle feature that switches between your new
|improved CIA registers and the old phantom registers for compatibility
|mode.
Map the toggle line in register 127, that is, in address $dc7f or $dd7f.
That ought to be far enough away that not very many people expect
anything there.
Scott McDonnell
CIA.
I only mentioned it in this discussion to introduce the fact that I will be
removing
them and freeing up space, and whether this would be a big problem or not.
I mentioned that in the commietech group, but forgot to mention it here.
Sorry, I should have specified that.
Anyway, the PLA will be a separate CPLD at this point, that I will reprogram
as
needed. Full address decoding is the plan.
Ideally, I WOULD prefer to integrate the CIAs and address decoder (PLA) into
one CPLD, but I am afraid I wouldn't have enough pins or product terms to do
do that. Maybe an FPGA, but again, I am just trying to stick to one step at
a time.
Once I have the cores finished, it would be fairly easy to port it and
implement
it differently.
Thanks for pointing out my omission.
Scott
"MagerValp" <Mage...@cling.gu.se> wrote in message
news:p14fzbr...@panini.cling.gu.se...
Jim Brain
Firstly, congrats on the project. I want to try out CPLDs as well.
But, apologies in advance for this, but I think the topic is valid here.
I see a lot of CPLD work going on, but I see very few projects emulating
an interface or IC using a PIC/SX/AVR controller. Why is that?
I was looking over the specs on some of these units today, and checking
prices.
Taking IDE64 as an example, the CPLD in it is $35.00 single quantity. A
52 pin SX or a 64 pin AVR is $15.00. The SX can go at 75MHz, which
means one coulod emulate quite a bit in SW.
Not trying to upset this project, just asking. I just thought say,
emulation would work just as well, and the cost seems better.
My thoughts were a better UART cart that emulated the 6551. Immediate
support by all the term/BBS apps, but the ability to support 2 UARTs,
have a FIFO, etc... A controller that supports enough pins for a 6551
emulator is the same price as a real 6551 from jameco.
Inquiring minds....
Jim
Scott McDonnell
"Jim Brain" <br...@jbrain.com> wrote in message
news:J48ac.135004$po.863184@attbi_s52...
> Scott McDonnell wrote:
> But, apologies in advance for this, but I think the topic is valid here.
> I see a lot of CPLD work going on, but I see very few projects emulating
> an interface or IC using a PIC/SX/AVR controller. Why is that?
Yes, that is certainly an option, except when I get to anything more complex
like the 6510 CPU, SID, and VIC.
The idea though is that I want an HDL core that can can be sythesizable 40
years from now. HDL can do that. Someone can even take the core and
have an ASIC made from it. So, there is the longetivity.
Also, one of the plans for the project is to build a one-chip C64. The HDL
code used for the separate CPLDs can be easily integrated together and
programmed into an FPGA. Also, SoC technology is getting there enough
that they can house RAM, ROM, peripherals, clocks, CPU and everything
else in one device. The HDL could be ported over to that when it is
availible
and cheap enough to be feasible. So, HDL is portable for describing
hardware.
Then there is the flexibility. In a micro, the pins are already defined and
limited. A micro with enough ports would probably be more expensive
than a CPLD. I haven't looked at the chip the IDE64 uses, but $35 seems
a bit expensive. Perhaps, they chose a bigger CPLD than neccessary to
accomodate future plans?
It's not that I hadn't thought about microcontrollers, it's that I just
don't feel
they fit into this particular project for me. However, you did spark
something,
unintentionally: I could use a micro to patch in areas while I am
developing.
For example, the PLA might be a good candidate for a flash micro. It
pretty much would be limited to a LUT, though, but would be great to use
while developing. I bet the timing would be a pain though. At any rate, I
may give it a whirl and see.
Thanks for the thought.
Scott
Spiro Trikaliotis
Scott McDonnell wrote:
> Anyway, right now I am redesigning the CIAs, and plan to integrate them into
> one chip, tighten thier addressing (so they only use16 addresses locations,
> instead of 256), and remove, improve, and re-route portions of it to remain
> compatible, but with more modern hardware.
On
http://www.softwolves.pp.se/misc/arkiv/cbm-hackers/5/5263.html
you can find Dave Ross announcing a CIA VHDL description. Unfortunately, the
included link does not work anymore, but I have the VHDL file here on my
HD (Watson652605-11-01.zip) in case you're interested.
Furthermore, from
http://www.softwolves.pp.se/misc/arkiv/cbm-hackers/5/5710.html
it seems that there are others who have worked on such a thing, too.
> For example, CIA1 is *almost* entirely used for the keyboard and control
> ports. By redesigning this CIA, I can map in a serial based keyboard (PS/2?)
> to free up pins and allow an external, more modern keyboard.
Yes, but this should work with a Joystick emulation, too, as it uses
the same pins. Have you considered this, too?
> What I would like is
> the expertise of those more familiar with the programming side of things to
> help me determine what features could be removed without breaking (normal)
> compatability.
Just a thought: Why don't you use an open-source emulator <shameless plug>like
VICE</shameless plug> and test different options to see how the programs you
want to use are affected? From what I know, the CIAs have been utilized quite
extensively and "from the inside out". IIRC, the reason the replacement of
the CIAs with 85xx types by Commodore on newer C64s did break some games/demos
was that the timing was "off-by-one" on the latter models. So, extensive
testing seems appropriate.
Spiro.
Scott McDonnell
news:c4cgnu$2h4mt9$1...@ID-9481.news.uni-berlin.de...
> Hello Scott,
>
> On
> http://www.softwolves.pp.se/misc/arkiv/cbm-hackers/5/5263.html
>
> you can find Dave Ross announcing a CIA VHDL description. Unfortunately,
the
> included link does not work anymore, but I have the VHDL file here on my
> HD (Watson652605-11-01.zip) in case you're interested.
>
> Furthermore, from
> http://www.softwolves.pp.se/misc/arkiv/cbm-hackers/5/5710.html
>
> it seems that there are others who have worked on such a thing, too.
Yes, thanks for the link. It looks like Rainer Buchty was also looking for
others
to do this at that time.
I would be interested, but only if I could somehow get ahold of Dave Ross.
It
would be important to find out why it isn't still available somewhere. I see
from
the CBM hackers list, that he began talking quite a bit to Jeri about it.
Perhaps
he yanked the design for her to use in the C-1?
Unfortunately, this is what I have run into many times. Noone that has done
previous work is willing to share anything because they don't want to
interfere
with Jeri's work. That is thier perogative, but the C-1 is a commercial
project.
I am looking to offer free VHDL models.
FWIW, everything but the SID, VIC, and PLAs are already available in VHDL
here, if you want to license them:
http://home.teleport.com/~scd/avail_ip.htm
In fact, there are many half-completed, commercial, or closed projects for
the
MOS/CSG chips scattered around. I would be interested in the half-completed
projects with the authors permission. Otherwise, I will simply do the work
from
scratch, since what I want to do is offer these models for free for
preservation.
According to other messages by Dave Ross on comp.arch.fpga, he was unable
to fit his design in a CPLD, did not have the TOD implemented yet, etc.. As
I
said, I would like to see how far he was able to get, but only if I could
verify
with him that it was OK to complete his work.
If you send it to me, I will do my best to track him down and see what his
thoughts
are.
> > For example, CIA1 is *almost* entirely used for the keyboard and control
> > ports. By redesigning this CIA, I can map in a serial based keyboard
(PS/2?)
> > to free up pins and allow an external, more modern keyboard.
>
> Yes, but this should work with a Joystick emulation, too, as it uses
> the same pins. Have you considered this, too?
That is what I meant by the control ports, yes. However, I was only planning
at this moment to support the original digital sticks, since it seems most
people
prefer those on the Commodore equipment. Am I right about that?
>
> > What I would like is
> > the expertise of those more familiar with the programming side of things
to
> > help me determine what features could be removed without breaking
(normal)
> > compatability.
>
> Just a thought: Why don't you use an open-source emulator <shameless
plug>like
> VICE</shameless plug> and test different options to see how the programs
you
> want to use are affected? From what I know, the CIAs have been utilized
quite
> extensively and "from the inside out". IIRC, the reason the replacement of
> the CIAs with 85xx types by Commodore on newer C64s did break some
games/demos
> was that the timing was "off-by-one" on the latter models. So, extensive
> testing seems appropriate.
Good suggestion. I might have to brush up on my C++ a bit, though. I was
never that
good at it. For windows programming, I tend to stick to Visual Basic.
Scott
Dave Ross
old enteract.com web site.
The current location is http://watsonc64.home.comcast.net/commodore.html
I'll be moving that stuff to a more permanent home at csixty4.com soon
(time permitting).
You can go ahead and ignore the "licensing" terms on the VHDL 6526.
I never synthesized it, so I don't know if it works -- although I remember
it being pretty complete. VHDL turned out to be too expensive of a hobby
for me at the time. I'd love to pick it up again one of these days.
Have fun!
- Dave
Rick Balkins
for VIC-20s and stuff of that nature but we are talking 6526 as the C64 has
them and must make a 100% compatible with exact 6526 characteristics not
just 6522s which was already taken care of.
WDC already has had 6522 compatible 65c22 for several years but not the
6526. So here is the answer. Right now, there is NO need to worry about the
6522 but the 6526. Even though they are VERY compatible but the 6526 is
slightly different.
"RajW" <r...@intelc64.net> wrote in message
news:poag60pc3q5orr4pr...@4ax.com...
> Just curious (and I have done no research on this) are there any other
Rick Balkins
> Firstly, congrats on the project. I want to try out CPLDs as well.
It doesn't have to be a CPLD but an FPGA (by principle - there isn't any
real difference to worry about too much)
and can be down to $5 for the CPLD thats a 44 pin package (EPM3064ALC44-4)
from www.arrow.com
> But, apologies in advance for this, but I think the topic is valid here.
> I see a lot of CPLD work going on, but I see very few projects emulating
> an interface or IC using a PIC/SX/AVR controller. Why is that?
Well, you can't really emulate 100% and an FPGA/CPLD would be more capable
of emulating the chip.
Now a PIC or an AVR and all would require other stuff to make it emulate
100% or even at the level the FPGA is
potentially capable of would make the FPGA/CPLD options more suitable. Given
that you can actually buy an FPGA for
$20 that would be large enough for the 6526 emulation.
> Taking IDE64 as an example, the CPLD in it is $35.00 single quantity. A
> 52 pin SX or a 64 pin AVR is $15.00. The SX can go at 75MHz, which
> means one coulod emulate quite a bit in SW.
Available for even $2.10 (single quanity) (EPM3064ALC44-10) 10NS
Dave Ross
> I would be interested, but only if I could somehow get ahold of Dave Ross.
> It
> would be important to find out why it isn't still available somewhere. I see
> from
> the CBM hackers list, that he began talking quite a bit to Jeri about it.
> Perhaps
> he yanked the design for her to use in the C-1?
If only it were that good a reason.
The fact is that I'm cursed. The ISPs I have accounts with keep getting
bought out and I end up having to change my email & web addresses at
least once a year.
That's no longer an issue now that I bought my own domain (csixty4.com),
but it's going to take some time to get everything moved over.
> According to other messages by Dave Ross on comp.arch.fpga, he was unable
> to fit his design in a CPLD, did not have the TOD implemented yet, etc.. As
> I
> said, I would like to see how far he was able to get, but only if I could
> verify
> with him that it was OK to complete his work.
That sums it up pretty well. There were several revisions that I did
over a period of almost a year. The one on my web site is the best of
all of them.
My goal was to fit everything into a CPLD that cost around $30 at the
time (2001, I believe). Unfortunately, that didn't work out too well.
You might have better luck with a modern CPLD, but I would have had to
move up to an FPGA and that wasn't very cost-effective for making a
drop-in replacement.
The real kicker for me was trying to get an adapter board made for
putting in the original CIA socket. Someone suggested against using
header pins in place of DIP legs because they can ruin the grip of the
socket. But, my only other alternative was to have socket adapters
custom-made at about $50/ea.
The TOD shouldn't be too hard to add, but it needs a lot of real estate
for all the counters.
- Dave
Jim Brain
> Well, you can't really emulate 100% and an FPGA/CPLD would be more capable
> of emulating the chip.
Disagree. Code and enough I/O pins on a controller can emulate anything
digital, assuming the clock speed is high enough inside to run the code
fast enough.
> Now a PIC or an AVR and all would require other stuff to make it emulate
Uh, no. Well, not any more than an FPGA/CPLD, which is an adapter
socket. They require no external circuitry. All IO has selectable
High-Z, edge trigger, level trigger (hi or low), input/output, tristate,
internal pullups, etc.
> 100% or even at the level the FPGA is
> potentially capable of would make the FPGA/CPLD options more suitable. Given
> that you can actually buy an FPGA for
> $20 that would be large enough for the 6526 emulation.
>
>
>>Taking IDE64 as an example, the CPLD in it is $35.00 single quantity. A
>>52 pin SX or a 64 pin AVR is $15.00. The SX can go at 75MHz, which
>>means one coulod emulate quite a bit in SW.
>
>
> Available for even $2.10 (single quanity) (EPM3064ALC44-10) 10NS
Fine, but it's a 44 pin part. The ispLSI in IDE64 is 64 pins, and I was
trying to compare apples to apples pin-wise. An AVR AtMega128 has 53
pins...
I agree a CPLD makes more sense if you need 100MHz+ operation, as most
can operate into 400MHz. But, for a 1-10 MHz unit, I see a controller
as offering more options.
Take for instance the Dave Ross posting about the CIA TOD clocks taking
so much CPLD real-estate. It is true. Have to bunch up the macrocells
into counters. ON an Atmel, simply code them up in SW. You can have as
many as you want.
Things I was thinking of include:
Write a softCIA, which can turn into a completely different function on
write to a certain memory location. In essence, stuff a math
coprocessor into the CIA slot, accessible by writing a byte to a high
address in the address map of the CIA. It's a contrived example, but I
am sure other ideas may come up.
It's not that I don't see value in Scott's answer (synthesizable VHDL to
preserve the function...) I just see a controller offering the ability
to offer more functions at a low MHz in the same space for less money.
(I can implement a CIA and a coprocessor and something else with
constant cost, a CPLD requires more gates, thus more cost...)
However, it is one things to spout off about the idea, another to
actually implement it. So, I am ordering a handful of microcontrollers
to try things out.
JIm
Dave Ross
>>> Taking IDE64 as an example, the CPLD in it is $35.00 single quantity. A
>>> 52 pin SX or a 64 pin AVR is $15.00. The SX can go at 75MHz, which
>>> means one coulod emulate quite a bit in SW.
The SX chips are pretty capable, executing 1 instruction per cycle for
everything but jumps. But their internal oscillator only goes up to
4MHz, which is useless for something like this. You need an external
oscillator or R/C network to run it at a higher clock speed.
> Take for instance the Dave Ross posting about the CIA TOD clocks taking
> so much CPLD real-estate. It is true. Have to bunch up the macrocells
> into counters. ON an Atmel, simply code them up in SW. You can have as
> many as you want.
I see an advantage in the fact that programmable logic chips can work in
parallel, while microcontrollers are inherently serial. Everything you
do in one cycle of the 64's clock has to be done in a certain number of
cycles on the microcontroller. The more complex the simulation, and the
more features you add to the original design, the harder it is to do
everything in that window.
> It's not that I don't see value in Scott's answer (synthesizable
VHDL to
> preserve the function...) I just see a controller offering the ability
> to offer more functions at a low MHz in the same space for less money.
> (I can implement a CIA and a coprocessor and something else with
> constant cost, a CPLD requires more gates, thus more cost...)
If cost is your limiting factor, you could probably use two
microcontrollers and it would still cost less than a comparable CPLD.
> However, it is one things to spout off about the idea, another to
> actually implement it. So, I am ordering a handful of microcontrollers
> to try things out.
Be sure to let us know how it goes!
- Dave
Jim Brain
> microcontrollers and it would still cost less than a comparable CPLD.
Cost has always been a factor in this arena.
I like Scott's idea of a single chip 64. I would even burn one into a
FPGA if he gets it going.
My viewpoint is a bit different though. It seems many people don't have
an issue putting a new kernal in, buying an IDE64 or RR, but they won't
buy a C-1 or use an emulator for philosophical reasons. I see their
point. I would think a CPLD 64 would fit in this latter category.
Something about the soul of a 64 not being there.
Today, every user can either obtain a CIA/SID/CPU/etc. or has a donor
board with one. Someday, they will all be gone, and Scott/your HDL will
be needed.
Ironically, you can buy the AVR controller as coreIP HDL...
> Be sure to let us know how it goes!
It'll be a while. Haven't programmed controllers since the HC11 in 1993.
Rick Balkins
suitable for this task of a CIA.
Why emulate when you can make the FPGA/CPLD a CIA 6526 clone. Remember the
CIA was 40 pins.
BTW: The price isn't all that much different for a 100 pin or even 144 pin
part and it really doesn't matter.
If we want an even faster option, we can but the idea was to rebuild the CIA
so we would be able to have a CIA replacement part.
Heck, we can even make it support upto 230.4 Kbps if we really wanted to.
Point is, why worry about that. The idea was to have a
6526 replacement part while retaining compatibility with the original 6526
in case it becomes hard to find 6526s as they are no longer
produced.
I was giving price of the inexpensive parts and the 100 pin parts isn't much
more expensive either.
An FPGA can be set to whatever clock is needed.
"Jim Brain" <br...@jbrain.com> wrote in message
news:QWrac.41385$w54.274170@attbi_s01...
> Disagree. Code and enough I/O pins on a controller can emulate anything
> digital, assuming the clock speed is high enough inside to run the code
> fast enough.
>
> Uh, no. Well, not any more than an FPGA/CPLD, which is an adapter
> socket. They require no external circuitry. All IO has selectable
> High-Z, edge trigger, level trigger (hi or low), input/output, tristate,
> internal pullups, etc.
>
Scott McDonnell
Except for the simple fact that WDC wants "licensing." They don't
sell individual parts. They sell IP cores and production ICs,
but not to individuals. Either one requires a license with an estimate
on how many you plan to purchase in the first year.
Read WDC's instructions for ordering: Credit approval. Net 30 days
terms. $100 minimum order. Must have a signed, authorized
purchase. IOW, you must be a company.
The only "distributors" are for international customers. Thier terms are
the same. For USA orders, you deal directly with WDC.
Source: http://www.westerndesigncenter.com/NewPages/contactus.html
This is the same with Seirra Designs which I posted a link to in
another post. And at least Sierra Design has the 6510, 6522, 6526,
and 6502. The only cores they are missing is the VIC and SID cores.
But, again, they won't even talk to you unless you plan to purchase a
bunch of them for a new design.
The idea here is to create free IP cores, not commercial. Cores that are
open and will be availible hopefully long after I am dead. If WDC or SD
go out of business, guess what goes with them?
No business has any interest in preserving the C64. Once it is no longer
a profit maker for them, they would rather junk it than give it away. The
community is the only ones with a bonafide interest in preservation.
Scott
"Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote in
message news:106k7bc...@corp.supernews.com...
Scott McDonnell
> > Rick Balkins wrote:
> >
> > Now a PIC or an AVR and all would require other stuff to make it emulate
>
> Uh, no. Well, not any more than an FPGA/CPLD, which is an adapter
> socket. They require no external circuitry. All IO has selectable
> High-Z, edge trigger, level trigger (hi or low), input/output, tristate,
> internal pullups, etc.
Interesting and valid point.
> Take for instance the Dave Ross posting about the CIA TOD clocks taking
> so much CPLD real-estate. It is true. Have to bunch up the macrocells
> into counters. ON an Atmel, simply code them up in SW. You can have as
> many as you want.
Yes, I imagine it would. However, you probably already read that I wish to
place the TOD clock externally. This is because the TOD is failry useless
since it is not battery backed. Also, I could give a calendar function as
well
as someone else suggested.
In fact, I would like to move several of the features outside of the CIA.
Like
I mentioned, I am not shooting for a 'plugin' replacement chip. I am looking
at this from a "system" perspective. The different components of the HDL
set will be compatible with each other, and software compatible with a 64.
>
> Things I was thinking of include:
>
> Write a softCIA, which can turn into a completely different function on
> write to a certain memory location. In essence, stuff a math
> coprocessor into the CIA slot, accessible by writing a byte to a high
> address in the address map of the CIA. It's a contrived example, but I
> am sure other ideas may come up.
...but an interesting idea
>
> It's not that I don't see value in Scott's answer (synthesizable VHDL to
> preserve the function...) I just see a controller offering the ability
> to offer more functions at a low MHz in the same space for less money.
> (I can implement a CIA and a coprocessor and something else with
> constant cost, a CPLD requires more gates, thus more cost...)
Well, I think we are looking for a solution to two different problems,
actually. Nothing wrong with either of them.
Designing an entirely new motherboard/system offers me a lot of flexability
compared to designing components to work with the original motherboard.
As long as the software, when asking the right questions it gets the right
answers, it won't know the difference.
Maybe my aversion to using microcontrollers in a new motherboard design
is just that the vision of a board with 6 to 8 microcontrollers on it seems
kindy cheesy to me. Personal, aesthetic tastes, maybe.
>
> However, it is one things to spout off about the idea, another to
> actually implement it. So, I am ordering a handful of microcontrollers
> to try things out.
Awesome! I wish you the best of luck and look forward to seeing what
you come up with.
Scott
Scott McDonnell
news:bCqac.41807$JO3.30673@attbi_s04...
> Scott McDonnell wrote:
>
> > I would be interested, but only if I could somehow get ahold of Dave
Ross.
> > It would be important to find out why it isn't still available
somewhere. I see
> > from the CBM hackers list, that he began talking quite a bit to Jeri
about it.
> > Perhaps he yanked the design for her to use in the C-1?
>
> If only it were that good a reason.
>
> The fact is that I'm cursed. The ISPs I have accounts with keep getting
> bought out and I end up having to change my email & web addresses at
> least once a year.
Well, better that reason than the one I imagined! : )
>
> That's no longer an issue now that I bought my own domain (csixty4.com),
> but it's going to take some time to get everything moved over.
>
> > According to other messages by Dave Ross on comp.arch.fpga, he was
unable
> > to fit his design in a CPLD, did not have the TOD implemented yet, etc..
As
> > I said, I would like to see how far he was able to get, but only if I
could
> > verify with him that it was OK to complete his work.
>
> That sums it up pretty well. There were several revisions that I did
> over a period of almost a year. The one on my web site is the best of
> all of them.
Excellent. I am so glad you joined in this thread.
>
> My goal was to fit everything into a CPLD that cost around $30 at the
> time (2001, I believe). Unfortunately, that didn't work out too well.
> You might have better luck with a modern CPLD, but I would have had to
> move up to an FPGA and that wasn't very cost-effective for making a
> drop-in replacement.
Well, as you might have noticed, I am avoiding the whole drop-in
replacement idea because of the limitations. The idea is to design all
the chips so that they work together as a new system on a new
motherboard. When the entire project is complete, I will make
available board layout files, schematics, source code, etc.. so the
new system can be fully replicated by someone with the means.
If someone wants to take the source and make a drop-in
replacement, then I wish them the best of luck.
>
> The real kicker for me was trying to get an adapter board made for
> putting in the original CIA socket. Someone suggested against using
> header pins in place of DIP legs because they can ruin the grip of the
> socket. But, my only other alternative was to have socket adapters
> custom-made at about $50/ea.
I believe there are thinner header pins available for this purpose. Another
idea is to replace the sockets on the board with machine pin sockets.
These are much more durable and should accept standard header pins.
>
> The TOD shouldn't be too hard to add, but it needs a lot of real estate
> for all the counters.
Well, the plan is to use a regular battery-backed RTC module from
modern IC manufactures, typically for PC or embedded usage. This
allows setting the clock once and it will update itself when there is no
power. It also allows a calendar to be placed at a free register for
even more usefulness.
Basically, this means that I do not need to worry about how much
real estate it will use AND will result in a much more useful feature.
All I should need at most is an interface between the 6526 and the
RTC to reformat the data, or handle the RTC to retrieve and store
the data if necessary.
You can find a decent selection of these devices at:
http://www.maxim-ic.com/products/timers/real_time_clocks.cfm
Scott
Scott McDonnell
"Dave Ross" <wats...@ten.tsacmoc> wrote in message
> I don't have time to look at that link right now, but it probably has my
> old enteract.com web site.
>
> The current location is http://watsonc64.home.comcast.net/commodore.html
>
> I'll be moving that stuff to a more permanent home at csixty4.com soon
> (time permitting).
>
> You can go ahead and ignore the "licensing" terms on the VHDL 6526.
> I never synthesized it, so I don't know if it works -- although I remember
> it being pretty complete. VHDL turned out to be too expensive of a hobby
> for me at the time. I'd love to pick it up again one of these days.
Very generous of you! Thank you very much. Even if I do not use your code,
it will be an invaluable resource. I cannot tell you how much I appreciate
this.
BTW, VHDL is not that expensive nowadays. You can get development
boards from http://www.fpga4fun.com for as little as $60, this includes
programming cables, headers for jumpering into a design, and some
include tutorial components like switches and LEDs to help learn the
process.
You can also find used Devry eSoC boards sometimes on Ebay for around
$60. This is actually a pretty nice set-up.
Scott
Matthew Montchalin
|Cost has always been a factor in this arena.
|
|I like Scott's idea of a single chip 64. I would even burn one into a
|FPGA if he gets it going.
|
|My viewpoint is a bit different though. It seems many people don't
|have an issue putting a new kernal in, buying an IDE64 or RR, but they
|won't buy a C-1 or use an emulator for philosophical reasons.
If a good number of C-1 computers become available on EBay, or somewhere
in the real world if anywhere, I expect a fair number to sell. But a C-1
booklet guaranteeing some kind of a memory map for a particular FPGA core
is probably going to sell a whole lot more, especially if offered separately.
Rick Balkins
help you out in how to get the parts.
Don't freak out. You can still get the parts. Just order $100 worth of parts
as you would likely need that. First off, when you
order the parts, you would sign a sheet of paper but you don't necassarily
have to be a "company".
"Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in message
news:V_uac.142825$1p.1843744@attbi_s54...
> Rick,
>
> Except for the simple fact that WDC wants "licensing." They don't
> sell individual parts. They sell IP cores and production ICs,
> but not to individuals. Either one requires a license with an estimate
> on how many you plan to purchase in the first year.
>
> Read WDC's instructions for ordering: Credit approval. Net 30 days
> terms. $100 minimum order. Must have a signed, authorized
> purchase. IOW, you must be a company.
>
> The only "distributors" are for international customers. Thier terms are
> the same. For USA orders, you deal directly with WDC.
<<< snip >>>
Scott McDonnell
sell? I am not selling anything, we have the C-1 for that. If I develop
with the WDC or SD parts, then everyone that also wants to implement
the design has to jump through the same hoops, spend a minimum
$100 there, and we still have the issue whether WDC or SD will
still be in business 10 years from now.
Just my $.02
Scott
"Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote in
message news:106lp17...@corp.supernews.com...
Rick Balkins
"Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in message
> The point was: why would I bother unless I was making a product to
> sell? I am not selling anything, we have the C-1 for that. If I develop
> with the WDC or SD parts, then everyone that also wants to implement
> the design has to jump through the same hoops, spend a minimum
> $100 there, and we still have the issue whether WDC or SD will
> still be in business 10 years from now.
>
> Just my $.02
>
> Scott
They'll be around for awhile. Anyway, WDC has licensed cores that are used
in modern embedded systems as well and are more widely used then it was in
the 1980s but the funny thing is that we don't see it and what's more funny
is that they are embedded in chips that have a different number like one has
a custom controller with a 65c02 core but has a model number and chip
package that you wouldn't even recognize it as a 6502 but if you look into
the specs (it actually is).
The fact is that they are hidden and that we don't realize they are 6502
based controllers. Funny,eh ?
Scott McDonnell
Yep, I'm sitting here laughing about it as we speak. :)
Scott
Rick Balkins
"Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in message
> Yep, I'm sitting here laughing about it as we speak. :)
>
> Scott
The ironic part is that it is true and considering the level of licensing
and the number of licensees and the amount of units produced with those core
will lead to a fairly high number and including the number of years and the
fact that SO few 6502s actually fail. Mostly other components fail and the
6502 finds a new body to be put in. Fact is so many are around that it is
suprising. If one can actually count how many 6502 based microcontrollers
are produced, there is more of them produced each year then Intel CPUs.
John Moore
"Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in message
<snip>
> I expect a flamewar when I get to the SID and
> VIC chips, though. :( So, the 6510 is next.
Why not allow the ability to plug a original SID into your project?
Somebody else said something about the 'soul' of the 64 and IMO my 64 lost a
little of its when it's sid died. I replaced it (same model and rev no.)
but in the back of my mind it just dosent sound like MY c64 anymore... or it
could be the fact that I am now listening to it with a surround sound amp
rather than a crappy tv speaker!
> The ROMS will become flash memory and the RAM will become a single chip
SRAM
> chip. Perhaps once everything is completed, a single-chip C64 design would
> be done just to complete the portfolio.
Im non to bothered about the number of chips but if you can reduce the
motherboard by about 1/3 or even just 1/2 of a newer type borad then just
think of the possibilities (assuming there will be a reduced power
consumption). You could do so much. A c64 laptop, probably made from a
cannibalised PSOne with a ldc screen and a handbuilt keyboard. Or a c64
inside a 1514 (or 1541-II), or something small enough to sint ontop of one.
A in car C64! Or a c64 inside a NES case with a built in tape drive and/or
cart slot.
--
"I'm programmed to never perform any extraneous tasks."
Please change 'nospam' to jcom to reply.
----- http://jcom.shorturl.com ----
Matthew Montchalin
|The point was: why would I bother unless I was making a product to
|sell? I am not selling anything, we have the C-1 for that.
We don't have the C-1 for that *yet.* Unless you have some kind of
special information saying when it will be out. Do they even have
a real snail-mail (permanent) address yet?
|If I develop with the WDC or SD parts, then everyone that also wants
|to implement the design has to jump through the same hoops, spend a
|minimum $100 there, and we still have the issue whether WDC or SD
|will still be in business 10 years from now.
|
|Just my $.02
Could you please bottom-post when replying to Rick?
Six of DLoC
> "Six of DLoC" <sixSP...@darklordsofchaos.com> wrote in message
> news:Xns94BB521C2E5...@63.223.5.254...
>> "Scott McDonnell" <devi...@NOSPAMexcite.com> wrote in
>> news:SVO9c.119292$1p.1684256@attbi_s54:
>>
>> > OK, some of you already know that I have been working on a new C64
>> > motherboard. Well, the idea is also to rebuild the CSG/MOS chips in
>> > CPLDs and FPGAs so that I can simplify and shrink the design. Also,
>> > I do not wish to rely on hard to find parts (part of preserving the
>> > C64's future!)
>> Are you going to make your cores public domain?
>>
>> S.o.D.
>
> Six,
>
> I was replying with that info (in another post) while you were typing
> your question. But yes, sort of (how else could I claim to be
> "preserving" the C64?) I intend to offer up everything: schematics,
> source code, cores, etc..
Then I would like to offer my help in any way it is needed. I'm a firm
believer in that we will need to be able to implement the various chips in
our Commodores in FPGA or CPLD if we are to have replacements once the
originals are all gone. Also, I think the future of C64 expansion will be
in small chip-replacements that offer advanced features.
Paul Allen Panks
For a moment I thought you were discussing something else! ;-)
This sounds like a great project, by the way. A single-chip design for the
Commodore 64 remains a very attractive idea.
Sincerely,
Paul Allen Panks
dun...@yahoo.com
P.S. I received a response for one of the movie studios. Unfortunately,
they are unable to accept "pitches" for movie ideas. These must be done
through a script and movie agent. Oh well.
Sincerely again,
Paul
silverdr
> I like Scott's idea of a single chip 64. I would even burn one into a
> FPGA if he gets it going.
>
> My viewpoint is a bit different though. It seems many people don't have
> an issue putting a new kernal in, buying an IDE64 or RR, but they won't
> buy a C-1 or use an emulator for philosophical reasons. I see their
> point. I would think a CPLD 64 would fit in this latter category.
> Something about the soul of a 64 not being there.
You know? I am one of those that believe that even the 64c with narrow
board (new VIC and SID) is NOT a true C64. In fact some things work
different there as we know. Still I buy Scott's idea perfectly as long
as it is NOT going to be uC based _emulation_. I want the chips
preserved. Not their functionalities only. This I already have in VICE
and Co. I want a true hardware solution that can give me chip
replacements when I eventually run out of spares for my (only true ;-)
1985 version of the C64. I also want to be able to build anytime a (true
hardware) 64 on a small footprint mainboard. Thus I love the idea not
only "buy" it!
>
> Today, every user can either obtain a CIA/SID/CPU/etc. or has a donor
> board with one. Someday, they will all be gone, and Scott/your HDL will
> be needed.
>
That is.
silverdr
>
> That is what I meant by the control ports, yes. However, I was only planning
> at this moment to support the original digital sticks, since it seems most
> people
> prefer those on the Commodore equipment. Am I right about that?
>
I think so. I would sum this up as:
1. compatibility
2. economy
3. additional features
are priorities in that order.
If there would be a chance for componentisation that would allow e.g.
creation of EXACT chip replicas OR extended ones that would be probably
also great. I am not sure how much (if at all) of an overhead would this
be if done so that first EXACT replicas and then the versions with
additional extensions would be developed but I guess this would be my
preferred approach.
Scott McDonnell
"silverdr" <silv...@inet.remove.it.pl> wrote in message
news:406c64ec$1...@news.inet.com.pl...
> Scott McDonnell wrote:
>
>
> >
> > That is what I meant by the control ports, yes. However, I was only
planning
> > at this moment to support the original digital sticks, since it seems
most
> > people
> > prefer those on the Commodore equipment. Am I right about that?
> >
>
> I think so. I would sum this up as:
>
> 1. compatibility
> 2. economy
> 3. additional features
>
> are priorities in that order.
I share those priorities as well. That's why I will not focu on cost. Even
if it is
prohibitively expensive now, that will change in just a few years. The
ability
to make your own chips will not. At least as long as PLDs exist that do not
force an architecture on you. If the language changes, the code can be
ported.
However, if PLDs become microcontrollers with programmable hardware
attached, then we will unfortunately have to emulate. Although we see this
happening right now, I am hoping it will not completely take over any time
soon.
>
> If there would be a chance for componentisation that would allow e.g.
> creation of EXACT chip replicas OR extended ones that would be probably
> also great. I am not sure how much (if at all) of an overhead would this
> be if done so that first EXACT replicas and then the versions with
> additional extensions would be developed but I guess this would be my
> preferred approach.
Understood, and Rainer has convinced me of this as well. So, exact
chip replicas (in function) are the first models that will be developed. I
will be
sure to release these first and separately from any enhancements made. It
makes more sense, too. Having the exact replicas to begin with will allow
true compatability testing and easier troubleshooting. Once all that is
working,
then expansions can be made. I got delusional with all the possibilities for
enhancements when I began breaking the parts down and seeing what was
ultimately possible. So, 'back to BASIC'.
Scott McDonnell
P.S. I thought 'cybersquatting' was illegal? I just tried to look at the
availability
of www.back2basic.??? or www.backtobasic.??? and they are all sitting there
for sale ($2K-$3K!!!) Probably because this is similar to one of the slogans
for
a god-awful cigarette brand.
silverdr
>
> Understood, and Rainer has convinced me of this as well. So, exact
> chip replicas (in function) are the first models that will be developed. I
> will be
> sure to release these first and separately from any enhancements made. It
> makes more sense, too. Having the exact replicas to begin with will allow
> true compatability testing and easier troubleshooting.
That's exactly what I am about.
> Once all that is
> working,
> then expansions can be made.
That's it.
> I got delusional with all the possibilities for
> enhancements when I began breaking the parts down and seeing what was
> ultimately possible. So, 'back to BASIC'.
>
> Scott McDonnell
>
> P.S. I thought 'cybersquatting' was illegal? I just tried to look at the
> availability
> of www.back2basic.??? or www.backtobasic.??? and they are all sitting there
> for sale ($2K-$3K!!!) Probably because this is similar to one of the slogans
> for
> a god-awful cigarette brand.
Yeah... you always come to the Basic... Jim Beam!
I recall a very cogent ad from them in (AFAIR) the famous Sep'79 Playboy
issue (was it the last page?) with this slogan. It was so well targeted
(at me) that until today, whenever I buy a bottle of whiskey I always
look for this brand first... Good that at least I am aware how they got
me ;-)
Matthew Montchalin
|I think so. I would sum this up as:
|
|1. compatibility
|2. economy
|3. additional features
|
|are priorities in that order.
I kind of like it in reverse order.