More Configuration Bits?

[zBeeble]

I'm tinkering with the C=64 sub-project. I've figured out how configuration bits work after a lot of UTSL and a little bit of other reading.

According to c64.sv, only O and UV are unused. Given that I can easily imagine the "use" for more bits here, Is there any movement in a direction of expanding the number of available bits? How much, in fpga resources do the bits and menu cost?

[ExCyber]

I'm not an expert on the MiSTer framework either, so take this with a grain of salt, but it looks to me like:

1) The status port was already expanded to 64 bits, it's just that only 32 of them are directly accessible through the configuration string.
2) There's a mechanism for custom handling of an option entry (using core-specific code in Main_MiSTer) by using an entry that starts with "OX". I don't really understand how this works, but it's used by ao486 for the boot order option.
3) When a core outgrows CONF_STR altogether (e.g. because the available options for one item depend on the state of another item), it's handled by writing the core-specific menu structure and configuration logic directly into the Main_MiSTer code. This is how Atari ST and Minimig configuration are handled.

[zBeeble]

sigh. More reading. K.

[Grabulosaure]

You can access bits 32 to 63 of the configuration string by using a lowercase "o" instead of uppercase "O".

(examples : GBA, Genesis...)

[zBeeble]

Geez. Someone should put that in the documentation.

I could really use some help with the connections between files. Is there anywhere besides UTSL I can pick up where, for instance, I pick up the address and data lines from the ram module (if installed)?

Another confusing thing is that we have v, sv, and vhd. Effectively (although not quite) three different languages. This makes figuring the connections between the files very much more difficult.

It's why I'm currently poking at a few C=64 projects before looking at what I really want to do.

[Sorgelig]

sv and v is mostly the same language. SV is more advanced. like C++ and C.
If you want to work with HDL you can prefer some language but you need to understand both VHDL and Verilog to be able to work on cores (unless you want to write a whole core yourself).

[zBeeble]

OK. I'm learning a lot from the code itself. And thank-you for your patience.

Right now, the biggest gap that I know I have is how files connect. I have an example, too.

So... I'm looking at the C64 core. c64.sv is system verilog. According to google, this is verilog++, kinda --- and includes some means to verify or test --- but why is only one file .sv for C64?

Then, I get it, verilog vs. VHDL --- it's going to be a matter of where the code came from --- and at this point, so many of the cores or a mashup of a few different projects. Looks like the 65C02 code is related to a 65C816 someone did ... the SID chip design looks pulled from somewhere different. ETC. Cool.

So... here's what I'm trying to track down right now. And this shares a little bit with what I posted as a reply in the other forum, but it's not long.

For the DRAM, sys_top.v has:

output [12:0] SDRAM_A,
inout [15:0] SDRAM_DQ,

... which seems to be too few bits. My SDRAM module is 128M. Even the C64 has 16 address lines. I checked other projects, this appears to be shared (as I understand it should). So c64.sv, then, says:

output [12:0] SDRAM_A,
output [1:0] SDRAM_BA,
inout [15:0] SDRAM_DQ,

which seems to at least agree. OK... does that mean the SDRAM_A of sys_top is connected to the SDRAM_A of C64.sv? What about the size of the SDRAM ... 128M should be 27 bits ...

[schendel]

If you have looked at the code headers, you will see that each of these files was written by a different author for a different project, so you can expect that some detective work is in order to understand what is going on.

Considering the animosity between differernt HDLs, it is amazing that it is relatively easy to connect code written in different HDLs to eachother (as long as VHDL and System Verilog stoop downto the abstraction level of Verilog). You have to look at the module/entity names, not at the file names to see how they are connected.

In all MiSTer cores, sys_top is the top level design file. This is intended as a file that contains code that is intended to be independent of the hardware being emulated. To allow this, the module name of the emulated hardware is always emu, independent of what is being emulated. This is why the module name of the c64.sv file is emu.

If you look inside fpga64_sid_iec.vhd, you can see that the cpu address bus really is 16 bits, but also that the RAM is not part of this code. Probalby because the orignal FPGA that this code was written for did not have enough block RAM to implement the RAM directly in FPGA code. Instead, it is passed out to ramAddr to the emulator top level. Here it gets a bit tricky to follow, because the address is converted to an 25 bit address inside the Cartridge port emulator, which is then passed to the SDRAM controller.

Addressing of SDRAM is a bit more complicated than the SRAM of the C64.
Look up what the Row Address Strobe (RAS) and Column Address Strobe (CAS) control lines are for here:
https://en.wikipedia.org/wiki/Synchrono ... _operation
This may also help to understand the specifications for the DIMMs that you are putting in your PC a bit better.

[Sorgelig]

As said above SDRAM works differently than SRAM. It has 2 cycles to send address split to row and column, so theoretical max for 13bit SDRAM address is 26bit of 16bits data in each cell. 64MB chip uses less address lines in column. Then 2 chips are multiplexed by CS line. Only a single core (NeoGeo) needs more than 64MB so it uses both chips. Other cores use only one chip, so chip multiplexing is absent and basically SDRAM is used as 64MB (or even 32MB).

[Sorgelig]

Thanks to HDL, both Verilog and VHDL can be connected to each other much easier than in traditional programming.
VHDL needs a header file (or component description inside VHDL) if you want to use Verilog while Verilog doesn't need anything and can instantiate VHDL modules directly.
Many cores include modules from different authors written for different projects, that's why some cores have mixture of VHDL and Verilog.

[zBeeble]

Is there any way a core can probe the size of an SDRAM beforehand?

Do we have a memory map anywhere of how cores use it? I'm trying to figure out where I can carve out 2M or even 16M for a 1750 Ram Expansion Unit (REU) for the C=64 port. It seems like the ROMs might be loaded into SDRAM instead of using a bunch of the LUTs.

There are tiny parts of the project with some documentation. The remainder are somewhat frustrating.