zet.aluzina.org

not github has a snapshot of the project, it can be compiled here right after a fresh git clone and the generated sof runs here.
the current status is that the vga frambuffer is still in onchip memory csram but the fml bridge and arbiter are running. port 0 (vga) is doing nothing.

the fmlbrg_dcb has some differencies with the milkimist when you look at the fsm but currently it is not clear if we need these changes. zet runs yes the invalidate_bit ist not used. it reminds of the cache work around the nios cache has (bit31)

I am not sure if you are running windows or linux, but I use windows. So I cheat and using GitGUI, ha ha ha, but you know what, it works great for me. Much easier I think.

Hi Donna, i am using both Linux (Ubuntu via VBox) and Windows.
Linux for compilation, i would if i could the new bios doesn't compile here there must be something missing like watcom but i haven't found what from where i need to install to be able to compile the bios sorces ....

the main difference between using git via windows and linux is that the files differ.
get your files via linux and get them via windows git (like tortoisegit) the differ in length due to windows/linux file formats.

i prefer using tortoise as i am used too (daily business is tortoisesvn) but i am willing to go the linux way was zeus said that is a linux project ...
but i agree with you the context file extension you get with tortoisegit and the resulting icon symbols is realy much easier as these command line stuff (what was the correct syntax again, ups i missed to add a text for the commit ) once you are used to work with that you will never go back to commandline again ... or could you think of not using a mouse and keyboard only when designing schematics or layouts ?

what steps do i need to get the latest stable bios from your github and get is compiled, what should i install on linux ? or do you have a windows solution ?
i prefer the virtualbox linux as it seperates the installation and the windows already has visual studio 2005/8 and enough other tools, so i would like to have the watcom on linux ...

did you fixed your boot bug ?

the vga section is currently updated to run completly within the 100MHz Sdram domain.
in planar mode the fsm requests 3x the frame buffer with 3 different adr. locations in 3 clock cycles. as each clock cycle (25MHz) is 4 sdram clocks, there won't be enough time.
i will need to rewrite some parts of these modules to get more clock cycles.
currently each mode has 8 25MHz cycles fot he complete fsm's inside these modules. after moving to 100MHz clock domain, i will have 4x8 = 32 clock cycles
but these changes will need some days ... shortly before vacation

whew, SDRAM frame buffer is turning out to be a touch one !!

Nice work though getting the VGA over into the SDRAM clock domain, that is a big step.

i definitly have lost a couple or more hairs and some of the left ones turned gray.
when the vga framebuffer is completly inside sdram in all modes, you can call me Gandalf

when the job needs more modifications, i am thinking of changing the frame buffer access into using the sync time to get more time for reading from sdram like a read ahead and buffer these data.
currently i must consider that each access takes 8-10 sdram clock cycles and i need 3 of them and need to handle the complete fetch within 32 cycles. and there is a zet cpu asking for input too

edit : the read ahead could also use burst mode to fetch the complete line within less clock cycles than reading word by word.

vga text mode is now displaying the init screen
but ... yes but.

shouldn't the offset of the moved csram to sdram be csram + 0xA0000 ?
in fact i need to add 0xAC000 that the text is fetched from sdram and displayed ?

inside vga.v is this structure
always @(posedge wb_clk_i)
csr_adr_i <= wb_rst_i ? 17'h0 : csr_adr_o + start_addr[15:1];

i would expect that start_addr holds the offset 0xC000 (forget adr bit 0 0xA0000 is easier to recognire as VGA memory as 0x50000 )

but in fact this register is 0x0000

donna, zeus ... any comments ?

hmmm, I am probably out of my league here a little bit I guess, but I thought that Text starts at 0xB8000, and graphics starts at 0xA0000 ?

I am not sure what that verilog code does, maybe Zues knows?

But I think he may still be on holiday. I think I was born on the wrong continent for sure !

okay donna here is yor first verilog lesson

always @(posedge wb_clk_i)
csr_adr_i <= wb_rst_i ? 17'h0 : csr_adr_o + start_addr[15:1];

means, whenever there is a change in the wb_clk_i signal from 0 to 1 do this
when signal wb_rst_i is 1 let csr_adr_i be 0 otherwise the sum of the register csr_adr_o and start_addr


you might be right,
the base adr of the vga memory area should be 0xa000 and end at 0xbffff
but the base adr shift for the different modes should be set anywhere (in hardware by verilog as hardcorecodes or by software vga bios)
but the register that holds the offset value is not set.
as long as there was (still is everywhere else than here ) the vga frame buffer located in the csram no need to set any offset as the csram was not the sdram ...

but that is not the only problem i have, i have much bigger problems but more about that when i can say what is the reason and how others can setup the de1 in a way to see the problem and might help
i still see problems with the amount of clock cycles available even in the 100MHz domain. each sdram access that is not inside the cache takes 8-9 clock cycles. in one of the modes we need 3 fetches, each worst case 9 cycles what would take 3x9 27 cycles out of total 32 and there is a zet cpu who would also need 9 cycles when there are 32-3x9 = 5 cycles left. i have a feeling that i will need to complete rewrite the vga memory access to fill some pixel fifos ... but first i need to get a stabe and trustable text mode out of sdram ...

but donna ... could you post what is needed to compile the bios with open watcom, or post an image thatwould run on the de1 ??? i only have an image from you but i am not shure it is thelatest based on that what is on git.

you're killing me !!!!
I know what it does litterally, but like a lot of zet, there is a severe lack of commenting in the code and also a lack of documentation, so often times it is difficult to figure out what is going on (this is not meant as a critisism, this is common with open source type projects like this, no one has time to document).

But I have looked at the Zet VGA code and my conclusion is the same as yours, to run it in SDRAM will take a major re-write. The approach I have taken in other projects is similar to what you are talking about. Basically set up a line buffer and do a fast page read for that line into cache, then release the DRAM to the CPU while dribbling out the pixels. Eventually it is something I wanted to work on, but I am still involved here with ZBC, but maybe if you get it started? It is a big job I think. Also, for ZBC, I used 143Mhz SDRAM because I have this funny feeling that might be what will be needed, so I used the faster DRAM just in case.

I went ahead and attached the zip file of the last release I did of the zetbios for the de1. I have found a couple of really minor bugs since then in porting it to ZBC but I they are pretty minor. I need to go back and update it. But I have tested it well on my DE1 so it should be OK. I also included the bios.rom file in it which is a completely compiled and ready to go binary. I hope this helps.