Started by ComSoft6128, 22:44, 29 December 17
0 Members and 1 Guest are viewing this topic.
Quote from: rpalmer on 23:40, 01 January 18GUNHEAD,While I don't wish to nit-pick, that instruction is not how I/O works on a Z80. The CPC uses the I/O instruction INI or IN r,(C) where r is the register to load to.You need an INI followed by INC B to get just one byte of data from an I/O Port (the INC B is to restore the B register). The INI and INC B instruction total 24 T-States (20 for INI and 4 for INC). This means that the max transfer is 4MHz/(1024*24), which 162.76K/s and we know the CPC is actually about 3.5 MHz (due to interruptions via the CRTC) so the transfer is going to be about 140K/s.rpalmer
Quote from: GUNHED on 00:21, 03 January 18In addition you're wrong about the CRTC, it extends Z80 commands to full us frames, but the Z80 still works with 4 MHz, because the CPC has a 16 MHz crystal divided by 4.
Quote from: GUNHED on 00:21, 03 January 18Well, In don't want to nit-pick either. But in the case of the 8255IDE you can use four subsequent INI instructions then just reload B (LD B,D for example, which is just one us). You can make a block or a loop around a block. Then you reach the speed which I told you. I have the routines up and running. See Wiki page for further details.
Quote from: rpalmer on 04:08, 03 January 18What is the hardware for 8255IDE you are using?
Quote from: rpalmer on 04:08, 03 January 18I suspect that you do not really understand how the CRTC (and GA chip) access the DRAM then to display the picture.Let me inform you of HOW IT DOES THIS1. The CRTC (6845) triggers the GA to get display data (principally via the DISPEN signal - see the CPC main board schematic). Only the CRTC register settings determine when to access video data to display a picture and not the GA otherwise it would be pointless to have the CRTC at all.2. The GA then interrupts the current instruction (or next instruction) to get said data, so in conclusion the CRTC DOES indirectly slow the Z80 - end of story.This means that at times the Z80 is NOT running at 4MHz all the time, but a little less than that at times, hence it is often stated to be approximately 3.5 MHz overall.If all of this is confusing then I have nothing to add to simplify it further, it is what it is.
Quote from: arnoldemu on 10:55, 03 January 18That is a little confusing especially point 2 where you say it "interrupts the current instruction". This causes confusion with z80 or peripheral interrupts.
Quote from: rpalmer on 04:08, 03 January 18GUNHED,I suspect that you do not really understand how the CRTC (and GA chip) access the DRAM then to display the picture.[...]This means that at times the Z80 is NOT running at 4MHz all the time, but a little less than that at times, hence it is often stated to be approximately 3.5 MHz overall.[...]
Quote from: arnoldemu on 10:50, 03 January 18I believe @GUNHED is using Yarek's 8255IDE (see here http://8bit.yarek.pl/interface/yamod.ide8255/ ). He also has an internal 4mb from yarek. Yarek's design has 4 ports so you can do INI 4 times before reloading B.
Quote from: CloudStrife on 13:57, 03 January 18INI doesn't 20 T-State, it take 16 T-State
Quote from: CloudStrife on 13:57, 03 January 18Yes the GA insert WAIT state that slow down the Z80 on certain instruction...
Quote from: CloudStrife on 13:57, 03 January 18So at least when you are patronizing, try to use the right value... And the right term, a wait state IS a wait state, not an interrupt...
Quote from: CloudStrife on 13:57, 03 January 18And please, stop this fucking 3.5 MHz bullshit, the Z80 RUN AT 4 MHz, the fact that is slowed by other peripherical change nothing to this fact... it's the same on MSX, it's the same on Spectrum, it's the same on PC and this value is not even right... For exemple in this case the CPC have an equivalent speed of a Z80 of 3.33MHz, not 3.5MHz. If you want to do timing calculation on the CPC, you forget the T-state and just took a CPC NOP timing table.
Quote from: rpalmer on 23:44, 03 January 18Seriously, the GA interrupts ANY instruction execution via the WAIT signal (to delay it) and not certain instructions.
Quote from: Bryce on 23:55, 03 January 18The /WAIT signal only instructs the CPU that the buses aren't available
Quote from: rpalmer on 00:40, 04 January 18Sorry bryce, but that is not correct either.The Z80 CPU manual states:/WAIT. Wait (input, active low). /WAIT indicates to the CPU that the addressed memory or I/O devices are not ready for data transfer. The CPU continues to enter the Wait state as long as the signal is active. Extended /WAIT periods can prevent the CPU from properly refreshing dynamic memory.There is no mention of buses.rpalmer
Quote from: Bryce on 10:05, 04 January 18/WAIT indicates to the CPU that the addressed memory or I/O devices are not ready for data transfer = The buses can't be used.
Quote from: Bryce on 11:33, 04 January 18/WAIT indicates to the CPU that the addressed memory or I/O devices are not ready for data transfer = The buses can't be used BY THE Z80.
Quote from: rpalmer on 10:48, 04 January 18The clever designers of the CPC did allow the buses
Page created in 0.100 seconds with 25 queries.