RE: Building my monster C64 accelerator

From: Baltissen, R (Ruud) (
Date: 2003-08-19 07:46:06

Hallo allemaal,

> Read/write to the Ram: full 65816 speed (using a 55ns SRAM chip)

This covers an item I always have been wondering about and which is solved
in the SCPU AFAIK: parallel (S)RAM. Attaching a much faster CPU with its own
RAM to the C64 is no problem. When writing/reading to/from the I/O it is
just a matter of slowing down an synchronisation. One also has to write to
the native DRAM to get text on the screen. OK, then we also take care of
these 1000 bytes. But when in graphical mode, we have to deal with an area
of 16 KB and worse, which exact area inside the 64 KB. 

A intelligent design could do this with a buffer. The CPU just writes to the
buffer and a seperate mechanism takes car of the transfer. But that takes a
lot of electronics and the SCPU doesn't do it in this way AFAIK.

OK, the the program should tell the system when or when not to use native
RAM. The problem here is that native C64 programs don't know about the extra
hardware, thus cannot tell the design what native RAM is (not) needed. This
would force one to use all native RAM to be sure that all graphics work out
fine. But the SCPU doesn't work in this way AFAIK.

So what is exactly the trick?

   / __|__
  / /  |_/     Groetjes, Ruud
  \ \__|_\


De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken. Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij overgebrachte virussen.

The information contained in this e-mail is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail; please delete in this case the e-mail and do not disclose its contents to any person. We don't accept liability for any errors, omissions, delays of receipt or viruses in the contents of this message which arise as a result of e-mail transmission.

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.