Mega65-MiSTer

[Alynna]

I've decided to attempt to do this.
https://github.com/alynna/mega65-mister

The goal of the project is to:

• Implement the Mega65 core on MiSter
• Do it in such a way that it is easy to update from their upstream so we can benefit from their continued development.
• As such, I have implemented their repo as a module in mega65-mister (at rtl/mega65/
• Code above the tree at rtl/mega65 (in rtl/) will be used to implement a functional wrapper around the mega65 core, interfacing its devices in a MiSTer compatible way.

Immediate challenges I see

• BRAM is overused in Mega65. We need to swap out much of their BRAM with a SDRAM interface.
  [**]There is a huge advantage to this as well. The MiSTer version will have much more RAM than the actual version.
• Identify and remove all test modules from the core. It will just eat up our LEs.
• Identify and replace all modules that interface with their hardware.
  [**]A strategy to do this, includes simply removing the files from the qip's in our build that interface with their external interfaces, and replacing them with MiSTer interfaces instead. This also saves LEs.

This is an open project, if you think you can contribute to this core, private message me and I will give you commit access. I will accept pull requests that make something work, as well.

Alright guys lets do this. LEEEEEEEROOOOYYYYY JEEEENNNNKINNNNSSSS!

[Malor]

Good luck! That looks like a heck of a project.

My only real complaint is that I wish they'd used a 65816 instead. It's still mostly a 6502, most of the time, but has 16-bit instructions and a 24-bit bus, which would have made memory management dead easy. IIUC, designing a board around that chip was complex, because the pins switched back and forth between being address and data, but an FPGA implementation might be able to skip that problem entirely.

That's not what they did, though. 6502 it is.

[Alynna]

Oh I know, I actually really do not like the 4510 stuff. There is actually a 65832 specification out there straight from WDC for using 32bit addressing...

[ericgus09]

Ah wonderful, I think you will find this project far more challenging and interesting as folks have said trying to port it to MISTER would be complicated but I think you are fully up to this challenge, I look forward to watching your progress!

[killersquirel]

This is very exciting. I am looking forward to watching your progress.

[LamerDeluxe]

Awesome! I will also enjoy watching the development of this core. I had the chance to get a C65 when they were originally sold on eBay, but didn't, for some reason I can't remember. Would be great to try it and a great addition to MiSTer's arsenal.

[Alynna]

I have the Nexys7DDR and I am able to run the mega65 core on it. Noting its differences I hope to bring it to the MiSTer. The Mega65 team has built a "Mister to Mega65" interface to run cores that were made for Mister on the Mega65 (resynthesized of course). I am looking at reverse-engineering (in the most literal sense) to see how they are doing that and how I can do the reverse.

The Big Bad right now I am working on is the RAM. BRAM is way overused in the mega65 core. All of main memory is BRAM. The 8mb RAM that the Mega65 has in SDRAM is not even regular RAM, it is mapped upwards past it.

I need to turn that into SDRAM, wholesale. We have less BRAMable logic units to work with, but we have tons of SDRAM compared to Mega65, so if we can introduce some wait states into the memory interface, we could in theory, replace that BRAM with SDRAM.

This means a wrapper interface. I want to keep the 40mhz speed, and I am thinking if I run RAM at 120mhz, I will have enough time on the SDRAM to make it "same cycle addressable" by the 40mhz running 4510. If it can be read or written to in the same cycle, it will be able to function as BRAM.

I am creating a wrapper to use SDRAM as BRAM as my current project. Once I am confident that is working, it is onto interfaces, screen being first of course.

[Malor]

Is 40MHz slow enough to avoid the SDRAM refresh cycle? I don't actually know details of how that process works. And triple clocking seems kinda weird and non-binary.... maybe you might get more accurate timing with 80MHz RAM? Maybe?

I'm speaking from vast ignorance, so ignore me entirely if I'm being an idiot.

[Alynna]

80mhz might be sufficient. I'm trying this first. 120mhz is an option if I need to (I can do a cycle stretch) but I would really like to avoid it. The cycle stretch might make things complex, and at that point it might be better to run at 30mhz and do 30*4 if I have to. I mean we'd still like it at 1, 2, 3.5 and 30mhz, right? But tbh, if I can replace the BRAM with a 2 cycle SDRAM clock, then in theory we can do 80 at 40, and 120 at 60mhz That would be cool. I don't want to make promises, but at the very least, I think I can get 30mhz working.

[Malor]

I was reading an article about SDRAM on FPGA, and that made it sound like you had to clock the SDRAM at 8x the speed of the core, so a 4MHz Z80 needs 32MHz RAM. It could be wrong, or I could be misunderstanding completely, but it sounded tricky.

[robinsonb5]

I was reading an article about SDRAM on FPGA, and that made it sound like you had to clock the SDRAM at 8x the speed of the core, so a 4MHz Z80 needs 32MHz RAM. It could be wrong, or I could be misunderstanding completely, but it sounded tricky.

A random access read to SDRAM involves first opening a row, which takes around 20ns (so either 2 or 3 cycles, depending how fast you're clocking the RAM), then triggering a read. The chip takes either 2 or 3 cycles to send the data, depending on whether you've configured CAS latency 2 or 3 (bearing in mind not all chips can do CAS 2 at more than 100MHz) - so by the time you've noticed that the core wants data, sent commands to the chip, the chip's seen the commands, send the response, and you've sent it to the core, eight cycles is a reasonable rule of thumb for turnaround time.

If you leave the row open, you can avoid those initial 2 or 3 cycles as long as the next access is to the same row. Unfortunately you then incur an extra few cycles penalty if the next access is to a different row, because you have to close the current row before opening another (from the same bank).

The saving graces of SDRAM are burst transfers and banks: Because there are multiple banks in the chip - which behave almost like four independent chips sharing a bus - you can set up a transfer to one bank while another transfer is happening. (But this is much harder on MiSTer than almost anywhere else because on MiSTer SDRAM modules two of the address lines are shared with the data mask signals.)

Oh, and yes, you have to squeeze some refresh cycles in somewhere. Triggering an Autorefresh typically takes all four banks offline for at least 60ns. It's also possible to do it manually by simply ensuring every row in every bank is opened and closed at least once every 64ms.

[Alynna]

I haven't weighed on this mostly because i've been experimenting with the knowledge gained and mostly last night.
And I want to note to folks that right now the entirety of the core I am currently working on is making the SDRAM look "zero wait state" to the 45xx and its hardware.

There have been many failures but I feel i'm getting... a little closer. This 8 cycle turnaround time seems to be ... what the core will have to expect to deal with to appear zero wait state to the hardware. This 8 second turnaround also presumes CAS 3, because running at CAS2 isn't even guaranteed for the chip I have.

The expected FIXED SDRAM speed will be CAS3 at 114.545454mhz

As such right now I am trying to make everything work at 3.5mhz (the second fastest speed presented by the Mega65 and the original speed of the C65. This specific frequency is actually NTSC/4.

At 3.5mhz, zero wait state can be achieved at an SDRAM speed as little as 28mhz. Which means I feel it is well within target for an SDRAM interface. i've looked at the clock reactions in the signal tap analyzer and ran some numbers, and here is what I am thinking may end up possible for speeds:


3.5mhz: Cycle exact, the "hurry up and wait" clock rate (for refresh and row changes).
14mhz: Cycle exact. Exact NTSC clock, 4x faster than C65, 1/3 the speed of Mega65.
28mhz: Not cycle exact, but possible. We would slow down to 3.5mhz during page changes and refresh, to give the RAM re-setup time.
40mhz: Probably forget about it. Even with clock stretching (slow to 3.5mhz), it would be spending too much time at 3.5mhz to see a benefit and it is basically certain to introduce instability at best, and simply break everything at worst.

Refresh time would always come during the vertical blank interval. All hardware would continue to run, but at 3.5mhz, during the VBI.

Expected timing is follows:

3.5mhz: 8 cycles read time, 8 cycles work time, 8 cycles write time, 8 cycles refresh row (scanline modulo 4) at end of current scanline.
14mhz: 8 cycles read/write command, Refresh of odd rows come during the VBI of odd frames, even rows on the VBI of even frames (32ms apart).
28mhz: 4 cycles read/write command, when more time is needed, clock is stretched to 3.5mhz when more bus time is needed 3.5 synched to the system bus....

[Malor]

I wonder how the actual Mega65 people are doing it? That's on FPGA too, right?

[Alynna]

Yes. And they are doing it by using 384KB of bram just on system memory. Not an option for MiSTer. On the other hand, Mega65 only provides 8mb of SDRAM period, something that CAN be done better on MiSTer.

Technically all of their SDRAM (known as ATTIC and BASEMENT RAM) is on a slower bus than that 384K which is on the FPGA itself. Its a ... design decision, for sure. There is also a segment of memory that expects waitstates (its effectively the I/O memory) that DDR would easily be usable in, but TBH, 32mb of SDRAM is 4x more than the Mega65 brings to the table and that's kind of our baseline.

[Malor]

Hmm, seems like any new software would probably be written for the fastest clocking, so the Mister's version would probably be considered drastically inferior.

[R4M]

Hmm, seems like any new software would probably be written for the fastest clocking, so the Mister's version would probably be considered drastically inferior.

I'm not so sure about that. Remember, that there are only 1500 MEGA65 so far. The user base on MiSTer would be much bigger and probably hard to ignore.

[ericgus09]

Hmm, seems like any new software would probably be written for the fastest clocking, so the Mister's version would probably be considered drastically inferior.

I'm not so sure about that. Remember, that there are only 1500 MEGA65 so far. The user base on MiSTer would be much bigger and probably hard to ignore.

Ironically the MISTER version could very well end up being the dominant one .. thats very interesting and very likely to be an accurate assessment ..

[Alynna]

Any speed we get above 3.5mhz is doing better than the original C65, soo

[manni199]

Yes. And they are doing it by using 384KB of bram just on system memory. Not an option for MiSTer. On the other hand, Mega65 only provides 8mb of SDRAM period, something that CAN be done better on MiSTer.

Technically all of their SDRAM (known as ATTIC and BASEMENT RAM) is on a slower bus than that 384K which is on the FPGA itself. Its a ... design decision, for sure. There is also a segment of memory that expects waitstates (its effectively the I/O memory) that DDR would easily be usable in, but TBH, 32mb of SDRAM is 4x more than the Mega65 brings to the table and that's kind of our baseline.

But the DE10 nano ALTERA Cyclone V FPGA contains also BRAM.
Datasheet: 5.570kBit
So there are about 700kB very fast RAM.
Or is even that RAM to slow for 40MHz?

[Alynna]

that is a new direction I can't really comment on yet. I was told we did not have enough BRAM, but that is very fast.
It is fast enough that it might be viable as a page cache.

If I can successfully set up a cache, I may be able to go to .. 33mhz constant. this would be done with a 133mhz SDRAM bus, acting as BRAM. However the CPU would also be given 16K of L1 cache
on 4 cycle read/write (meaning we are not in refresh and we are not changing pages) writes would go directly to SDRAM. But during page changes or the refresh signal, read/write would go to the L1 cache, and committing to RAM would occur on cycles where the CPU is not accessing RAM, such as during register operations.

The best scenario I believe, for our BRAM, is for L1 cache to be implemented, and not only speed up operations for recent and nearby read/write ops, but also buffer the access to SDRAM during long operations.
In this way it may... *may* be possible to sustain 33mhz operation, but its likely that if this route is gone, a "fallback to 16mhz"" mode will be implemented for when cache pressure is extreme enough to fill it, to give the cache time to commit memory to SDRAM. However this slowdown may be on the order of 10-30 cycles and most the time, unnoticable.

[neodyme60]

Any news or progress? I am curious

[Alynna]

I just got a new job so alot of stuff is on pause, but its on my todo still.

[Grumpy-Old-Gamer]

I can remember Sorg stating on the FB group he thought it would fit on the DE-10 but saw no point in porting it

[ericgus09]

I can remember Sorg stating on the FB group he thought it would fit on the DE-10 but saw no point in porting it

Yea he's like that bout a lot of things .. he says no .. then it ends up happening anyway.. often he only sees it from his personal perspective only then comes to understand the benefits or how it appeals /is good for a larger audience .. first rule of working with sorg, ignore when he says "no" or "no point" .. lol

[Grumpy-Old-Gamer]

I can remember Sorg stating on the FB group he thought it would fit on the DE-10 but saw no point in porting it

Yea he's like that bout a lot of things .. he says no .. then it ends up happening anyway.. often he only sees it from his personal perspective only then comes to understand the benefits or how it appeals /is good for a larger audience .. first rule of working with sorg, ignore when he says "no" or "no point" .. lol

His reasoning was pretty solid at the time though

The C64 compatibility isn't very good, hence why they have ported the MiSTer C64 core to M65

There is no software and he said when he looked even bios wasn't finished

He did do the ZX Spectrum Next port

[ericgus09]

His reasoning was pretty solid at the time though

Oh im not talking c64 core only but all kinds of cores, the minimig core etc.. its kinda his thing and not unique to only one core.. its a pattern.. lol..

resist .. resist .. {get shown legitimate use cases/examples/arguments} .. concede ..

[Alynna]

To be honest, who cares if the C64 support isn't good. We have a C64 core for that.
If/When I get around to the C65 core (SuperCPU128 is a much more attractive project for me at the moment) I will not bother with trying to make the C64 part work. It is a waste of logic elements. Though who knows, maybe i'll find a way to just load the C64 core when someone uses 'go64' on the core. That's effectively what the Mega65 people are doing now anyway...

[Alynna]

SuperCPU128 is giving me alot of ideas about what to do when its time to port this core. I am now looking at 28mhz CPU speed, instead of 33 or 40, because it is much easier to sync up with NTSC signal. Expected available speeds will be 1.03mhz, 2.06, 3.57. 7.16, 14.32. amd 28.65mhz. I don't want to promise 57.14mhz, but it is not completely impossible.

SDRAM speed will probably be 114.54mhz, not unreasonable. When I do these designs, I like to run the SDRAM fast because it allows me to get closer and closer to a "BRAM like" design for accessing the SDRAM.

One of the biggest hurdles for doing the Mega65 is the lack of waitstates in higher speed modes. If we go a little slower (like 28mhz) we can probably get there with the SDRAM. I believe MiSTer also has enough BRAM available to do the bottom 384k that most Mega65's have. We will see.

[Syntax Error]

is this still alive, i was thinking this week other than a jag and a falcon030 , the new machines like mega64 and commanderx16 are definitely missing in my mister list ... assuming the x16 is open source there wouldnt be a problem and since the thing can run a sharp x68k i assume both other machines should be possible - however, i hear and see nothing but arcade machines on youtube (and the occasional "NOW the saturn core is working" video) it makes me think the moment the replay2 arrives all those guys and gals will leave to get their hands on ... on trial-version of switch games and dump the mister like its hot , i actually got one for my retro programming fetish but the computer cores all seem ... patched and left behind mostly and for some reason their respective scenes dont pick up on it - hence the question, is this thing here particular still alive ? (if anyone knows about a commanderx16 core i would certainly like to know too at least that way i can afford it and if the cores are good do some lightweight afternoon tea coding on it)

[FPGA64]

is this still alive, i was thinking this week other than a jag and a falcon030 , the new machines like mega64 and commanderx16 are definitely missing in my mister list ... assuming the x16 is open source there wouldnt be a problem and since the thing can run a sharp x68k i assume both other machines should be possible - however, i hear and see nothing but arcade machines on youtube (and the occasional "NOW the saturn core is working" video) it makes me think the moment the replay2 arrives all those guys and gals will leave to get their hands on ... on trial-version of switch games and dump the mister like its hot , i actually got one for my retro programming fetish but the computer cores all seem ... patched and left behind mostly and for some reason their respective scenes dont pick up on it - hence the question, is this thing here particular still alive ? (if anyone knows about a commanderx16 core i would certainly like to know too at least that way i can afford it and if the cores are good do some lightweight afternoon tea coding on it)

There are a finite number of developers and they work on what interests them in their own time for free. As such there may not be one who is interested in these cores. So you just have to wait for someone to come along or learn how to program a FPGA yourself and provide the cores.