zet.aluzina.org

Finally!!

After 8 months, and a lot of changes, the 1.2.0 release just came out

I'm very happy because this is the largest release in terms of many changes introduced. Since the last release v1.1.2, now we have two more FPGA boards supported: Terasic Altera DE0 and Terasic Altera DE2-115. I removed support for Xilinx ML403 as the framebuffer has to be rewritten with a new arbitrer.

So now for all three boards: DE0, DE1 and DE2-115 we have a common BIOS in OpenWatcom that has a bootrom part that is being loaded directly in the FPGA (thanks to Donna).

As you may know, we have also mouse support on all boards (except DE1 if you didn't make the hardware change) which is working in most programes present in the SD card (Lemmings, Dune2, Norton Commander, Edit and Microsoft Windows), using the Cute Mouse driver from FreeDOS. We have to thank Donna for this too

The BIOS compiled with RELEASE flags is running much faster now, also because of the shadow part running in RAM. We can see now the effects of the OpenWatcom compiler.

Since the last release, we have also new Zet opcodes, system timer improvements, speaker support, a new UART core and a lot of bug fixes. So many thanks to Donna, Yury, Alterafreak and all of you that contributed to this release

The new tar.bz2 and .zip packages now include .sof and .pof files for all boards with the compiled version of the BIOS. Also new scripts for flashing the boards from Linux.

Enjoy it!!

i was mostly offline for a while, so this is realy great news

my little son is fine now and everything went perfect, so i will need to look what is changed and how i can update my sources to be on the track again.
this will take a while, but i think it is needed to build framebuffer upon these changes.

just downloaded v1.2.0.zip but i am missing the bootrom sources inside the src folder ...

so still looking foreward to see the improvements.

great job !

I'm very glad your son ended fine with the operation

There are no sources for the bootrom. It's simply taking the last 256 bytes of the compiled BIOS. The Makefile is doing that automatically when doing "make".

You have first to build the BIOS before building the bitstream with Quartus.

About the IO map of the flash, it's not memory mapped anymore, so 0xfxxxx and 0xcxxxx are mapped now to RAM except the last 256 bytes 0xfffxx which are mapped on to the bootrom. The IO space for the flash has been moved to 0x0238 - 0x023b, but the BIOS copy from flash to RAM and the floppy access is handled by the BIOS transparently, as it was before.

So... welcome back!!

yes we are glad too and didn't expect that it would be that good.
in fact he was walking again less than 2 hours after he wake up from the operation...

so just the last 256 bytes .... well ... in that case ... a perfect "kiss" aproach ... and i was thinking about it.

with that memory layout it should run here too on my own pcb.

i'll be back soon.

What are the system's performances (benchmark) on the different supported boards, as far as memory and cpu is concerned? I've attached a benchmarking utility (under msdos) as I would like to compare Zet's performances to real hardware.


Thank you,
J.

Haha I think you would get a bit disappointed... 5.08 Mhz

This applies for all boards, as the SoC is the same.

just tried that tool too while merging my sources with git master V1.20 and wonder where the slight different results come from. could it be that the videospeed is influenced by the sdram cache ?
CPU clock 4,268MHz
CPU 5.13MHz
Video 2978 chr/ms
just started to upgrade the zet cpu core only, no bios shadow and other new tricks...

I see, that's very strange...

Do you have a larger cache?? It can be too that the timer was upgraded and now the timer counter can be changed to allow more precise interrupts. That was not available before. If the program is checking the performance against the timer interrupt, that can be a reason...

a larger cache ... well ... due to my motto : "Frankie says ... have all that you desire"
yes the memory blocks are already paid and if they are free i use them as cache.
i guess 16KByte cache or somewhere around that.
but i will need to upgrade all the other cores too, as well as the bios
i'll attach a smaler picture next time when i have upgraded.

Regarding the speed I can say that IMHO the largest hidden resource to increase Zet speed is not CPU clock but SDRAM access optimization. I have not tried the latest release yet but on previous Zet I saw that SDRAM access was the slowest thing. Shadow BIOS now if it is made without SDRAM access optimization can make Zet a bit slower not faster.

The facts as I understand are as follows:
1. FLASH read access is made within single Zet clock without wait states (actually as I remember the clock speed was selected taking in account FLASH access speed).
2. SDRAM read access requires 3-4 extra wait states (of slow Zet clock!) even if data is already in cache!

That can provide 3-4 times speed increase if cache access will be shortened to 1 clock cycle without wait states as it should be in normal system. One of sources of this problem is different clock domains for SDRAM cache and CPU. Another possible source of the problem could be cache design itself (although I haven't checked how many original cache clock cycles it requires to get cached data from cache). It looks that any general independent clock domain synchronization approach will not be optimal in this case because it always requires several clocks. Here we may need one clock derived from another clock (divided by N, for example) and with known interclock timing it is possible to make synchronous interclock buffer without waitstates.

From timing diagrams I've seen in SignalTap I remember that cache to SDRAM interface looks quite good but CPU to cache interface requires some new ideas.