Graphic cards?
Cameron Kaiser
>Is it possible that we will see a graphic card to the C64 in the future or
>is it just to expensive to develop? I would like to see a cartridge with a
>graphic chip similar to VIC-III.
It would be nice to have control over a video card, like some SVGA card or
something. That's on my wish list.
--
Cameron Kaiser * cka...@stockholm.ptloma.edu * posting with a Commodore 128
personal page: http://calvin.flactem.com:3001/~spectre/ >> temporary <<
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/~spectre/cwi/ **
Rainer Buchty
|> >Is it possible that we will see a graphic card to the C64 in the future or
|> >is it just to expensive to develop? I would like to see a cartridge with a
|> >graphic chip similar to VIC-III.
|>
|> It would be nice to have control over a video card, like some SVGA card or
|> something. That's on my wish list.
Now, the question is what do you expect from such a card. Let's think about
an old ISA VGA card which (somehow) could be interfaced to your Commodore:
A complete picture in 640x400/256 cols needs 250kBytes to be transferred. This
transfer is limited to 1MB/s on a standard machine, so this transfer takes
abt. 1/4s. Even worse with bigger pictures and/or more colors... Such a device
could only be used as some kind of frame buffer - not for any kind of "motion
picture" such as games or even scrolling your GeoText window.
Ok, let's do it the DMA way and let the card fetch its video data directly.
Nothing must run faster than the PLA (85ns) which limits the transfer rate
to roughly 11MByte/s - our 250kByte picture could theoretically be fetched in
0.02s achieving a 50Hz frame rate. C64 DRAMs usually are 150ns "fast", thus
limiting the max. data rate to 6.67MByte/s lowering the frame rate to 27Hz.
However, no stock C64 will offer 250kB of memory. So we need to add the time
needed for REU or whatever data transfer running again with 1MHz... Again, think
of even bigger and/or true-color pictures.
And this is only theoretical. In real life that DMA transfer need to sync to the
standard C64 bus timing and especially the VIC DMA which will at least halve the
frame rate again. Switching off the VIC is no real option to me since I like the
idea of running multiple screens (e.g. VIC-native for GoDot control and VGA for
graphics display).
Personally, I think the best solution for any external graphics adapter is
(again) a separate computer (like e.g. the SCSI interface is one) offering some
kind of "video protocol". Instead of drawing a circle in memory one just sends a
command "c(m,r)" which will draw a circle with center point M and radius R.
Display PostScript, if you like.
Regards,
Rainer
--
Rainer Buchty, LRR, Technische Universitaet Muenchen
Phone: +49 89 289-25770, Fax +49 89 289-28232, Room S3240
Greg Nacu
ckaiser wrote...
c> Lars Forsberg <l...@pdc.kth.se> writes:
>Is it possible that we will see a graphic card to the C64 in the future or
>is it just to expensive to develop? I would like to see a cartridge with a
>graphic chip similar to VIC-III.
c> It would be nice to have control over a video card, like some SVGA card or
c> something. That's on my wish list.
I would like to see something developed that improves either the Resolution or
the colour depth... But I Don't think a SVGA card is the best idea. It leads
the way towards PCness a little too much for my comfort. I admit that the graphics
array in C64/128's is archaic, but to just stick on a SVGA card would make it
too similar to the PC in appearence.
Perhaps what Nate dannenberg mentions on his page... His digiMax soundCard
For playing Mods with his own ModPlay, has 4 8bit dac's built in... He hinted
at those Dac's being possibly capable of Modifying the Intensities of the RGB
used by the 128's 80 column VDC. THAT would be interesting. Because it would
keep most Current 'Classic' commodore users happy (due to the fact that it is
still using the original video circuitry), plus it would give us a greater color
depth through a sort of 'hardware hack'. Very cool.
Just my two cents. Maybe we should bug nate about it. :)
Greg_Nacu__/~
Lars Forsberg
only a few more things that you would like to add to a C64.
Is it possible that we will see a graphic card to the C64 in the future or
is it just to expensive to develop? I would like to see a cartridge with a
graphic chip similar to VIC-III.
/ Lars
Lars Forsberg
> |> It would be nice to have control over a video card, like some SVGA card or
> |> something. That's on my wish list.
>
> Now, the question is what do you expect from such a card. Let's think about
> an old ISA VGA card which (somehow) could be interfaced to your Commodore:
>
> [...]
>
> Personally, I think the best solution for any external graphics adapter is
> (again) a separate computer (like e.g. the SCSI interface is one) offering some
> kind of "video protocol". Instead of drawing a circle in memory one just
> sends a command "c(m,r)" which will draw a circle with center point M
> and radius R. Display PostScript, if you like.
Most graphic cards already got some kind of "video protocol" so that you
could easily draw lines and filled polygons. However, I don't think they
are following any standards and a video protocol standard is what the C64
needs. You shouldn't need to write several versions of your program
because there are several kinds of graphics cards.
I like the "video PostScript" idea, and that got me to think about a video
terminal from HP. This terminal was connected to the serial port as usual,
and you could use it as a normal terminal, but it also had a graphic mode
where you could write dots, lines, and maybe circles. A friend of mine
used it to show fractals from a Data General minicomputer.
At the time this terminal was made, there wasn't any standard protocol
(correct me if I'm wrong) for graphical terminals. My friends program
couldn't be run on any other terminal but HP's. A standard would have
made it terminal independent. MIT developed the X Window protocol later
on, and with that you had a standard. The X terminal was made, which
is a display terminal that communicates with a host computer system using
the X Window protocol. Nowadays we are using computers to act like X
Window terminals with a program called X server.
I want a graphic card for my C64 to make it able to show nice
pictures, not to play fast games. I don't know much about the X Window
protocol, but I think that using this protocol with a C64 is an
interesting idea. It will need an extra CPU on the graphic card and a
program for it so that it can communicate with the graphic CPU. If that
solution is a SVGA-card with an extra CPU that takes care of the
communication between the C64 and the SVGA-card doesn't matter, it's up to
the vendors of the card.
The problem with X is that it assume that the X terminal got a keyboard
and mouse, but I want to use my C64 as keyboard. I don't think this is a
problem if you're only going to show formatted text and graphics, i.e.
using only one way traffic.
/ Lars
Spiro Trikaliotis
Lars Forsberg schrieb in Nachricht ...
>Is it possible that we will see a graphic card to the C64 in the future or
>is it just to expensive to develop? I would like to see a cartridge with a
>graphic chip similar to VIC-III.
IMHO, the best solution would be to make an ISA adapter for the C64
expansion bus. Then we could physically connect graphic cards, net-
work cards, ISDN cards, ... to the C64, without developping the inter-
face for every device from scratch.
I see 2 possibilities for this:
A direct connection C64 <-> ISA, where ISA would be 8 bit in this case.
It's the easiest solution, but has the disadvantage that we only have
an 8 bit ISA and we must find a way to map the ISA addresses (which, in
fact, are even 2 address rooms, I/O and memory), so we would need some
means to do that mapping.
On the other side, we could use a bridge between the 65xx-bus and the
ISA bus, which would allow using even 16 bit ISA (AFAIK, there are
many cards out there which will not work on an 8 bit ISA bus). This
would even allow to use different timing on the ISA (I don't know if
all ISA cards are able to work with only 1 MHz or less!), and the
address mapping would be no problem anymore because we would have a
different address space!
I'm not sure if this bridge could be a passive one (only a PIA, VIA or
CIA), or better an active one (with some help of a processor, ASIC, or
whatever).
Has anyone done something like that, or is someone at least planning
to do so?
Spiro.
Carlsson, Anders
> This terminal was connected to the serial port as usual, and you
> could use it as a normal terminal, but it also had a graphic mode
> where you could write dots, lines, and maybe circles.
>
> At the time this terminal was made, there wasn't any standard
> protocol (correct me if I'm wrong) for graphical terminals.
I guess this is not some kind of Tektronix-emulation mode? Not
sure how common those were (I never saw one, only used 'xterm -t').
--
Anders Carlsson
Rainer Buchty
|> I would like to see something developed that improves either the Resolution or
|> the colour depth... But I Don't think a SVGA card is the best idea. It leads
|> the way towards PCness a little too much for my comfort. I admit that the graphics
|> array in C64/128's is archaic, but to just stick on a SVGA card would make it
|> too similar to the PC in appearence.
This is a funny point. I see various reasons why ISA, PCI and AGP turn(ed) up to
be bottlenecks in modern PC systems - but really no reason why at least this idea
shouldn't be used on an old Commodore.
This point of exclusiveness does result in nothing more than costs. Take Amiga
graphic cards for example: They used the same chips - but just another bus
interface which made the cards 2 to 3 times more expensive than their PC mass
market counterpart. You do not fear adding various "support computers" (SCSI
interface, SCPU) to your Commodore - but you fear using an "alien" card holding
nothing more than a graphics chip due to its bus interface? :)
On the other hand: Show me a place where you still can get graphic chips
- in quantities of less than 1000 per order
- interfaceable to ancient electronics, i.e. not having a PCI/AGP
interface embedded
|> Perhaps what Nate dannenberg mentions on his page... His digiMax soundCard
|> For playing Mods with his own ModPlay, has 4 8bit dac's built in... He hinted
|> at those Dac's being possibly capable of Modifying the Intensities of the RGB
|> used by the 128's 80 column VDC. THAT would be interesting. Because it would
|> keep most Current 'Classic' commodore users happy (due to the fact that it is
|> still using the original video circuitry), plus it would give us a greater color
Nice idea, indeed. But it will give us only more colors - no greater resolutions,
no higher, more eye-friendly picture rate.
Rainer Buchty
|> A direct connection C64 <-> ISA, where ISA would be 8 bit in this case.
|> It's the easiest solution, but has the disadvantage that we only have
|> an 8 bit ISA and we must find a way to map the ISA addresses (which, in
|> fact, are even 2 address rooms, I/O and memory), so we would need some
|> means to do that mapping.
8Bit only is a dead end since it shuts the majority of ISA peripherals out.
|> I'm not sure if this bridge could be a passive one (only a PIA, VIA or
|> CIA), or better an active one (with some help of a processor, ASIC, or
|> whatever).
It must be active since ISA bus timing does only know two clocks: slow (4.77MHz)
and fast (sometimes adjustable to 8/10/12MHz). Also, the way of handling IRQ and
DMA is too PC-stylish to achieve a proper solution by a passive interface.
Again, the interface needs to be a separate computer which handles data transfer
between C64 and ISA.
Spiro Trikaliotis
Rainer Buchty schrieb in Nachricht
<85euit$q4f$2...@sunsystem5.informatik.tu-muenchen.de>...
>In article <85eo7e$1jqq1$3...@fu-berlin.de>, "Spiro Trikaliotis" <Trik...@gmx.de> writes:
>8Bit only is a dead end since it shuts the majority of ISA peripherals out.
ACK.
>|> I'm not sure if this bridge could be a passive one (only a PIA, VIA or
>|> CIA), or better an active one (with some help of a processor, ASIC, or
>|> whatever).
>It must be active since ISA bus timing does only know two clocks: slow (4.77MHz)
>and fast (sometimes adjustable to 8/10/12MHz). Also, the way of handling IRQ and
>DMA is too PC-stylish to achieve a proper solution by a passive interface.
Well, I don't think that most cards will _depend_ on at least 4.77 MHz, so
they might work with less.
The IRQs could be handled passively, too, i.e. by ORing (simplest approch)
or by using a register which is ORed and can be read by the C64.
(oh, I forgot: The OR must be in negative logic!)
Regarding DMA: I don't think that this is a 'must be', because there are
not so many cards which do that. Possibly some SCSI adaptors and sound cards,
but that's all. And I doubt any real C64 enthusiast wants to connect a PC
sound card to his C64.
>Again, the interface needs to be a separate computer which handles data transfer
>between C64 and ISA.
Well, a µC should work, doesn't it?
Spiro.
Rainer Buchty
|> Well, I don't think that most cards will _depend_ on at least 4.77 MHz, so
|> they might work with less.
But that would drive such an interface almost useless since you can't reliably
say if all ISA peripherals will work with such low clock rates (remember that
there are two clock signals on the ISA bus with different clock rate and even
pulse width).
|> The IRQs could be handled passively, too, i.e. by ORing (simplest approch)
|> or by using a register which is ORed and can be read by the C64.
|> (oh, I forgot: The OR must be in negative logic!)
If you think of a 1MHz scenario, ok (however, ISA interrupts are priorized - the
higher number an interrupt has the lower it is priorized). But with "fast" clock
rates (4.77 or 12MHz) this might cause problems since a device surely wants its
interrupt served within a special time to work properly. (As an example think of
a raster IRQ which needs to be served immediately and not "somewhere" in the
future.)
|> Regarding DMA: I don't think that this is a 'must be', because there are
|> not so many cards which do that. Possibly some SCSI adaptors and sound cards,
|> but that's all. And I doubt any real C64 enthusiast wants to connect a PC
|> sound card to his C64.
I'd like the idea of driving one of my Gravis Ultrasound cards by the C64. But
you are right - a sound card is surely the lessest needed peripheral.
|> >Again, the interface needs to be a separate computer which handles data transfer
|> >between C64 and ISA.
|>
|> Well, a 湣 should work, doesn't it?
Guess so. Or some distinct bridging hardware glued into a CPLD or FPGA.
On the other hand - if we need to build a separate "communication computer"
anyway why not using an old 286 for this task and establishing a parallel
connection (through user port<>LPT) between them. This would allow access to
all kind of PC hardware at almost no effort - all which has to be done is a
special link service allowing video communication (e.g. X protocol) and other
peripheral access (fast serial with up to 115200 bit/s, SPP/EPP/ECP devices, SCSI
& IDE, network, ISDN...).
This idea is not new and somewhat only an extension to the original 64net
concept.
Ok, it won't work with standard software - but neither does any other hardware
unless the driver routines were hacked into the OS (take JiffyDOS/SCSI for
example).
Yes, I know: A little box offering - let's say 4 - ISA slots being connected to
the expansion port is more sexy :)
Niall Tracey
: Lars Forsberg <l...@pdc.kth.se> writes:
: >Is it possible that we will see a graphic card to the C64 in the future or
: >is it just to expensive to develop? I would like to see a cartridge with a
: >graphic chip similar to VIC-III.
: It would be nice to have control over a video card, like some SVGA card or
: something. That's on my wish list.
I think the best solution would be to use latched-memory communication
(like in the 128's VDC) and send simple commands. No VESA SVGA setup
does enough on its own to deal with a C64 and still provide a decent
refresh rate (unless all you want to do with it is to view
jpegs). Building an intermediate computer between the C64 and an SVGA
card would be a unnecessarily expensive task, when a great deal of
functions would still be unavailable. A fully integrated video
computer with standard effects, such as FADE, LIGHTNING, NIGHTTIME
etc.
Actually, it might be possible to rig up an effects box to do that
sort of thing on the Luma output (perhaps), but the composite would be
a trickier. Black and white games..? It'd never catch on...
--
NT As long as but a hundred of us remain alive, never will we on any
\ \/ /conditions be brought under English rule. It is in truth not for
\ / glory, nor riches, nor honours that we are fighting, but for
/ \ freedom -- for that alone, which no honest man gives up but with
/ /\ \life itself. -- Arbroath, 1320
Spiro Trikaliotis
Rainer Buchty wrote in message
<85f6md$frl$1...@sunsystem5.informatik.tu-muenchen.de>...
>In article <85f1ij$1j2h6$1...@fu-berlin.de>,
>"Spiro Trikaliotis" <Trik...@gmx.de> writes:
>>The IRQs could be handled passively, too, i.e. by ORing (simplest approch)
>>or by using a register which is ORed and can be read by the C64.
>If you think of a 1MHz scenario, ok (however, ISA interrupts are priorized - the
>higher number an interrupt has the lower it is priorized). But with "fast" clock
>rates (4.77 or 12MHz) this might cause problems since a device surely wants its
>interrupt served within a special time to work properly. (As an example think of
>a raster IRQ which needs to be served immediately and not "somewhere" in the
>future.)
Well, although I remember that some old VGA were able to generate an
interrupt, I cannot remember seeing any program using that. I remember
that most old VGA cards had the option to disable the interrupt with a
jumper, which was recommended by many manufacturers, so, I don't believe
that your scenario is very realistic. ;-)
Anyway, allowing the C64 to handle more than one IRQ at a time with
priorities assigned would need some modification of the SW, too, since
the IRQs of the processor had to be allowed very quick for that, so the
priorities should have to be assigned in SW. Since we need the SW help,
it is no problem to read the above mentioned register to find out which
(ISA-)interrupt generated the IRQ.
>|> Well, a µC should work, doesn't it?
>Guess so. Or some distinct bridging hardware glued into a CPLD or FPGA.
Of course, that's a better solution, but I also believe it's more
complicated than a µC.
>Yes, I know: A little box offering - let's say 4 - ISA slots being connected to
>the expansion port is more sexy :)
Yes, that idea looks fine, doesn't it?
>Rainer Buchty, LRR, Technische Universitaet Muenchen
BTW: What's the meaning of LRR?
Spiro.
Rainer Buchty
|> Well, although I remember that some old VGA were able to generate an
|> interrupt, I cannot remember seeing any program using that. I remember
|> that most old VGA cards had the option to disable the interrupt with a
|> jumper, which was recommended by many manufacturers, so, I don't believe
|> that your scenario is very realistic. ;-)
I wonder what could be done with VGA cards if one would sync to the raster timing
:)
Thinking only of VGA cards you are right - there's no need for IRQ, neither DMA.
All one has to do is "somehow" create a bus interface.
Thinking of other peripherals IRQ and DMA is pretty necessary, the latter for
intelligent I/O cards such as e.g. SCSI controllers.
|> Anyway, allowing the C64 to handle more than one IRQ at a time with
|> priorities assigned would need some modification of the SW, too, since
|> the IRQs of the processor had to be allowed very quick for that, so the
|> priorities should have to be assigned in SW. Since we need the SW help,
|> it is no problem to read the above mentioned register to find out which
|> (ISA-)interrupt generated the IRQ.
On PCs this was done by 8237 (or whatever its name was) - a priority interrupt
controller. In our case this could be reduced to simple priority-ORing the
incoming IRQ lines.
|> Of course, that's a better solution, but I also believe it's more
|> complicated than a µC.
Depends on the problem (and of course the personal skills :), I'd say.
|> BTW: What's the meaning of LRR?
"Lehrstuhl für Rechnertechnik und Rechnerorganisation", in English "Chair for
System Architecture and System Organization" which is the 10th chair of the
Department of Computer Science at TU Munich.
Regards,
Rainer
--
Rainer Buchty, LRR, Technische Universitaet Muenchen
John H. Guillory
<Trik...@gmx.de> wrote:
>IMHO, the best solution would be to make an ISA adapter for the C64
>expansion bus. Then we could physically connect graphic cards, net-
>work cards, ISDN cards, ... to the C64, without developping the inter-
>face for every device from scratch.
Not asking for too much, are you? Why not just add a few SDRAM
sockets and a PPGA socket? While your at it, make a Parallel Port
adapter that looks like a PC printer port (with an option later on to
print to win-printers by loading their drivers from disk or cd-rom...)
>I see 2 possibilities for this:
>A direct connection C64 <-> ISA, where ISA would be 8 bit in this case.
>It's the easiest solution, but has the disadvantage that we only have
>an 8 bit ISA and we must find a way to map the ISA addresses (which, in
>fact, are even 2 address rooms, I/O and memory), so we would need some
>means to do that mapping.
The mapping of the memory wouldn't be much of a problem, it would
likely have other problems though.... If we're just talking 1-2 cards
at a time. The easiest solution for memory would be to have an eprom
on the card that allows a configuration program to be ran, which
allows the user to map any address line to any address line on the
cartridge port. Likewise, same thing with the i/o ports. The IRQ's
would get interesting, as the commodore has IRQ's, but they are just 2
Maskable and non-maskable. Therefore, the best option I could see
would be to store the IRQ number in a memory location and generate an
IRQ on the Non Maskable Interrupt pin.... Then, a patch could be
written to read the IRQ number and jump to a table setup for the
various IRQ's.... If that option would be used, I'd highly recommend
for simplicity sake have a dipswitch to disable the IRQ useage....
>On the other side, we could use a bridge between the 65xx-bus and the
>ISA bus, which would allow using even 16 bit ISA (AFAIK, there are
>many cards out there which will not work on an 8 bit ISA bus). This
>would even allow to use different timing on the ISA (I don't know if
>all ISA cards are able to work with only 1 MHz or less!), and the
>address mapping would be no problem anymore because we would have a
>different address space!
Actually, nearly every ISA card on the market is Expected to be able
to handle 4.77mHz. Most will go faster, I've never actually tested it
on a slower system.... I do know that video cards usually don't have a
problem going faster, but Floppy disk cards and hard drive cards will
usually start getting read errors when pushed too fast.... These would
likely be the ones to give you problems... Either way, what's to stop
you from putting an on-board 8086 chip to handle the hard work... You
could map the I/O ports of the 8086 to a given memory location, then
use the i/o ports to configure where you want each address line, etc.
Spiro Trikaliotis
Rainer Buchty schrieb in Nachricht
<85fpel$stc$1...@sunsystem5.informatik.tu-muenchen.de>...
>In article <85fobj$1lim6$2...@fu-berlin.de>,
>"Spiro Trikaliotis" <Trik...@gmx.de> writes:
>I wonder what could be done with VGA cards if one would sync to the raster timing
>:)
I believe a VGA is not as good as a VIC, because with the C64, you know
the exact timing of all system components. This is not possible on PCs,
because there are so many variants!
Do you want a proof? Only have a brief look at the demos which run only
with NTSC or only with PAL. Here, it's only one component that has a
different (relative) timing, but on the PC...
>Thinking of other peripherals IRQ and DMA is pretty necessary, the latter for
>intelligent I/O cards such as e.g. SCSI controllers.
Again: I see the necessity for IRQ, but with DMA, I'm not sure.
It would be nice to have it, but... the only device I really know that
uses DMA (except of sound cards) if the Adaptec AHA-1542( ,B,C), but
I don't even know if it really uses the DMA lines or if it uses an own
kind of DMA, going around the DMA controller.
Ah yes, the floppy controller needs DMA, too, but we have other
possibilities to get a PD 765 (look at the 1570, 1571, 1581).
[IRQ handling]
>On PCs this was done by 8237 (or whatever its name was) - a priority interrupt
>controller. In our case this could be reduced to simple priority-ORing the
>incoming IRQ lines.
Sorry, but the 8237 is the DMA controller. The 8259A is the PIC (BTW: It
means "_programmable_ interrupt controller", and only the A-Version can
be used with the 8086, the 8259 (non-A) is only for the 8080.
I've programmed this little thing some time ago, so I know it well.
It has some footangles, but works if you know them.
>|> BTW: What's the meaning of LRR?
>"Lehrstuhl für Rechnertechnik und Rechnerorganisation", in English "Chair for
>System Architecture and System Organization" which is the 10th chair of the
>Department of Computer Science at TU Munich.
Well, then you're the person to make the controller, aren't you?
To be honest, I don't know exactly what a CPLD or an FPGA is capable of
and which tools are needed to design them. I believe you have to know
VHDL or Verilog for them, don't you? (I've heard two semesters about VHDL,
but that's all I've done in this respect).
Spiro.
Spiro Trikaliotis
John H. Guillory wrote:
>On Tue, 11 Jan 2000 08:58:11 +0100, "Spiro Trikaliotis"
><Trik...@gmx.de> wrote:
>>IMHO, the best solution would be to make an ISA adapter for the C64
>>expansion bus. Then we could physically connect graphic cards, net-
>>work cards, ISDN cards, ... to the C64, without developping the inter-
>>face for every device from scratch.
>Not asking for too much, are you? Why not just add a few SDRAM
>sockets and a PPGA socket? While your at it, make a Parallel Port
>adapter that looks like a PC printer port (with an option later on to
>print to win-printers by loading their drivers from disk or cd-rom...)
I don't want to make a PC out of the C64.
As we all know, expansion cards for the C64 are rare, at least when
you want to interface something that's not 15 years old. We hear every
now and then the question, "can I connect my C64 to a PC monitor", or
"how can I attach a SCSI or IDE drive to my C64". Last week, we had the
question how to attach a C64 to an ethernet network.
Although there are solutions for every problem, they are expensive
because you have to begin from scratch in most cases, and every extension
only adds one peripheral to the C64.
The mentioned 65xx <-> ISA - Bridge would allow to take components which
we can get at a reasonable price (at least now, this might change in the
next years if ISA gets replaced by PCI) and connect them to the C64, so
only the SW problem remains. I believe that's a good idea.
>The mapping of the memory wouldn't be much of a problem, it would
>likely have other problems though.... If we're just talking 1-2 cards
>at a time. The easiest solution for memory would be to have an eprom
>on the card that allows a configuration program to be ran, which
>allows the user to map any address line to any address line on the
>cartridge port. Likewise, same thing with the i/o ports.
You're thinking about a type of MMU, aren't you? And the EPROM would
set this MMU accordingly. Did I catch your point?
>The IRQ's
>would get interesting, as the commodore has IRQ's, but they are just 2
>Maskable and non-maskable. Therefore, the best option I could see
>would be to store the IRQ number in a memory location and generate an
>IRQ on the Non Maskable Interrupt pin.... Then, a patch could be
>written to read the IRQ number and jump to a table setup for the
>various IRQ's.... If that option would be used, I'd highly recommend
>for simplicity sake have a dipswitch to disable the IRQ useage....
Well, you're thinking about the same solution as I did before
(the registered IRQ which are ORed for the C64); the only point I'm
not sure of is if NMI or IRQ should be used. I tend to think IRQ is
better, because with NMI, we might get some problems.
The IRQ routine itself had to re-enable IRQ as fast as possible!
>Actually, nearly every ISA card on the market is Expected to be able
>to handle 4.77mHz. Most will go faster [...]
As you set, it's not a problem for these cards to go faster, we
would need them to go slower. With a bridge, we might let them
work with the expected 4.77 MHz.
>Either way, what's to stop
>you from putting an on-board 8086 chip to handle the hard work... You
>could map the I/O ports of the 8086 to a given memory location, then
>use the i/o ports to configure where you want each address line, etc.
As I said above, I don't want to make an Intel based computer out of
a C64, I only want a solution to use newer technologies (_ethernet_,
hard disc, CD-ROMs, or other media) on the C64 for a reasonable price,
and able to be expanded without inventing a new (hardware-) wheel.
Apropos wheel, device drivers for these components could be included
into wheels, don't they? ;-)
Spiro.
Daniel Morrow
nothing :-p. Later!
Rainer Buchty
|> I believe a VGA is not as good as a VIC, because with the C64, you know
|> the exact timing of all system components. This is not possible on PCs,
|> because there are so many variants!
With our adapter we would know the proper timing :)
But I'd say the main reason why it isn't used on the PC is that there are so many
different VGA cards so that you simply must use the VGA BIOS routines. On the C64
that one's at first sight pretty useless - but could be replaced by similar
routines written in 6502 assembler.
|> Do you want a proof? Only have a brief look at the demos which run only
|> with NTSC or only with PAL. Here, it's only one component that has a
|> different (relative) timing, but on the PC...
I know that difference very well.
|> Again: I see the necessity for IRQ, but with DMA, I'm not sure.
|> It would be nice to have it, but... the only device I really know that
|> uses DMA (except of sound cards) if the Adaptec AHA-1542( ,B,C), but
|> I don't even know if it really uses the DMA lines or if it uses an own
|> kind of DMA, going around the DMA controller.
I had a quick look into the 8237 spec yesterday and it seems that DMA is limited
to 64kB pages (nothing unfamiliar to us :) so ISA-DMA (if needed) should be
possible. But don't get me wrong: I agree with your point of view that ISA-DMA is
a nice to have but not necessarily needed feature.
|> Ah yes, the floppy controller needs DMA, too, but we have other
|> possibilities to get a PD 765 (look at the 1570, 1571, 1581).
It doesn't necessarily need DMA... NMI is far enough. I'm currently documenting
the OS of a 6809 machine (Ensoniq SQ80) which makes use of the well-known WD1772,
all floppy communication is done by NMI.
|> Sorry, but the 8237 is the DMA controller. The 8259A is the PIC (BTW: It
|> means "_programmable_ interrupt controller", and only the A-Version can
|> be used with the 8086, the 8259 (non-A) is only for the 8080.
I knew I mixed up the numbers... But it's also priority encoded :)
|> Well, then you're the person to make the controller, aren't you?
Must I? :) Just kidding. Personally, I like John Guillory's idea of using a
80xx subsystem very much - for some simple reson: Simplicity of design. And if we
build a complete external "communication computer" then I just don't care about
the CPU. I don't like Intel CPUs at all (does anybody?) but in some cases there's
no way around (mostly due to low costs - 8051-type microcontrollers are just that
cheap...)
However, I'm not convinced that this is necessarily needed here.
Thinking of the possible bridge - could someone clarify the use of the following
signals:
- slow clock (4.77MHz)
- fast clock (14.xxMHz)
- BHE
My ISA documentation say that a device can use either 4.77MHz or 14.xxMHz. How
does the system know or better: Which is the "real" ISA clock which all transfers
run synchronously to?
My ISA documentation also tells nothing about the BHE signal...
|> To be honest, I don't know exactly what a CPLD or an FPGA is capable of
|> and which tools are needed to design them. I believe you have to know
|> VHDL or Verilog for them, don't you? (I've heard two semesters about VHDL,
|> but that's all I've done in this respect).
Not necessarily. Especially when designing with CPLDs *never ever* use VHDL since
the synthesis result will never be as good as the same design being synthesized
from a lower level language such as ABEL. I've recently made a design which
needed a XC95144 when synthesizing from VHDL, XC9572 when synthesizing from ABEL.
That's almost half the size!
And you don't need special tools beside a text editor. If you want to develop
with CPLDs there's this fantastic WebFitter from Xilinx (www.xilinx.com) where
just anybody can upload his/her designs and let them being synthesized at no
cost but short time.
Joe Forster/STA
PC: old game intros by cracker groups like Hybrid and TRSI. The inherent
problem is that these are supposed to work on PC's of any speed (and
they do!), therefore, the timing must be _general_ rather than _exact_.
So, the raster tricks consist of only some horizontal raster lines, as
some rainbow-colored background for the text, across the screen. (At
least, in the intros I've seen.)
Joe Forster/STA
s...@c64.org
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
Spiro Trikaliotis
Rainer Buchty wrote in
<85himt$5o2$1...@sunsystem5.informatik.tu-muenchen.de>:
>Must I? :) Just kidding. Personally, I like John Guillory's idea of using a
>80xx subsystem very much - for some simple reson: Simplicity of design. And if we
>build a complete external "communication computer" then I just don't care about
>the CPU. I don't like Intel CPUs at all (does anybody?) but in some cases there's
>no way around (mostly due to low costs - 8051-type microcontrollers are just that
>cheap...)
Well, instead of an 8051, we might even consider using a 80186. I believe
it's simpler because it contains already an 8259A, an 8237, and much of
the external logic needed to interface them, on the other hand, we could
copy much code from existing systems and would not have to invent all
from scratch. AFAIK, the 80186 is built until now, isn't it?
>Thinking of the possible bridge - could someone clarify the use of the following
>signals:
> - slow clock (4.77MHz)
> - fast clock (14.xxMHz)
> - BHE
AFAIK, the 14 MHz is not used for the timing of the bus, but as base for
external video cards or something like this. AFAIK, it's exactly the
14.xxx MHz needed for NTSC color generation (as it's needed inside the
NTSC C64).
So, only the slow clock would be the frequency base for the ISA bus.
>My ISA documentation say that a device can use either 4.77MHz or 14.xxMHz. How
>does the system know or better: Which is the "real" ISA clock which all transfers
>run synchronously to?
As I said, it should be the slow clock (which will raise when the ISA bus
is 8 MHz or 10 Mhz or even 12 Mhz; the 14 Mhz will AFAIR always remain
the same!).
>My ISA documentation also tells nothing about the BHE signal...
BHE ("bus high enable") enables the 16 bit mode of the ISA bus. It's active
low, so a high means "perform only an 8 bit transfer", and a low means
"perform a 16 bit transfer". But my documentation does not say _when_ it
has to be enabled. AFAIR from another documentation (an old mainboard had,
which I unfortunately gave away with that old board w/o copiing it first),
it has to be enabled a little bit after a valid address is encountered
from the card.
Ah yes, I forgot: The BHE is set by an ISA card, while MEM CS16 und
IO CS 16 are set by the mainboard itself. The mainboard might ignore
BHE (for example, because it was too late), then the CS 16 lines will
remain inactive.
Sorry, my documentation is not very complete either, so here I wrote
some things I only remember, so not everything might be accurate, although
I hope so!
Spiro.
Rainer Buchty
|> Well, instead of an 8051, we might even consider using a 80186. I believe
|> it's simpler because it contains already an 8259A, an 8237, and much of
|> the external logic needed to interface them, on the other hand, we could
|> copy much code from existing systems and would not have to invent all
|> from scratch. AFAIK, the 80186 is built until now, isn't it?
We just threw away a bunch of 80186-machines a few weeks ago... Again a warning
that one never should throw away things. Once you get rid of them you certainly
almost instantly need them :)
I don't know if the 80186 still is built, but if everything fails one could go
for AMD ELAN (80386'n'stuff).
|> AFAIK, the 14 MHz is not used for the timing of the bus, but as base for
|> external video cards or something like this. AFAIK, it's exactly the
|> 14.xxx MHz needed for NTSC color generation (as it's needed inside the
|> NTSC C64).
Yep, it's 4times the color carrier frequency if I remember right. You'll find the
respective value in PAL machines also.
So it's only ISA DOTCLOCK to give it a more C64-alike name :)
|> As I said, it should be the slow clock (which will raise when the ISA bus
|> is 8 MHz or 10 Mhz or even 12 Mhz; the 14 Mhz will AFAIR always remain
|> the same!).
Ok. That makes things clear - and more easy.
|> BHE ("bus high enable") enables the 16 bit mode of the ISA bus. It's active
|> low, so a high means "perform only an 8 bit transfer", and a low means
|> "perform a 16 bit transfer". But my documentation does not say _when_ it
|> has to be enabled. AFAIR from another documentation (an old mainboard had,
|> which I unfortunately gave away with that old board w/o copiing it first),
|> it has to be enabled a little bit after a valid address is encountered
|> from the card.
|>
|> Ah yes, I forgot: The BHE is set by an ISA card, while MEM CS16 und
|> IO CS 16 are set by the mainboard itself. The mainboard might ignore
|> BHE (for example, because it was too late), then the CS 16 lines will
|> remain inactive.
From what you are writing I think it works as follows:
(1) CPU applies MEM/IO address (and MEM/IOCS8)
(2) selected device lowers BHE if it's a 16 bit device
(3) memory decoder lowers MEM/IOCS16 respectively
(4) bus transfer (r/w) takes place (either one or two cycles)
For simplicity reasons it might be likely that MEM/IOCS16 will *always* be
lowered together with MEM/IOCS8 and only BHE is processed dynamically.
Spiro Trikaliotis
Rainer Buchty schrieb in Nachricht
<85krh5$3bb$1...@sunsystem5.informatik.tu-muenchen.de>:
>In article <85kftd$1plas$4...@fu-berlin.de>, "Spiro Trikaliotis" <Trik...@gmx.de> writes:
>We just threw away a bunch of 80186-machines a few weeks ago... Again a warning
>that one never should throw away things. Once you get rid of them you certainly
>almost instantly need them :)
:-(
>I don't know if the 80186 still is built, but if everything fails one could go
>for AMD ELAN (80386'n'stuff).
Well, I'm not sure if we don't need external logic with the ELAN.
AFAIR, the 386 bus doesn't "support" the ISA bus since it uses
a different bus (but I'm not sure...). I don't know if the ELAN
has the necessary interface either.
>Yep, it's 4times the color carrier frequency if I remember right. You'll find the
>respective value in PAL machines also.
Yes, I looked it up: 14.31818 MHz on NTSC, 17.73447 MHz on PAL
machines.
>So it's only ISA DOTCLOCK to give it a more C64-alike name :)
No, the DOTCLOCK on C64 is different: 8.18 MHz on NTSC, 7.88 MHz on PAL.
The respective name on C64 is Phi-Color.
>From what you are writing I think it works as follows:
>(1) CPU applies MEM/IO address (and MEM/IOCS8)
>(2) selected device lowers BHE if it's a 16 bit device
>(3) memory decoder lowers MEM/IOCS16 respectively
>(4) bus transfer (r/w) takes place (either one or two cycles)
Yes, that is what my memory tells me.
>For simplicity reasons it might be likely that MEM/IOCS16 will *always* be
>lowered together with MEM/IOCS8 and only BHE is processed dynamically.
No, MEM/IO CS 16 are only lowered when BHE has been activated
*and* the mainboard decides it wants to.
Spiro.
Rene van Belzen
wrote:
>With the SCPU, harddisk controllers, and more memory there seems to be
>only a few more things that you would like to add to a C64.
>
>Is it possible that we will see a graphic card to the C64 in the future or
>is it just to expensive to develop? I would like to see a cartridge with a
>graphic chip similar to VIC-III.
>
Although I have no special hardware knowledge, I hope I can contribute
something useful to this thread.
What about using the "new" v9990 chip that is used to enhance the
graphic capabilities of the MSX-2 computer? It is much better than the
VDC, also in its handling of separate memory. It can handle more GFX
memory more efficiently, draws certain primitives with hardware, and
has lots of sprite planes.
I know someone who wants to make a GFX card for his 8-bit Atari, which
means if he succeeds, it should also be possible to make something
similar for the C64/C128. I hope he publishes his project somewhere on
the Internet.
And we would not be pushed into the PC domain in any way ;-)
Bye,
Rene.
Rainer Buchty
|> >So it's only ISA DOTCLOCK to give it a more C64-alike name :)
|>
|> No, the DOTCLOCK on C64 is different: 8.18 MHz on NTSC, 7.88 MHz on PAL.
|>
|> The respective name on C64 is Phi-Color.
<blush> You are right. :)
|> >From what you are writing I think it works as follows:
|> >(1) CPU applies MEM/IO address (and MEM/IOCS8)
|> >(2) selected device lowers BHE if it's a 16 bit device
|> >(3) memory decoder lowers MEM/IOCS16 respectively
|> >(4) bus transfer (r/w) takes place (either one or two cycles)
|>
|> Yes, that is what my memory tells me.
|>
|> >For simplicity reasons it might be likely that MEM/IOCS16 will *always* be
|> >lowered together with MEM/IOCS8 and only BHE is processed dynamically.
|>
|> No, MEM/IO CS 16 are only lowered when BHE has been activated
|> *and* the mainboard decides it wants to.
So it's a pretty easy state machine. I'd prefer a glue logic then.
Rainer Buchty
|> What about using the "new" v9990 chip that is used to enhance the
|> graphic capabilities of the MSX-2 computer? It is much better than the
|> VDC, also in its handling of separate memory. It can handle more GFX
|> memory more efficiently, draws certain primitives with hardware, and
|> has lots of sprite planes.
I've done a quick search about the V9990. From the specs found on various MSX
pages I'd say this chip lacks *the* feature: higher vertical refresh rates. Its
advantage is allowing the use tons of colors, supporting playfields, sprites and
virtual screens.
But: Yamaha doesn't know anything about this chip anymore. However, they offer a
bunch of other chips (see http://www.yamahayst.com/graphics/index.htm) -
unfortunately the datasheet links are broken.
Lars Forsberg
> But: Yamaha doesn't know anything about this chip anymore. However, they
> offer a bunch of other chips (see
> http://www.yamahayst.com/graphics/index.htm) -
> unfortunately the datasheet links are broken.
I tried just recently and some of them work. I find them to be very
interesting, but I wonder how much they cost?
/ Lars