Hi,
Thank you for the exellent T80 Core. I use that in the C-One Projekt.
Now I have found a Bug and fix it.
TobiFlex

when "10100010" | "10101010" | "10110010" | "10111010" =>
-- INI, IND, INIR, INDR
MCycles case to_integer(unsigned(MCycle)) is
when 1 =>
Set_Addr_To Set_BusB_To Set_BusA_To Read_To_Reg Save_ALU ALU_Op when 2 =>
IORQ Set_BusB_To Set_Addr_To when 3 =>
--TobiFlex was here
if IR(3) = '0' then
IncDec_16 else
IncDec_16 end if;
TStates Write I_BTR when 4 =>
NoRead TStates when others => null;
end case;
when "10100011" | "10101011" | "10110011" | "10111011" =>
-- OUTI, OUTD, OTIR, OTDR
MCycles case to_integer(unsigned(MCycle)) is
when 1 =>
TStates Set_Addr_To Set_BusB_To Set_BusA_To Read_To_Reg Save_ALU ALU_Op when 2 =>
Set_BusB_To Set_Addr_To when 3 =>
--TobiFlex was here
if IR(3) = '0' then
IncDec_16 else
IncDec_16 end if;
IORQ Write I_BTR when 4 =>
NoRead TStates when others => null;
end case;
end case;

Hi., Already got that one - it's in the Bally code release on www.fpgaarcade.com I have a few bug fixes from a number of people for both the 6502 and z80 cores. I have asked for CVS write permission on opencores as Daniel appears to have vanished. I will also put up and maintain the cores on the arcade website - when I get time. /Mike mikej at opencores.org -- INI, IND, INIR, INDR -- note B is decremented AFTER being put on the bus MCycles TStates IORQ if IR(3) = '0' then --IncDec_16 NoRead null; end case; when "10100011" | "10101011" | "10110011" | "10111011" => ----- Original Message ----- From: gutobix at gmx.de> To: cores at opencores.org> Sent: Wednesday, March 30, 2005 1:00 PM Subject: [oc] T80 bugfix for INI, IND, INIR, INDR, OUTI, OUTD, OTIR, OTDR

gutobix at gmx.de wrote:

I believe I posted that one to the mailing list a year and a half ago.
Unfortunately Daniel seems to have vanished, and there was a bug in TV80
when I tried to switch to it instead (specifically the JR instruction
was the same speed as JP instead of two cycles slower, which screwed up
timing dependencies -- too bad, since it otherwise worked fine --
faster, even.)

-hpa

I did a lot of the debug work on the t80, and am maintaing the T80 & T65 cores at www.fpgaarcade.com. Let me know if there are any bug fixes I have not merged yet. I will push them back to opencores at some point. /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: Tuesday, August 09, 2005 12:53 AM Subject: Re: [oc] T80 bugfix for INI, IND, INIR, INDR, OUTI, OUTD, OTIR, OTDR

MikeJ wrote:
Hi there, I looked through your stuff, and it looks like you have most of the same stuff; you have a different Auto_wait fix than I have, but they probably both work. Something I added is a RETI# output; this is not in the original Z80, of course, but since the latter used bus snooping to detect RETI#, and bus snooping is a bit painful to do in a typical FPGA/ASIC environment without tristate busses, I decided the cleanest way to signal RETI is to have another output on the CPU -- the synthesizer will optimize it out if it's not used. My code is part of the ABC80 FPGA project (ftp://ftp.abc80.org/pub/fpga/abc80/) -- it also contains a PIO design in Verilog. Since the rest of the project is in Verilog I'd like at some point to switch it over to the TV80 core, but I haven't been able to yet because of the JR bug. -hpa

Hi Peter,

We spoke a while back, and you mentioned the JR bug recently on the
list. I had a little time today to look in to it, and was wondering
if you could elaborate on what the bug is.

According to the Z80 handbook, the cycle timing for a JR operation is
4/3 if the test fails, and 4/3/5 if the test passes. This matches the
mcycle coding in the microcode as well as the results I see in
simulation.

Could you (re)summarize the problem for me?

Thanks,

Guy

Guy Hutchison wrote:


Sorry... didn't see the message until now.

The problem is that if the test passes, the timing is 10 cycles
(presumably 4/3/3, like JP.)

-hpa

On 12/13/05, H. Peter Anvin hpa at zytor.com> wrote: Could you download a new version of the core and check this again? I can't point to anything that has changed, but in my tests I see JR having 4/3/5 timing on pass and 4/3 timing on fail. I have added a simple test (jr1.asm) that performs a number of jump pass/fails, if you want to check for yourself. - Guy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20051213/5e21a968/attachment.htm