Author Topic: FPGA VGA Controller for 8-bit computer  (Read 433874 times)

0 Members and 6 Guests are viewing this topic.

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2825 on: October 08, 2021, 05:05:27 pm »
Ok, give this a shot.

I re-did the Z80_Bus_Interface.sv completely.
The simulator now supports everything except the 'WAIT' management.

Things to test and check:

Lines 362-364: Is this the correct way to handle the bank ID?
Lines 425-450: I hope I got the sound and keyboard correct since all the IO ports are now stored and decoded in an array seen on lines 154-177.

I will need SignalTap shots or reads (cached & uncached) and writes.

If this new bus interface works like the old one, then I will add in the wait.

I've attached the Modelsim Project and a new gpu.sv and xxxx.sdc files.

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2826 on: October 08, 2021, 09:23:24 pm »
Okay, this version works, but not as well as before these changes.  By that, I mean that the DMI is able to correctly set up the screen without using the LDIR clear-screen trick, but the bootstrap screen is corrupted (that uses the LDIR trick), so read timing isn't quite right.

First write for a cache miss:



Second write for a cache hit:



First read for a cache miss:



Second read for a cache hit:



Port writes and reads seem to work okay (haven't been able to test the PS2 or sound though).
« Last Edit: October 08, 2021, 10:32:40 pm by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2827 on: October 08, 2021, 10:47:27 pm »
Is it just me, or, does the 'cmd_read_req' look inverted?

It's odd as the 'CMD_read_ready[1]' seems to be positive polarity.

Well, going by that, on CH_C011, you can see at the fall of Z80_RDn_r & Z80_MREQn_r, the read req is sent out on the same clock.  The read ready comes back in 2 clocks, and 1 clock later, 245 dir is set while the data outputs 1 clock later.

CH_C010 shows a slow read...

Ok, I need to see why that read is inverted there.

Also, please provide the latched Z80_addr_r input instead of the mem-range.  Something is fishy about the not in cache read req.

And I want to see a port read and port write.  We will save the read-op-code for when the 'wait' is functioning.

Except for the inverted 'cmd_read_req', it looks like I can add the 'WAIT' tonight which should fix the last read data problem.
The only problem is that I need to assert it immediately as I send the read req.

Well, I guess the time accurate Modelsim Z80 bus generator was really needed to generate a real Z80 bus interface which works as fast as possible without all that old code we had to filter the bus signals.


*** What does the read DDR3 data look like on the Z80 display hex.  Does it read correct data?

Also, I need to make the read_req and the write_req send out a single command instead of a whole bunch.

« Last Edit: October 08, 2021, 10:50:53 pm by BrianHG »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2828 on: October 09, 2021, 09:22:49 am »
Ok, here you go, the hopefully final Z80 interface with 'WAIT' processing.

The new simulator has 2 setups.

do setup_z80.do / run_z80.do
Will simulate the Z80 bus interface on it's own and will work with any FPGA vendor's version of ModelSim.

do setup_z80_to_DDR3.do / run_z80_to_DDR3.do
Will simulate the Z80 bus with my DDR3 ram controller, completely so you can see how the waits are effected.
This simulation requires Altera/Intel's version of ModelSim.

Things to read in the module parameter settings:
Code: [Select]
// Z80 bus timing settings.
   .READ_PORT_CLK_POS     ( 2       ), // Number of Z80_CLK cycles before the bus interface responds to a Read Port command.
   .WRITE_PORT_CLK_POS    ( 2       ), // Number of Z80_CLK cycles before the bus interface samples the Write Port command's data.

// 0 to 3, Number of CMD_CLK cycles to wait for DDR3 read before asserting the WAIT during a Read Memory cycle.
// Use 0 for an instant guaranteed 'WAIT' every read.  (Safest for Read Instruction Opcode cycle.)
// Use 3 for compatibility with waiting for a BrianHG_DDR3 read cache hit before asserting the 'WAIT'.

   .Z80_DELAY_WAIT_RI     ( 0       ), // 0 to 4, Number of CMD_CLK cycles to wait for DDR3 read_ready before asserting the WAIT during a Read Instruction Opcode cycle.
   .Z80_DELAY_WAIT_RM     ( 3       ), // 0 to 4, Number of CMD_CLK cycles to wait for DDR3 read_ready before asserting the WAIT during a Read Memory cycle.
   .Z80_WAIT_QUICK_OFF    ( 1       ), // 0 (Default) = WAIT is turned off only during a low Z80_CLK.  1 = WAIT is turned off as soon as a read_ready is received.

and

Code: [Select]
// Read IO port addresses range.
   .READ_PORT_BEGIN       ( 240     ), // Sets the beginning port number which can be read.
   .READ_PORT_END         ( 249     ), // Sets the ending    port number which can be read.

and new IO port when you are ready to get rid of the legacy IO port stuff inside the Z80 bus controller:

Code: [Select]
// ***********************************
// *** Z80 IO Read and Write ports ***
// ***********************************

   output logic [255:0] WRITE_PORT_STROBE          = 0 , // The bit   [port_number] in this 256 bit bus will pulse when the Z80 writes to that port number.
   output logic   [7:0] WRITE_PORT_DATA   [0:255]      , // The array [port_number] will hold the last written data to that port number.
   output logic [255:0] READ_PORT_STROBE           = 0 , // The bit   [port_number] in this 256 bit bus will pulse when the Z80 reads from that port number.
   input  wire    [7:0] READ_PORT_DATA    [0:255]      , // The array [port_number] will be sent to the Z80 during a port read so long as the read port
                                                         // number is within parameter READ_PORT_BEGIN and READ_PORT_END.

This was 3 solid days of work, so you better appreciate it.


I need read and write snapshots.  I hope everything works now.
If not, play with the  Z80_WAIT_QUICK_OFF     and/or make  Z80_DELAY_WAIT_RM     =0.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2829 on: October 09, 2021, 09:29:00 am »
Signaltap these signals:

Z80_CLK_r, 
Z80_ADDR_r,
Z80_M1n_r, 
Z80_IORQn_r,
Z80_MREQn_r,
Z80_RDn_r, 
Z80_WRn_r, 
Z80_wData_r,
Z80_fpga_data_oe,
Z80_fpga_data_out,
CMD_read_req, 
CMD_read_ready,
Z80_WAIT,

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2830 on: October 09, 2021, 09:36:38 am »
****** This post is a little useless now, as I was writing it whilst you posted your last two updates, but I'll post it anyway. ********

Also, please provide the latched Z80_addr_r input instead of the mem-range.  Something is fishy about the not in cache read req.

And I want to see a port read and port write.  We will save the read-op-code for when the 'wait' is functioning.

Is Z80_addr_r[0..15] not what you're wanting to see?  I'd added it to the write traces after I'd done the reads, so I'll do a couple more reads.

Here's a cache miss read at 0000:



And here's a cache hit read 0001:




*** What does the read DDR3 data look like on the Z80 display hex.  Does it read correct data?

Without any WAITs added, I'm getting good clean data in the DMI for the most part, but read timings are still not quite there.  As you can see with the page 0 dump below, a single 0x7E is snuck into the returned data:

Code: [Select]
DUMP &C000
     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C010 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00  ................
C020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C060 08 00 0F 00 12 00 00 50 02 7F 01 DF 00 00 00 00  .......P........
C070 00 01 0F 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C080 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C0F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

This is pretty rare, but it's enough to throw the LDIR clear-screen function and corrupt the screen setup data in the bootstrap every time.

Port reads and writes

Here's a port write - I can't get a port read at the moment without modifying the Z80_Interface as Quartus seems to be optimising everything away on that side.

« Last Edit: October 09, 2021, 09:38:14 am by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2831 on: October 09, 2021, 09:53:23 am »
Here is a Sim with DDR3 of the worst case scenario.



This is where read problems will occur without the WAIT.
Notice that during the refresh-write-read, there are 3 TW clock cycles added.
« Last Edit: October 09, 2021, 09:55:07 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2832 on: October 09, 2021, 09:59:33 am »
Ok, here you go, the hopefully final Z80 interface with 'WAIT' processing.

Okay, just a real quick update on this build.  The initial screen is fine as set up by the bootstrap, so it seems reads are working well now (at least LDIR clear screen is having no issues).

The only issue is that I have to press space to get to the menu, and when I do, the system locks up with WAIT permanently low (the CPU card has an LED for WAIT).  I'll look to get more traces later.

EDIT: Same issue with WAIT_QUICK set to 1.
« Last Edit: October 09, 2021, 10:05:15 am by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2833 on: October 09, 2021, 10:12:41 am »
Give this a try.  I'm now maintaining a read continuous request until the read ready is received.

If this doesn't work, I'll make it so that if at any time a read_ready comes in, the wait will clear.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2834 on: October 09, 2021, 10:33:04 am »
No, same issue with that build.  :(
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2835 on: October 09, 2021, 10:43:16 am »
Ok, this one is going to hurt if it works.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2836 on: October 09, 2021, 10:46:00 am »
No, that does the same thing.   :-\
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2837 on: October 09, 2021, 11:00:25 am »
Hun?
How is that possible unless a read is totally missed?

Note that each of these are simulating fine...

Holy crap, this one must work...
It is self clearing...

Line 346 is the wait algorithm...

There must be something going wrong with the Z80 bus reads.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2838 on: October 09, 2021, 11:17:57 am »
Yep, that works. :-+
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2839 on: October 09, 2021, 11:20:40 am »
Ok, before I make final changes, please go through a flurry of tests.

Signaltap & Z80 read/write...

 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2840 on: October 09, 2021, 12:03:07 pm »
Ok, before I make final changes, please go through a flurry of tests.

Signaltap & Z80 read/write...

Okay, page dumps are all good from the Z80.  Signal Taps as follows.

Cache miss, writing to 0000:



Cache hit, writing to 0001:



Cache miss, reading from 0000:



Cache hit, reading from 0001:



 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2841 on: October 09, 2021, 12:16:17 pm »
Looking at the CMD_read_ready[1], the length of those extended wait TW cycles are absurd.
Are you still using that junk transistor with the 200ns turn off?

What about the 'LDIR' clear screen trick?

If you cant get all the test signals, maybe we need to find their root source to tap.

Like, I really want to see the 'Z80_WAIT' output in the signaltap.  It is kinda the important thing.
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2842 on: October 09, 2021, 12:22:59 pm »
Here is another test.
It should stop flooding the DDR3 read requests after a read_ready has been received.  (It's my multiport's cache system which prevents this trick from making my DDR3 controller PHY from going on a non-stop reading rampage.)
And one-shot the DDR3 writes.
« Last Edit: October 09, 2021, 12:27:39 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2843 on: October 09, 2021, 03:16:40 pm »
Looking at the CMD_read_ready[1], the length of those extended wait TW cycles are absurd.
Are you still using that junk transistor with the 200ns turn off?

Well, I swapped it with an NX138 a few weeks ago and it hasn't made much difference.  I'm waiting on the latest version of the DECA interface card to arrive and I'll try out the 74LVC06 then.

What about the 'LDIR' clear screen trick?

That's working fine.  When the uCOM resets, or first powers up, it boots into the bootstrap.  That uses the LDIR trick to clear the GPU's page 0 before setting up the screen, so I know straight away if the LDIR trick works with the latest build or not.

If you cant get all the test signals, maybe we need to find their root source to tap.

Like, I really want to see the 'Z80_WAIT' output in the signaltap.  It is kinda the important thing.

I'm not likely to have the time to do that today, unless it's much later tonight.  Failing that, maybe tomorrow.  Got a busy weekend unfortunately.

Here is another test.
It should stop flooding the DDR3 read requests after a read_ready has been received.  (It's my multiport's cache system which prevents this trick from making my DDR3 controller PHY from going on a non-stop reading rampage.)
And one-shot the DDR3 writes.

This one works fine as well. :-+
 
The following users thanked this post: BrianHG

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2844 on: October 10, 2021, 06:09:07 am »
Ok, here is V1.10 of the Z80 bus testbench and bus interface.  Test it to see if it works and also fixes the read cache as last read cache you showed me here https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3737161/#msg3737161 didn't work, it sent the 'wait' anyways when it didn't need to.

By the way, there is no such thing as a write cache hit.  Writes are always a cache hit.  It's a question of if you can completely fill the write cache.  To do this, the Z80 will need to be clocked at 4.8GHz if it were doing nothing but writing data in a straight line.  But since it needs to read op-code to do the writing, make that >9GHz Z80.

I need to know if you can test reading opcode from GPU ram.  It is important as it is worth running read opcodes through a second DDR3 read channel so they have their own separate 16 instruction cache compared to the read and write memory instructions.  This might effect the either the maximum MAGGIE layers or GEO performance if you store OP-code in the DDR3.  It's just a consideration.
« Last Edit: October 10, 2021, 08:04:11 am by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2845 on: October 10, 2021, 11:07:27 am »
Ok, here is V1.10 of the Z80 bus testbench and bus interface.  Test it to see if it works and also fixes the read cache as last read cache you showed me here https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg3737161/#msg3737161 didn't work, it sent the 'wait' anyways when it didn't need to.

No worries, will try to get this done later today if I can.

By the way, there is no such thing as a write cache hit.  Writes are always a cache hit.  It's a question of if you can completely fill the write cache.  To do this, the Z80 will need to be clocked at 4.8GHz if it were doing nothing but writing data in a straight line.  But since it needs to read op-code to do the writing, make that >9GHz Z80.

A worthy goal, but 9GHz might be a bit beyond 70's silicon and well into the futuristic optical domain.  I'll get in touch with Intel and SMC and see what they can do. :-DD

I need to know if you can test reading opcode from GPU ram.  It is important as it is worth running read opcodes through a second DDR3 read channel so they have their own separate 16 instruction cache compared to the read and write memory instructions.  This might effect the either the maximum MAGGIE layers or GEO performance if you store OP-code in the DDR3.  It's just a consideration.

Yes, no problem.  I can write a little program and load it into page 1 of GPU RAM and execute it no problems.  Although I can't really see any particular use for it - there's plenty of RAM available elsewhere.
« Last Edit: October 10, 2021, 11:13:35 am by nockieboy »
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2846 on: October 10, 2021, 11:28:49 am »
I need to know if you can test reading opcode from GPU ram.  It is important as it is worth running read opcodes through a second DDR3 read channel so they have their own separate 16 instruction cache compared to the read and write memory instructions.  This might effect the either the maximum MAGGIE layers or GEO performance if you store OP-code in the DDR3.  It's just a consideration.

Yes, no problem.  I can write a little program and load it into page 1 of GPU RAM and execute it no problems.  Although I can't really see any particular use for it - there's plenty of RAM available elsewhere.

Make the Z80 bus generic and support everything.  You never know, you may just use the all the onboard ram as your system memory.  Otherwise loading and executing software from the onboard/SD card flash will be tediously slow.

LOL, you'll have a deca board with nothing but a Z80 mounted on it...
 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2847 on: October 10, 2021, 12:28:55 pm »
Ok, once you checked the V1.10 bus controller and it has passed, here I made your GPU geometry unit run on the DDR3.

Now with more R&W ports on my multiport front end, FMAX has boggled down.  There might be graphic garbage.  It looks like I will need to make my simple high speed stack-able 2:1 multiport front end this week as you will need it for more RW ports if you want any real speed.

*Don't forget you need to copy the font into the DDR3 as it has random junk at power-up.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #2848 on: October 12, 2021, 11:32:31 am »
Okay, running code from GPU RAM.  Here's the program in the GPU RAM at page 1:

Code: [Select]
DUMP &C100
     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C100 3E 55 01 20 00 21 FF C0 77 2B 10 FC C9 00 00 00  >U. .!..w+......
C110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
Ready
DASM &C100,&C
DISASSEMBLING C100h to C10Bh:

C100 3E 4E     LD   A,$55
C102 06 20     LD   B,$20
C104 21 45 00  LD   HL,C1FFH
C107 77        LD   (HL),A
C108 2B        DEC  HL
C109 10 20     DJNZ C107H
C10B C9        RET
             ----------------

It should write 0x55 to C1E0-C1FF.  Here's page 1 after it's run:

Code: [Select]
DUMP &C100
     +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
C100 3E 55 06 20 21 FF C1 77 2B 10 FC C9 00 00 00 00  >U. !..w+.......
C110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
C1E0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55  UUUUUUUUUUUUUUUU
C1F0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55  UUUUUUUUUUUUUUUU

So that's code executing in page 1 of the GPU RAM and writing to the same page.  Here's a Signal Tap of the first opcode (0x3E) being read:



And one of those 0x55s being written to GPU RAM:


 

Online BrianHG

  • Super Contributor
  • ***
  • Posts: 7789
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #2849 on: October 12, 2021, 11:40:25 am »
Ok, excellent.
We seem to get the wait out ahead in time.

Now, change this parameter:
Code: [Select]
   .Z80_DELAY_WAIT_RI     ( 2       ), // 0 to 7, Number of CMD_CLK cycles to wait for DDR3 read_ready before asserting the WAIT during a Read Instruction Opcode cycle.
And capture the second read opcode as this one should now be read from cache without any 'WAIT' inserted as my DDR3 will now return the data quick enough to not need to.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf