It shouldn't?

Here is the repository of the files, as they stand.

https://github.com/jmstein7/65c02_errata

The bit that still looks dodgy to me is:


The MUX data signals (ram_read, rom_read) are delayed by one cycle (because of the register in the block RAM), which is correct.

The MUX control signals (RE, ram_e, rom_w) are combinatorially generated from the 65C02 core address bus. This means they will switch one cycle early wrt the data.

I think the code will run for a while, and then crash at the first RAM access.

This was the point I was trying to make in the earlier posts.

(It's sometimes helpful to try actually draw this out as a schematic)

Dave

That's funny - I've been doing just that (drawing it out). Otherwise, I confuse the heck out of myself. Shockingly, it doesn't crash as it should... it reads and write to/from the stack, no problem. But, I digress. Any ideas as far as how I can mend this? I'm actually still very new to all this, so I don't fully grasp all these concepts (yet). But, I am trying really hard. -Jon

I'm very intrigued then as to why this is working...

I'll try to get this running myself tomorrow.

I still think the MUX control logic needs an extra cycle delay, so it "lines up" with the data:


This is a great way to learn - for both of us....

Dave

You read my mind with the ACIA placeholder - I was wondering how to go about that. That looks like a great solution.

I'm going to try and make those changes (without moving the goalposts again). There is just something so enjoyable about doing all this... stuff. Even when it frustrates me to no end. I can literally sit and work on this for hours (if my kids are not jumping all over the place, of course), and time just flies.

Can't wait to see what you come up with - in light of your elucidation, I'm also curious as to why this even functions. -Jon

edit: Dave, your modifications worked! It's alive!!!

That's great!

Do you think you could commit/push the latest version to github?

I've had a play with the project, using the iverilog simulator.

Pretty much all that is needed is a top level test harness:
https://github.com/hoglet67/65c02_errat ... n/top_tb.v

This ended up including a simple ACIA simulation (hanging off the external bus)

I've kept notes here on the issues that I found.
https://github.com/hoglet67/65c02_errat ... _notes.txt

The incorrect pipelining did in fact cause a failure: the first JSR to ended up in the wrong place.

When I run the simulation, I now get:

It's definitely worth learning how to simulate verilog designs. It's often far easier to find problems in a simulation than using a logic analyzer on real hardware.

The simulation output a "value change dump file" that can be viewed with gtkwave.

With this, you can see all the internal signals:


The simulator tends to be more pessimistic that real live, in terms of uninitialized signals. So some of the issue I hit you might get away with on real hardware.

Dave

Good morning, and, absolutely. I made some changes (I started to add the ACIA back in), so I need to finish hooking that up - I kind of left it dangling again, over night.

Coffee, here I come.

Dave,

This is incredible. I need to learn how to do this sort of thing.

-Jon

Dave,

The GitHub archive is updated:
https://github.com/jmstein7/65c02_errata

I added the acia back in and tried to hook it up to the S7's internal UART. As expected, it doesn't work. So, have a go at it. It's weird, because the raw data off the logic analyzer suggests that it should be working. Perhaps it's the acia code?

I have a full can oscillator at 1.8432 connected to the FPGA and, then, into the acia. Connected to a multi-region clock-enabled pin (positive side).

-Jon

It's going to be hard to simulate this, because the ACIA is in VHDL rather than Verilog, and Icarus Verilog (my preferred simulator) is Verilog only.

it would need to be translated to Verilog, which is a somewhat manual process.

Was there a particular reason you picked that ACIA?

Dave

Two reasons: 1) it is one of the very few soft acias I could find out there, but 2) it's written by LIV2, whom I'm told is a trusted member here (I asked in an earlier thread about it), and he said it performs the basic functions, which is enough for our purposes, here, I think.

But, I'm not married to it. If you know of another (in Verilog), let's try it out.

-Jon

edit: now it "works" - well, kind of. I updated the constraints file, and the top file, so you can see the changes (in github). I'm now using an external serial device (pictured below), with the results, below...

PS Here is the logic analyzer read-out:

1111111111111100 10000101 fffc r 85
1111111111111101 11000001 fffd r c1
1100000110000101 11011000 c185 r d8
1100000110000110 01011000 c186 r 58
1100000110000110 01011000 c186 r 58
1100000110000111 00100000 c187 r 20
1100000110000111 00100000 c187 r 20
1100000110001000 11000001 c188 W c1
0000000110111110 10001001 01be W 89
0000000110111101 00000000 01bd r 00
1100000110001001 11000001 c189 r c1
1100000110001001 11000001 c189 r c1
1100000101011101 10101001 c15d r a9
1100000101011110 00010000 c15e r 10
1100000101011111 10001101 c15f r 8d
1100000101100000 00000011 c160 r 03
1100000101100001 00010000 c161 W 10
1000000000000011 00000000 8003 r 00
1100000101100010 10101001 c162 r a9
1100000101100011 11001001 c163 r c9
1100000101100100 10001101 c164 r 8d
1100000101100101 00000010 c165 r 02
1100000101100110 11001001 c166 W c9
1000000000000010 00000000 8002 r 00
1100000101100111 01100000 c167 r 60
1100000101101000 00011000 c168 r 18
0000000110111100 00000000 01bc r 00
0000000110111101 10001001 01bd r 89
0000000110111110 11000001 01be r c1
1100000101101001 10101101 c169 r ad
1100000110001010 10101001 c18a r a9
1100000110001011 00001101 c18b r 0d
1100000110001100 00100000 c18c r 20
1100000110001101 11000001 c18d W c1
0000000110111110 10001110 01be W 8e
0000000110111101 00000000 01bd r 00
1100000110001110 11000010 c18e r c2
1100000110001110 11000010 c18e r c2
1100001010100101 01001000 c2a5 r 48
1100001010100110 00101001 c2a6 r 29
1100001010100111 00001101 c2a7 W 0d
0000000110111100 00000000 01bc r 00
1100001010100111 01111111 c2a7 r 7f
1100001010101000 10001101 c2a8 r 8d
1100001010101001 00000000 c2a9 r 00
1100001010101010 00001101 c2aa W 0d
1000000000000000 00000000 8000 r 00
1100001010101011 00100000 c2ab r 20
1100001010101100 11000010 c2ac W c2
0000000110111011 10101101 01bb W ad
0000000110111010 00000000 01ba r 00
1100001010101101 11101111 c2ad r ef
1100001010101101 11101111 c2ad r ef
1110111100000000 11011010 ef00 r da
1110111100000001 01011010 ef01 r 5a
1110111100000010 00000000 ef02 W 00
0000000110111001 00000000 01b9 r 00
1110111100000010 10100000 ef02 r a0
1110111100000011 11000001 ef03 W c1
0000000110111000 00000000 01b8 r 00
1110111100000011 10001111 ef03 r 8f
1110111100000100 10100010 ef04 r a2
1110111100000101 00000101 ef05 r 05
1110111100000110 11001010 ef06 r ca
1110111100000111 11010000 ef07 r d0
1110111100000111 11010000 ef07 r d0
1110111100001000 11111101 ef08 r fd
1110111100001001 10001000 ef09 r 88
1110111100000110 11001010 ef06 r ca
1110111100000111 11010000 ef07 r d0
1110111100000111 11010000 ef07 r d0
1110111100001000 11111101 ef08 r fd
1110111100001001 10001000 ef09 r 88
1110111100000110 11001010 ef06 r ca
1110111100000111 11010000 ef07 r d0
1110111100000111 11010000 ef07 r d0





https://photos.google.com/share/AF1QipM1BPMjKumR_siFSWqlkTik-T303uN3s1Gt12JGhWNUjX1JeWQdzOpDRnCW4SYbyQ?key=MEEyV0kxR1JZT0xkVklickNfR19jZFRMZmxFOERn

That looks close!

I've done a quick port of the 6551 ACIA to Verilog:
https://github.com/hoglet67/65c02_errat ... IA-Verilog

I can simulate your latest top.sv file with only very minor changes:
https://github.com/hoglet67/65c02_errat ... 09674a13c4

Here's the start of the output:


The baud rate appears to be 115,200 baud, and you can just make out from the binary patterns that the UART is not rearting characters in the simulation.

So, either the bug was in the ACIA and it was fixed when I ported to Verilog (very unlikely).

Or the bug is in top.sv and it's timing related, so the simulation and FPGA differ (quite likely).

Here's a simulation of the write to the ACIA TxDATA register:


One thing to note is the write is happening in the middle of the bus cycle, because the ACIA is using the falling edge of the clock (PHI2). I don't see a particular problem with that.

If I think of any other reasons for the double characters, then I'll let you know.

If you want to play around with the simulation, everything your should need is in github:
https://github.com/hoglet67/65c02_errata/

Dave

What speed is your 65C02 running at?

Mine was running in the Simulation at 10MHz.

I've slowed it down to 1MHz, and I now see double characters:


This is the WW in WWeellccoommee.

Let me see if I can spot why this is happening...

If I simulate the 65C02 at 2MHz the double characters goes away.

As a guess, this looks like a bug in the ACIA, which only occurs if the PHI2 clock (e.g. 1MHz) is slower than the ACIA clock (1.8432MHz).

Edit: Here's what's going on in the ACIA_TX component:


You can see TXLATCH pulses just once (writing the character to the TxDATA register), but r_txtaken pulses twice.

Looking at the code:

The intent is that the r_txtaken should reset r_txready. But there two different clocks at play here.

The r_txready pulse lasts one 1.8432MHz cycle, and it's feeding into a state machine clocked off Phi2. If Phi2 << 1.8432MHz then this pulse can be missed. The slower Phi2 is, the more chance of it being missed.

If you look at your output, occasionally you might get the character repeating more than twice.

I think this is a great example of how powerful simulation can be!

Dave