SuperCPU for my C64 and C128

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SuperCPU for my C64 and C128

dsp8bit

Hi Guys,

 I'm Luis Rene and I'm new in this forum. I'm interested in trying to develop a SuperCPU replica for my Commodore 64. Recently, I’m trying to understand the C64. I wanted to get into the retrocomputing passion due to I wanted to understand how old computers works and how they were conceptualized and designed. While searching about how the C64 works and buying 6510 CPUs (for future replacements), I saw on eBay the SuperCPU costing hundreds to thousands of dollars. Hence, the SuperCPU left me intrigued. So, I decided to contribute with something with the community.

 I'm a FPGA designer and I thought that SuperCPU replica is a good project. However, there is not much technical information about the SuperCPU and time ago I decided to leave this project for a while.

 In these days, I wanted to try again after almost a year…

And I would like to ask for help. I can’t find enough technical information to understand how the SuperCPU works. I can't find information about the booting process, how is the signaling exchange between the C64 and the SCPU, how are the bytes load/store operations or simply memory management between the C64 and the SuperCPU. Also, how the SuperCPU chances its operation during the turbo/normal mode, the JiffyDOS, etc. There is some information, but for me is a little ambiguous. Unfortunately, I’m a little stuck due to my lack of information, etc., of the C64 as well as the SuperCPU (which it is not available and I haven't touch one). I understand electronics, FPGAs, however, I don't understand in detail how the C64 and SCPU systems work together at firmware level.

 With respect to my project in a prototype process, I'm considering work with a FPGA + 65816 chip for achieve a replica of the SuperCPU. Later I will check to implement everything within a FPGA. I've visualized the modern SCPU+ with more features or advantages. I visualize to offer reconfigurability or versatility for machines like C64, c128, trying to solve the issues of the SCPU in his days.

Because of this, that it is required to design a reconfigurable 6502-based CPU... in other words a reconfigurable CPU with includes a 6510, 8502, 65C02, 65C816 and Also a 16bit architecture of the 6502/8502 with illegal opcodes in a way that allows compatibility defined by the user.

I understand the concern of the community related to the frustration or rejection of the user experience playing games or running programs between 1Mhz and 20Mhz. I think will be interesting for user and developers to customize several parameters. I imagine a SuperCPU but with more capabilities like a wide range of frequency operation from 2Mhz to 50Mhz that you can tune any time. For developers, a debugging tool in hardware in order to set breakpoints and run step by step your programs in real HW. Sorry, maybe these are stupid thinks, but I'm trying to propose ideas that can improve the actual SuperCPU conceptualization. I've read several reviews showing the bad things about the SuperCPU. That's why I was thinking in a new SuperCPU with more advantages.

I hope you can give some guidance, feedback of the goals as well as some technical information about my hobby project. 

Luis Vela

dsp8bit

twitter @LuisRene5


Luis Vela
dsp8bit
@LuisRene5
Reply | Threaded
Open this post in threaded view
|

RE: SuperCPU for my C64 and C128

Baltissen, GJPAA (Ruud)
Hallo Luis,


> how is the signaling exchange between the C64 and the SCPU

The SuperCPU disables the 6510 and takes over the C64. I don't know exactly how but this page has info on the CP/M card for the C64:

    http://baltissen.org/newhtm/c64_cpm.htm

It includes a schematic and should give you an idea how the 6510 can be stopped and put in tri-state and how the a-synchronous Z80 handles the transfer of data between itself and the C64. This could be a starter for a simple design where the 65816 just runs at 1 MHz and does nothing else than replacing the 6510. Next step could be to make the 65816 run at an odd frequency like 5Mhz just to make sure that the synchronization works. Then it is adding RAM, ROM and I/O to the design.

When I bought the 1541Ultimate one of the ideas was to use as a development platform as well. Particularly I had the SCPU in mind. But I soon found out it was way above my head: no FPGA knowledge :( But I thought that what I could not, maybe others could. So I convinced Gideon to make the Ultimate open source. Maybe something for you?

Regarding my FPGA knowledge: I bought a Godil and did some small projects with it. But it convinced me that the Ultimate is still out of my league yet :(

Good luck and have fun!


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org






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.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


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.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

dsp8bit
Hi Baltissen,

Thanks for sharing. My first roadmap it's to develop my prototype in development platform and lateral try to design a custom board. Also, i have considered to implement the prototype in the U2+ and then, to allow the community to reuse the hardware bought already for them (this is a possibility but first let me see to achieve the project  hahaha). Right now, i don't have a U2+, i'm seeking to get one from Gideon with a safe shipping service because the postal service in my country is awful. 

Cheers,
Luis Vela
dsp8bit

El jue., 19 de jul. de 2018 1:13 AM, Baltissen, GJPAA (Ruud) <[hidden email]> escribió:
Hallo Luis,


> how is the signaling exchange between the C64 and the SCPU

The SuperCPU disables the 6510 and takes over the C64. I don't know exactly how but this page has info on the CP/M card for the C64:

    http://baltissen.org/newhtm/c64_cpm.htm

It includes a schematic and should give you an idea how the 6510 can be stopped and put in tri-state and how the a-synchronous Z80 handles the transfer of data between itself and the C64. This could be a starter for a simple design where the 65816 just runs at 1 MHz and does nothing else than replacing the 6510. Next step could be to make the 65816 run at an odd frequency like 5Mhz just to make sure that the synchronization works. Then it is adding RAM, ROM and I/O to the design.

When I bought the 1541Ultimate one of the ideas was to use as a development platform as well. Particularly I had the SCPU in mind. But I soon found out it was way above my head: no FPGA knowledge :( But I thought that what I could not, maybe others could. So I convinced Gideon to make the Ultimate open source. Maybe something for you?

Regarding my FPGA knowledge: I bought a Godil and did some small projects with it. But it convinced me that the Ultimate is still out of my league yet :(

Good luck and have fun!


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org






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.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


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.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Luis Vela
dsp8bit
@LuisRene5
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

traymond160
Hi Luis,

I have read on some websites about the older Super CPU has some incompatibilities and I believe it mentions optimization issues.

I own both the C64V1 and V2 Super CPUs I really use them for the faster speed and using the Wheels upgrade for GEOS (US upgrade) I really have no complaints about them I love the faster speed, if I have to run at 1 MHz I can tell it has spoiled me seems very slow. :) 

The current SCPU seems to have an issue with playing the unpacked Riff Wave files using the $D418 SID routine, the SID uses a 4-bit frequency and so does a. Unpacked Riff Wave file they are compatible, I have noticed that at about 14 to 20 MHZ (with the 65816) playing this kind of wave file plays too fast like Chipmunks so using a delay slows it down and the Wave file will play at the desired speed.  
This is a little off topic but I know older PCs with accelerators have this issue so some games etc just play too fast, is this the actual optimization 
speed or the problems with C64 games? Maybe it's something Im just not 
understanding as usual.


I welcome new improvements one suggestion, CMD with the V1 they made a separate PCB for the RAM that plugged into the main board was fine, but 
they used a cheaper 72 pin Ram socket (socket was good) the two retainers at both ends that firmly seat the RAM module in place were made of cheap plastic they eventually break off.
I'm not criticizing CMD they were trying to make the unit cost effective and they learned a lesson with this because the V2 SCPU ram retainers were the better metal type.

The last SCPU's haven't been made in years now so I welcome a new excellerator that can be made again finally.

Im hoping the Ramcard can be made the same it compatible to support those who may need their V1 Ramcard fixed or a new one.

I'm In the same boat learning FPGA, electronics MOS etc 
I enjoy this list and the interesting posts about Commodore hardware.

I fully support this project I wish you success.

Terry Raymond


On Thu, Jul 19, 2018, 7:25 AM Luis Rene Vela Garcia <[hidden email]> wrote:
Hi Baltissen,

Thanks for sharing. My first roadmap it's to develop my prototype in development platform and lateral try to design a custom board. Also, i have considered to implement the prototype in the U2+ and then, to allow the community to reuse the hardware bought already for them (this is a possibility but first let me see to achieve the project  hahaha). Right now, i don't have a U2+, i'm seeking to get one from Gideon with a safe shipping service because the postal service in my country is awful. 

Cheers,
Luis Vela
dsp8bit

El jue., 19 de jul. de 2018 1:13 AM, Baltissen, GJPAA (Ruud) <[hidden email]> escribió:
Hallo Luis,


> how is the signaling exchange between the C64 and the SCPU

The SuperCPU disables the 6510 and takes over the C64. I don't know exactly how but this page has info on the CP/M card for the C64:

    http://baltissen.org/newhtm/c64_cpm.htm

It includes a schematic and should give you an idea how the 6510 can be stopped and put in tri-state and how the a-synchronous Z80 handles the transfer of data between itself and the C64. This could be a starter for a simple design where the 65816 just runs at 1 MHz and does nothing else than replacing the 6510. Next step could be to make the 65816 run at an odd frequency like 5Mhz just to make sure that the synchronization works. Then it is adding RAM, ROM and I/O to the design.

When I bought the 1541Ultimate one of the ideas was to use as a development platform as well. Particularly I had the SCPU in mind. But I soon found out it was way above my head: no FPGA knowledge :( But I thought that what I could not, maybe others could. So I convinced Gideon to make the Ultimate open source. Maybe something for you?

Regarding my FPGA knowledge: I bought a Godil and did some small projects with it. But it convinced me that the Ultimate is still out of my league yet :(

Good luck and have fun!


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org






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.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


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.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

MiaM
In reply to this post by dsp8bit
Den Wed, 18 Jul 2018 13:57:48 -0500 skrev Luis Rene Vela Garcia
<[hidden email]>:
> Hi Guys,

Welcome :)

I'm not totally sure exact what information you are looking for.

But in general there are two strategies here. One needs to be used and
the other can greatly speed up things.

As Ruuds stuff about the CP/M cartridge says, the C64 has a mode where
an external CPU can access the C64's internal memory.

But you can also do it the other way around, let the C64 access
external memory. This is called the "Max" or "Ultimax" mode.

The intention of the mode is to provide compatibility with the
Max/Ultimax gamle machine which was like a C64 but almost only for game
playing, containing a small amount of static ram and partially the I/O
a C64 has, but otherwise you had to provide a cartridge with rom and in
some cases (the Basic programming language cartridge) also ram).

But in practise you can assert _GAME at any time which disables most of
the C64 internal memory and let you drive the data bus in the cartridge
port when the C64 does a read operation. This way you can provide
external memory for the VIC-II video chip. The exception is the first
part of RAM (iirc 4k) which were actual ram on a Max/Ultimax and thus
the internal C64 memory is always enabled at those addresses. Also the
I/O areas might not be possible to disable (but I'm not sure here).

For a 65816 accelerator I think you should start as Ruud suggest by
running the 65816 at 1MHz and let it use the C64's internal memory for
the first 64k of address space.

Then I actually suggest using a PLL driven oscillator and sync it to
the C64 clock frequency as it makes timing easier.

The next step would be to add ram which at first is enabled for the
addresses above 64k.

Here comes a nice trick: The next step would be to put the C64 in
Max/Ultimax mode and let the C64 VIC-II chip read from the faster
memory in the 65816. From the point where VIC-II supplies a valid
address to the point it samples the bus you are free to do a faster
read cycle of your memory and latch the read data until the VIC-II
actually samples the data bus. That way a VIC-II read cycle will only
take as short time as the memory can provide data at, and not a full
half of a 1MHz cycle.

Unfortunitely this won't work for the first 4k. You can speed up things
a lot by writing both to the internal C64 memory and the faster
expansion memory, but only read from the faster memory. There is
nothing but the CPU that can alter memory contents so that won't cause
any incompatibly.

The I/O address space must of course be directed directly to the
existing C64 hardware.

A tricky part is the 6510 buildt-in I/O port at address 0/1. The only
way to actually read/write to that port is to run code in the 6510
itself. However that port controls memory mapping and some pins of the
cassette interface. If we assume the 65816 won't use the cassette
interface (but switch to 6510 mode as the cassette port anyway needs
compatible timing) the memory mappings can be simulated by adding a
port at address 0/1 on the 65816 and map in/out write protected parts
of memory that contains copies of the C64 ROM's, and also map in/out
access to the original C64 hardware for the I/O space. That way almost
all C64 software will run fine, and you can also soft load basic/kernal
rom images.

I'm not sure how JiffyDOS works on a SuperCPU, but in general JiffyDOS
is a replacement kernal so you'd just need to use another image for
Kernal. If you want to, you could make your hardware able to show it's
ram to the 6510 CPU (using the _GAME technique) making it possible to
let the 6510 use a JiffyDOS image instead of the standard kernal.

Btw even thogh JiffyDOS is a great improvement, as the 65816 mode won't
be compatible with existing timing critical software (like games and
demos) anyways, I suggest adding a SD card interface to your hardware,
and space for some kind of ROM making it possible to load/save to the
SD card directly. That would win over any JiffyDOS solution speedwise,
while those wanting a 100% compatible drive can use either an existing
1541 or a 1541 Ultimate, even together with your hardware.



--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

RE: SuperCPU for my C64 and C128

Baltissen, GJPAA (Ruud)
Hallo Mia,


> Here comes a nice trick: The next step would be to put the C64 in
> Max/Ultimax mode and let the C64 VIC-II chip read from the faster memory
> in the 65816.

Are you sure that this happens with the SCPU as well?


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org



 
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.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


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.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617


smf
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

smf
On 20/07/2018 07:11, Baltissen, GJPAA (Ruud) wrote:
> Are you sure that this happens with the SCPU as well?

It doesn't, by default it mirrors writes to the first 64k

This slows the super cpu down, because it can run software at 20mhz but
if two writes happen one after the other then it has to wait for the
first 1mhz write to complete.

So you can turn off mirroring of certain ranges.

http://ftp.giga.or.at/pub/c64/supercpu/superprog.html

If you add an ultimax mode then you still have to mirror ram at the
start of memory, but you have to solve the problem of interleaving the
1mhz vic reads into the 20mhz cpu reads.

You still need to support all the supercpu mirroring schemes as well, or
you won't be able to get the correct timing for demo effects.


Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

dsp8bit
In reply to this post by traymond160
Thanks Terry for sharing your view and knowledge.  
I'm considering the platform has a feature where the speed can be customized by the user at any time. Therese, the wavefiles or other programs should be played without issues. 

Thanks again,

Luis Vela
dsp8bit

El jue., 19 de jul. de 2018 1:12 PM, Terry Raymond <[hidden email]> escribió:
Hi Luis,

I have read on some websites about the older Super CPU has some incompatibilities and I believe it mentions optimization issues.

I own both the C64V1 and V2 Super CPUs I really use them for the faster speed and using the Wheels upgrade for GEOS (US upgrade) I really have no complaints about them I love the faster speed, if I have to run at 1 MHz I can tell it has spoiled me seems very slow. :) 

The current SCPU seems to have an issue with playing the unpacked Riff Wave files using the $D418 SID routine, the SID uses a 4-bit frequency and so does a. Unpacked Riff Wave file they are compatible, I have noticed that at about 14 to 20 MHZ (with the 65816) playing this kind of wave file plays too fast like Chipmunks so using a delay slows it down and the Wave file will play at the desired speed.  
This is a little off topic but I know older PCs with accelerators have this issue so some games etc just play too fast, is this the actual optimization 
speed or the problems with C64 games? Maybe it's something Im just not 
understanding as usual.


I welcome new improvements one suggestion, CMD with the V1 they made a separate PCB for the RAM that plugged into the main board was fine, but 
they used a cheaper 72 pin Ram socket (socket was good) the two retainers at both ends that firmly seat the RAM module in place were made of cheap plastic they eventually break off.
I'm not criticizing CMD they were trying to make the unit cost effective and they learned a lesson with this because the V2 SCPU ram retainers were the better metal type.

The last SCPU's haven't been made in years now so I welcome a new excellerator that can be made again finally.

Im hoping the Ramcard can be made the same it compatible to support those who may need their V1 Ramcard fixed or a new one.

I'm In the same boat learning FPGA, electronics MOS etc 
I enjoy this list and the interesting posts about Commodore hardware.

I fully support this project I wish you success.

Terry Raymond


On Thu, Jul 19, 2018, 7:25 AM Luis Rene Vela Garcia <[hidden email]> wrote:
Hi Baltissen,

Thanks for sharing. My first roadmap it's to develop my prototype in development platform and lateral try to design a custom board. Also, i have considered to implement the prototype in the U2+ and then, to allow the community to reuse the hardware bought already for them (this is a possibility but first let me see to achieve the project  hahaha). Right now, i don't have a U2+, i'm seeking to get one from Gideon with a safe shipping service because the postal service in my country is awful. 

Cheers,
Luis Vela
dsp8bit

El jue., 19 de jul. de 2018 1:13 AM, Baltissen, GJPAA (Ruud) <[hidden email]> escribió:
Hallo Luis,


> how is the signaling exchange between the C64 and the SCPU

The SuperCPU disables the 6510 and takes over the C64. I don't know exactly how but this page has info on the CP/M card for the C64:

    http://baltissen.org/newhtm/c64_cpm.htm

It includes a schematic and should give you an idea how the 6510 can be stopped and put in tri-state and how the a-synchronous Z80 handles the transfer of data between itself and the C64. This could be a starter for a simple design where the 65816 just runs at 1 MHz and does nothing else than replacing the 6510. Next step could be to make the 65816 run at an odd frequency like 5Mhz just to make sure that the synchronization works. Then it is adding RAM, ROM and I/O to the design.

When I bought the 1541Ultimate one of the ideas was to use as a development platform as well. Particularly I had the SCPU in mind. But I soon found out it was way above my head: no FPGA knowledge :( But I thought that what I could not, maybe others could. So I convinced Gideon to make the Ultimate open source. Maybe something for you?

Regarding my FPGA knowledge: I bought a Godil and did some small projects with it. But it convinced me that the Ultimate is still out of my league yet :(

Good luck and have fun!


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org






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.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


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.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
Luis Vela
dsp8bit
@LuisRene5
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

dsp8bit
In reply to this post by MiaM
Thank you  Mia,

I didn't know much about the the Max or Ultimax model. The information that you shared and ideas, is great in order to establish the possibilties of dealing with the RAM resources. I Will check the _game technique. 

Thanks,
Luis Vela
dsp8bit


El jue., 19 de jul. de 2018 6:37 PM, Mia Magnusson <[hidden email]> escribió:
Den Wed, 18 Jul 2018 13:57:48 -0500 skrev Luis Rene Vela Garcia
<[hidden email]>:
> Hi Guys,

Welcome :)

I'm not totally sure exact what information you are looking for.

But in general there are two strategies here. One needs to be used and
the other can greatly speed up things.

As Ruuds stuff about the CP/M cartridge says, the C64 has a mode where
an external CPU can access the C64's internal memory.

But you can also do it the other way around, let the C64 access
external memory. This is called the "Max" or "Ultimax" mode.

The intention of the mode is to provide compatibility with the
Max/Ultimax gamle machine which was like a C64 but almost only for game
playing, containing a small amount of static ram and partially the I/O
a C64 has, but otherwise you had to provide a cartridge with rom and in
some cases (the Basic programming language cartridge) also ram).

But in practise you can assert _GAME at any time which disables most of
the C64 internal memory and let you drive the data bus in the cartridge
port when the C64 does a read operation. This way you can provide
external memory for the VIC-II video chip. The exception is the first
part of RAM (iirc 4k) which were actual ram on a Max/Ultimax and thus
the internal C64 memory is always enabled at those addresses. Also the
I/O areas might not be possible to disable (but I'm not sure here).

For a 65816 accelerator I think you should start as Ruud suggest by
running the 65816 at 1MHz and let it use the C64's internal memory for
the first 64k of address space.

Then I actually suggest using a PLL driven oscillator and sync it to
the C64 clock frequency as it makes timing easier.

The next step would be to add ram which at first is enabled for the
addresses above 64k.

Here comes a nice trick: The next step would be to put the C64 in
Max/Ultimax mode and let the C64 VIC-II chip read from the faster
memory in the 65816. From the point where VIC-II supplies a valid
address to the point it samples the bus you are free to do a faster
read cycle of your memory and latch the read data until the VIC-II
actually samples the data bus. That way a VIC-II read cycle will only
take as short time as the memory can provide data at, and not a full
half of a 1MHz cycle.

Unfortunitely this won't work for the first 4k. You can speed up things
a lot by writing both to the internal C64 memory and the faster
expansion memory, but only read from the faster memory. There is
nothing but the CPU that can alter memory contents so that won't cause
any incompatibly.

The I/O address space must of course be directed directly to the
existing C64 hardware.

A tricky part is the 6510 buildt-in I/O port at address 0/1. The only
way to actually read/write to that port is to run code in the 6510
itself. However that port controls memory mapping and some pins of the
cassette interface. If we assume the 65816 won't use the cassette
interface (but switch to 6510 mode as the cassette port anyway needs
compatible timing) the memory mappings can be simulated by adding a
port at address 0/1 on the 65816 and map in/out write protected parts
of memory that contains copies of the C64 ROM's, and also map in/out
access to the original C64 hardware for the I/O space. That way almost
all C64 software will run fine, and you can also soft load basic/kernal
rom images.

I'm not sure how JiffyDOS works on a SuperCPU, but in general JiffyDOS
is a replacement kernal so you'd just need to use another image for
Kernal. If you want to, you could make your hardware able to show it's
ram to the 6510 CPU (using the _GAME technique) making it possible to
let the 6510 use a JiffyDOS image instead of the standard kernal.

Btw even thogh JiffyDOS is a great improvement, as the 65816 mode won't
be compatible with existing timing critical software (like games and
demos) anyways, I suggest adding a SD card interface to your hardware,
and space for some kind of ROM making it possible to load/save to the
SD card directly. That would win over any JiffyDOS solution speedwise,
while those wanting a 100% compatible drive can use either an existing
1541 or a 1541 Ultimate, even together with your hardware.



--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Luis Vela
dsp8bit
@LuisRene5
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

dsp8bit
In reply to this post by smf
So you can turn off mirroring of certain ranges.

http://ftp.giga.or.at/pub/c64/supercpu/superprog.html

If you add an ultimax mode then you still have to mirror ram at the 
start of memory, but you have to solve the problem of interleaving the 
1mhz vic reads into the 20mhz cpu reads.

Thank smf, i will check it.

El vie., 20 de jul. de 2018 5:31 AM, smf <[hidden email]> escribió:
On 20/07/2018 07:11, Baltissen, GJPAA (Ruud) wrote:
> Are you sure that this happens with the SCPU as well?

It doesn't, by default it mirrors writes to the first 64k

This slows the super cpu down, because it can run software at 20mhz but
if two writes happen one after the other then it has to wait for the
first 1mhz write to complete.

So you can turn off mirroring of certain ranges.

http://ftp.giga.or.at/pub/c64/supercpu/superprog.html

If you add an ultimax mode then you still have to mirror ram at the
start of memory, but you have to solve the problem of interleaving the
1mhz vic reads into the 20mhz cpu reads.

You still need to support all the supercpu mirroring schemes as well, or
you won't be able to get the correct timing for demo effects.


Luis Vela
dsp8bit
@LuisRene5
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

MiaM
In reply to this post by smf
Den Fri, 20 Jul 2018 11:30:20 +0100 skrev smf <[hidden email]>:

> On 20/07/2018 07:11, Baltissen, GJPAA (Ruud) wrote:
> > Are you sure that this happens with the SCPU as well?
>
> It doesn't, by default it mirrors writes to the first 64k
>
> This slows the super cpu down, because it can run software at 20mhz
> but if two writes happen one after the other then it has to wait for
> the first 1mhz write to complete.
>
> So you can turn off mirroring of certain ranges.
>
> http://ftp.giga.or.at/pub/c64/supercpu/superprog.html
>
> If you add an ultimax mode then you still have to mirror ram at the
> start of memory, but you have to solve the problem of interleaving
> the 1mhz vic reads into the 20mhz cpu reads.

The speed of the VIC-II reads won't be a problem, it's just a matter of
inserting one wait state for the 65816 unless you have super fast ram
that can run zero wait state at the equivalent of 40MHz, then you don't
even need a wait state. Such fast rams which might be available as cache
rams, remember that you only need 64k of those unless you want to add
register to let VIC access more than 64k.

> You still need to support all the supercpu mirroring schemes as well,
> or you won't be able to get the correct timing for demo effects.

Will 6510 based demos work at all on a 65816? I'd assume that they use
some well known illegal op codes?


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

smf
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

smf
On 23/07/2018 21:34, Mia Magnusson wrote:
>> If you add an ultimax mode then you still have to mirror ram at the
>> start of memory, but you have to solve the problem of interleaving
>> the 1mhz vic reads into the 20mhz cpu reads.
> The speed of the VIC-II reads won't be a problem, it's just a matter of
> inserting one wait state for the 65816

You'll be doing bidirectional memory accesses across a bus where both
sides run off different clocks.

I'm not saying it can't be done, but you have to do it & there will be
headaches

>> You still need to support all the supercpu mirroring schemes as well,
>> or you won't be able to get the correct timing for demo effects.
> Will 6510 based demos work at all on a 65816? I'd assume that they use
> some well known illegal op codes?

You misunderstood, I am talking about 65816 demo effects.

I don't know how many 6510 demos use illegal opcodes, but none of my old
demos used them though.



Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

Groepaz
Am Montag, 23. Juli 2018, 23:54:26 CEST schrieb smf:

> >> You still need to support all the supercpu mirroring schemes as well,
> >> or you won't be able to get the correct timing for demo effects.
> >
> > Will 6510 based demos work at all on a 65816? I'd assume that they use
> > some well known illegal op codes?
>
> You misunderstood, I am talking about 65816 demo effects.
>
> I don't know how many 6510 demos use illegal opcodes, but none of my old
> demos used them though.

a lot of them do. pretty much all "modern" ones probably :)

a bigger problem is the commonly used RMW instruction to acknowledge
interrupts though (inc $d019) - that doesnt work on 65816, meaning a whole lot
of simple raster interrupt stuff will not work.


--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

Mit dem Aberglauben ist es so eine Sache. Ich habe noch keinen Menschen
getroffen, der sein dreizehntes Monatsgehalt zurückgegeben hätte.
<Fritz Muliar>





Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

MiaM
In reply to this post by smf
Den Mon, 23 Jul 2018 22:54:26 +0100 skrev smf <[hidden email]>:
> On 23/07/2018 21:34, Mia Magnusson wrote:
> >> If you add an ultimax mode then you still have to mirror ram at the
> >> start of memory, but you have to solve the problem of interleaving
> >> the 1mhz vic reads into the 20mhz cpu reads.
> > The speed of the VIC-II reads won't be a problem, it's just a
> > matter of inserting one wait state for the 65816
>
> You'll be doing bidirectional memory accesses across a bus where both
> sides run off different clocks.

No, the VIC can only read, never write, so it's unidirectional. And I'm
assuming buses in sync.
 
> I'm not saying it can't be done, but you have to do it & there will
> be headaches

1 or even 2MHz is slow compared to for example 20MHz. With a 20MHz
"memory clock" you have 5 memory clock cycles for each VIC read cycle,
that gives you plenty of time to insert a wait state, do the actual
read and latch the data for VIC to read whenever the 1MHz cycle is in
the state where VIC reads the data.

> >> You still need to support all the supercpu mirroring schemes as
> >> well, or you won't be able to get the correct timing for demo
> >> effects.
> > Will 6510 based demos work at all on a 65816? I'd assume that they
> > use some well known illegal op codes?
>
> You misunderstood, I am talking about 65816 demo effects.

Oh. I didn't even know that there are such things. :)

> I don't know how many 6510 demos use illegal opcodes, but none of my
> old demos used them though.

Some of the illegal op codes kind of begs to be used though. I
understand that few used them back in the days as noone knew if there
would be a C64-II that didn't implement them, and there were no easy
way to check if they do work on many different C64's. But nowdays there
won't be any new C64 without them and it's well known that they exist
in every C6t4.


--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

Groepaz
Am Dienstag, 24. Juli 2018, 00:48:19 CEST schrieb Mia Magnusson:

> > I don't know how many 6510 demos use illegal opcodes, but none of my
> > old demos used them though.
>
> Some of the illegal op codes kind of begs to be used though. I
> understand that few used them back in the days as noone knew if there
> would be a C64-II that didn't implement them, and there were no easy
> way to check if they do work on many different C64's. But nowdays there
> won't be any new C64 without them and it's well known that they exist
> in every C6t4.

back in the days they were also used a LOT - mostly for obfuscation in
original games (in their copy protection)

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

PROGRAM n. A magic spell cast over a computer allowing it to turn one's input
into error messages. tr.v. To engage in a pastime similar to banging one's
head against a wall, but with fewer opportunities for reward.





smf
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

smf
In reply to this post by MiaM
On 23/07/2018 23:48, Mia Magnusson wrote:
> No, the VIC can only read, never write, so it's unidirectional. And I'm
> assuming buses in sync.

It's bidirectional. The VIC can read, the 65816 can read and write.

In the SuperCPU the 65816 decides when to run at 20mhz and when to slow
down to 1mhz, throwing in ultimax mode then you have to also pay
attention to vic fetches.

It needs to be optional, or you will kill timing with existing SuperCPU
software.

What you're describing sounds more like
https://www.c64-wiki.com/wiki/Flash_8



smf
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

smf
In reply to this post by Groepaz
On 23/07/2018 23:54, [hidden email] wrote:
> back in the days they were also used a LOT - mostly for obfuscation in
> original games (in their copy protection)

And yet there are plenty of original games that run without problem on
the SuperCPU.

Of the 3 c64 game  projects I have in the pipeline, 2 of them work fine
while the 3rd suffers badly from running too fast. I'd not tried them
until now, I somehow missed vice supporting it.

I can put in some frame limiting but the scrolling will still flicker
due to the cpu being able to accelerate past the vic. This will take
further consideration as having the faster cpu is actually useful, if I
leave it running at 20mhz then I don't know how tollerant I can be for
the cpu running faster due to the timing differences of ultimax mode.

Although I don't know how accurate vice is at SuperCPU timing either.



Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

Groepaz
Am Dienstag, 24. Juli 2018, 06:59:17 CEST schrieb smf:
> On 23/07/2018 23:54, [hidden email] wrote:
> > back in the days they were also used a LOT - mostly for obfuscation in
> > original games (in their copy protection)
>
> And yet there are plenty of original games that run without problem on
> the SuperCPU.

sure. however there are also plenty that do not. what are you trying to say?
:)

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

Jetzt sag nicht wir müssten unseren Kindern in der Schule Medienkompetenz
beibringen? Können wir nicht lieber irgendwas verbieten?





Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

dsp8bit
In reply to this post by smf
smf wrote

> On 23/07/2018 23:48, Mia Magnusson wrote:
>> No, the VIC can only read, never write, so it's unidirectional. And I'm
>> assuming buses in sync.
>
> In the SuperCPU the 65816 decides when to run at 20mhz and when to slow
> down to 1mhz, throwing in ultimax mode then you have to also pay
> attention to vic fetches.
>
> It needs to be optional, or you will kill timing with existing SuperCPU
> software.

Thanks for the sharing this aspects of the VIC-II. I will keep in mind these
considerations.



-----
Luis Vela
dsp8bit
@LuisRene5
--
Sent from: http://cbm-hackers.2304266.n4.nabble.com/

Luis Vela
dsp8bit
@LuisRene5
Reply | Threaded
Open this post in threaded view
|

Re: SuperCPU for my C64 and C128

dsp8bit
In reply to this post by Groepaz
For understanding the VIC-II, I found this website

https://dustlayer.com/vic-ii/2013/4/22/when-visibility-matters
<https://dustlayer.com/vic-ii/2013/4/22/when-visibility-matters>  





-----
Luis Vela
dsp8bit
@LuisRene5
--
Sent from: http://cbm-hackers.2304266.n4.nabble.com/

Luis Vela
dsp8bit
@LuisRene5
12