Re: SuperCPU for my C64 and C128

Den Wed, 25 Jul 2018 11:24:14 +0100 skrev smf <smf@null.net>:
> On 24/07/2018 23:56, Mia Magnusson wrote:
> >
> > We are talking about VIC reading from fast ram here, aren't we? :O
> 
> Yes. Which on SuperCPU is only ever accessed by the 65816 reading and 
> writing and the supercpu only uses the expansion port for updating
> the mirrored ram inside the c64 and for reading I/O.
> 
> Implementing ultimax it then has to monitor the expansion port for
> vic2 reads and be able to satisfy them from the fast ram. It pretty
> much doubles the complexity.

But the VIC-II bus cycles is still read only. All other stuff is
already there anyway.

> > Well, it's true that you have a software selectable 1MHz mode, but
> > the memory hardware will itself slow down the CPU when the CPU
> > accesses 1MHz address space (i.e. the first 4k if not using shadow,
> > and all I/O).
> 
> You can't switch to 1mhz for the first 4k, that is where zero page
> and stack are.
> 
> Most software isn't going to be using the first two pages for vic,
> but I remember writing basic games which used the tape buffer etc for
> sprites. So it would make sense to use some of the reserved v2
> optimisation register values to add a mode where $200-$7ff is
> mirrored & one where $200-$1000 is mirrored.

Well, if you want to be 100% compatible except timing you need the CPU
to write to the first 4k of the internal RAM which is 1MHz cycles.

> > What SuperCPU software are there that really uses exact timing?
> 
> I don't have a SuperCPU, but in the CMD FAQ it talks about writing
> FLI in 20mhz. FLI is going to be timing sensitive.
> 
> I don't understand why the first thought on making a SuperCPU clone 
> would be that it's not worth doing due to lack of existing software,
> so you might as well make something entirely different.

Well, if you can do something great, why only make it good enough and
miss a challenge? :)

> > But yeah, as VIC-II anyway will use C64's internal ram for the first
> > 4k, all logic to handle not using my proposal is already there so it
> > would be super easy to add an on/off function.
> 
> As I pointed out, you don't want the SuperCPU to use the first 4k.

Well, you absolutely want it to write to the default screen ram place :)

> The logic isn't already there, he hasn't even started implementing it 
> AFAICT.
> 
> I quite like the idea of using ultimax mode, but it would seem to be 
> something you'd do after you'd got the existing functionality working.

IMHO it's a good idea to think projects through before implementing
them. By doing something that "should probably work" as code for a FPGA
it's easier to estimate how many pins and how much "code" the FPGA must
have to be able to achieve the goal. It would be a bummer if a pin or
some minor space in the FPGA is missing to be able to implement the
ultimax mode.

Also it's not obvious which is easiest to bring up first, either only
running the ultimax mode or only running the 65816 from C64's internal
ram ("slow mode"). (Of course only using the ultimax mode with no other
way of the cart to communicate with the C64 won't work with existing
programs, but might be good enough to be able to run some test programs
to check that the hardware works as expected so far. That is a good
step while developing hardware).

> Especially as he wants to support C128 mode as well, which adds
> another level of complexity & there is less documentation on how that
> works.

For an external cartridge on a C128, it seems like the only way for a
SuperCPU to be compatible is to emulate the C128 MMU. This is btw
interesting as except for the VDC it would probably be rather easy to
emulate a C128 using a SuperCPU-deluxe++-replica even on a C64.


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