How does the memory for Mega65 work? I downloaded the master branch from https://github.com/gardners/c65gs yesterday, and are still learning..
After some fiddling I managed to build the complete project.
Is the DDRWRapper used or not? I thought that only M10K RAM was used in this project this far..
Why is Antialias used? Is it to be able to show different resolutions using the 1920*1200 and minimize artifacts? Cool for it to be clocked at 400Mhz!
Hiya Magnus,
From my past experiences with dev-internal questions, I found Paul was faster to respond on the google-groups site:
https://groups.google.com/forum/#!forum/c65gs-development
I'm guessing it's because he's getting email notifications there, but not on this forum site (so he only visits this forum site once in a while?).
So just thought I'd mention it, in-case you want to drop your Q there too.
Yeah, a 400MHz 8-bit machine sounds awesome. I remember reading an interview in Commodore Free where Paul has a 'secret' plan to fabricate the final chip and make it 10GHz, holy moly !!! 
http://www.commodorefree.com/magazine/vol8/issue82.html
...but it's a secret, so shhhhh, don't tell anybody 
Gurce
It's true that I would love to fabricate the final IC, and that using modern processes, that a speed in the GHz range should be quite possible.
Meanwhile, we are running at 192MHz for the pixel clock, and 48MHz for the CPU.
The DDR memory has so far proved to be a complete pain, and doesn't work. We are currently planning to use memory much more like the 16MB on the original Nexys board, as it is MUCH simpler to interface to, and 16MB of RAM for an 8-bit computer should be sufficient. If you need bulk storage, there is the SD card interface which can do several MB/sec with a decent SD card, and can give you many GB of space.
Would these 16MB be zero wait state ?
I think 16 Mbytes "should be enough for everyone" 
Still if there is DDR memory available it can be used as some kind of "fast storage" even with "bizarre amount" of wait states, it would be still faster than an SD card for example, if some needs large amount of temporary storage during the run of their program?
They're making their own motherboard so their won't be that DDR blob on there. If SD card access is fast 16MB would be fine I guess. If not, having more memory would limit load time (i.e.: for a game, that would limit load time between levels as you would have loaded a lot of datas during startup)
... and if we have too much RAM, then games will take too long to load at the start, because people will load 100s of MB of stuff, which then won't feel very 8-bit
Good point
i understand that the DDRwrapper component does not function correctly at this point in time on:
https://github.com/gardners/c65gs
and so I have removed the internals of the DDRwrapper component and replaced it with simple logic, this revision is on my fork at
https://github.com/Ben-401/c65gs/tree/dockit
which builds slightly quicker because does not have to compile the ddr-controller.
My current focus is NOT to get the ddr-controller working at this stage.
Hi Ben,
great to see you being active here
The DDR-Ram is obsolete as we will have nice "retro-Ram"
In general: we need to
a) fix bitplanes in c65 mode, make zed yago demo run (goal 100% reached)
b) enhance C64 compatibility (already far better than original c65; CIAs need work)
c) fix some hypervisor bugs
d) enhance floppy emulation
still waiting for an VHDL hero to pop up
I'll be sitting on the prototype boards until that happens.
best
Deft
...for...
a) I can provide an old MESS version which actually compiles AND has working bitplanes in BASIC.
b) We have the CIA diagrams and some other documentation I believe
c) Paul knows more
d) see above
you can count on any support you need!
