C64 in PC using ISA
Ruud Baltissen
Jim Brain wrote:
> There used to be a 64 on an ISA card available. And, it would not be
> too tough to build one, but most people are loath to open their PC and
> install such a unit.
I have given this idea quite some thoughts in the beginning of the
90's. The core of my idea was to replace the 6510 by an interface that
on its turn fits in an 16 bits ISA-slot. I even draw a schematic to
find out that 50% was occupied by the I/O-port alone when using
discrete logic. Only much later I started thinking about using a real
6526 or a Z80-PIO.
But I never found a satisfying way to synchronise the ISA-bus with the
C64 that allowed to read a byte from a cartridge, process it and being
in time to get the next byte in time. Have a look at the next
instruction
$80FD sta $D000
and asume we have to read the last byte, $D0, of it. After the falling
edge of CLK2 I have to read the register that contains the data which
costs us one ISA-cycle and then I have to process it to see what the
C64-program wants.
Being the last byte of an instruction, I have to check for an IRQ, NMI
or RESET first, which means an ISA-cycle.
Then I have to present the 6510 bus with a new address ($D000), 16
bits in this case = 1 ISA-cycle.
The last thing I must do is to present the new data, another
ISA-cycle. I also have to alter the R/W bit but that can be a part of
this ISA-cycle as well.
Four cycles in total. With 8 MHz this means 500 ns., exactly 1 MHz.
But:
a) both the PAL and NTSC-C64 aren't 1 Mhz
b) I have no way to synchronise the clock of the PC with the one of
the C64
This means that I only can rely on three cycles: I am one short.
AFAIK the only solution is to use PCI that allows us an higher
throughput but that also means I need another technology like ASIC or
FPGA.
Hmmm, an idea that pops up just right now, 10 years too late: the data
only has to be valid in the last 250 ns. of CLK2. This means I still
can write it even when the upper half of CLK2 already has begun.
Your opinion/ideas, please.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
Phueque
machine that can even support an ISA card.
And why do away with a real 6510 if your not going to see a major
speed increase? Even back in the day the C64's biggest bottle neck was
the IEC serial drive access.
I would be more interested in something like a Commodore One as PCI
card.
On 16 Jul 2004 05:13:09 -0700, Ruud.Ba...@abp.nl (Ruud Baltissen)
wrote:
Rick Balkins
is a computer - and what I am talking about is putting the C64DTV onto a
plug-in board. All the PC-10 has to be and act like is - A: Be a keyboard
interface and B: Be a source for an HD (X1541????)
Plug in C= drives be nice and all AND be able run a cabling over to the
PC-10 and access the PC-10 drives via a X1541 kind of cable.
AS for execution of Commodore games and cartridges - LET the C64DTV do the
processing.
Just mere networking two computers via ISA in a sense. The C64DTV has its
OWN CPU processing. (Also the ISA would be a "powersource" for the C64DTV
and the ISA slot mainly be "keyboard interface" in a way. So the Terminal
Interface software would be to input the commands from the Keyboard into the
DTV keyboard/input buffer. This is what I am basically talking about.
As for your project - I'll look over and see what the idea I can come up
with.
"Ruud Baltissen" <Ruud.Ba...@abp.nl> wrote in message
news:8b0a868e.0407...@posting.google.com...
> Hallo allemaal,
Rick Balkins
"Phueque" <Phu...@evilwork.com> wrote in message
news:26pff0p0ofsi1b1q6...@4ax.com...
> At this point an ISA C64 card would be useless. I have only one
> machine that can even support an ISA card.
>
> And why do away with a real 6510 if your not going to see a major
> speed increase? Even back in the day the C64's biggest bottle neck was
> the IEC serial drive access.
>
> I would be more interested in something like a Commodore One as PCI
> card.
I was talking about a C64DTV ISA card.
The C64DTV has its own internal processing power. The internal chips on the
card doesn't have to be limited to the bus speed of the slot. The slot is
mostly for keyboard interfacing and power source.
I think the X1541 option would still be doable BUT I also think a similar
version of the card can be available via PCI as well. I want one for my
Commodore PC-10 and for my P4 PC.
Anyway - I would think this be a fun thing. I am not talking about C64 ISA
but C64DTV ISA.
Certainly it be interesting to see a C64 ISA or C64 PCI.
DEFINITELY a C-1 PCI.
Phueque
manufacture, even low numbers, and ISA card would be a waist.
I would rather see a USB or Firewire unit.
Right now I'm beating the bushes for Eithernet ISA cards fro my old
Tyan Tsunami motherboard because for a machine that old the only real
purpose is to be a server/ Router. It's the one thing that I can use
those 5 slots for without feeling like I'm compromising performance.
Phueque
over a 386?
At any rate... we're talking a VERY SMALL Market, and a if all it's
going to do is communicate keyboard and FauxIEC, might as well put it
on the USB bus, or better yet Firewire. I suspect at this point more
total machine have USB than ISA. Certainly more working machines.
Rick Balkins
> DId a PC10 have enough horsepower for that? I don't recall any C=PC
> over a 386?
>
> At any rate... we're talking a VERY SMALL Market, and a if all it's
> going to do is communicate keyboard and FauxIEC, might as well put it
> on the USB bus, or better yet Firewire. I suspect at this point more
> total machine have USB than ISA. Certainly more working machines.
>
The idea isn't a far stretch from a terminal emulator - OK.
ISA was in the Commodore PC-10.
Looked inside.
Mine had 640KB RAM.
NOT for "EMULATING" the C64. That is what the C64DTV is for. Second of all -
the Commodore PC-10 is 4.77 MHz 8088. Which is more faster than a C64. The
C64DTV would be handling its own processing. The Commodore PC-10 was used by
Commodore to diagnose the C64. In fact - if they can have an A64 emulator
for an Amiga - the PC-10 is more than capable of doing things of the sort.
Hell - there is absolutely and UTTERLY nothing that makes Star Commander too
hard for the Commodore PC-10 except that the code was compiled for a 286 and
not an 8086.
BTW: There is ISA based NICs.
Rick Balkins
> If it's for your self, sure... do what you want. But for any kind of
> manufacture, even low numbers, and ISA card would be a waist.
> I would rather see a USB or Firewire unit.
>
> Right now I'm beating the bushes for Eithernet ISA cards fro my old
> Tyan Tsunami motherboard because for a machine that old the only real
> purpose is to be a server/ Router. It's the one thing that I can use
> those 5 slots for without feeling like I'm compromising performance.
It has to be made by them. I don't have the legal authorization to make the
unit for one and if they made one - I would buy one. As I said - it can be
"low volume" (300 units) compared to the 1000s of C64DTV or 1000s of PCI
based C64DTV or whatever.
BTW: Google is your friend.
But here is a link:
http://www.computersurplusoutlet.com/showproduct.asp?C=11&s=55
Google Search link:
http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=ISA+Network+Cards
Rick Balkins
"Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
news:c8cbc925.04071...@posting.google.com...
> Or a USB-to-go unit, which was a peripheral for a PC but could be a
> master for a selected collection of USB things.
<<< snip >>>
> Instead of working to retain every part of old external interfaces,
> come up with external interfaces for old gear that let it work like
> the new gear when in 1MHz mode. But primarily it is running C64 games
> off of CD-ROMs, as well as the stuff you would normally use that kind
> of multi-CD player for.
All I was talking about is making the $35-38 unit in the ISA connector.
Hey putting it all on the ISA card would be cleaner. (Ok with the
connectors - it maybe some $50-60 unit.
Similarly priced for a PCI slot version too.
Jim Brain
> All I was talking about is making the $35-38 unit in the ISA connector.
>
> Hey putting it all on the ISA card would be cleaner. (Ok with the
> connectors - it maybe some $50-60 unit.
It's your opinion, and you are entitled, but a USB fob or parallel port
fob would be "cleaner", as:
No opening up machine to install
Board size could be smaller (ISA and PCI have board minimums)
ISA card wires would need a pigtail attachment, as DIN connectors will
not fit in ISA/PCI chassis slot without compromising structural
integrity of metal. (There's less than 1/8 inch left of width after DIN
width is subtracted)
ISA IO decoding and addressing is a bit tricky, as you need to ignore
DMA and tristate your data.
IO space is at a premium. Jumper would no doubt be needed to cover all
the possibilities.
Signals will be running around on your board at 8-10MHz (or more, as
some motherboards run ISA bus up to 16MHz...) At those speeds, PCB
traces become transmission lines. All bends must be rounded, or they
will radiate EMF. All unused pins must be tied to known state. AHC or
HC logic must be used to ensure adequate performance.
The cleanest solution in my mind is hacking Marko's C2N232 IEC support
or mine from my project to add keyboard decoding/encoding. Then,
interfacing with the unit would be easily done via RS232 (and you could
add a USB option for a few bucks...) No MHz bus or decoding to do, chip
costs would be < $10.00, board layout is simple and does not require an
edge connector (like ISA/PCI), nor standard sizing (like PCI/ISA).
Connector costs would still be needed, but unit would work in all PCs
(including your PC-10), including Macs and other types.
There's a reason why I am spending my time on an RS232 solution. I have
an ISA prototyping card here, and could easily implement your idea...
Jim
--
Jim Brain, Brain Innovations
br...@jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Rick Balkins
"Jim Brain" <br...@jbrain.com> wrote in message
news:wHZKc.100112$WX.72240@attbi_s51...
>
> It's your opinion, and you are entitled, but a USB fob or parallel port
> fob would be "cleaner", as:
> No opening up machine to install
> Board size could be smaller (ISA and PCI have board minimums)
> ISA card wires would need a pigtail attachment, as DIN connectors will
> not fit in ISA/PCI chassis slot without compromising structural
> integrity of metal. (There's less than 1/8 inch left of width after DIN
> width is subtracted)
I figure an small donggle then. I remember the DIN not fitting between the
brackets.
Which in fact I posted awhile back on C-One List on the Rev.0 board. A
dongle can be made for that issue.
> ISA IO decoding and addressing is a bit tricky, as you need to ignore
> DMA and tristate your data.
> IO space is at a premium. Jumper would no doubt be needed to cover all
> the possibilities.
Unless you can control it via software. There are software controlled jumper
switching. Of course - I have a NIC for ISA that is like that but this means
a second "microcontroller".
You know - this brings another idea. (In such I would prepare to use both
the RS-232 AND the Centronics Parallel port because I have a modem card in
the PC-10.)
Which I would replace in a heartbeat for a NIC or a FASTER modem or simply
an ISA RS-232 card with 1655xA card which will then be used as a gate
interface through my Cabletron Hub/router thinggy. (One of the MRXI models)
> Signals will be running around on your board at 8-10MHz (or more, as
> some motherboards run ISA bus up to 16MHz...) At those speeds, PCB
> traces become transmission lines. All bends must be rounded, or they
> will radiate EMF. All unused pins must be tied to known state. AHC or
> HC logic must be used to ensure adequate performance.
Well - true. The traces can be made smaller than classic ISA uses. They can
be nearly as thin or as thin as the PCI trace lines. Though the Centronics
can be moved up faster though. Plus one can use the RS232.
> The cleanest solution in my mind is hacking Marko's C2N232 IEC support
> or mine from my project to add keyboard decoding/encoding. Then,
> interfacing with the unit would be easily done via RS232 (and you could
> add a USB option for a few bucks...) No MHz bus or decoding to do, chip
> costs would be < $10.00, board layout is simple and does not require an
> edge connector (like ISA/PCI), nor standard sizing (like PCI/ISA).
> Connector costs would still be needed, but unit would work in all PCs
> (including your PC-10), including Macs and other types.
>
> There's a reason why I am spending my time on an RS232 solution. I have
> an ISA prototyping card here, and could easily implement your idea...
Hmmm.... interesting.
Dr. Bruce R. McFarling
> It's your opinion, and you are entitled, but a USB fob or parallel port
> fob would be "cleaner", as:
... yes ...
> The cleanest solution in my mind is hacking Marko's C2N232 IEC support
> or mine from my project to add keyboard decoding/encoding. Then,
> interfacing with the unit would be easily done via RS232 (and you could
> add a USB option for a few bucks...)
One point is, if its hacking Marko's C2N232 (which I just saw ... its
heaps cool), the C64 alike need not actually USE C2N format ... it
could
go straight to the fastloader format, with its system ROM using that
for device #1. So there is a gadget that lets a stock 64 work with a
fairly universal port, and the new unit has the port built in.
If the unit is upgraded so that it can be used as a general serial
port on the C64 side, that would be tops. The web page I found
indicated that was on the "to do" list, but I do not know how current
it is.
OK, I'll swap the Playstation faceplate connection back to User Port
B. There seems to be enough lines on the User Port to support a mode
1 IDE port and still bit bang the Playstation ports.
Peter van Merkerk
> There's a reason why I am spending my time on an RS232 solution. I have
> an ISA prototyping card here, and could easily implement your idea...
Keep in mind that RS232 ports are on the way out, just like parallel
ports. If you want to be future proof I think USB is the best bet. As
far as ISA card are concerned; try finding a PC that still supports
those, even in second hand PC's these things are becomming rare.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Jim Brain
> Jim Brain wrote:
> Keep in mind that RS232 ports are on the way out, just like parallel
> ports. If you want to be future proof I think USB is the best bet. As
> far as ISA card are concerned; try finding a PC that still supports
> those, even in second hand PC's these things are becomming rare.
I'm keeping it in mind. However, serial was chosen for the following
reasons:
It's easy to develop initial code for. I had to learn the IEC protocol,
no sense adding USB to the mix until I get one protocol understood
There are low cost ICs that will convert USB to RS232...
Once the initial work is complete, USB support should be
straightforward, though I will have to learn USB. USB is just another
flavor of serial interface.
Serial is more mature and easier to program from user space. USB
typically requires special drivers for various OS types
Older machines, which may be used for this project, don't have USB
If time should grow short, serial is still more prevalant. As Cameron
noted, they make USB to RS232 adapter cables and the cables support many
OS types...
I'm not deluded into thinking that RS232 is the best, but it fit the
criteria for the project, it's prevalant, it's available on older and
newer machines (newr machines might need a USB adapter...), it's easy to
develop for, and it's a known quantity, leaving my brain cells to tackle
the unknown land of IEC... My feeling is that once the IEC code is in
place, a quick weekend of work should produce a USB version.
Rick Balkins
"Peter van Merkerk" <mer...@deadspam.com> wrote in message
news:2m415nF...@uni-berlin.de...
> Keep in mind that RS232 ports are on the way out, just like parallel
> ports. If you want to be future proof I think USB is the best bet. As
> far as ISA card are concerned; try finding a PC that still supports
> those, even in second hand PC's these things are becomming rare.
True and tomorrow PC will not have NOT have ANY ports that the original PCs
have.
I think I said or hinted that I don't mind ANY USB stuff or PCI or any of
those new port interfacing for my P4 but I want something for my PC-10 and
keep the original motherboard and keep it as much Commodore as Commodore can
get. For example the C64DTV is still Commodore branded. So I don't mind the
C64DTV internal board. I think Jim Brain gets my idea. You may wonder - WHY
????
Because I like to use that PC-10 and it be something cool for it. The C64DTV
would essentially become the "keyboard" to the C64DTV AND be a storage/disk
drive for the C64DTV.
So with a RS-232 Serial KB interface + Centronics Parallel compatible X1541
cable for storage peripherals would sound like a nice idea. As for mouse,
there is a way for that too. I can stick a 65c22 onto an ISA for Mouses
anyway.
Rick Balkins
> I'm keeping it in mind. However, serial was chosen for the following
> reasons:
>
> It's easy to develop initial code for. I had to learn the IEC protocol,
> no sense adding USB to the mix until I get one protocol understood
> There are low cost ICs that will convert USB to RS232...
> Once the initial work is complete, USB support should be
> straightforward, though I will have to learn USB. USB is just another
> flavor of serial interface.
> Serial is more mature and easier to program from user space. USB
> typically requires special drivers for various OS types
> Older machines, which may be used for this project, don't have USB
> If time should grow short, serial is still more prevalant. As Cameron
> noted, they make USB to RS232 adapter cables and the cables support many
> OS types...
>
> I'm not deluded into thinking that RS232 is the best, but it fit the
> criteria for the project, it's prevalant, it's available on older and
> newer machines (newr machines might need a USB adapter...), it's easy to
> develop for, and it's a known quantity, leaving my brain cells to tackle
> the unknown land of IEC... My feeling is that once the IEC code is in
> place, a quick weekend of work should produce a USB version.
>
NOT to mention if you have any PCI slot than you can just buy yourself a
IEEE1294 card for the Parallel port (choose the right flavor of X1541 kind
of cable) and a 16551A card (Might be 16550A) aka RS232 card which will
solve the job. Of course you can run that. EITHER way, we just have to write
a RS232 Terminal Emulator to emulate the Commodore keyboard with the PC
keyboard. Then you also have a 64HDD or Star Commander kind of program for
the C64DTV to use your HD or Floppy Drives as a Commodore peripheral drive.
The above software features can be integrated into one program though.
MS-DOS doesn't "multi-task" but can "multi-thread".
Windows versions of the software can be made too for the different versions
of Windows. Then there is also Linux and the Unix flavors to make for too
the software and Mac.
I do become interested with the option and I believe the COM1 port in the
Centronics port can get the 12v power. The C64DTV is designed around a
battery operation I believe. Keeping the power down in the milliwatts so the
COM1 port could actually power the unit even on the ol' PC-10 and other PC
XTs. I recall the port was some 300 milliwatts. Typically like Commodore
64's User Port. Same basic specs. 300 milliwatt was standard for Modems.
That was the standard wattage modems run at and sometimes that was enough to
power it. I don't think Commodore gave much in terms of wattage anyway. The
typical power for the ports were like 50 to 100 milliwatts. From what I
remember.
Jim Brain
> solve the job. Of course you can run that. EITHER way, we just have to write
> a RS232 Terminal Emulator to emulate the Commodore keyboard with the PC
> keyboard. Then you also have a 64HDD or Star Commander kind of program for
> the C64DTV to use your HD or Floppy Drives as a Commodore peripheral drive.
> The above software features can be integrated into one program though.
Exactly. Although I understand your statement, a terminal emulator is
not needed per se. If the 64DTV keyboard support survives the cost
reducing that Tulip/Ironstone will be doing to ensure profit, the
resulting interface will be PS2 based. PS2 keyboard sequences are easy,
and can be accomplished with minimal code (PS2_KEY LEN SCAN_CODE
SCAN_CODE...) The code from my C=Key prj should be easy to adapt.
> MS-DOS doesn't "multi-task" but can "multi-thread".
I'd check your sources. DOS natively supports neither. DOS supports a
single execution path and a number of software interrupts. In any case,
threading/tasking is not needed here. Simply hook the serial IRQ and
the file IRQ and you are done.
> I do become interested with the option and I believe the COM1 port in the
COM should be plenty. I would not recommend gathering +5v from any PC
ports nowadays. It is tempting, but that's a very expensive Power
Supply to fry... A 9v wall wart and a 7805/10uF cap are well worth the
nominal cost. Now, an exception would be USB, which is designed to
source a couple hundred mA...
Rick Balkins
> Exactly. Although I understand your statement, a terminal emulator is
> not needed per se. If the 64DTV keyboard support survives the cost
> reducing that Tulip/Ironstone will be doing to ensure profit, the
> resulting interface will be PS2 based. PS2 keyboard sequences are easy,
> and can be accomplished with minimal code (PS2_KEY LEN SCAN_CODE
> SCAN_CODE...) The code from my C=Key prj should be easy to adapt.
The PC-10 doesn't have PS/2 but one can be mocked together. It is just
mocking the XT/AT interface and decoding them and emulating to C64 style key
code. (I would call it a key code translator. We in telecommunication world
calls this "terminal emulation". We take key code on the key code matrix of
the XT keyboard and translate it to the code used on the C64 for emulating
the C64 style keyboard for the C64DTV. Since the C64DTV would be acting like
the C64. Would this be correct. Like I said - it doesn't have to be a
"fancy" terminal emulation but the key scan code translation would be to
emulate the C64 style keys.
> I'd check your sources. DOS natively supports neither. DOS supports a
> single execution path and a number of software interrupts. In any case,
> threading/tasking is not needed here. Simply hook the serial IRQ and
> the file IRQ and you are done.
Technically - your right because multi-threading is done within a given
app/task.
MS-DOS is just a kernal/DOS like Commodore Kernal + DOS. The multi-threading
is simply based on the logic built into the actual "program" you run. OSs
don't "multi-thread" per se. It is within the given application/software. It
is like task switching on a timer. Cheesy way but MS-DOS would be just like
Commodore 8 bit in this sense. (I am not talking "literal" but am talking
what applications do based on the design.
> > I do become interested with the option and I believe the COM1 port in
the
> COM should be plenty. I would not recommend gathering +5v from any PC
> ports nowadays. It is tempting, but that's a very expensive Power
> Supply to fry... A 9v wall wart and a 7805/10uF cap are well worth the
> nominal cost. Now, an exception would be USB, which is designed to
> source a couple hundred mA...
Well - the PC-10 had +12v and -12v given to the port. (It uses the 25 pin
style connector.)
Here is the pinout from Appendix H
-------------------------------------
Pin Definition Serial Port: ( Pinout on the Computer side )
Computer Peripheral
Side Side
--- 1 Chassis GND ----
--- 2 TxD --->
<-- 3 RxD ----
--- 4 RTS --->
<-- 5 CTS ----
<-- 6 DSR ----
--- 7 SIG GND ----
<-- 8 DCD ----
--- 9 +12 V ----
--- 10 -12 V ----
--- 20 DTR --->
<-- 22 RI ----
Pin Definition for Parallel (Centronics compatible) port: (Computer side
pinout)
Computer Peripheral
Side Side
--- 1 Strobe --------->
--- 2 D0 ------------->
--- 3 D1 ------------->
--- 4 D2 ------------->
--- 5 D3 ------------->
--- 6 D4 ------------->
--- 7 D5 ------------->
--- 8 D6 ------------->
--- 9 D7 ------------->
<-- 10 ACK -------------
<-- 11 BUSY ------------
<-- 12 PE --------------
<-- 13 SLCT ------------
--- 14 AUTO FDXT ------>
<-- 15 ERROR -----------
--- 16 INIT ----------->
--- 17 SLCT IN -------->
--- 18-25 GND ----------
---------------------------------------------------------------
Here it is. I may suspect that the newer COM ports reduced the voltage.
So for what it is worth I may go with your suggestion of a simple PSU JUST
like an external modem.
Hook it up like the external modem. Besides - we can turn on and off the
unit.
Jim Brain
> The PC-10 doesn't have PS/2 but one can be mocked together. It is just
> mocking the XT/AT interface and decoding them and emulating to C64 style key
> code. (I would call it a key code translator. We in telecommunication world
> calls this "terminal emulation". We take key code on the key code matrix of
> the XT keyboard and translate it to the code used on the C64 for emulating
> the C64 style keyboard for the C64DTV. Since the C64DTV would be acting like
> the C64. Would this be correct. Like I said - it doesn't have to be a
> "fancy" terminal emulation but the key scan code translation would be to
> emulate the C64 style keys.
emulator is an incredible stretch...
In any case, you're misunderstanding the project. It matters not at all
what keyboard style the PC has, as it is not relevant. As well, you're
going on the premise that the C64DTV will accept 64 key codes (ala the
8x8 keyboard matrix on the 64...) The C64DTV, if it has a keyboard
connector pinout at all (which is not yet set in stone...), will be a
AT/PS2 style connector that understands a PS2/AT style keyboard.
So, all you have to do is generate valid AT keyboard codes. You can
generate them from anywhere...
while(-1 < (a=getchar())) {
switch(a) {
case 'a':
// 0x1c='A' scan code... 0xf0 = KEY_UP...
// A, KEY_UP, A is sequence...
send_to_serial(0x01c,0xf0,0x1c);
break;
case 'A':
// 0x12 is LEFT shift.
// SHIFT, A, KEY_UP, A, KEY_UP, SHIFT is sequence
send_to_serial(0x12,0x01c,0xf0,0x1c,0xf0,0x12);
break;
// etc...
}
}
Yes, you could hook the keyboard interrupt, and just pass the raw codes
along, but there are a number of issues with that:
Only works on PCs...
Can't be done very easily outside of DOS
Gets hooked before regular keyscan routine, so you need to deal with
Alt-Tab and such stuff yourself.
Precludes "keyboard stuffing" from an application... (Or, at least
makes it much harder to do...)
So, in the end, something like the above is best (No, I would not code
it exactly like that, but the proper way to code it takes too much space
for this post... If you want to see proper code, look at my C=Key prj,
as it does the same thing.
> Well - the PC-10 had +12v and -12v given to the port. (It uses the 25 pin
> style connector.)
Note that these are non-standard. According to EAI-232:
9 - Reserved for data set testing
10 - Reserved for data set testing
When you underake a project like this, you have to think of more than
your personal needs. You have a PC-10, so these pins would work for
you, but you'd be the lucky person who'd get it to work. I think that's
true of a lot of projects I've seen in here over the years. People
develop for their needs and environment only, and thus limit who can
utilize their project. Obviously, the other extreme is trying to please
everyone, but there is a happy medium...
Still, although the academic exercise was useful for me, it seems a tad
premature to work on a project to interface a non-existent unit to a PC.
If the required interface ports get cost reduced out of the 64DTV,
then this project will forever remain an academic exercise. If the unit
never materializes, the same is true.
I'm not saying don't archive this discussion, but there are a myriad
projects that do not lack key components that people could work on.
Dr. Bruce R. McFarling
> > There's a reason why I am spending my time on an RS232 solution. I have
> > an ISA prototyping card here, and could easily implement your idea...
> Keep in mind that RS232 ports are on the way out, just like parallel
> ports. If you want to be future proof I think USB is the best bet. As
> far as ISA card are concerned; try finding a PC that still supports
> those, even in second hand PC's these things are becomming rare.
Of course, Nintendo Entertainment System clones are also produced and
sold in vary large numbers. So the other way to future proof is to be
so cheap that you penetrate markets that the real computer makers
ignore.
Dr. Bruce R. McFarling
> The cleanest solution in my mind is hacking Marko's C2N232 IEC support
> or mine from my project to add keyboard decoding/encoding. Then,
> interfacing with the unit would be easily done via RS232 (and you could
> add a USB option for a few bucks...) No MHz bus or decoding to do, chip
> costs would be < $10.00, board layout is simple and does not require an
> edge connector (like ISA/PCI), nor standard sizing (like PCI/ISA).
> Connector costs would still be needed, but unit would work in all PCs
> (including your PC-10), including Macs and other types.
Of course, if it lived inside a keyboard, it would be the other way
around, pretending to be a PS2 keyboard when hooked up to the PC, and
the other
ports and brick on the wall come into play when you unplug it to take
it
home.
To me, though, considering the evolution of the dirt-cheap Famiclone
market (which seems to be where the idea for the retro computer inside
the game controller comes from), the most commercially important port
after something like the C2N232 would be a Joystick port 2,
so someone else can plug in and it can play 2 player games.
Dr. Bruce R. McFarling
> Signals will be running around on your board at 8-10MHz (or more, as
> some motherboards run ISA bus up to 16MHz...) At those speeds, PCB
> traces become transmission lines. All bends must be rounded, or they
> will radiate EMF. All unused pins must be tied to known state. AHC or
> HC logic must be used to ensure adequate performance.
If it was decided to have a "turbo" mode, but the intention was to
avoid adding major headaches to the design, would 4MHz then be a
better target than 8MHz or more?
I was also thinking of the strategy of having a new port that was
designed so it could be added to a stock C64, as opposed to the
tactic of duplicating all of the stock C64 ports, since so much
of the C64 *gear* is specialty items nowadays.
What I came up with was:
9 lines to match DB9 connector, straight through, bus master on
one side (the female connector, of course), bus slave on the
other side (the male connector).
Data line
Data clock
Control line
Control clock
/Select
IRQ
3v
9v
ground
The stock C64 interface:
Plug into user port, 2 connectors, a 9v input jack.
SP1, CLK1, SP2, CLK2, PB1 and PB2 as /SELECT for 1 and 2, PB3 and PA2
for the (polled) IRQ lines.
How it would work:
IDE - the Control line feeds an 8-bit serial-to-parallel part.
R/W - b7
/R - b5
/RESET - b7
/CS1 - b4
/CS0 - b3
A2 - b2
A1 - b1
A0 - b0
The Data line connects to a universal 16 bit shift register, and IRQ
connects to the IRQ line.
To write, have a byte with a R/W low and /R high in the control latch,
or put it out. Put two bytes out the Data line, then pull SELECT low.
The control lines go to the IDE, and the contents of the shift
register are written to the appropriate register.
To read, have or put the correct byte in the control latch, pull the
SELECT low, then drive the shift register with the data port in input
mode, reading off one byte for 8bit data and two bytes for 16bit data.
8 bit devices would be similar, just an 8bit shift register. So a
dongle with a buffered serial port could be attached to an external
modem to put the modem on one of the devices.
To put cheap non-volatile memory on the twin serial port, a circuit to
generate a start state for an 8pin serial flash one SELECT transition
high to low, and a stop state on SELECT transition low to high, put
the chip directly on the Data and Data Clock lines. Given 16Mbit
serial flash (2Mx8), it might not be necessary to even have a control
register.
Of course, its possible to just have an IDE connector on the dataport
by putting the low bye on SP1, the high byte on 1, Port B as the 8
required output lines and PA2 or FLAG2 as IRQ from the IDE. But then
you have an all lines connected DB25 cable and a bigger connector
sticking out the base of the computer-in-a-joystick.
Jim Brain
> To me, though, considering the evolution of the dirt-cheap Famiclone
> market (which seems to be where the idea for the retro computer inside
> the game controller comes from), the most commercially important port
> after something like the C2N232 would be a Joystick port 2,
> so someone else can plug in and it can play 2 player games.
Given the amount of ASIC space needed to support the second joyport, I'd
be extremely surprised if the 2nd joystick was not brought out on pads.
HOwever, I would doubt the cassette port would be present, and the
user port is suspect. I'd bet on the joystick port, the expansion port,
the keyboard port and the serial port.
Jim Brain
> Jim Brain <br...@jbrain.com> wrote in message news:<wHZKc.100112$WX.72240@attbi_s51>...
>
>
>>Signals will be running around on your board at 8-10MHz (or more, as
>>some motherboards run ISA bus up to 16MHz...) At those speeds, PCB
>>traces become transmission lines. All bends must be rounded, or they
>>will radiate EMF. All unused pins must be tied to known state. AHC or
>>HC logic must be used to ensure adequate performance.
>
>
> If it was decided to have a "turbo" mode, but the intention was to
> avoid adding major headaches to the design, would 4MHz then be a
> better target than 8MHz or more?
The context was an ISA card. When developing an ISA card, you do not
get to set the bus speed. The PC clocks the bus at 8-16 MHz. So, you
have to deal with the speed, even though you don't need it.
> I was also thinking of the strategy of having a new port that was
> designed so it could be added to a stock C64, as opposed to the
> tactic of duplicating all of the stock C64 ports, since so much
> of the C64 *gear* is specialty items nowadays.
Not to shoot down anyone's idea, but here are a few thoughts:
If you want a new port as you describe, you can get it with fewer pins.
Most newer controllers have an SPI (synchronous peripheral
interconnect) that only takes 4 wires (CLK,MISO,MOSI,GND) MOSI=master
out, slave in, MISO is the reverse..
It can transfer a byte on both directions at ~1Mhz or so, and all the
controllers I have seen support the exact same spec.
The standard can support a master with multiple slaves, but half duplex
only. The controller can provide the 8 bits and IRQ to the 64.
All that is needed is a packet format.
The code for this is trivial... If you want to experiment with this, I
can help you realize something.
If your goal is an IDE port on the 64, though, there's a reason IDE64
and such use the expansion port. The user port is just limited in what
it can do...
Dr. Bruce R. McFarling
> SP1, CLK1, SP2, CLK2, PB1 and PB2 as /SELECT for 1 and 2, PB3 and PA2
> for the (polled) IRQ lines.
This is ugly. I've been scratching at hypothetical dirt cheap PSX
interface code, and realised that there is a way to simulate the clock
using the DDR register that speeds things up a good way, which does
away with needing both DAT and CMD on the "outside edge" of the Port
B. So tidy that up to use the top half of Port B and PA2, and
allocate:
PB0: /SELECT1
PB1: IRQ1
PB2: /SELECT2
PB3: IRQ2
Two female DB-9 connectors for the twin serial links and one male DB-9
connector for the C2N232.
Of course, when you would most likely want to have the keyboard is the
same time you will most like want to have access to a modem, so one
serial port device could combine a PS2 keyboard port and an RS2323
interface. Then the other can talk to an IDE box that has a hard
drive and a CD-ROM, the C2N232 port can allow the PC to download files
to the joystick-C64, and a PSX memory card port is available for cheap
permanent storage.
Lance Lyon
> DId a PC10 have enough horsepower for that? I don't recall any C=PC
> over a 386?
I have (& still from time to time use) a Commodore P75 here.
cheers,
Lance
--
// Landover Amiga BBS
Australia's oldest Commodore & Amiga BBS
http://commodore.thebbs.org
telnet://commodore.thebbs.org //
Rick Balkins
"Lance Lyon" <ll...@commodore.thebbs.org> wrote in message
news:2meae6F...@uni-berlin.de...
>
> "Phueque" <Phu...@evilwork.com> wrote in message
> news:m0vif0dqg86t9jkfd...@4ax.com...
>
> > DId a PC10 have enough horsepower for that? I don't recall any C=PC
> > over a 386?
>
> I have (& still from time to time use) a Commodore P75 here.
>
> cheers,
>
> Lance
That's an ESCOM "Commodore" right ????
Dr. Bruce R. McFarling
> If you want a new port as you describe, you can get it with
> fewer pins. Most newer controllers have an SPI (synchronous
> peripheral interconnect) that only takes 4 wires
> (CLK,MISO,MOSI,GND) MOSI=master out, slave in, MISO is the reverse..
> It can transfer a byte on both directions at ~1Mhz or so, and all the
> controllers I have seen support the exact same spec.
Do you have a link for a version of that spec?
> The standard can support a master with multiple slaves, but half duplex
> only. The controller can provide the 8 bits and IRQ to the 64.
> All that is needed is a packet format.
> The code for this is trivial... If you want to experiment with this, I
> can help you realize something.
The serial link I was envisioning does not need a packet format and would not
demand very much intelligence at all on the slave side. A command byte is:
b7 - /RESET
b6 - /Write
b5 - /Read
b4 - /SelectB
b3 - /SelectA
b2 - a2
b1 - a1
b0 - a0
All bits high switches the MISO channel to device info, b3-b7 high,
b2-b1 not all high leaves the device passive.
Pull Data/Command low to put the command byte onto the MOSI channel.
Put out a byte. Pull Data/Command high, and then write out on the
MOSI line. That drives the clock for a read. Pull Data/command low
again to write the data, if the slave was in write mode.
Select0 and Select1 are the device select. Both low select the
device, while the inverse of select0 in is connected to select1
out and select1 in is connected to select0 out, so the second
device in the chain is selected with 01, the third device with
11, and the last device with 10.
> If your goal is an IDE port on the 64, though, there's a reason IDE64
> and such use the expansion port. The user port is just limited in what
> it can do...
How so? I have not looked at this for so long that I forget what
else inside the C64 shares the lines on the top of the User port,
but serial lines are as wide as the shift register on the other
side of the line, and more than enough control lines available via
PB7-PB0 for as many control lines as can fit into a DB9 straight
through cable. If the clock frequency is somewhere in the range
of 1-4 microseconds (250Khz ~ 1Mhz), that's good enough for
government work.
Jim Brain
> Do you have a link for a version of that spec?
Sure. Here's a vendor spec for SPI:
http://www.atmel.com/dyn/resources/prod_documents/doc2503.pdf
ATMega32 from Atmel. Others are similar. Look for SPI.
> The serial link I was envisioning does not need a packet format and would not
> demand very much intelligence at all on the slave side. A command byte is:
OK, you can use more pins and skip the packet format.
>>If your goal is an IDE port on the 64, though, there's a reason IDE64
>>and such use the expansion port. The user port is just limited in what
>>it can do...
>
>
> How so? I have not looked at this for so long that I forget what
> else inside the C64 shares the lines on the top of the User port,
> but serial lines are as wide as the shift register on the other
> side of the line, and more than enough control lines available via
> PB7-PB0 for as many control lines as can fit into a DB9 straight
> through cable. If the clock frequency is somewhere in the range
> of 1-4 microseconds (250Khz ~ 1Mhz), that's good enough for
> government work.
True, but using serial means you need some smarts on the other end (IDE
is parallel), whereas if you connect to the expansion port (ala IDE64),
you don;t need a controller on the IDE side.
Dr. Bruce R. McFarling
> True, but using serial means you need some smarts on the other end (IDE
> is parallel), whereas if you connect to the expansion port (ala IDE64),
> you don;t need a controller on the IDE side.
How intelligent is a shift register? I admit that it may need
something on the order of a 4x4 to 8x4 PROM to select the correct
shift register, but it would not need a controller.
Jim Brain
I just don;t think something as simple as a shift register is going to
mesh nicely with IDE. The shift register will get the data there, and
you've brought out the select and R/W lines, but it just seems to me
that there's more to it than that.
Although, I have not examined the ATS IDE spec in any detail, so maybe
it is that easy. Seems like if it was, they'd have made serial ATA a
lot sooner, as those big ribbon cables in a PC are a big problem size
and crosstalk wise.
Rick Balkins
have USB internal drives. (Solves the big ribbon solution for pre-Serial ATA
IDE computers.
"Jim Brain" <br...@jbrain.com> wrote in message
news:rBtNc.196792$Oq2.174952@attbi_s52...
> I just don;t think something as simple as a shift register is going to
> mesh nicely with IDE. The shift register will get the data there, and
> you've brought out the select and R/W lines, but it just seems to me
> that there's more to it than that.
>
> Although, I have not examined the ATS IDE spec in any detail, so maybe
> it is that easy. Seems like if it was, they'd have made serial ATA a
> lot sooner, as those big ribbon cables in a PC are a big problem size
> and crosstalk wise.
>
> Jim
I could have gotten by using a mini-DIN (8-pin) and gave the clock signal in
a similar fashion as was on the Serial Port on a C-128D.
Bingo - give yourself a reasonably fast serial protocol. Besides, the copper
wire will handle speed. (Just make sure each of the wires inside are
insulated wires). You can put a pretty fast wire signal. (Remember USB 2.0
uses 4 pins on 4 gold or copper wires.)
So just use that. Job done.
Now, have something USB like on 8 wires is reasonable by have the ability to
feed 3 streams instead of 1 stream. USB typically is as below:
Pin 1 +5V Red
Pin 2 -Data White
Pin 3 +Data Green
Pin 4 GND Black
-------------------------------------------------
My idea would be to go the following on a 8 pin mini-DIN:
Pin 1 +5v or 12v
Pin 2 Data (In Bi-D mode output)
Pin 3 Data (In Bi-D mode output)
Pin 4 Data (In Bi-D mode input)
Pin 5 Data (In Bi-D mode input)
Pin 6 Command Channel (Bi-directional) / Mode set
Pin 7 Clock (syncronous mode) - 1MHz~400 MHz
Pin 8 GND
In Unidirectional mode the 4 data lines would be set to the direction based
on the direction flag of a "Direction" register.
In Bi-D mode (upto 800Mbps per direction / 1.6 Gbps throughput)
In Uni-D mode (upto 1.6 Mbps on the given direction / 1.6 Gbps throughput)
Clock is for bus timing/sync.
Dr. Bruce R. McFarling
> I just don;t think something as simple as a shift register is going to
> mesh nicely with IDE. The shift register will get the data there, and
> you've brought out the select and R/W lines, but it just seems to me
> that there's more to it than that.
It depends on what kind of speed you are targetting. The SPI
interface
specification gave a clock of 1/4 the oscillator (in the C64, a 250KHz
clock, for a 4us frequency) citing reliability.
And this is just Mode 1, taken from a microcontroller oriented hack.
> Although, I have not examined the ATS IDE spec in any detail, so maybe
> it is that easy. Seems like if it was, they'd have made serial ATA a
> lot sooner, as those big ribbon cables in a PC are a big problem size
> and crosstalk wise.
Speed. Instead of LOAD/SAVE addr, you have:
1) toggle into command mode, download control byte
2w) toggle into data mode, download data, toggle command/data,
download data, etc.
2r) toggle into data mode, upload data, toggle command data, upload
data, etc.
You can't have a slow port between a fast hard drive and a fast
computer. There's no problem I can see having a slow port between a
fast hard drive and a slow computer.
Rick Balkins
connected to a fast computer.
"Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
news:c8cbc925.04072...@posting.google.com...
<<< snip >>>
Dr. Bruce R. McFarling
> Dr. Bruce R. McFarling wrote:
>
> > To me, though, considering the evolution of the dirt-cheap Famiclone
> > market (which seems to be where the idea for the retro computer inside
> > the game controller comes from), the most commercially important port
> > after something like the C2N232 would be a Joystick port 2,
> > so someone else can plug in and it can play 2 player games.
> Given the amount of ASIC space needed to support the second joyport, I'd
> be extremely surprised if the 2nd joystick was not brought out on pads.
> HOwever, I would doubt the cassette port would be present, and the
> user port is suspect. I'd bet on the joystick port, the expansion port,
> the keyboard port and the serial port.
Aha ... its the expansion port that I was not looking at including. If
you are going to go that far toward a full blown C64, why not just pop
it inside a PS2 keyboard and have the keyboard port internal? You'd
need to have them fabricate a run of bottom panels with the right
cutouts -- expansion port, AV ports, DC power connector, etc, but
in quantity that is no much more than just the standard PS2 kayboard
case. That's where you save the lines in the central FPGA and the
board.
And I don't see the point in bringing out the serial port ... its
a bad design for obsolete hardware, that is impossible to obtain in
some of your key markets for making substantial profits.
So this would be the pads for joy1, connected to the joystick that it
is inside, a set-up so that when the unit is on, the joystick port
is joystick2 in, and when the unit is off, the joystick port is
a dumb digital joystick, so that if people with two units meet, they
can turn one on, connect the two with a female-female straight through
DB9 cable, and play two player games.
And then a second DB9 (female, to avoid confusion) to bring out a
fast serial port.
As far as downloading games from a PC into the unit, I realised that
it would be plenty fast to just do it over the joystick port, "firing"
when a nybble is ready to be downloaded. The embedded firmware in
the unit would handle storing that in a slot in the serial flash.
That's the cheapest workable approach I can see.
Dr. Bruce R. McFarling
> What about a slow drive and a fast computer? Or a slow computer and
> a fast computer?
As long as the fast computer is the one with extra resources (normal),
why not?
Very few drives are that slow. Driving the clock at 1/4 osc is a
frequency of 4us or a raw bandwidth of 250Kbps -- that is, a tad over
60KBps.
With a stock C64, how much information do you want to transfer at one
go? With 64KB RAM, 60KBps is plenty fast. If we are going to
"assume" a high speed cartridge with massive memory, we may as well
"assume" that the user port is managed as a bidirectional parallel
port (possible, with an inbound and outbound latch and a fast enough
processor to keep up), which could be up to one byte every second
system clock -- 500KBps, or 4Mbps.
I'm looking at the C64 as the very simplest, slowest, and lowest
resource computer that proved out as a useful general purpose
computer, and therefore a way to get a VolksComputer sold in 3rd world
countries at a profit for less than the cost of shipping discarded
desktop PC's.
Jim Brain
> Aha ... its the expansion port that I was not looking at including. If
> you are going to go that far toward a full blown C64, why not just pop
> it inside a PS2 keyboard and have the keyboard port internal? You'd
Intended initial market is gaming, not typing. As well, packaging and
weight would drive the price up. (shipping costs)
> need to have them fabricate a run of bottom panels with the right
> cutouts -- expansion port, AV ports, DC power connector, etc, but
> in quantity that is no much more than just the standard PS2 kayboard
> case. That's where you save the lines in the central FPGA and the
> board.
You wouldn't save the lines. They'd still be needed, to run out to the
ports you describe.
> And I don't see the point in bringing out the serial port ... its
> a bad design for obsolete hardware, that is impossible to obtain in
> some of your key markets for making substantial profits.
The new trend in consumer gear is "hackability". Think TiVo...
Bringing out a pad is insignificant in cost, and even if they do bring
them out, they would NOT put the actual ports on... However, IF
enterprising consumers figure out how to interface existing serial or
expansion port peripherals to the unit, that could drive more sales, and
the pads suddenly drive profits. If nothing happens, there's little to
no risk.
> So this would be the pads for joy1, connected to the joystick that it
> is inside, a set-up so that when the unit is on, the joystick port
> is joystick2 in, and when the unit is off, the joystick port is
> a dumb digital joystick, so that if people with two units meet, they
> can turn one on, connect the two with a female-female straight through
> DB9 cable, and play two player games.
No, I doubt that. Again, don't expect the ports to be there. Just
internal printed circuit board non-silkscreened "pads". I assume games
will all be patched to use one of the joystick ports, and the other will
exist on the board as traces and pads. Again, an enterprising consumer,
provided the pads are there, could connect a DE-9 (B=25 E=9) connector
to them.
> As far as downloading games from a PC into the unit, I realised that
> it would be plenty fast to just do it over the joystick port, "firing"
> when a nybble is ready to be downloaded. The embedded firmware in
> the unit would handle storing that in a slot in the serial flash.
If the IEC bus is brought out, existing stuff like 64HDD and such would
work. Joystick would not, because how are you going to get the code to
use the joystick as a transfer port be loaded?
The cheapest workable approach for them is to not provide ANY ports...
It'll be like the other joystick units out there. battery cover,
joystick shaft, fire button, maybe a couple A/B buttons, cord with RCAs
for video/audio. Nothing more. Average consumer will plug in, play,
and that's it.
C.S.C. folks may grab a screwdriver and peer inside. They'll no doubt
see 2-3 SMD ICs. One will be the ASIC, another some ROM. A third maybe
for clock generation or something else that can't be easily suffed into
ASIC, but count on 2 ICs. They won't put the games on the ASIC, as that
would limit the ability to bring out a version with more or different games.
The last item is a suitable reason why, though Ironstone may not have
any need to bring out additional ports, they may go ahead and not cost
reduce them out of the ASIC. That way, the ASIC can be retargeted for
other products later on (a more expanded unit with keyboard, as you
initially noted...)
Obviously, I'm not them, and the above is taking the facts and applying
some logic, but I gathered that Ironstone has good business sense.
Rick Balkins
circuit board that converts the raw key signals to PS/2 with the computer.
If we go that far than we can go with a Terbium based computer (give it a
matter of months maybe a year). Then add video and sound and I/O (plus I/O
expansion slots).
"Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
news:c8cbc925.0407...@posting.google.com...
> Aha ... its the expansion port that I was not looking at including. If
> you are going to go that far toward a full blown C64, why not just pop
> it inside a PS2 keyboard and have the keyboard port internal? You'd
> need to have them fabricate a run of bottom panels with the right
> cutouts -- expansion port, AV ports, DC power connector, etc, but
> in quantity that is no much more than just the standard PS2 kayboard
> case. That's where you save the lines in the central FPGA and the
> board.
<<< snip >>>
Dr. Bruce R. McFarling
> Why worry if you can go straight from the ribbon. Replace the internal
> circuit board that converts the raw key signals to PS/2 with the computer.
> If we go that far than we can go with a Terbium based computer (give it a
> matter of months maybe a year). Then add video and sound and I/O (plus I/O
> expansion slots).
Fair point on the keyboard. I'm not sure what "then add video and
sound" means -- the FPGA cores to provide the VIC and SID functions
would be the video and sound, no?
Anyway, start adding adding features and then you wouldn't be able to
sell it for under $20 .. you end up flying past what an scaled down
emulation solution would cost and start pushing toward CommodoreOne.
OTOH, a C64-in-a-joystick would, as long as two can be linked together
for two-player gaming, put a big dent in the 3rd world Nintendo
Entertainment System clone market. If it could be expanded into an
operational system for as little extra as possible, millions would be
sold.
But only if you hit the price point. No matter how nifty the
features, if the price point is around $50 you are throwing away more
than half the potential market.
Dr. Bruce R. McFarling
> The cheapest workable approach for them is to not provide ANY ports...
> It'll be like the other joystick units out there. battery cover,
> joystick shaft, fire button, maybe a couple A/B buttons, cord with RCAs
> for video/audio. Nothing more. Average consumer will plug in, play,
> and that's it.
If they aren't interested in the biggest part of the potential
market, sure. But there is no way to undercut Famiclones in
the 3rd world, there has to be a feature benefit. And the
single biggest feature benefit to go for is 2 player gaming.
In developed country markets, its not as big a deal, but its
a much smaller market niche in developed countries. These
"minimum order 2,000 units" shipments are not mostly going
to Europe or North America!
And after all, some of the more popular new Famiclone units out
there ARE more than joypad and buttons, they include two pads, or
a combined gun / joypad controller.
Dr. Bruce R. McFarling
> Not to shoot down anyone's idea, but here are a few thoughts:
> If you want a new port as you describe, you can get it with fewer pins.
> Most newer controllers have an SPI (synchronous peripheral
> interconnect) that only takes 4 wires (CLK,MISO,MOSI,GND) MOSI=master
> out, slave in, MISO is the reverse..
> It can transfer a byte on both directions at ~1Mhz or so, and all the
> controllers I have seen support the exact same spec.
> The standard can support a master with multiple slaves, but half duplex
> only. The controller can provide the 8 bits and IRQ to the 64.
> All that is needed is a packet format.
The fourth pin is not GND, its /SlaveSelect ... its "GND" if the /SS
is always selected.
Its when I saw the SPI spec in the Amtel micrcontroller that I
recognised this from somewhere else ... its the Playstation
controller/memory card interface, except without the power lines and
with one select line rather than two.
Upside is, it is based around a single shift register (that is, as the
outbound info is shifting out, the inbound info is shifting in).
Downside is that ... well, it is based around a single shift register.
(1) Separate downstream data and command shift registers allows the
packet format to be replaced by bringing the command shift register
into play. (2) Seperate downstream data and command shift registers
means that there is no need to count up to 8 and say "job done", which
frees it to have the data as wide as need be.
In any event, its two distinct registers in the C64, since the two
serial port lines are connected to two distinct CIA registers, rather
than being the top and bottom bit of a single shift register. That
gives the freedom to go either way.
I did not realise that the Playstation interface was an example of
such a common interface. I'll look again at how hard it is to put an
IDE port on the other side of the conventional SPI. Since the C64
DOES HAVE two separate registers for input and output, it may be that
a simple state machine and two shift registers on the IDE side can do
the job done by toggling the Command/Data line in the approach I
sketched out earlier.
Rick Balkins
"Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
news:c8cbc925.04072...@posting.google.com...
> As long as the fast computer is the one with extra resources (normal),
> why not?
>
> Very few drives are that slow. Driving the clock at 1/4 osc is a
> frequency of 4us or a raw bandwidth of 250Kbps -- that is, a tad over
> 60KBps.
Most Commodore drives due to the slowness of the spinning disks and the
speed of the heads - data was often limited to some 8KBps. (60KBps would
literally mean that you could transfer the content of a disk side of a 1541
disk in about 3 seconds. Commodore protocols were nowhere near that and
Commodore disk drives as well as most floppy drives were slow.
In fact 60 KBps is about as fast as most Commodore serial drives EVER get
short of the CMD HD drives.
> With a stock C64, how much information do you want to transfer at one
> go? With 64KB RAM, 60KBps is plenty fast. If we are going to
> "assume" a high speed cartridge with massive memory, we may as well
> "assume" that the user port is managed as a bidirectional parallel
> port (possible, with an inbound and outbound latch and a fast enough
> processor to keep up), which could be up to one byte every second
> system clock -- 500KBps, or 4Mbps.
With a cartridge - you use the expansion port typically due to address line
requirements.
Flash "Disks" (Compact Flash for example) - User Port is doable BUT you will
want to treat the 8 bit parallel like you were communicating with an REU
except you are not dealing with "address lines" but simple 1 MHz AND 8 bit
parallel data transer. This would give you about 1 Megabytes per second or 8
Mbps. ONLY problem will be in the CPU executing the transfer instructions in
a 1:1 ration. (So the CPU won't be a bottleneck here). So you will likely
need a SuperCPU to process the transfer instructions and move the data to
the expansion port fast enough.
Reason for my concern = X number of CPU clock cycles per transfer
instruction execution.
I recall it be some 2-8 cycles to perform such as a minimum. 1 MHz CPU @ 2-8
cycles for transfer of a byte = transfer rate max of 125,000 bytes - 500,000
bytes per second. (122/123 KBytes per second -> 488/483 Kbytes per second)
This would be without assistance of DMA.
> I'm looking at the C64 as the very simplest, slowest, and lowest
> resource computer that proved out as a useful general purpose
> computer, and therefore a way to get a VolksComputer sold in 3rd world
> countries at a profit for less than the cost of shipping discarded
> desktop PC's.
Also C64 was back in 1982.
The first PC barely had 8 bit bus max performance of 4-8 MHz. (You had to
divide total bandwidth by the number of slots if you were to use all the
slots.)
Typically - you can only directly communicate with one slot at a time.
(Typically 5-8 slots)
Rick Balkins
> Fair point on the keyboard. I'm not sure what "then add video and
> sound" means -- the FPGA cores to provide the VIC and SID functions
> would be the video and sound, no?
In fact - you could integrate off the digital features into one chip. My
point is you have to replace the core components than put a Terbium CPU and
add the "video/sound and I/O" into the system. You could put all that into
one FPGA/ASIC or use a microcontroller that does all that. Ok an option -
you take keyboard controller chip and ribbon socket and the components and
add them in so you don't have to worry about converting raw key code but
just convert the PS/2 signals without needing a "PS/2 port connector". You
can just take the signal lines that would otherwise go down long wires and
bring them directly to your FPGA (having a hot "virtual" PS/2 port -
technically its physical but not wasting space with excess plastic and
all".) The video/audio does require outputting to some sort of analog such
as a monitor/speaker respectfully. You will need to have Video DAC(s) and
Sound DAC(s). That is not handled via FPGA. (You could use FPAA for this if
you need programmable DACs.) FPAA is Field Programmable Analog Array (which
does for the Analog world what FPGA does for Digital). This is why there are
DACs in the C-One. For converting FPGA digital signals into actual sound
signals. Or handling the individual R,G,B, settings for the video signals.
> Anyway, start adding adding features and then you wouldn't be able to
> sell it for under $20 .. you end up flying past what an scaled down
> emulation solution would cost and start pushing toward CommodoreOne.
>
> OTOH, a C64-in-a-joystick would, as long as two can be linked together
> for two-player gaming, put a big dent in the 3rd world Nintendo
> Entertainment System clone market. If it could be expanded into an
> operational system for as little extra as possible, millions would be
> sold.
Technologically it does (well the prototype ASIC) does. Just a matter of
programming the built in ROM. (where would you think the 30 games are
stored) I am basing on info that have been received from some credible
sources. The consumer version may not have the "ports" physically there but
I doubt they can make much difference in price by removing the solder-pads
since the board would be small as is. You could bypass even that and go
direct to pin and provide any of the resistors/glue components and that sort
of stuff yourself. Then bridge that in right at the pins themselves.
(Technically easier to have the solder-pads so you can just add the physical
connectors. You save more just removing the physical connectors than a few
inches x few inches of the PCB being slightly smaller.
> But only if you hit the price point. No matter how nifty the
> features, if the price point is around $50 you are throwing away more
> than half the potential market.
You would be selling both versions as individual products. The version with
the ports and all would be say eC64DTV (e=extended/enhanced) with the
additional ports at say $50 USD where the lower price c64DTV would be
without the ports and be say $35-40 USD. These would be sold as seperate
products but are essentially the same base product but the eC64DTV would be
a more extended version with the extended features. NOTE of DISCLAIMER: The
eC64DTV is not an actual product but a theoretical version of the C64DTV
with the ports and this paragraph should be considered on basis of theory.
This is ENTIRELY based on my ideas and is NOT to be "expected" but who knows
anything can happen. I know enough that Tulip people do watch and may look
at the ideas and possibly consider it as two individual products. This way
and they can get BOTH markets. By providing both versions with slight name
changes. Marketing wise - those who will by cheap - by the cheaper versions
and the geekier ones of us would by the more pricier/enhanced versions and
get both customers. Where the geekier ones of us would consider spending $50
if it had the ports but not spend any money if it didn't. Some of us who
would be interested in possibly programming for the c64DTV platform would
want the ports and all. So for $50. Hell - I be willing to spend as much as
$99 for the version with ports and developer software and the sort. Either
way, you get the general idea and it be nice to develop for. As I see it - I
go for that ANY day.
Dr. Bruce R. McFarling
> > OTOH, a C64-in-a-joystick would, as long as two can be linked together
> > for two-player gaming, put a big dent in the 3rd world Nintendo
> > Entertainment System clone market. If it could be expanded into an
> > operational system for as little extra as possible, millions would be
> > sold.
> Technologically it does (well the prototype ASIC) does. Just a matter of
> programming the built in ROM. (where would you think the 30 games are
> stored).
I would think on a serial flash. When I am talking about chips on the
bus, its because that's the only way I can think through it ... obviously
all those parts are either on a single ASIC or hard burned into a
single FPGA.
I am basing on info that have been received from some credible
> sources. The consumer version may not have the "ports" physically there but
> I doubt they can make much difference in price by removing the solder-pads
> since the board would be small as is. You could bypass even that and go
> direct to pin and provide any of the resistors/glue components and that sort
> of stuff yourself. Then bridge that in right at the pins themselves.
But that is hobbyist stuff. The number one big opportunity in the
bigger of the two markets is something that is automatically a two
player set up if two people with their one-player units meet up.
The number two big opportunity is if you can download games into
the unit ... obviously you have taken care of proper IP for the
games that come included, but if people in a 3rd world country get
a CD Rom full of C64 disk images and software to download any of
those games into a unit for a fee, that guarantees the stocking
of the units about as far as the electric grid reaches. If the
hardware is a single ASIC or FPGA and a serial flash chip, plus
lines to a DB9 connector, battery case, power input plug, and AV plug,
the extra cost of wiring up the DB9 port connector is more than paid
for by the substantial features boost compared to the standard $20
Famiclone in a controller that currently dominates 3rd world video
game markets.
> You would be selling both versions as individual products. The version with
> the ports and all would be say eC64DTV (e=extended/enhanced) with the
> additional ports at say $50 USD where the lower price c64DTV would be
> without the ports and be say $35-40 USD.
That's locking yourself out of the biggest markets on offer, and
restricting it to retro gaming in the 1st world.
Jim Brain
> I would think on a serial flash. When I am talking about chips on the
> bus, its because that's the only way I can think through it ... obviously
> all those parts are either on a single ASIC or hard burned into a
> single FPGA.
ASIC, cheaper. And you can think of it as flash, but I believe (for the
speeds we are talking), Masked ROM is still cheaper, so I suspect you'll
see ROM. However, if it is FLASH, that's all the better...
> But that is hobbyist stuff. The number one big opportunity in the
> bigger of the two markets is something that is automatically a two
> player set up if two people with their one-player units meet up.
> The number two big opportunity is if you can download games into
> the unit ... obviously you have taken care of proper IP for the
Possibly, but look at it this way.
64DTV comes out as is, and is a big hit in the retro market. Ironstone
then can recoupl cash and come out with an expanded unit like you
describe. Retro gamers would probably buy the enhanced unit even though
they have the original.
It's a common business practice to not put all the goodies in version 1.
That way, there is the option of version 2. Given your third world
analogy, I would think there is plenty of time to bring out 64DTVv1,
reap some cash, add the options you describe, bring out v2, reap some
more cash, and use the buzz from v1 as a marketing tool in those
countries to drive sales.
> That's locking yourself out of the biggest markets on offer, and
> restricting it to retro gaming in the 1st world.
Why think of this product as a one time deal? Why not think of it as a
franchise, with enhanced products coming out for a couple years? I
don;t see how they will lock themselves out of a market they are not
sure even exists. As a business owner, I'd rather target the retro
gamers and the novelty buyers in civilized nations first, grab some
cash, and then work on newer/expanded products.
Without ports on the unit, FCC signoff is much easier, and cost is
pretty much bare-bones. If you were bringing this into a market and
were not sure of success, I think you'd go a bit safe too.
I agree with Rick. v1 will be basic unit, and there may be a v2 with
additional functionality, if the market demands and can sustain it.
JIm
Rick Balkins
> I would think on a serial flash. When I am talking about chips on the
> bus, its because that's the only way I can think through it ... obviously
> all those parts are either on a single ASIC or hard burned into a
> single FPGA.
I was talking about the Tulip/Commodore C64DTV. Ok, there may be a serial
flash to contain the ASIC hardware core but as for the built in software
where the games are stored - this can be a standard Flash ROM with standard
data/address bus access.
> I am basing on info that have been received from some credible
> > sources. The consumer version may not have the "ports" physically there
but
> > I doubt they can make much difference in price by removing the
solder-pads
> > since the board would be small as is. You could bypass even that and go
> > direct to pin and provide any of the resistors/glue components and that
sort
> > of stuff yourself. Then bridge that in right at the pins themselves.
>
> But that is hobbyist stuff. The number one big opportunity in the
> bigger of the two markets is something that is automatically a two
> player set up if two people with their one-player units meet up.
> The number two big opportunity is if you can download games into
> the unit ... obviously you have taken care of proper IP for the
> games that come included, but if people in a 3rd world country get
> a CD Rom full of C64 disk images and software to download any of
> those games into a unit for a fee, that guarantees the stocking
> of the units about as far as the electric grid reaches. If the
> hardware is a single ASIC or FPGA and a serial flash chip, plus
> lines to a DB9 connector, battery case, power input plug, and AV plug,
> the extra cost of wiring up the DB9 port connector is more than paid
> for by the substantial features boost compared to the standard $20
> Famiclone in a controller that currently dominates 3rd world video
> game markets.
Remember ModemWars and Null Modeming two C64s together. Same principle can
be made.
Like I said the "conceptual" eC64DTV would be having ports which would
indeed allow for two players to be tied in like that via RS-232 cross-over
cabling.
> That's locking yourself out of the biggest markets on offer, and
> restricting it to retro gaming in the 1st world.
Why would it ????? The C64 already have duel computer gameplay capability
and if you have an RS-232 compatible port - you would be able to do that.
All that needs to be done is games being written to support such. The idea
would be a system that supports various market places. All that needs to be
done in a dual player game is one acts as server+player while the other acts
a player and just need a port to pass the info back and and forth.
If you have the hardware - you got the possibilities. Having two models that
are available. Ok the "conceptual" eC64DTV would be an idea to support the
dual player and serve the audience that would be interested in such but
there are some that will be just dirt cheap but you have varying markets.
Besides, Nintendo was selling the GB Advance while they were selling the GB
Color. The C64DTV is a toy and so would the "conceptual" eC64DTV. They
market as toys. If the eC64DTV sports say 16-Bit mode and say 12-BIT or
16-BIT video support. That be cool. While being backward compatible. It
would be like Apple IIe was to Apple II. Ok. I don't see any limiting. Just
how you do your advertisements.
None of these are necassarily "intended" to be all in all "revolutionary"
nor intended to sell for a 10 year figure. Being that these are toys and
would be marketed more like that. It is more likely that you can expect
significant sales if you take the right outlet for example Toys'R Us. I am
not concerning myself entirely on the advertising. Besides - no one person
makes a good advertisement despite the credit often going to someone who may
make the main concept of the advertisement but it takes a few others
suggestions that refines it. God crafts the stone but it often take someone
else to polish it. :-)
Rick Balkins
> Dr. Bruce R. McFarling wrote:
>
> > I would think on a serial flash. When I am talking about chips on the
> > bus, its because that's the only way I can think through it ...
obviously
> > all those parts are either on a single ASIC or hard burned into a
> > single FPGA.
> ASIC, cheaper. And you can think of it as flash, but I believe (for the
> speeds we are talking), Masked ROM is still cheaper, so I suspect you'll
> see ROM. However, if it is FLASH, that's all the better...
ASIC is for the "hardware" but Flash is likely for containing the games.
The ASIC is for you CPU/Video/Sound & I/O while the FlashROM is used to
store the games and ROM code. (Like a ROM cartridge in which you can bank in
30 ROM games or the sort.)
There got to be some place to store the games. The ASIC just ain't for
storing them.
> > But that is hobbyist stuff. The number one big opportunity in the
> > bigger of the two markets is something that is automatically a two
> > player set up if two people with their one-player units meet up.
> > The number two big opportunity is if you can download games into
> > the unit ... obviously you have taken care of proper IP for the
> Possibly, but look at it this way.
>
> 64DTV comes out as is, and is a big hit in the retro market. Ironstone
> then can recoupl cash and come out with an expanded unit like you
> describe. Retro gamers would probably buy the enhanced unit even though
> they have the original.
>
> It's a common business practice to not put all the goodies in version 1.
> That way, there is the option of version 2. Given your third world
> analogy, I would think there is plenty of time to bring out 64DTVv1,
> reap some cash, add the options you describe, bring out v2, reap some
> more cash, and use the buzz from v1 as a marketing tool in those
> countries to drive sales.
Actually the enhance version is my idea sort of and I like to see that
happen. As for the principle - you state it like I was intending and the
heart of the principle.
> > That's locking yourself out of the biggest markets on offer, and
> > restricting it to retro gaming in the 1st world.
>
> Why think of this product as a one time deal? Why not think of it as a
> franchise, with enhanced products coming out for a couple years? I
> don;t see how they will lock themselves out of a market they are not
> sure even exists. As a business owner, I'd rather target the retro
> gamers and the novelty buyers in civilized nations first, grab some
> cash, and then work on newer/expanded products.
This is what is the principle of many other ideas that I have provided and I
don't think Commodore International B.V. should lock itself like Commodore
did too deeply. They need to be flexible and build a "strong diversified"
business/market. This take time but you must take small steps first. Walk
before you run. I am well into the supporting factor. I don't say Commodore
should forsake their heritage but that must be where you start. This is what
Commodore is remembered but then expand into new directions. This is where I
call for a bridge. There has been a 10 year period so we expect to make a
little larger step because there is a wide river of time in between so we
need connection but we must build the bridge on both sides and connect the
middle - but proceed forward with the roads while the bridge is being built.
The past road had been built but the future road must be paved while we
build the bridge in between. This is called multitasking and that is what
Commodore must do. The bridge must be built quickly so people can get across
as soon as possible. Thankfully we already built the islands in between.
(Yes I use alot of metaphors here but you can take a little bit of
imaginations but many of us already used row boats to get across. The bridge
is so you don't have to take the ferry)
This may take a little explaining but maybe its just getting to late to
really explain it out.
> Without ports on the unit, FCC signoff is much easier, and cost is
> pretty much bare-bones. If you were bringing this into a market and
> were not sure of success, I think you'd go a bit safe too.
>
> I agree with Rick. v1 will be basic unit, and there may be a v2 with
> additional functionality, if the market demands and can sustain it.
Hehehe, yep.
I would buy the expanded version as well. Those at Tulip who do keep an eye
on me - yes I would. :-)
Dr. Bruce R. McFarling
> > need to have them fabricate a run of bottom panels with the right
> > cutouts -- expansion port, AV ports, DC power connector, etc, but
> > in quantity that is no much more than just the standard PS2 kayboard
> > case. That's where you save the lines in the central FPGA and the
> > board.
> You wouldn't save the lines. They'd still be needed, to run out to the
> ports you describe.
What I meant here was ...
| /I/O1 | 7 | I/O block 1 @ $ DE00-$DEFF (active low) unbuffered I/O |
| /GAME | 8 | active low ls ttl input |
| /EXROM | 9 | active low ls ttl input |
| /I/O2 |10 | I/O block 2 @ $DF00-$DFFF (active low) buff'ed ls ttl |
| /ROML |11 | 8K decoded RAM/ROM block @ $8000 (active low) buffered |
| | | ls ttl output |
| BA |12 | Bus available signal from the VIC-II chip unbuffered |
| | | 1 Is load max. |
| /DMA |13 | Direct memory access request line (active low input) |
| | | ls ttl input |
| /ROMH | B | 8K decoded RAM/ROM block @ $E000 buffered |
But if the 65C02, CIA's, VIC, SID, and memory configuration is all in the
same package as the 92K RAM, you would also save:
| D7 |14 | Data bus bit 7 \ |
| D6 |15 | Data bus bit 6 + |
| D5 |16 | Data bus bit 5 | |
| D4 |17 | Data bus bit 4 +- unbuffered, 1 ls ttl load max |
| D3 |18 | Data bus bit 3 +- |
| D2 |19 | Data bus bit 2 | |
| D1 |20 | Data bus bit 1 + |
| D0 |21 | Data bus bit 0 / |
| A15 | F | Address bus bit 15 \ |
| A14 | H | Address bus bit 14 + |
| A13 | J | Address bus bit 13 | |
| A12 | K | Address bus bit 12 | |
| A11 | L | Address bus bit 11 | |
| A10 | M | Address bus bit 10 | |
| A9 | N | Address bus bit 9 | |
| A8 | P | Address bus bit 8 +-- unbuffered, 1 ls ttl load max |
| A7 | R | Address bus bit 7 +-- |
| A6 | S | Address bus bit 6 | |
| A5 | T | Address bus bit 5 | |
| A4 | U | Address bus bit 4 | |
| A3 | V | Address bus bit 3 | |
| A2 | W | Address bus bit 2 | |
| A1 | X | Address bus bit 1 + |
| A0 | Y | Address bus bit 0 / |
You would need to bring out one serial line and clock for the serial
flash, and at least five inputs for joystick1 it is riding inside.
If the proposed DB9 serial daisychain was multiplexed with joystick 2
and "joystick out", that adds another serial external line, and the
minimum of five input lines required for joystick2. So the fast
serial daisychain adds 1 external pin to the C64On-A-Chip.
I don't see how you can bring out the bus and bring the RRP down into the
real juicy price points below $30.
Dr. Bruce R. McFarling
> "Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
> news:c8cbc925.04072...@posting.google.com...
> > As long as the fast computer is the one with extra resources (normal),
> > why not?
> > Very few drives are that slow. Driving the clock at 1/4 osc is a
> > frequency of 4us or a raw bandwidth of 250Kbps -- that is, a tad over
> > 60KBps.
> Most Commodore drives due to the slowness of the spinning disks and the
> speed of the heads - data was often limited to some 8KBps. (60KBps would
> literally mean that you could transfer the content of a disk side of a 1541
> disk in about 3 seconds. Commodore protocols were nowhere near that and
> Commodore disk drives as well as most floppy drives were slow.
Yes, quite. It would have been silly of me to say "no drives are every
that slow".
> In fact 60 KBps is about as fast as most Commodore serial drives EVER get
> short of the CMD HD drives.
Since they are synchronous serial, and you need time to load or unload
the CIA's serial data register, much faster than 60KBps would just
shift the constraint from the port to the processor.
> With a cartridge - you use the expansion port typically due to
> address line requirements.
> Flash "Disks" (Compact Flash for example) - User Port is doable BUT you will
> want to treat the 8 bit parallel like you were communicating with an REU
> except you are not dealing with "address lines" but simple 1 MHz AND 8 bit
> parallel data transer. This would give you about 1 Megabytes per second or 8
> Mbps. ONLY problem will be in the CPU executing the transfer instructions in
> a 1:1 ration. (So the CPU won't be a bottleneck here). So you will likely
> need a SuperCPU to process the transfer instructions and move the data to
> the expansion port fast enough.
Yes, and then its not a stock C64. I recognise that as you add gear
to a stock C64, you quickly outgrow this, but then if you have a
expansion port processor, it would be a design option to ramp up
to the 1Mbs or 250KBps that is more normal nowadays for this type
of serial port, as long as you had a couple of shift registers that
can handle the oscillator on the expansion port.
> Reason for my concern = X number of CPU clock cycles per transfer
> instruction execution. I recall it be some 2-8 cycles to perform
> such as a minimum. 1 MHz CPU @ 2-8 cycles for transfer of a
> byte = transfer rate max of 125,000 bytes - 500,000 bytes per
> second. (122/123 KBytes per second -> 488/483 Kbytes per second)
> This would be without assistance of DMA.
And as you push a component of a system toward its optimum, you always
push the system as a whole away from its optimum. If your basic loop
is transferring a 512 byte block:
STA V+1
STY V
; various port set up tasks
; ...
LDA #2
STA COUNT1
LDY #0
LOOP1:
LDA (V),Y ; 5
STA PORT ; 4
INY ; 2
BNE LOOP1 ; 2/3
INC V+1
DEC COUNT1
BNE LOOP1
RTS
That is 12 clocks between port accesses on the inner loop. If
the clock is at 1/2 osc, you are outrunning the clock, but then
you can make it a more general purpose routine and make use of
most of that time:
STA V+1
STY V
STX LEN ; 0 implies whole sector
LDA #0 ; Carry implies one additional sector
ROL A
ADC #1
STA COUNT1
; various port set up tasks
; ...
LDY #0
LOOP1:
LDA (V),Y ; 5
STA PORT ; 4
NOP ; 2
INY ; 2
CPY LEN ; 3
BNE LOOP1 ; 2/3
INC V+1
DEC COUNT1
BNE LOOP1
RTS
If 1/2 osc works well, that looks pretty nice. Its not the
kind of thing I could possibly work out except by trial and
error, but electronic whiz bangs might be able to. It may
be that the commonly available parts for the other side are
fast enough that its not an issue. But it would argue in
favour of fan-out select lines instead of the cross over and
invert thing I sketched out, which would risk propogating
delays on the inversion.
> > I'm looking at the C64 as the very simplest, slowest, and lowest
> > resource computer that proved out as a useful general purpose
> > computer, and therefore a way to get a VolksComputer sold in 3rd world
> > countries at a profit for less than the cost of shipping discarded
> > desktop PC's.
>
> Also C64 was back in 1982.
>
> The first PC barely had 8 bit bus max performance of 4-8 MHz.
> (You had to divide total bandwidth by the number of slots if
> you were to use all the slots.)
Yes, but the IBM is internally more complex, faster, and higher
resource, which says that if you had a early vintage PC, not
only would it be harder to find software that worked on it
compared to the stable design target provided by the C64, but
anything the C64 could do, could be done cheaper on the C64.
And in the 3rd markets that I am looking at, doing barely
enough but cheaper basically always wins.
Dr. Bruce R. McFarling
> In fact - you could integrate off the digital features into one chip. My
> point is you have to replace the core components than put a Terbium CPU and
> add the "video/sound and I/O" into the system. You could put all that into
> one FPGA/ASIC or use a microcontroller that does all that. Ok an option -
> you take keyboard controller chip and ribbon socket and the components and
> add them in so you don't have to worry about converting raw key code but
> just convert the PS/2 signals without needing a "PS/2 port connector". You
> can just take the signal lines that would otherwise go down long wires and
> bring them directly to your FPGA (having a hot "virtual" PS/2 port -
> technically its physical but not wasting space with excess plastic and
> all".) The video/audio does require outputting to some sort of analog such
> as a monitor/speaker respectfully. You will need to have Video DAC(s) and
> Sound DAC(s). That is not handled via FPGA. (You could use FPAA for this if
> you need programmable DACs.) FPAA is Field Programmable Analog Array (which
> does for the Analog world what FPGA does for Digital). This is why there are
> DACs in the C-One. For converting FPGA digital signals into actual sound
> signals. Or handling the individual R,G,B, settings for the video signals.
So there's the big attraction in ASIC, since with FPGA you cannot leave
the whole bus inside a chip ... you would need to bring out at minimum
address lines and select lines for the VIC/SID substitute. I had an
inkling of this, but not the whole story.
Western Design licenses FPGA 65C02 cores, so it would not necessarily be
more parts than I thought for the bus based design. 3 32K Static RAM,
one FPGA, and one FPAA (plus minor parts).
> > Anyway, start adding adding features and then you wouldn't be able to
> > sell it for under $20 .. you end up flying past what an scaled down
> > emulation solution would cost and start pushing toward CommodoreOne.
> > OTOH, a C64-in-a-joystick would, as long as two can be linked together
> > for two-player gaming, put a big dent in the 3rd world Nintendo
> > Entertainment System clone market. If it could be expanded into an
> > operational system for as little extra as possible, millions would be
> > sold.
> > But only if you hit the price point. No matter how nifty the
> > features, if the price point is around $50 you are throwing away more
> > than half the potential market.
> You would be selling both versions as individual products. The version
> with the ports and all would be say eC64DTV (e=extended/enhanced) with
> the additional ports at say $50 USD where the lower price c64DTV would
> be without the ports and be say $35-40 USD. These would be sold as
> seperate products but are essentially the same base product but the
> eC64DTV would be a more extended version with the extended features.
It still busts the price point. Not that wouldn't be a design option
for the C64DTV, since they seem content with the smaller market
anyway (and recognising that the following:
> NOTE of DISCLAIMER: The eC64DTV is not an actual product but a
> theoretical version of the C64DTV with the ports and this paragraph
> should be considered on basis of theory. This is ENTIRELY based
> on my ideas and is NOT to be "expected" but who knows anything can
> happen. I know enough that Tulip people do watch and may look at
> the ideas and possibly consider it as two individual products.
applies to the whole discussion) .... but if they could hit the
price point, there is a massive upside.
> Some of us who would be interested in possibly programming for the
> c64DTV platform would want the ports and all. So for $50. Hell - I
> be willing to spend as much as $99 for the version with ports and
> developer software and the sort. Either way, you get the general
> idea and it be nice to develop for. As I see it - I go for that
> ANY day.
The flipside is that if more C64DTV's are sold than the original
C64 (a possibility -- certainly far more Famiclones have been
sold than the original NES and Famicom combined!), then there's
the thrill in showing off to a wider audience what can be done
under such resource constraints.
Rick Balkins
"Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
news:c8cbc925.04072...@posting.google.com...
> So there's the big attraction in ASIC, since with FPGA you cannot leave
> the whole bus inside a chip ... you would need to bring out at minimum
> address lines and select lines for the VIC/SID substitute. I had an
> inkling of this, but not the whole story.
You can actually emulate or build a core to process the digital side of the
VIC and SID but you have to tie in to convert digital RGB signals into
analog signals and convert digital signals into actual sound. The "GPU" and
the "SPU" can be put into the FPGA but to take the video out to the CRT (you
need a DAC) and to make the sound sound more then little clicks (you need a
DAC for sound) Hence tha 18-Bit Sound DAC to make the 18Bit digital signals
and produe the actual analog signals from it. As for timing (that can be
handled within the FPGA)
ASIC helps a tid bit more. ASICs are less expensive in "large volume" but
more expensive in prototype level volume.
> Western Design licenses FPGA 65C02 cores, so it would not necessarily be
> more parts than I thought for the bus based design. 3 32K Static RAM,
> one FPGA, and one FPAA (plus minor parts).
Yes, indeed.
Given that we are talking about a $30-40 unit compared to a $300-400 unit. I
think it is possible. Since you could buy something like 10 of these for the
price of 1 C64. 160 Million Gameboys. (not talking about GB Color or GB
Advance. - ok check Nintendo site.)
Alright - the reason that computers hardly can sell in such numbers is
"price". $300 compared to $30. That is why there are Trillions of marbles
and not Billions of computers.
For $300 - you can buy 1000 marbles.
Same basic principle. People can willfully buy more DTVs than they will
full-size computers. Hence why more Nintendos and SNESs than C64s. Take the
price figure and non-competitive market.
Dr. Bruce R. McFarling
> 64DTV comes out as is, and is a big hit in the retro market. Ironstone
> then can recoupl cash and come out with an expanded unit like you
> describe. Retro gamers would probably buy the enhanced unit even though
> they have the original.
Actually its a bit of a retracted unit, as it heads for getting
the best features/cost breakdown for a very, very low price
point.
> It's a common business practice to not put all the goodies in version 1.
And a common business practice to not hit the very cheapest
mass production design on the first crack, because on the first
crack you don't know whether you are designing across 1,000 or
1m units.
> That way, there is the option of version 2. Given your third world
> analogy, I would think there is plenty of time to bring out 64DTVv1,
> reap some cash, add the options you describe, bring out v2, reap some
> more cash, and use the buzz from v1 as a marketing tool in those
> countries to drive sales.
If the 64DTV has the extra pads, then options can be brought out ...
the tricky thing would be to make the 3rd world version a useful
enough subset of the expanded 1st world geek retro unit
> > That's locking yourself out of the biggest markets on offer, and
> > restricting it to retro gaming in the 1st world.
> Why think of this product as a one time deal? Why not think of it as a
> franchise, with enhanced products coming out for a couple years?
That's how I was looking at it ... this as the base, and then
building up form that base, and the base set too high to crack
the market I am talking about.
> I don't see how they will lock themselves out of a market they are
> not sure even exists. As a business owner, I'd rather target the
> retro gamers and the novelty buyers in civilized nations first, grab
> some cash, and then work on newer/expanded products.
Well, twisting it from being about expanded to it being about
shifted, the retro gamers in developed countries spend a lot
less on newly produced 8bit game machines than is spent in
3rd world markets. I'd follow the money, if I could get enough
useful information about the market.
> Without ports on the unit, FCC signoff is much easier, and cost is
> pretty much bare-bones. If you were bringing this into a market and
> were not sure of success, I think you'd go a bit safe too.
I would set a minimum spec, and try to get it as cheap in that
spec as possible. That spec would be:
- plug and play C64 games included
- AV television jacks
- 2 player option
- downloadable games option
Rick Balkins
> the best features/cost breakdown for a very, very low price
> point.
>
> mass production design on the first crack, because on the first
> crack you don't know whether you are designing across 1,000 or
> 1m units.
> If the 64DTV has the extra pads, then options can be brought out ...
> the tricky thing would be to make the 3rd world version a useful
> enough subset of the expanded 1st world geek retro unit
Actually V2 is a refined Version 0 and V1 is a cost reduced version 0.
Version 0 is preproduction version and version 2 is essentially a refined
version 0 without the cost reduction but refined because they want to make
sure bugs are removed before production.
Basically it would have the ports. The version with the pads (and ports on
some of them) are essentially "version 0" - preproduction models. Version 1
(production version) might not have the pads nor the ports (but the pins on
the chip would still have it.) just to reduce the price a little. While the
"Version 2" (the conceptual "eC64DTV" or whatever) would be essentially the
Version 0 - refined (maybe new plastic housing case and all).
Ok - for those others not following thoroughly (this is talks with a
theoretical context AND does NOT represent what Commodore International B.V.
(a Tulip Computers N.V. company) will actually do.
> > Why think of this product as a one time deal? Why not think of it as a
> > franchise, with enhanced products coming out for a couple years?
>
> That's how I was looking at it ... this as the base, and then
> building up form that base, and the base set too high to crack
> the market I am talking about.
>
> > I don't see how they will lock themselves out of a market they are
> > not sure even exists. As a business owner, I'd rather target the
> > retro gamers and the novelty buyers in civilized nations first, grab
> > some cash, and then work on newer/expanded products.
>
> Well, twisting it from being about expanded to it being about
> shifted, the retro gamers in developed countries spend a lot
> less on newly produced 8bit game machines than is spent in
> 3rd world markets. I'd follow the money, if I could get enough
> useful information about the market.
Ok but the letter "e" in the "conceptual" eC64DTV doesn't really have to be
deeply explained but is just a way to model name the (enhanced/extended
version) but the e part would not necassarily be the central focus. You get
too caught up with expectations from people that often is MORE than what is
being done.
> I would set a minimum spec, and try to get it as cheap in that
> spec as possible. That spec would be:
> - plug and play C64 games included
> - AV television jacks
> - 2 player option
> - downloadable games option
That is well within scope of option. Just need a 9-pin connector tied to
specific pins of the 24 pin "User" Port. (so it may be tied to a 25pin DSub
or a 9pin Dsub.)
Then you just need a simple cross-over cable which already exists. All it is
is cross overing the Tx and Rx lines accordingly and the the sort.
I am speaking from a technical side of this but this is not what the
marketing boys have to be concern about NOR the average consumer who just
wants to know what kind of cable needed. (If it is not provided already is
"Bundle-Pack" edition. Two of them in one pack with cross-over cable
included. "Batteries Not Included") The AC adaptor be available. Logically,
it be marketed like toys and other electronic gadgets. Like two FRS Radios
or two phones and charger or whatever. This is normal business practice in
the marketplace.
In this marketplace - Commodore International's entire "electronics"
division would be competition with your typical Emmerson, Hitachi,
Philip/Magnavox, and the sort in the "consumer electronics" market. It is
easy to make some sales in this market especially if you can get a contract
with your "Circuit City" and the sort kind of places. Getting them the sales
rep to promote and support YOUR products otherwise the competition will have
a marketing agreement for them to bad mouth their competitions which would
include Commodore and sing praises of their products. Even though their
products may very well suck and Commodore being superior.
Typical market game.
Dr. Bruce R. McFarling
> Actually V2 is a refined Version 0 and V1 is a cost reduced version 0.
> Version 0 is preproduction version and version 2 is essentially a refined
> version 0 without the cost reduction but refined because they want to make
> sure bugs are removed before production.
> Basically it would have the ports. The version with the pads (and ports on
> some of them) are essentially "version 0" - preproduction models. Version 1
> (production version) might not have the pads nor the ports (but the pins on
> the chip would still have it.) just to reduce the price a little. While the
> "Version 2" (the conceptual "eC64DTV" or whatever) would be essentially the
> Version 0 - refined (maybe new plastic housing case and all).
Actually, after shopping for the games in a joystick at the local
Big W, 64 games is probably enough of a market separation at the
get go. It does not get it into the biggest market, but the
standard Famiclone simply cannot get into the main 1st world
markets (Big W, Target etc.) because, after all, they are based
on blatently stolen IP.
> Ok - for those others not following thoroughly (this is talks
> with a theoretical context AND does NOT represent what Commodore
> International B.V. (a Tulip Computers N.V. company) will actually
> do.
> Ok but the letter "e" in the "conceptual" eC64DTV doesn't really
> have to be deeply explained but is just a way to model name the
> enhanced/extended version) but the e part would not necassarily
> be the central focus. You get too caught up with expectations
> from people that often is MORE than what is being done.
There is no problem with expectations in the 3rd world market ...
the existing product that fills these channels are based in large
part on lies and deception ... ie, "over 10,000 games" meaning 20
games, each with 512 variations of parameter settings (and consider
that is you have sound on/off, difficulty easy/medium/hard/very
hard, and start in level 1, 2, 3 or 4, that is already 256 "games").
Delivering inside what you claim to deliver on the box is a
massive step.
There is also no problem with FCC certification.
A C64DTV-W that JUST has a DB9 joystick 2 port would be a fine
start. There is no need to be compatible with existing C64
peripherals, since there is no existing C64 gear in the markets
we are talking about. There is no need to be "master" on a
serial daisychain yet, as long as the following spec is met.
> > I would set a minimum spec, and try to get it as cheap in that
> > spec as possible. That spec would be:
> > - plug and play C64 games included
> > - AV television jacks
> > - 2 player option
> > - downloadable games option
>
> That is well within scope of option. Just need a 9-pin connector tied to
> specific pins of the 24 pin "User" Port. (so it may be tied to a 25pin DSub
> or a 9pin Dsub.)
> Then you just need a simple cross-over cable which already exists. All it is
> is cross overing the Tx and Rx lines accordingly and the the sort.
If the selected lines are joystick 2 IN when the unit is on, then
there is no need to make any modification to support 2 player mode,
and it can rely on straight through DB9 cables, which eliminates
a lot of headaches. The joystick simply needs to BE in digital
joystick mode when it is turned off. Then a DB9 male port provides
the interface to the outside world, and a DB9 female-female cable
allows the C64DTV-W to be the second joystick when it is is turned
off and plugged into another C64DTV-W.
For "downloading" games to a C64DTV-W, a PC interface kit would be
a CD-ROM and a widget that allows nybbles to be streamed down into
the joystick port. Those would be sold primarily to the businesses
that are selling the C64DTV-W, so they can make a continuous stream
of income from downloading games into individual units.
> I am speaking from a technical side of this but this is not what
> the marketing boys have to be concern about NOR the average consumer
> who just wants to know what kind of cable needed.
Yeah, I've been really confusing in this, since I've come at it
from the marketing angle, but its a lot more fun to speculate
on the technical side.
> The AC adaptor be available. Logically, it be marketed like toys and
> other electronic gadgets. Like two FRS Radios or two phones and charger
> or whatever. This is normal business practice in the marketplace.
Just bear in mind that often things are done differently in
different countries. For example, in the more substantial
market towns in India (which would be electrified, unlike
many outlying villages), toys and other electronic gadgets are
sold as part of the general stock of a small handful of
retailers of mixed durable goods. So if there is some sugar
to give them an additional bonus from selling these instead
of Famiclones, you can be sure of a prominent position in the
shop, while the Famiclones will be in the back shelves.
> In this marketplace - Commodore International's entire "electronics"
> division would be competition with your typical Emmerson, Hitachi,
> Philip/Magnavox, and the sort in the "consumer electronics" market.
The larger market for these kinds of toys is higher volume and lower
overhead, so these are not the kinds of firms you are competing
with. You are competing with the Chinese OEM manufacturer of
joystick Famiclones that will sell you units for $4-$12 each in
lots of 2,000.
Dr. Bruce R. McFarling
> I just don't think something as simple as a shift register is going to
> mesh nicely with IDE. The shift register will get the data there, and
> you've brought out the select and R/W lines, but it just seems to me
> that there's more to it than that.
Except for speed, there's nothing more to it than that ... but that's
a big exception!
Here's a version that "wraps around" an SPI interface.
* +3v
* GND
* MOSI
* MISO
* CLK
* /SC1 - SPI select
* /SC2 - ADI select
* DATA/CONTROL
/SC1 is serial channel 1 select. This is the /SS -- "slave select" --
in the SPI.
On serial channel 1, there can be more than one device as long as each
device recognises the first byte of a control packet and discards
packets that are not direct to it.
/SC2 is serial channel 2 select. This is the "addressable device
interface". Control held low connects MOSI to the device command
register and MISO to the device status line or register. The device
command register is:
b7 - dev1
b6 - dev0
b5 - mode1
b4 - mode0
b3 - SelectB/A
b2 - a2
b1 - a1
b0 - a0
If the ADI device number (from 0 to 3) matches Dev1 and 0, then the
device responds to the device mode, otherwise the device is
deselected.
Mode 0 is deselected, Mode 1 is read, Mode 2 is write, and Mode 3 is
reset. This is since I worked out that there is no way to do
READ&WRITE or RESET&READ if the device is counting clocks and latching
or writing the data lines at appropriate intervals on its own, and it
has to do that to for /SC2 data mode to be like /SC1 data mode.
In read mode, latch the 8/16 data lines into the shift register, and
feed the bits out as the clock ticks over. Latch the data lines again
every 8/16 clocks.
In write mode, read MOSI into the shift register for 8/16 clocks, the
8/16 data lines, then repeat.
In reset mode ... uh, reset then deselect the device. Another command
byte is required to do something.
If it was desired to add more than 4 ADI devices, it would be possible
to specify a hub that would respond the /COMMAND signal when neither
/SC1 nor /SC2 are low (selected), and then act as a switching device
between different ports. That bridge is left to be crossed later ...
I've sketched out a couple, and the idea is workable, but at the
moment there is only 1 widely available collection of devices for the
serial channel 1, and 0 for the serial channel 2, so there doesn not
seem to be an urgent need for a hub.
I would leave the frequency at the Playstation 1 memory card
specification for now ... 4us is "normal", up to 1us is "allowed".
Dr. Bruce R. McFarling
> I would leave the frequency at the Playstation 1 memory card
> specification for now ... 4us is "normal", up to 1us is "allowed".
Oh, and I saw in the CIA specifications that the fastest that the
serial port can operate the CLK line is phi2/4, so I guess that means
that the 62.5 maximum bandwidth really is it, even if a processor
accelerator is running, as long as its using the motherboard CIA.
Actually, it does make sense ... in flip flop mode, latch 0;
underflow, switch from low to high; latch 0; underflow, switch from
high to low ... 4 clock cycles.
Note that running it at this speed, you would have to work out the
timing and run in the foreground, masking out the interupt on the
"write buffer empty / read buffer full", since serving the interupt
would take too much time to do it in the background.
Rick Balkins
> agi...@netscape.net (Dr. Bruce R. McFarling) wrote in message
news:<c8cbc925.04080...@posting.google.com>...
>
> > I would leave the frequency at the Playstation 1 memory card
> > specification for now ... 4us is "normal", up to 1us is "allowed".
>
> Oh, and I saw in the CIA specifications that the fastest that the
> serial port can operate the CLK line is phi2/4, so I guess that means
> that the 62.5 maximum bandwidth really is it, even if a processor
> accelerator is running, as long as its using the motherboard CIA.
62.5 based on a 1 MHz clock. Double that at 2 Mhz timing - if you were
communicating with drives with 2 MHz 6522/26 or 65c22. Now, 4 Mhz would
allow for faster that that. BUT the 8522 had features over the bus that
moved it even faster running in a syncronous-like communication mode -
running at clock rate. This potentially allow protocols to "stream" data at
full clock rate until a signal like EOF (End of File). This means the drive
shifts back to a normal mode waiting for commands all. This was typically
called BURST mode. Part of a BURST protocol. The 65c22 like the 6522 is not
really have to be limited to 62.5 Kbps.
> Actually, it does make sense ... in flip flop mode, latch 0;
> underflow, switch from low to high; latch 0; underflow, switch from
> high to low ... 4 clock cycles.
>
> Note that running it at this speed, you would have to work out the
> timing and run in the foreground, masking out the interupt on the
> "write buffer empty / read buffer full", since serving the interupt
> would take too much time to do it in the background.
In the 128/128D there was BURST mode that allowed for a speed burst.
Dr. Bruce R. McFarling
[quoth I]
> > Oh, and I saw in the CIA specifications that the fastest that the
> > serial port can operate the CLK line is phi2/4, so I guess that means
> > that the 62.5 maximum bandwidth really is it, even if a processor
> > accelerator is running, as long as its using the motherboard CIA.
> 62.5 based on a 1 MHz clock.
I slipped a 2 somewhere doing my gazintas, that's 31.25MBps (ie, 250Mbps).
> Double that at 2 Mhz timing - if you were communicating with drives
> with 2 MHz 6522/26 or 65c22.
That's the master clock, so what matters for the slave devices is that
they can cope with a master clock at that frequency. However, as I
said, I would follow the PSX specification and say devices ought to
be able to operate at up to 1Mbps (1us frequency), although 250Kbps
(31.25KBps, 4us frequency) is the norm.
After all, if two quite different devices (the Amtel microcontroller
that Jim Brain references and the CIA spec) both give 1/4 osc. as
the maximum, and 4MHz avoids most problems with radiation by short
trace lines, then there is no need to limit the speed of the slave
devices to the speed of a stock C64.
Dr. Bruce R. McFarling
> In the 128/128D there was BURST mode that allowed for a speed burst.
Yeah, at a 4us frequency so a bandwidth of about 31.25MBps, and in
practice a transfer speed of something a little less than that ... oh
wait, that is from Jim Brain's CHacking article on the burst mode, so
maybe I should let him answer. Anyway, it seems that the transfer
speed of burst mode is on the order of 25KBps when it gets going. The
major advantage of a new serial bus over piggybacking onto an existing
one is that data must be transfered at slow serial daisychain speeds
in the handshake to establish burst mode, while this would be
effectively in burst mode all the time.
Rick Balkins
"Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
news:c8cbc925.04080...@posting.google.com...
> > 62.5 based on a 1 MHz clock.
>
> I slipped a 2 somewhere doing my gazintas, that's 31.25MBps (ie, 250Mbps).
KBps / Kbps but not MBps / Mbps.
> > Double that at 2 Mhz timing - if you were communicating with drives
> > with 2 MHz 6522/26 or 65c22.
>
> That's the master clock, so what matters for the slave devices is that
> they can cope with a master clock at that frequency. However, as I
> said, I would follow the PSX specification and say devices ought to
> be able to operate at up to 1Mbps (1us frequency), although 250Kbps
> (31.25KBps, 4us frequency) is the norm.
True but 8522 as in the C-128 has a special burst protocol that allowed
faster protocol speed operations matching that of the "FAST Clock". This
equals upto 16 Mbps (2 MBytes per second) based on the 2 MHz clock source.
The 8522 is an enhanced 2 MHz version of the 6522/6526 with enhancements.
> After all, if two quite different devices (the Amtel microcontroller
> that Jim Brain references and the CIA spec) both give 1/4 osc. as
> the maximum, and 4MHz avoids most problems with radiation by short
> trace lines, then there is no need to limit the speed of the slave
> devices to the speed of a stock C64.
When you go up in speed - you change the base wires and add more insulation.
This is based on how you make up the cable wiring and in some cases a
thinner wire made of gold would do for continuity transfer. Copper is
another choice but as you go up in clock frequency - you must choose better
wiring and add insulation. Ok shorter (often is thinner not necassarily
shorter trace lines) would do.
At frequencies between 1-4 Mhz it doesn't matter so much. But moving to 20
Mhz and it does.
Rick Balkins
port design.
The key would be "protocol" switching over same hardware depending on mode.
If I would design a new computer platform - I personally like the use of the
PS/2 style connector in (reverse gender) so you don't plug in a actual PS/2
keyboard in. I would use also USB 2.0 as well. This might be an idea.
Generally speaking - I would wire the cables with fine grade wires made of
the best material for the clock range. Aluminum isn't as good as copper or
gold at higher frequencies and the use of a Commodore sort of like protocol
but with a FAST clock and a stream-lined data port. I would use all 6 pins.
Idea - similar to a cross-between USB and Commodore Serial bus concept.
Pinout idea -
Pin 1 - Data In
Pin 2 - Data Out
Pin 3 - Ground
Pin 4 - +5v
Pin 5 - Clock
Pin 6 - Command Line (Bi-Directional)
Being that it is in a Reverse Gender of the PS/2 - You ain't plugging a PS/2
connector in.)
Ok, It is similarly pinned out so that you don't spike the circuit someway.
(Ok Pin 3/4 maybe transposed but this would be double verified). The
difference between timing will make a difference in the cable quality and
amount of insulation and the sort. General basis for the Dual data lines is
full duplex communication operations.
The reason is electronic safety. The voltage line is assumed for standard
power feed.
The amount of mA maybe interesting but I might set the guage a little
thicker than usual if possible for boosting amperage threshold. This is an
idea for something in terms of intellegent peripherals.
"Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
news:c8cbc925.04080...@posting.google.com...
Sam Gillett
"Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote ...
> True but 8522 as in the C-128 has a special burst protocol that allowed
> faster protocol speed operations matching that of the "FAST Clock". This
> equals upto 16 Mbps (2 MBytes per second) based on the 2 MHz clock source.
> The 8522 is an enhanced 2 MHz version of the 6522/6526 with enhancements.
Rick, me thinks you are pulling numbers out of your hat again. While the
"fast" serial protocol of the C128 and 1571/1581 is much faster than the
"slow" serial protocol of the C64/1541, there is no way it will do 2 MBytes
per second.
Try doing a little testing with your C128, and you will see that I am right.
--
Best regards,
Sam Gillett
Change is inevitable,
except from vending machines!
Rick Balkins
"Sam Gillett" <samgille...@diespammermsn.com> wrote in message
news:%1fQc.2075$P16....@nwrddc04.gnilink.net...
>
> Rick, me thinks you are pulling numbers out of your hat again. While the
> "fast" serial protocol of the C128 and 1571/1581 is much faster than the
> "slow" serial protocol of the C64/1541, there is no way it will do 2
MBytes
> per second.
>
> Try doing a little testing with your C128, and you will see that I am
right.
>
That is because the disk drives never pull the data from the media fast
enough. The disk drives just can't move fast enough to achieve that and the
CMD HDs never had the 8522s installed in them and the 1571 and I believe the
1581 drives are the ONLY drives capable of operating in burst mode BUT the
disk drive never pull the data off the disks fast enough. The reader just
isn't fast enough. You can have a theoretical speed but you ain't going even
to 1 MBytes because the disk reader can't pull enough data at the 300 RPMs.
Or even at 4500 RPMs.
It is like the IDE bus can move 33 MBytes per second but you can't move the
data that fast in real world. Never seen an HD move files larger than a few
Mbytes from one place to another or from one drive to another drive within 1
second. So even HDs aren't that fast.
This is even on a modern PC.
You need a chip based memory storage to move things that fast.
There are other factors than the bus clock that limits drive speed.
Rick Balkins
mode the 8502 is set to. The 8522 BURST protocol operates at bidirectionally
a 1 bit per direction every 2 cycles. Meaning 1 cycle is downstream and the
next cycle is upstream then downstream.
The Burst protocol was DIFFERENT then the CPU based software Serial protocol
that limited the 6522/6526.
Read - http://www.cs.tut.fi/~albert/Dev/burst/
Now, the 8522 if operating in one direction can achieve 1 bit per clock
cycle (unidirectionally) just like the 1750 REU DMA protocol allows upto 1
byte per clockcyle unidirectionally. Unlike the REU-DMA - the 8522
automatically shift to 2 MHz when the 8502 is set to 2 MHz when you type in
FAST command (or do the ML equivelent).
This means that data can go bidirectionally at upto 1 Mbits per second or 2
Mbits per second unidirectionally. This is if you don't switch directions
every cycle.
Now - I never said that their could be "other" factors that will slow or
limit data transfer rate like the speed of pulling data off the disk. These
factors also do come into play but that is the speed potentials. Just like
the slowness of the disk and reader of the floppy drives. NONE of the drives
ever matched the performance maximum of the 8522
Yes it was a syncronous serial protocol.
"Sam Gillett" <samgille...@diespammermsn.com> wrote in message
news:%1fQc.2075$P16....@nwrddc04.gnilink.net...
>
Jim Brain
> "Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote ...
>
>
>>True but 8522 as in the C-128 has a special burst protocol that allowed
>>faster protocol speed operations matching that of the "FAST Clock". This
>>equals upto 16 Mbps (2 MBytes per second) based on the 2 MHz clock source.
>>The 8522 is an enhanced 2 MHz version of the 6522/6526 with enhancements.
>
>
> Rick, me thinks you are pulling numbers out of your hat again. While the
> "fast" serial protocol of the C128 and 1571/1581 is much faster than the
> "slow" serial protocol of the C64/1541, there is no way it will do 2 MBytes
> per second.
>
> Try doing a little testing with your C128, and you will see that I am right.
>
Hehe, I noticed that last night, but I decided not to post...
The error is in thinking that the CIA can transfer an entire byte in 1
CLK. It uses Phi2 as the clock, so by definition, it cannot transfer
faster than the system clock (and page 432 of the PRG notes CNT can be
max Phi2/4, or 500kbps (~50kBps @ 2MHz Phi2)).
Even if the port could swing MHz timing, at that speed, the wires become
subject to transmission line theory, which means they'd need impedence
matching on each end (ala SCSI and Ethernet 10base5), and the 5V square
wave would be a mess. You'd at least need to put RS422 transceivers on
each end and bring the line levels into differential state to have a
chance of getting those speeds.
Bruce is correct though, that slave can run at any clock, though the
NMOS 85XX series switching times were 2MHz rated for a reason, so I
doubt the internal shift register will operate at much past 2MHz, if it
can even get that high (I suspect the shift register propagation delay
and flip flop set up and hold time also limit the top end of the speed.)
The incoming CNT line being able ot be driven at any speed was more a
way of minimizing issues related to mismatched clock speeds, or using
nonstandard clocks than it was to go much above the highest speed of the
part itself.
Obviously, we can quickly test how high the 128 CIAs can clock incoming
data, but I would be EXTREMELY surprose if you go much about 750 kbps on
a batch of ICs.
If you want faster speeds, It's a small matter to implement your own
shift register on the user port. a 74hc299, a clock , and a divide by 8
counter and your cooking with 50-MHz clock speed. However, running the
shifter > 2MHz won't do much good, as that's as fast as the 128 can read
and store the data.
Jim
Rick Balkins
which are now operationally capable of 20 MHz operations.
Serial support. If you wanted Duplex Serial support - you use a Dual 65c22
operation serial port. Tied to different phases of the clock. Command line
operating at both phases of the clock and have VIA#1 on high cycles and
VIA#2 operating on the low phase of the central clock. This would be a
challenge and fun theory. The C-128 had a 2 MHz mode and that made the
VIC-II inactive due to the system bus operating at 2 MHz. The 8502 gets its
timing based on the system bus. The VIC-II would be disabled when shifting
to 2 MHz. This means the speed could be brought upto 2 MHz. I never said the
serial bus operated in full bytes being that it is a serial port. The 8522
operated typically with bidirectional operation of upto 1 byte every 2
cycles. (1 bits per 2 clock cycles over the serial bus). This is the BURST
mode (this is bi-directional communication... hmmm).
Ok, it would be 1 MBits per second typically. (1 MBytes per second in full
parallel)
The 6526 was a bit interesting but the 8522 allowed considerably faster
communication.
The 6502 from MOS Technology were actually designed to support 5 MHz
operations. So was the I/O chips based on the Depletion Load technology that
is built into these chips. When they double doped the Ion used - they got
the venerable accident of having the 10 MHz 6502.
---------------------------------------------------------------
The NMOS 6502 used depletion load devices that strongly influenced the
speed of the 6502. The manufacturing process required a depletion ion
implant. On one of the production lot of wafers an operator made an
error that caused the wafers to be implanted twice. Because we used
conservative design concepts the 6502 worked even with the process
variations of twice the normal implant dose. The 6502 usually ran over 5
MHz and so the doubly implanted devices ran at over 10 MHz. I had built
a tester with ECL RAM that I loaded with the test program from a
Teletype using a paper tape reader (remember this was before PC in
1975-76). I believe that the 6502 running at 10MHz was the fastest
microprocessor in the world at that time.
[snip - different topic]
Bill
"The W65C02S Microprocessor Family,
the Leader in Timeless Architectures!"
William D. Mensch, Jr.
Chairman & CEO
The Western Design Center, Inc.
2166 East Brown Road
Mesa, AZ 85213
www.westerndesigncenter.com
men...@westerndesigncenter.com
Ph 480.962.4545
Fx 480.835.6442
-----------------------------------------------------------------
So if the 6522 and subsequently the 8522 used this depletion load technology
then 5 MHz is well within the functional capacity. The key is you match the
drives up as well if you are going to match. The 5v don't mean all that much
but will be picked up at those speeds just fine. They were designed around
the servicable operation of 5 Mhz. There is alot of room here and if you are
going to shift the speed up - I may suggest using copper or gold pins and
replace the DIN with gold contact or use a different guage wire for the
internal wires and use double insulated wires which would take care of this
transmission line problem unless you want to tell us about this transmission
line problem. Do you mean "cross-talk" ?
"Jim Brain" <br...@jbrain.com> wrote in message
news:hrgQc.246224$Oq2.143490@attbi_s52...
Sam Gillett
"Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote ...
> "Sam Gillett" <samgille...@diespammermsn.com> wrote in message
> news:%1fQc.2075$P16....@nwrddc04.gnilink.net...
>>
>> Rick, me thinks you are pulling numbers out of your hat again. While the
>> "fast" serial protocol of the C128 and 1571/1581 is much faster than the
>> "slow" serial protocol of the C64/1541, there is no way it will do 2
>> MBytes per second.
>>
>> Try doing a little testing with your C128, and you will see that I am
>> right.
>
> That is because the disk drives never pull the data from the media fast
> enough. The disk drives just can't move fast enough to achieve that and the
> CMD HDs never had the 8522s installed in them and the 1571 and I believe
> the 1581 drives are the ONLY drives capable of operating in burst mode BUT
> the disk drive never pull the data off the disks fast enough. The reader
> just isn't fast enough. You can have a theoretical speed but you ain't
> going even to 1 MBytes because the disk reader can't pull enough data at
> the 300 RPMs.
Craig Bruce did a little testing with the C128 and various drive types, both
with and without JiffyDOS. He recorded his results in the doc file for LRR.
http://www.csbruce.com/~csbruce/cbm/lrr/
Keep in mind that no matter how fast we can move data on the serial bus, we
can not receive data any faster than the CPU can move it to RAM. Nor can we
send data any faster than the CPU can fetch it, and send it to the serial
bus.
So, even with a very fast hard drive we will have another bottleneck in the
8502 (and Kernel routines).
Jim Brain
Hard facts:
A stock 64 cannot process more than 250,000 bytes per second. A 128 can
do no better than 500 kbps. A direct REU copy (pin the input address at
1 location, and do a 64 KB push/pull using the REU) can do no more than
1,000,000 bytes/sec. Period.
As a result, it makes no sense to design the hardware to go faster than
that, UNLESS the CPU is upgraded.
But, if you put in a new CPU:
System Clock needs to be bumped. (5MHz, you say?)
DRAM will be too slow, all 8 must be replaced
SRAM will be too slow, must be replaced
VIC cannot be made faster short of cryocooling, so it and SID will have
to be carved off into a separate "bridge" that continues to run at 2Mhz
tops. Circuitry will need to be added between bridge and main unit to
handle synchronization of writes/reads across the bridge
SID cannot be made faster, so it'll have to be carved out
EPROM will be too slow. Replace
What are we left with? A new computer... It will not be a 64 at that point.
(Academically interesting, but largely irrelevant 5Mhz/10MHz Mensch
musing deleted)
Bill is talking about the digital only ICs. He did not help in SID or
VIC development. Those devices are MUCH more limited in how fast they
can operate.
And, who cares what the 6522 can do, as it cannot replace a 6526 CIA?
It has no free running counter, no TOD, the registers are in different
locations. Forget the 65C22 or its derivatives.
> but will be picked up at those speeds just fine. They were designed around
> the servicable operation of 5 Mhz. There is alot of room here and if you are
Sure, they can operate at 5MHz using on board traces. Put wires and any
length into the mix, and kiss that speed goodbye.
> going to shift the speed up - I may suggest using copper or gold pins and
> replace the DIN with gold contact or use a different guage wire for the
> internal wires and use double insulated wires which would take care of this
> transmission line problem unless you want to tell us about this transmission
> line problem. Do you mean "cross-talk" ?
Transmissin line problems are simply that above certain speeds, you can
no longer treat a wire as a conduit of electricity, but as a radiator or
electromagnetic radiation (an antenna). Antennas demand impedence
matching, or they "ring":
If a square wave hits the end of the wire that has a 50 ohm "impedence"
(impedence is like resistance, but has an AC component to it), and there
is simply a pin and some solder at the end of that wire, the signal will
turn around and travel backwards through the same wire, wreaking havoc
with the portion of the wave behind it on the wire. And, if it doesn;t
find an impedence match on the source end, it turns around and comes
BACK, which then looks like a delayed version of the same signal. So,
in a worst case scenario, you start sending bits, but at the other end,
you get a straight 5v signal (the delayed version of the signal fills in
the 0volt holes in the waveform, and turns it into a constant 5v line.
At 5MHz, the effect is not as pronounced as at higher speeds, but it is
there. Distance effects how it operates, as the ringing and repeating
of the signal changes as the cable is longer or shorter (length = time
of propogation).
Note also that on a stock 64, fast load coders assume a 1 cycle delay
due to propogration delay for bits to come in on serial bus. (So, if
the bit is placed on the CIA output pin at time t, it will not arrive at
the 1541 until time t+1us. At 5Mhz, that's a 5 cycle delay.
MagerValp
ledge to speak of and is just pulling numbers out of his ass and
posting google results.
--
___ . . . . . + . . o
_|___|_ + . + . + . Per Olofsson, arkadspelare
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
Dr. Bruce R. McFarling
> "Dr. Bruce R. McFarling" <agi...@netscape.net> wrote in message
> news:c8cbc925.04080...@posting.google.com...
> When you go up in speed
I don't intend to. If I was going up in speed, I would find a
way to connnect a USB controller. And going up in speed always
costs money.
Interesting would be how stupid the slave side of a floppy disk
controller for this could possibly be. Driving the master clock
from the C64 side and in foreground would allow it to keep up
with the read of a floppy sector in 1571 burst mode. If you
can do that, you don't need smarts on the floppy side of the
interface anymore.
Rick Balkins
> Craig Bruce did a little testing with the C128 and various drive types,
both
> with and without JiffyDOS. He recorded his results in the doc file for
LRR.
>
> http://www.csbruce.com/~csbruce/cbm/lrr/
>
> Keep in mind that no matter how fast we can move data on the serial bus,
we
> can not receive data any faster than the CPU can move it to RAM. Nor can
we
> send data any faster than the CPU can fetch it, and send it to the serial
> bus.
>
> So, even with a very fast hard drive we will have another bottleneck in
the
> 8502 (and Kernel routines).
>
True but this is NOT entirely the problem of the serial bus but trouble in
the CPU not being able to read data from RAM and write data to RAM or
storage at a bit rate ratio of 1 bit per clock cycle. Though a 2 MHz CPU
should be able to move 250 KBytes of RAM. Since you get the information in
parallel but this is NOT so much the problem from the CPU to RAM and the
8522 in BURST mode doesn't require CPU intervention. The number of clock
cycles to fetch a byte may be the slow part. This can be solved by putting a
4 MHz CPU.
Rick Balkins
> Rick Balkins wrote:
> Hard facts:
>
> A stock 64 cannot process more than 250,000 bytes per second. A 128 can
> do no better than 500 kbps. A direct REU copy (pin the input address at
> 1 location, and do a 64 KB push/pull using the REU) can do no more than
> 1,000,000 bytes/sec. Period.
Jim - 2 Mbits per second is 250 KBytes per second but your bottleneck is NOT
the I/O but the CPU.
> As a result, it makes no sense to design the hardware to go faster than
> that, UNLESS the CPU is upgraded.
That is a solution that can and has been dealt with before. The 8502 does
have a clockability to 4-5 MHz operation.
> But, if you put in a new CPU:
>
> System Clock needs to be bumped. (5MHz, you say?)
> DRAM will be too slow, all 8 must be replaced
> SRAM will be too slow, must be replaced
> VIC cannot be made faster short of cryocooling, so it and SID will have
The VIC already is running running seperatly from the CPU. To be stock means
A) no modifications or any of that.
> to be carved off into a separate "bridge" that continues to run at 2Mhz
> tops. Circuitry will need to be added between bridge and main unit to
> handle synchronization of writes/reads across the bridge
> SID cannot be made faster, so it'll have to be carved out
> EPROM will be too slow. Replace
>
> What are we left with? A new computer... It will not be a 64 at that
point.
Why do we bother to worry about stock these days,
> (Academically interesting, but largely irrelevant 5Mhz/10MHz Mensch
> musing deleted)
Actually it has some relation to the internal IC.
VIC-II and SID on the C-128 were separately clocked because the C-128 system
bus would be 2 MHz when the 8502 is clocked to 2 Mhz. The System bus is very
much in sync with the CPU. The 8522 are moved to 2 MHz when the 8502 is
moved to 2 MHz.
> Bill is talking about the digital only ICs. He did not help in SID or
> VIC development. Those devices are MUCH more limited in how fast they
> can operate.
Aboe noted. The VIC-II and SID were seperately clocked and the VIC-II is
typically disabled at 2 MHz. If you didn't know the VIC-II was modified
hence the 856x number so they would be compliant enough.
The 858x was similar but I recall the SID is still functioning even in FAST
mode.
> And, who cares what the 6522 can do, as it cannot replace a 6526 CIA?
> It has no free running counter, no TOD, the registers are in different
> locations. Forget the 65C22 or its derivatives.
If you want the equivelent go to 65c134 (Watch-Dog timer / TOD)
The 65c22 is NOT 6522 and go read the specs. The 6526 is nothing more than a
bug-free 6522.
Read the 65c22 specs -
http://www.westerndesigncenter.com/wdc/datasheets/w65c22s.pdf
You count of the timer. In fact the 65c22 is essentially a 6526 minus the
TOD. As for register locations - it don't matter. If you are going to be
operating at higher clock rate then you would be talking about a new
computer system anyway.
> Transmissin line problems are simply that above certain speeds, you can
> no longer treat a wire as a conduit of electricity, but as a radiator or
> electromagnetic radiation (an antenna). Antennas demand impedence
> matching, or they "ring":
Ok.
> If a square wave hits the end of the wire that has a 50 ohm "impedence"
> (impedence is like resistance, but has an AC component to it), and there
> is simply a pin and some solder at the end of that wire, the signal will
> turn around and travel backwards through the same wire, wreaking havoc
> with the portion of the wave behind it on the wire. And, if it doesn;t
> find an impedence match on the source end, it turns around and comes
> BACK, which then looks like a delayed version of the same signal. So,
> in a worst case scenario, you start sending bits, but at the other end,
> you get a straight 5v signal (the delayed version of the signal fills in
> the 0volt holes in the waveform, and turns it into a constant 5v line.
> At 5MHz, the effect is not as pronounced as at higher speeds, but it is
> there. Distance effects how it operates, as the ringing and repeating
> of the signal changes as the cable is longer or shorter (length = time
> of propogation).
>
> Note also that on a stock 64, fast load coders assume a 1 cycle delay
> due to propogration delay for bits to come in on serial bus. (So, if
> the bit is placed on the CIA output pin at time t, it will not arrive at
> the 1541 until time t+1us. At 5Mhz, that's a 5 cycle delay.
First, if you are going to operate at 5 MHz, the drive would be operating at
5 MHz too.
In syncronous communication - both sides must match clock.
Certainly at 5 Mhz, you would be adjusting the onboard components like
resistors. The wires themselves ain't the problem. The 8522 is NOT software
driven in BURST mode and operates under a syncronous communication
philosophy. Now, the wire isn't the problem. The resistors and Ohm needs to
be adjusted. Ok Ohm's law.
Peter van Merkerk
> "Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote ...
>
>>True but 8522 as in the C-128 has a special burst protocol that allowed
>>faster protocol speed operations matching that of the "FAST Clock". This
>>equals upto 16 Mbps (2 MBytes per second) based on the 2 MHz clock source.
>>The 8522 is an enhanced 2 MHz version of the 6522/6526 with enhancements.
>
>
> Rick, me thinks you are pulling numbers out of your hat again. While the
> "fast" serial protocol of the C128 and 1571/1581 is much faster than the
> "slow" serial protocol of the C64/1541, there is no way it will do 2 MBytes
> per second.
You are correct Sam. The 16 Mbps figure is total bullshit.
There are several reasons why the C128 cannot even come close to that
number. The I/O chips including the CIA's always run at 1 MHz, even when
the C128 is running in FAST mode. Also with burst mode still only one
bit at a time is transfered. Since the CIA can only shift one bit every
four clock cycles the theoretical limit with the "burst" or "fast"
protocol is 0.25 MBits/sec, or about 31 KBytes a second. That is without
protocol overhead, and assuming the processor can keep the serial bus
fully occupied.
The burst mode is based on letting the CIA chips doing the actual
shifting of bits in and out rather than the processor. This way the
processor only has to read or write complete bytes. When using slow (C64
style) transfers the processor has to process each bit separately. This
means that the processor has do quite a bit of work for every bit
received or send. In fact with C64 style transfers the processor has to
do more work for a single bit than it would have to do for a byte in
burst mode.
Compared to todays standards the FAST serial bus protocol as found on
the C128 and the 1571 is still extremely slow. But it was adequate at
the time since the drive mechanics were the limiting rather than the
serial bus itself, like it was on the C64.
> Try doing a little testing with your C128, and you will see that I am right.
If you are interested in facts rather than fiction, read the Programmers
Reference Manual of the C128. Though I suspect Rick prefers his own
fantasy numbers.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl
Peter van Merkerk
> But, if you put in a new CPU:
>
> System Clock needs to be bumped. (5MHz, you say?)
> DRAM will be too slow, all 8 must be replaced
> SRAM will be too slow, must be replaced
> VIC cannot be made faster short of cryocooling,
Even with cryocooling, running the VIC at a higher clock speed would
affect the video timing, which would make it pretty useless.
Rick Balkins
"Peter van Merkerk" <mer...@deadspam.com> wrote in message
news:2nfe90...@uni-berlin.de...
> Sam Gillett wrote:
> > "Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote
...
> >
> >>True but 8522 as in the C-128 has a special burst protocol that allowed
> >>faster protocol speed operations matching that of the "FAST Clock". This
> >>equals upto 16 Mbps (2 MBytes per second) based on the 2 MHz clock
source.
> >>The 8522 is an enhanced 2 MHz version of the 6522/6526 with
enhancements.
> >
> >
> > Rick, me thinks you are pulling numbers out of your hat again. While
the
> > "fast" serial protocol of the C128 and 1571/1581 is much faster than the
> > "slow" serial protocol of the C64/1541, there is no way it will do 2
MBytes
> > per second.
>
> You are correct Sam. The 16 Mbps figure is total bullshit.
The 16 Mbps is based on parallel speed of 2 MHz @ 8 bit wide. The Serial is
1/8th that.
The REU has to operate at 1 MHz NOT 2 MHz.
2 MHz at 8bit parallel = 16 Megabits per second. The 8522 operates in two
mode - serial and parallel. In serial its 1 bit per 1 or 2 cycle(s) NOT
bytes per cycle. Mis-reading and misunderstanding. In 2 MHz - if you
dedicate WHOLE clock and move system bus to Full 2 MHz (thus - disabling the
VIC-II anyway).
Type FAST and VIC-II is disabled. Then run BURST mode on the drive.
PHI2 is also what times the 8502 if I recall right. What sets the VDC to 2
MHz mode.
The VIC-II has nothing to do with the 2 MHz mode as it is NOT in operation.
The Serial bus is NOT operating at 16 Mbits per second but 2 Mbits per
second. Mbps = Million "bits" per second and Mega is "million" so Mbps also
equals Mbits per second (aka Megabits per second)
MBps is MegaBytes per second. The capital B indicates bytes where the
lower-case b indicates bits. BIG BIG difference. The bits per second is
1/8th the speed of bytes per second. This MEANS that if I said 2 Mbps then
that means 250Kbytes per second maximum. Get it. When the writing is misread
or misunderstood because it appears some of you are thinking Mbps means
Megabytes per second and thinking Megabytes per second = Megabits per
second. WRONG !!!! Megabytes per second is 1000 or 1024 Kilobytes per second
where as 2 Megabits per second is 250 or 256 Kbytes per second but since we
are talking in terms of telecommunication we use the 1000 scale and NOT the
1024 scale and thus we are talking 250,000 bytes per second when I say 2
Mbps NOT 2,000,000 bytes per second. Got it now guys.
Hopefully this clarifies what is being said.
> There are several reasons why the C128 cannot even come close to that
> number. The I/O chips including the CIA's always run at 1 MHz, even when
> the C128 is running in FAST mode. Also with burst mode still only one
> bit at a time is transfered. Since the CIA can only shift one bit every
> four clock cycles the theoretical limit with the "burst" or "fast"
> protocol is 0.25 MBits/sec, or about 31 KBytes a second. That is without
> protocol overhead, and assuming the processor can keep the serial bus
> fully occupied.
CIA versus 8522 means comparing 6522 with 8522.
The reason the 8522 doesn't go to 2 MHz is because the diskdrives use 6522.
This is because the disk drives never had the 8522 chips. If they did - this
would have double the data rate because 8522 must sync with the disk drive
I/O (hence the 6522) to operate its BURST mode. Hence why it is called
"syncronous communication".
> The burst mode is based on letting the CIA chips doing the actual
> shifting of bits in and out rather than the processor. This way the
> processor only has to read or write complete bytes. When using slow (C64
> style) transfers the processor has to process each bit separately. This
> means that the processor has do quite a bit of work for every bit
> received or send. In fact with C64 style transfers the processor has to
> do more work for a single bit than it would have to do for a byte in
> burst mode.
>
> Compared to todays standards the FAST serial bus protocol as found on
> the C128 and the 1571 is still extremely slow. But it was adequate at
> the time since the drive mechanics were the limiting rather than the
> serial bus itself, like it was on the C64.
>
> > Try doing a little testing with your C128, and you will see that I am
right.
>
> If you are interested in facts rather than fiction, read the Programmers
> Reference Manual of the C128. Though I suspect Rick prefers his own
> fantasy numbers.
The limiting factor to 1 MHz is due to disk drives having 6522/6526 not
8522.
The reason for the 85xx number series was that the chips were 2 MHz
operational except for the analog components. The 8522 like the 8502 ran at
a switchable speed operation between 1 or 2 MHz. The limiting factor will be
the syncronizing with the clock of the drives I/O.
The serial bus was syncronous. If your device that you are communicating
with was NOT 2 MHz then it would have to sync to 1 Mhz. The 6522 used in
most of our favorite 1541, 1541-II and even in many 1571s were operating at
1 MHz based on a 6502 and a 6522 controller board and NOT 8502 + 8522 chips.
The limit can occur at either end.
If the drive controller is 1 MHz then the 8522 has to clock down to 1 Mhz to
syncronize and communicate so the 128 wouldn't be talking to fast for the
disk drive controller to understand. They never brought the I/O and main MPU
in the disk drives to 8502/8522 until maybe in much later drive system
(don't think they ever) because it would make the drive more expensive.
Dave Ross
On Thu, 5 Aug 2004, Rick Balkins wrote:
> The limiting factor to 1 MHz is due to disk drives having 6522/6526 not
> 8522.
>
> The reason for the 85xx number series was that the chips were 2 MHz
> operational except for the analog components. The 8522 like the 8502 ran at
> a switchable speed operation between 1 or 2 MHz. The limiting factor will be
> the syncronizing with the clock of the drives I/O.
Rick, I don't know where you got this information, but it is incorrect.
The 6526A used in the C128 is rated for 1MHz & 2MHz operation.
Source: http://www.funet.fi/pub/cbm/documents/chipdata/6526.zip
The 6510 is rated for 1MHz, 2MHz, or 3MHz operation.
Source: http://www.funet.fi/pub/cbm/documents/chipdata/6510.zip
The video portion of the VIC-II and the SID are both rated at 1MHz because
of timing issues. Still, all I/O within the C128 happens at 1MHz.
"Since the I/O devices, SID, etc., are rated at 1MHz only, stretching of
the 2MHz clock is used to allow these parts to be accessed directly by the
2MHz processor and still keep throughput to a maximum [...] The clock
sources and clock-stretching capabilities are generated by the VIC chip."
Source: C128 Programmer's Reference Guide, p 569.
If I recall, the 85xx designations were used because the new chips are
HMOS-II based, and not done in NMOS like the 65xx series.
Dave Ross
On Thu, 5 Aug 2004, Rick Balkins wrote:
> Actually it has some relation to the internal IC.
> VIC-II and SID on the C-128 were separately clocked because the C-128 system
> bus would be 2 MHz when the 8502 is clocked to 2 Mhz. The System bus is very
> much in sync with the CPU. The 8522 are moved to 2 MHz when the 8502 is
> moved to 2 MHz.
The VIC-IIe is not "separately clocked" from anything. In fact, it
*generates* the clocks used in the 128, a holdover from the original
VIC-II design.
"SYSTEM CLOCK CONTROL
The new VIC chip generates several clocks used by the C128 system. The
main clock is the 1MHz clock, which operates at approximately 1MHz at all
times. Most bus operations and all I/O operations take place in reference
to this clock. The next clock to consider is the 2MHz clock. This clock
clocks selected system components, such as the processor, at 2MHz when in
2MHz mode. The VIC chip monitors the /IOACC input, which indicates the
access of an I/O chip, and when asserted, will stretch the 2MHz clock to
synchronize all 2MHz parts with the 1MHz I/O parts. Finally, the last
clock is the Z80 clock, which is a 4MHz clock that takes place only during
the low half of the 1 MHz clock. Since all timed I/O parts look only at
the 1MHz clock, all I/O timings remain the same no matter what the 2MHz
clock is doing."
Source: C128 Programmer's Reference Guide, p 589.
Also note the schematic on page 727 which clearly shows that the 6526 is
connected to the 1MHz clock output of the VIC-IIe, and not the 2MHz clock.
The same is shown for the SID on page 722.
> The 858x was similar but I recall the SID is still functioning even in FAST
> mode.
The SID functions because it is attached to the 1MHz clock generated by
the VIC-II. Accessing the SID in FAST mode causes the "clock stretching"
described above.
The VIC-IIe probably could have been made to still generate video while
the system ran at 2MHz, but the designers probably decided that they had
bolted enough new functionality onto the die as it was.
- Dave
Rick Balkins
"Dave Ross" <wats...@ten.tsacmoc> wrote in message
news:Pine.LNX.4.58.04...@alice.local...
HMOS-II is still depletion-load technology.
The C-128 had 8526 - sorry it was 8526 not 8522.
The purpose of HMOS was faster clock operations at lower power current.
Since all NMOS including the HMOS depletion load technology were designed
for 5 MHz operations to begin with but were simply clocked at 1 Mhz. This
did also apply not just for the 6502 but for their other digital I/O chips.
Ok - it may be clocked 1 Mhz. Though - you could split the 2 MHz across the
three chips and disconnect the 1 MHz feed to it but it would move the 8526s
faster than usual. The 8526 was design with intent of 2 Mhz operation. The
reason they may have fed it a 1 Mhz clock is probably so the 8526s don't
outtalk the disk drives which were running at 1 Mhz.
Ok, we are talking design specs of the chip vs the applied configuration of
the chip. So we debated over this long enough. The 8502 was design for 2 MHz
because of the HMOS-II and the same benefit would apply to the 8526 as well.
Just the C-128 might haved it limited to 1 Mhz so users don't have to modify
the drives to run at 2 MHz. Ok, they could have clocked the I/O at 2 Mhz but
trying to keep the 8526 from talking to fast for the 1 Mhz clocked disk
drives. This can make sense for that purpose because people would still plug
in the old 1541 and the drives didn't have 2 MHz I/O. This way - you be
correct and it would make sense to keep the 8526 clocked at 1 MHz even
though it would ran at 2 MHz just fine.
Jim Brain
> 8522 in BURST mode doesn't require CPU intervention. The number of clock
> cycles to fetch a byte may be the slow part. This can be solved by putting a
> 4 MHz CPU.
intervention to load or store data.
Rick Balkins
> Sorry, no burst mode. Check your datasheets. CIA ALWAYS requires CPU
> intervention to load or store data.
>
The CIA 6526 does indeed have the feature but BURST mode is NOT a datasheet
term.
The 6522 originally was design to operate serial without CPU intervention
but had a bug in the serial communication port. The 6526 indeed does have
the BURST mode because the 6526 had the bug in ther serial port fixed. The
serial port was originally design so that data would be handled just like
how the BURST mode is done on the C128. The C-128 had finally got the ports
rewired so you can get the timing.
To enable burst mode - you have to do a few rewiring on the C64. BURST mode
simply refers to the bug-fixed serial port of the 6526 which allowed it to
do without CPU intervention.
Read - http://www.cs.tut.fi/~albert/Dev/burst/
"Commodore disk drives 1570/71 and 1581 implemented a new fast serial
protocol to be used with the C128 computer. This synchronous serial protocol
speeds up data transfer between the computer and the drive ten-fold. The
amazing thing is that this kind of serial protocol was supposed to be used
in VIC-20 and the 1540 drive until it was discovered that a hardware bug in
the 6522 VIA (versatile interface adapter) chip prevented the reliable use
of the chip's synchronous serial interface.
A working synchronous serial port would've allowed whole bytes to be sent in
both directions without processor intervention with the maximum speed of one
bit per two clock cycles. Without a bug-free synchronous serial port the
transfer had to be slowed down considerably so that the receiver has a
chance to detect all changes in the serial bus lines. This became the dead
slow software-driven Commodore serial protocol. "
This bug in the Serial port interface in the 6522 prevented the reliable
operations of the port and thus required the software transfer protocols.
The BURST mode simply takes advantage of the fixed synchronous serial
interface which was fixed in the 6526 (not tooken advantage in the C64 -
requires a little rewiring to take advantage) and 8526.
The CIA does have BURST mode but that is called synchronous serial
interface. The 6522 does but it has a bug. The 65c22 may not have this bug
either.
MORE reading from the site:
"Synchronous Serial
The complex interface adapter (6526 CIA) chips used in Commodore 64 and
later in Commodore 128 have bug-free synchronous serial interfaces: serial
data and serial clock inputs/outputs. In input mode, each time a rising edge
is detected in the serial clock pin (CNT), the state of the serial data (SP)
is shifted into a register. When 8 bits are received the accumulated bits
are moved into the serial data register and a bit is set in the interrupt
status register to reflect this. If the corresponding interrupt is enabled,
an interrupt is generated.
In output mode the serial clock line is controlled by Timer A. The serial
clock is derived from the timer underflow pulses. When a byte is written to
the serial data register, the value is clocked out through the serial data
pin (SP) and the corresponding clock signal appears on the serial clock pin
(CNT). After all 8 bits are sent, the serial interrupt bit is set in the
interrupt status register.
Synchronous serial bus is used in C128/157x/1581 fast serial protocol. An
obsolete signal in the peripheral serial bus (SRQ) was taken into service as
the new fast (synchronous) serial clock line. The old serial data line
doubles as both slow and fast serial data line. And the old serial clock
line doubles as slow serial clock line and fast serial (byte) acknowledge
line.
The fast serial protocol is basically very simple. The side sending data
configures its synchronous serial port into output mode, the other side uses
input mode. The old peripheral serial bus clock line is controlled by the
receiving side and is used as an acknowledge: when the receiver is ready for
data, it toggles the state of the clock line. The actual data is transferred
using the synchronous serial ports. The sender writes the data to be sent
into the serial data register and waits for the transfer to complete. The
receiver waits for a byte to arrive into its serial data register. The
actual bit transfer is automatically handled by the hardware.
Both the drive and the computer must detect whether the other side can
handle fast serial transfers. The computer sends one fast byte when
commanding the drive to listen or talk and the drive sends a fast serial
byte back. The computer can in practice send the fast serial byte anytime
after the drive is reset and before the drive would send fast serial bytes.
If the computer received a fast byte, it can use the fast serial to talk to
the drive. The block transfer rate increases by a factor of ten, which is
mostly evident in the C128 loading speed. Even normal byte transfers become
faster by a factor of two. Only two, because the CHRIN and CHROUT transfers
must still be initiated by the slow serial clock and data lines that are
used to generate the EOI (last byte to send/receive) condition.
Modification to c64
To use burst fastloader with C64 we need to connect the CIA synchronous
serial port to the synchronous serial lines of the Commodore peripheral
serial bus. Two wires are needed: one to connect the serial bus data line to
the syncronous serial port data line and one to connect the serial bus SRQ
(the obsolete line for service request, now fast serial clock) to the
synchronous serial port clock line. Select the right connections depending
on whether you want to use CIA1 or CIA2.
1570/1,1581 C64
Pin1 SRQ Fast serial bus clk CNT1/2 User port 4/6
Pin5 DATA Data - slow&fast bus SP1/2 User port 5/7
Top view - old c64, CIA1
User port Cass port Serial connector
|||||||||||| |||||| HHHHH behind:
|||||||||||| |||||| .-1 3 5-.
||______________________| 2 4 | / \
| CNT1 6 | // \\
|_______________________________| |||||
SP1 1 264 5
Top view - old c64, CIA2
User port Cass port Serial connector
|||||||||||| |||||| HHHHH behind:
|||||||||||| |||||| .-1 3 5-.
||________________________| 2 4 | / \
| CNT2 6 | // \\
|_________________________________| |||||
SP2 1 264 5
Solder the wires either to the resistor pack or directly to the user port
connector, but remember to leave the outer half of the connector free so
that you can still plug in your user port devices.
Then solder the other ends to the serial connector. Those left- and
rightmost pins are 1 and 5, respectively, so it is fairly easy to do the
soldering. You can also build a cable which connects those lines externally.
However, this modification has one important difference to the C128 fast
serial. In C64 the serial SRQ line is also connected to the cassette read
input. When this modification is present you can't use burst-capable drives
when the cassette drive is connected. By cutting a trace between SRQ and
cassette read you can probably make the cassette and fast serial work at the
same time, but I don't like these kind of destructive modifications.
Besides, the trace could be in a different place in different machines.
The C128 hardware includes a buffer driver between SRQ and the cassette read
line so that cassette activity or cassette drive presence will not disturb
the fast serial port. It also has a two-directional buffer that connects SRQ
and DATA to the CIA1 synchronous serial port. The direction is controlled by
the MMU chip. These buffers are required to hide the fast serial connection
is C64 mode.
In C128 you should either use CIA2 or connect the wires through a
"two-channel" on-off switch. Otherwise the CIA1 connection will interfere
with the C128 native mode operation. The switch makes it possible to disable
the modification in C128 mode and enable it again in C64 mode.
Theoretically you should be able to make the modification work with C128 in
both modes by first connecting the wires and then cutting/bending up U58
(74LS03) pins 3 and 8, and U60 (7407) pins 6 and 8. This disables the C128
fast serial hardware and the added wires will perform their function in C128
and C64 modes. I have not tested this, so if you try it, I would be very
interested in your results."
There is a software code but I am not typing it in for length. You can go to
the site and see. The C64 does indeed have the functional capability to go
into the "BURST" mode but you would have to build the routine into your own
software and make a few mods to the hardware.
BURST mode simply is a "Commodore" protocol that enables the use of the
bug-fixed Sync Serial Interface and thusly not require the SLOW SLOW
software-driven Commodore Serial Protocol. (Kernal driven - still
technically software driven)
Jim Brain
> Arguing these points with Rick is futile. He has no technical know-
> ledge to speak of and is just pulling numbers out of his ass and
> posting google results.
>
I always try to be optimistic. But, Rick, your information is just
incorrect in so many places. Not 1.0 MHz instead of 1.02MHz wrong, but
fundamentally wrong.
VIC IIe is not clocked separate.
The 6526 is much more than a bug-free 6522
CIA cannot bypass CPU in "burst mode"
6526 et al don't even have a burst mode. That's just C128/1571
marketing speak for using the already present shift register
65c22 is CMOS 6522, 65C22s is static 65c22. Bill's tweaks are extremely
minor, a few handshaking improvements.
In synchronous operation, both sides match clock by definition, because
the CLK signal goes with the data
The 8522 (really 8521, but that's a trivial issue) is indeed software
driven in ALL modes
My only issue is that this stuff gets archived. Someday, some poor sap
is going to google one of these topics,find this stuff, and think it's
close to correct...
Jim Brain
My statements relate to transferring more than 1 byte at those speeds.
I knew about CIASDR already (I was one of the first folks to obtain the
initial information about the 6522 bug from Jim Butterfield)
To be clear. The 6526 family can transfer 1 byte of data without CPU
intevention at CLK/32 bytes/sec using the serial shift register. 1 byte
of data can be transferred at CLK bytes/sec in parallel mode (using the
PORTA or PORTB)
Data can be loaded into CIA at CLK/8 bytes/sec in either mode. So,
serial max speed is CLK/32, while parallel mas speed is CLK/8
Jim
Dave Ross
On Thu, 5 Aug 2004, Rick Balkins wrote:
> The C-128 had 8526 - sorry it was 8526 not 8522.
The only reference I can find to an 8526 used in Commodore equipment is in
a wiki at c2.com. I could not find any other references to this chip
anywhere.
All other references, including Commodore's own schematics, show two
6526A's in the C128.
Commodore used the 8520 (Amiga CIA) in some 1581s and C128s. The chip is
virually identical to the 6526 except that the TOD clock behaves
differently. When they did use this alternate chip in the 128, they only
replaced one of the CIAs with it, presumably because this introduced
incompatiblities.
See this thread from a few years back:
http://groups.google.com/groups?threadm=76b8501b.0111151039.66dbc6b6%40posting.google.com&rnum=1&prev=/groups%3Fq%3D8520%2B%2522commodore%2B128%2522%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D76b8501b.0111151039.66dbc6b6%2540posting.google.com%26rnum%3D1
> Ok, we are talking design specs of the chip vs the applied configuration
> of the chip. So we debated over this long enough. The 8502 was design
> for 2 MHz because of the HMOS-II and the same benefit would apply to the
> 8526 as well. Just the C-128 might haved it limited to 1 Mhz so users
Read my post again. The 6526 was designed for 2MHz operation as well, and
the 6510 was designed for up to 3MHz operation. Higher clock rates are
not a benefit of the HMOS-II design. It's likely that they switched the
65xx family to this new technology because they wanted to use one set of
equipment to make 8-bit and Amiga chips.
Rick Balkins
> I always try to be optimistic. But, Rick, your information is just
> incorrect in so many places. Not 1.0 MHz instead of 1.02MHz wrong, but
> fundamentally wrong.
>
> VIC IIe is not clocked separate.
> The 6526 is much more than a bug-free 6522
> CIA cannot bypass CPU in "burst mode"
> 6526 et al don't even have a burst mode. That's just C128/1571
> marketing speak for using the already present shift register
> 65c22 is CMOS 6522, 65C22s is static 65c22. Bill's tweaks are extremely
> minor, a few handshaking improvements.
> In synchronous operation, both sides match clock by definition, because
> the CLK signal goes with the data
> The 8522 (really 8521, but that's a trivial issue) is indeed software
> driven in ALL modes
>
> My only issue is that this stuff gets archived. Someday, some poor sap
> is going to google one of these topics,find this stuff, and think it's
> close to correct...
Ok, I misread some of the info. The 65c22 indeed may have fixed the
synchronous serial interface which indeed is what the BURST mode is. BURST
mode is a kernal subroutine that uses that mode of the 6526 and 8526 which
even the original 6522 had but it didn't work.
This is what the 6522 documents called the "serial port". This was NEVER
connected in the C64 in such fashion. In fact ther C64 serial bus mode
wasn't all that much better than RS232 in this odd sense except it was
"syncronous" but not working all the way. Being that everything was software
driven.
The 65c22 does has free-run mode. Read the documents from WDC. The 65c22 in
fact is just a 6526 without TOD. Want a TOD - get a 65c134 which give you a
Real Time Clock which in fact is what TOD is fundamentally.
The W65C22S Versatile Interface Adapter (VIA) is a flexible I/O device for
use with the W65C series microprocessor family. The W65C22S includes
functions for programmed control of two peripheral ports (Ports A and B).
Two program controlled 8-bit bi-directional peripheral I/O ports allow
direct interfacing between the microprocessor and selected peripheral units.
Each port has input data latching capability. Two programmable Data
Direction Registers (A and B) allow selection of data direction (input or
output) on an individual line basis. Also provided are two programmable
16-bit Interval Timer/Counters with latches. Timer 1 may be operated in a
One-Shot Interrupt Mode with interrupts on each count-to-zero, or in a
Free-Run Mode with a continuous series of evenly spaced interrupts. Timer 2
functions as both an interval and pulse counter. Serial Data transfers are
provided by a serial to parallel/parallel to serial shift register.
Application versatility is further increased by various control registers,
including an Interrupt Flag Register, an Interrupt Enable Register and two
Function Control Registers. The IRQB output is an open drain.
Features of the W65C22S
a.. Advanced CMOS process technology for low power consumption
a.. Compatible with NMOS 6522 devices
a.. Low power consumption
a.. Two 8-bit, bi-directional peripheral I/O Ports
a.. Two 16-bit programmable Interval Timer/Counters
a.. Serial bi-directional peripheral I/OPort
< ^- The BURST protocol allows the use of this port based on the clock feed
to it. The bug in the ORGINAL 6522 was fixed in the 6526 and 8526 (not
8522).
The 65c22 had this bug fixed too. Since William D. Mensch whom which
designed the many chips with Chuck Peddle used by Commodore. William D.
Mensch fixed this because he was the main designer that design the CMOS
version and fixed bugs which he knew about and this STATIC version has also
a few other known improvements not to mention that they are now operating at
20 MHz. The Commodore serial port just wasn't wired to make use of this
bug-fixed serial I/O ports off a timer like it was suppose to be designed.
If you rewired the 6526 in the C64 - like how it is configured on the
C-128 - the BURST features would become functional and the speed of data
will improve dramatically. The problem in the un-modded stock C64 is that
the serial port was wired like the VIC-20 and just didn't take advantage of
the 6526 being bug-fixed. The bug was in the original 6522 serial
bi-directional port and thus they had to do alot of things like running all
the stuff software driven. The serial port was intended to be wired like it
is on the C-128 in "Fast Serial Bus" configuration. This could be done on
the C64 but they just didn't do it even though they fixed the hardware bug.
The C-128, they wired the port to take advantage of what the bidirectional
serial port of the CIA/8526 was capable of. This hence was called BURST mode
aka Fast Serial Bus protocol which wasn't really much of a protocol like the
software driven protocol was. It was just a protocol to make the data run in
a synchronous data stream.
You could rewire your C64 Serial port and the speed would go much faster but
you can't use the stock commands. You would need to run a special loader or
DOS Wedge cartridge which would have your "Fast Loader Protocol" but you
would need to make the mod to the serial port as well. The BASIC just
doesn't support usage of the Burst protocol because they never implemented
the usage until the C-128. BURST nothing more then a Kernal routine making
full use of the bi-directional serial port. You just have to rewire the
connector like it is on the C-128. I provided the documentations for doing
so. There is also alot of stuff that was not mention in the PRG.
a.. Enhanced "handshake" feature
a.. Latched Input/Output Registers on both I/OPorts
a.. Programmable Data Direction Registers
a.. TTL compatible I/O peripheral lines
a.. Single 1.8V to 5V power supply
a.. Bus compatible with high-speed W65C02S and W65C816S
a.. Register and Chip Selects specified for multiplexed operation
W65C22S Datasheet
Complete W65C22S Datasheet is available for downloading
a..
Rick Balkins
> I always try to be optimistic. But, Rick, your information is just
> incorrect in so many places. Not 1.0 MHz instead of 1.02MHz wrong, but
> fundamentally wrong.
>
> VIC IIe is not clocked separate.
> The 6526 is much more than a bug-free 6522
> CIA cannot bypass CPU in "burst mode"
> 6526 et al don't even have a burst mode. That's just C128/1571
> marketing speak for using the already present shift register
Yes and No. BURST mode is a "Kernal" routine protocol aka Fast Serial Bus
protocol.
The 6526 had this and so did the 8526 but the 6522 didn't "quite" had this
because there was a bug. The C64 serial port isn't wired right to enable the
Burst. The 65c22 may have the bug fixed as well.
I didn't say it had a "Burst" mode in that context that I think you are
interpreting it as. The 6526's improvement is that it allows burst mode by
fixing a bug in the 6522 hardware in the shift register. The bug is why they
went with this awesomely slow protocol that we are familiar with in the
VIC-20 and Commodore 64. The 6526 had it fixed in the C-64 but they didn't
wire the port for using the Serial port that way. The C64 can do the "Burst"
mode if the port was rewired.
> 65c22 is CMOS 6522, 65C22s is static 65c22. Bill's tweaks are extremely
> minor, a few handshaking improvements.
> In synchronous operation, both sides match clock by definition, because
> the CLK signal goes with the data
> The 8522 (really 8521, but that's a trivial issue) is indeed software
> driven in ALL modes
Yes but on the C64 - it is not wired for using the "Fast Clock" like on the
C-128 even though it could be rewired for that.
> My only issue is that this stuff gets archived. Someday, some poor sap
> is going to google one of these topics,find this stuff, and think it's
> close to correct...
That is why c.s.c. is not the place to try to gather information entirely
from. There has been so much false information in the past to so my errors
is just one pebble out of the millions of pebbles thrown in the lake. (one
drop in the bucket out of many.)
Rick Balkins
that the speed of serial would be 1 bit in contrast to 1 byte. Ok.
"Jim Brain" <br...@jbrain.com> wrote in message
news:68EQc.234055$JR4.144634@attbi_s54...
Rick Balkins
probably for synchronization purposes.
"Dave Ross" <wats...@ten.tsacmoc> wrote in message
news:Pine.LNX.4.58.04...@alice.local...
>
>
> On Thu, 5 Aug 2004, Rick Balkins wrote:
>
> > The C-128 had 8526 - sorry it was 8526 not 8522.
>
> The only reference I can find to an 8526 used in Commodore equipment is in
> a wiki at c2.com. I could not find any other references to this chip
> anywhere.
>
> All other references, including Commodore's own schematics, show two
> 6526A's in the C128.
>
> Commodore used the 8520 (Amiga CIA) in some 1581s and C128s. The chip is
> virually identical to the 6526 except that the TOD clock behaves
> differently. When they did use this alternate chip in the 128, they only
> replaced one of the CIAs with it, presumably because this introduced
> incompatiblities.
24 bit counter if I recall from something I read. The 8526 is a 6526A in
HMOS-II process.
I saw on Google references to 8526. This was probably something that varied
from unit to unit or time. Basically the 8526 is just that.
I am fully aware of the 8520 ACIA or CIA (whatever - just refer to it as
Amiga's CIA)
> See this thread from a few years back:
>
http://groups.google.com/groups?threadm=76b8501b.0111151039.66dbc6b6%40posting.google.com&rnum=1&prev=/groups%3Fq%3D8520%2B%2522commodore%2B128%2522%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D76b8501b.0111151039.66dbc6b6%2540posting.google.com%26rnum%3D1
>
> > Ok, we are talking design specs of the chip vs the applied configuration
> > of the chip. So we debated over this long enough. The 8502 was design
> > for 2 MHz because of the HMOS-II and the same benefit would apply to the
> > 8526 as well. Just the C-128 might haved it limited to 1 Mhz so users
>
> Read my post again. The 6526 was designed for 2MHz operation as well, and
> the 6510 was designed for up to 3MHz operation. Higher clock rates are
> not a benefit of the HMOS-II design. It's likely that they switched the
> 65xx family to this new technology because they wanted to use one set of
> equipment to make 8-bit and Amiga chips.
HMOS-II was for power efficiency. Like CMOS.
HMOS-II allowed for smaller die core more efficiently than NMOS. I could say
that it could be as you said. As for the 8502,6502 and all - they all are
design operational around 3 MHz since the first 6502 was design around 3
MHz. Most were simply clocked at 1 MHz due to things like DRAM speed vs
price. Remember the story of the 10 MHz 6502. Ok, all of the CPU even the
ones stamped for 1 Mhz is identical to the 3 Mhz model. The 65xx digital
chips are designed to double its rated clock. Ok the 1 & 2 Mhz models are
actually 3 Mhz identical cores so they have a max speed of 6 MHz. 5 MHz is
about the limit before signal quality degrades as the chip goes faster. The
key to the speed capabilities of the chip is directly related to the ion
implants. Given that the 6502 can double its rated clock. The rated clock is
based on the ion implants but the 1 Mhz and 2 Mhz parts happen to actually
used the same amount of ion implants as the 3 Mhz - it didn't really matter.
(There may be a few that just ain't going to work like this.) When they
accidently double the ion implant - the chip was technically rated for 6 Mhz
operation and was able to run at 10 Mhz at aproximately the same temperature
as a normal 6502 at 5 Mhz. HOT!!!!.
This in fact essentially made the chip maximum speed of operation
aproximately 12 Mhz. Ok heatsinks is not taken into account. Not bad for the
experiment. The conservative core design is equivelently done to the 6522s
and 6526s chips.
So one can nearly double its rated clock performance. The potential speed of
the chips will be some 5 Mhz. Don't push beyond that or the chip starts to
really heat up and the transistor/gates/latches won't operate fast enough.
This is still a factor in the 65c816. The SuperCPU is merely an
"overclocked" 65c816 which is a 14 Mhz part running at 20 Mhz which can max
out to around 25 Mhz. 14x2 = 28Mhz.
You would not want to quite double the clock because it gets somewhat
unreliable because you may get it to work on a good day because core
temperature is borderlining "overheating". You would need some sort of
cooling solution to move the 14 Mhz part to say 2.5x overclock - 14x2.5 = 35
Mhz.
The design of the chips have been quite conservative to allow for such clock
doubling which is NOT something you see in the Pentium 4. It would be like
running a 2.5 Ghz P4 at 5 Ghz.
Sam Gillett
"Rick Balkins" <rickbalki...@nospam.wavestarinteractive.com> wrote ...
> "Jim Brain" <br...@jbrain.com> wrote in message
> news:YOCQc.251669$Oq2.85219@attbi_s52...
>
>> My only issue is that this stuff gets archived. Someday, some poor sap
>> is going to google one of these topics,find this stuff, and think it's
>> close to correct...
>
> That is why c.s.c. is not the place to try to gather information entirely
> from. There has been so much false information in the past to so my errors
> is just one pebble out of the millions of pebbles thrown in the lake. (one
> drop in the bucket out of many.)
Drop in the bucket? More like the flood over the spillway! ;-)
Rick Balkins
> Drop in the bucket? More like the flood over the spillway! ;-)
>
There is alot more inaccuracy accumulated over 1995-2000 than this. This may
be archived but this is only a matter of a thread compared to 1000s of
thread of BS that is already archived among everything else. So yeah, it is
just a drop in the bucket. Ok, it is more like a drop in lake. It is only
remembered most because it is quite recent.
Let's get pass this point and move on.
Jim Brain
> Serial will be no faster than 1/8 the speed of the parallel due o the fact
> that the speed of serial would be 1 bit in contrast to 1 byte. Ok.
Hmm.... I suppose in that New Math, for sufficiently large values of 32
and sufficiently small values for 8.
Around here, I have not switched me or my adding systems here to "New
Math", so they all report 8/32 as 1/4....
Jim, has to get his calculator fixed, as it's generating incorrect
results", Brain
>>To be clear. The 6526 family can transfer 1 byte of data without CPU
>>intevention at CLK/32 bytes/sec using the serial shift register. 1 byte
>>of data can be transferred at CLK bytes/sec in parallel mode (using the
>>PORTA or PORTB)
>>
>>Data can be loaded into CIA at CLK/8 bytes/sec in either mode. So,
>>serial max speed is CLK/32, while parallel mas speed is CLK/8
--
Sam Gillett
"Jim Brain" <br...@jbrain.com> wrote ...
> Jim, has to get his calculator fixed, as it's generating incorrect
> results", Brain
Jim, there is nothing wrong with your calculator.
Someone else in here keeps pulling numbers out of his hat. He needs to get
his hat fixed, as it frequently generates incorrect numbers! ;-)
Rick Balkins
> Hmm.... I suppose in that New Math, for sufficiently large values of 32
> and sufficiently small values for 8.
Hmmm.......... There is 8 bits per byte. 8 bit parallel sends 1 whole byte
at a time.
Serial sends 1 bit at a time so serial would not be faster than 1/8th the
speed of the parallel. No, I am not comparing the "Parallel" port as in the
Printer port. The serial port can NOT be faster than 1/8th the Expansion
port which is 8 bit parallel. Ok, this is based on having the clock. Ok. If
you gave the serial a higher clock than then the Expansion port than it is a
WHOLE different story.
> Around here, I have not switched me or my adding systems here to "New
> Math", so they all report 8/32 as 1/4....
The serial port will not be faster than 128KBytes per second at 1 MHz. If
the bus takes two clock cycles to move a byte than that be 64 Kbytes per
second.
Jim Brain
My original answer stands. FOr a given CLK speed, CIA serial is /14 as
fast as CIA parallel.
> The serial port will not be faster than 128KBytes per second at 1 MHz. If
At CLK=1MHz, CLK/32 is fastest you can move bytes via shift register on
CIA, which is 31,250 bytes/sec
In parallel mode, you cna move 125,000 Bytes/sec.
Caveat: It's late, so I used 1,000,000 for 1 MHz, actual numbers will
vary via PAL/NTSC. As well, I assume no badlines, pure tight loop code
here.
Jim
Jim Brain
> Rick Balkins wrote:
>
> My original answer stands. FOr a given CLK speed, CIA serial is /14 as
> fast as CIA parallel.
>
>> The serial port will not be faster than 128KBytes per second at 1 MHz. If
>
> At CLK=1MHz, CLK/32 is fastest you can move bytes via shift register on
> CIA, which is 31,250 bytes/sec
> In parallel mode, you cna move 125,000 Bytes/sec.
>
> Caveat: It's late, so I used 1,000,000 for 1 MHz, actual numbers will
> vary via PAL/NTSC. As well, I assume no badlines, pure tight loop code
> here.
And, to be pedantically correct, if you transfer via REU or SCPU, the
ratio can be as high as 1/32 (1 byte/CLK via parallel, but still
1byte/32 clocks in serial mode)
Rick Balkins
transfer routine making it take 2x times as many instruction cycles as the
serial routine takes to transfer a single bit.
Though this is caused by a different issue in hardware. If the byte transfer
process was squeezed into 4 instruction cycles than yeah. This has to do
with how streamline they streamlined the serial bus.
"Sam Gillett" <samgille...@diespammermsn.com> wrote in message
news:A8iRc.5067$114....@nwrddc02.gnilink.net...
Peter van Merkerk
> Rick Balkins wrote:
>
>> Serial will be no faster than 1/8 the speed of the parallel due o the
>> fact
>> that the speed of serial would be 1 bit in contrast to 1 byte. Ok.
>
> Hmm.... I suppose in that New Math, for sufficiently large values of 32
> and sufficiently small values for 8.
>
> Around here, I have not switched me or my adding systems here to "New
> Math", so they all report 8/32 as 1/4....
>
> Jim, has to get his calculator fixed, as it's generating incorrect
> results", Brain
When one is determined enough in one's faith, trivialities like
rationalization and blatant, incontrovertible facts are merely
annoyances, and can be readily assumed to be nonsense.
Rick Balkins
of handling byte movement.
"Peter van Merkerk" <mer...@deadspam.com> wrote in message
news:2nme59F...@uni-berlin.de...
Sam Gillett
"Peter van Merkerk" <mer...@deadspam.com> wrote ...
> When one is determined enough in one's faith, trivialities like
> rationalization and blatant, incontrovertible facts are merely
> annoyances, and can be readily assumed to be nonsense.
Yes, and I understand that Rick is an ordained minister in The Church of the
Holy Serial Bus. ;-)
--
Best regards,
Sam Gillett
Out of my mind. Back in 5 minutes!
Russell Wallace
<rickbalki...@nospam.wavestarinteractive.com> wrote:
>The 6502 usually ran over 5
>MHz and so the doubly implanted devices ran at over 10 MHz.
I don't get this - is this guy really claiming the 6502 could run at 5
MHz even initially, and 10 MHz once they accidentally discovered how,
in the mid 70s? If so, why was it being clocked at 1 or 2 MHz in
computers built in the 1980s?
--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.
Jim Brain
> We already figured this out. It's settled. The issue is in the sloppy method
> of handling byte movement.
lda/sta.
I think sloppy might be a poor choice of words. It's just how long it
takes in a non-RISC CPU to get data through it, and there is not direct
memory-memory move opcode.
Jim