I would appreciate any help from people who used the T80 core on this.
This is more a multi-discipline problem, because it relates to Z80
assembly and VHDL:

I have this logic to read/write into memory.

DI_CPU is the Z80 input data bus.
DO_CPU is the Z80 output data bus.
A is the Z80 address bus.

The others signals are for video ram (block memory) and other devices.

This process is to store data on memory:

writevram: process(Clk_Z80)
begin
if Clk_Z80'event and Clk_Z80 = '1' then
if A >= x"2000" and A vram_addra_sig if Wr_n = '0' and MReq_n = '0' then
vram_dina_sig vram_wea_sig else
vram_wea_sig end if;
else
vram_wea_sig end if;
end if;
end process;


And this continuous assignment is to read memory and input from other
devices and send to the Z80:

DI_CPU ("0000" & SW) when (IORQ_n = '0' and Rd_n = '0' and A(7 downto 0) =
x"20") else
("0000" & KEY) when (IORQ_n = '0' and Rd_n = '0' and A(7 downto 0)
= x"30") else
ps2_ascii_reg when (IORQ_n = '0' and Rd_n = '0' and A(7 downto 0) =
x"80");


Now the program in Z80 assembly.
This next small program will run without problems, and the byte will
be stored in memory. I can have a buch of such commands,in sequence,
and they will run and the data will be stored in memory.

ld a,41h ; define data to store
ld (8250),a ; store the data in memory position 8250 decimal
ld a,42h
ld (8251),a

However, if I try to write a block of data, it will fail, and the data
will not be written into memory:

ld de,texto ; data to store in memory
ld bc,2000h ; address of memory to store the data
loop1:
ld a,(de) ; read 1 character
or a ; compares with zero
jr z,next1 ; if zero, then end of text
ld (bc),a ; store character in ram
inc bc ; point to next ram position
inc de ; point to next character
jr loop1 ; go to store next character
texto:
db "Testing T80 Core "
db 0

--

So, what do you think it is happening?
I have considered a T80 bug, but have not come to a definitive test to
prove that.

In the other hand, I really think there is a problem with my logic. I
am a beginner with VHDL and FPGAs.

The memory model were generated using coregenerator (xilinx) and
implemented in a Spartan 3E.
The problem does not occur when I use quartus and implement the design
on a DE1 board.

Any thoughts? Ideia? I really appreciate.
Thanks.

I'm impressed you managed to move the Xilinx coregen generated memory to Altera tools, if my memory serves me correct, the Xilinx tools point at some encrypted file , not the vhdl. If it works in Altera and not in Xilinx tools, then you could well have a porting problem, but in reverse. Sounds like you generate the code in Xilinx tools, and it did not work , then exported the vhdl to Altera tools, and it did work. Ok, one last step, new project in Xilinx, and import the Altera code into the new project, don't use ANYTHING from the previous Xilinx project. Does that 'work'. BTW: how are you certain it does not work ? Any idea which part does not work ? I think into the Altera tools you did not move the encrypted Xilinx code, but the modelsim simulation vhdl of the memory, which the Altera tools then compiled. An initial hunch is that the Xilinx tools are being clever, and knowing about the core gen stuff, are using one model for simulation one for synthesis. Use the vhdl from the working Altera design and that should force the Xilinx tools not to be clever and use the 'dum' vhdl as the Altera tools did. If it works, it does not mean the Xilinx tools are at fault initially, I just think you might have been trying to out smart them. Andrew Mulcock -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of ronivon.costa at gmail.com Sent: 05 May 2008 14:28 To: cores at opencores.org Subject: [oc] T80 Core x I would appreciate any help from people who used the T80 core on this. This is more a multi-discipline problem, because it relates to Z80 assembly and VHDL: I have this logic to read/write into memory. DI_CPU is the Z80 input data bus. DO_CPU is the Z80 output data bus. A is the Z80 address bus. The others signals are for video ram (block memory) and other devices. This process is to store data on memory: writevram: process(Clk_Z80) begin if Clk_Z80'event and Clk_Z80 = '1' then if A >= x"2000" and A http://www.opencores.org/mailman/listinfo/cores No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.8/1414 - Release Date: 04/05/2008 12:31 No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.8/1414 - Release Date: 04/05/2008 12:31

The assembly looks reasonable, although it looks like you're using a different assembler than the SDCC one. As I recall, the Z80 assembler requires a # in front of every numeric constant. Basic question: Have you simulated this in VHDL? Does it pass in simulation? When you synthesize the design to the different FPGA targets, does it meet timing in each target? Have you tried to simulate the gate level netlists coming out of the synthesis tool? On Mon, May 5, 2008 at 6:27 AM, ronivon.costa at gmail.com> wrote:

Hi Peter, I have not been idle on this - for a change :) I have been working with Alessandro who has written a complete set of instructions for the Z80. I have dug out my old board which has a real z80 on and I have fixed a few operation timings. I am waiting for an additional to the test case which will allow me to test the undocumented instructions as well - after this I will check back into opencores. I did not receive too much detail from you on the auto-wait problem. Tell you what, why don't I send you the current snapshot and you can have a play, tell me whats broken and I'll fix it and check in the whole lot.?? I think the other fixes you made to the opencores varient have already been fixed in the FPGA version, so I think it is worth you starting from that point. Let me know, /Mike ----- Original Message ----- From: "H. Peter Anvin" hpa at zytor.com> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Thursday, December 25, 2008 8:51 AM Subject: Re: [oc] Re: T80 Core x webmaster at opencores.org wrote: Hello, Did anything ever happen with this? I'm kind of curious... it looks to me as if the Auto_Wait stuff is completely broken in the fpgaarcade version of the core, and I'm interested in trying to merge my changes with the ones in that version -- if at all meaningful. (I happen to have a new FPGA board for Christmas, hence the temporary interest...) -hpa _______________________________________________ http://www.opencores.org/mailman/listinfo/cores