I've just made a little recording, with Links 2 (XT 10MHz emulation on UniPCemu) and compared it to the Youtube recording( https://www.youtube.com/watch?v=m6Uoi9U3gKA ) at https://www.dropbox.com/s/gn83bp8uen2ut5t/Uni … yquist.wav?dl=0

I've modified the low-pass filter to filter at the nyquist frequency(44.1kHz samplerate, with 96dB attenuation(assuming 6dB per octave)).

1//Speaker low pass filter values (if defined, it's used)! We're 96dB dynamic range, with 6dB per octave, so 16 times filtering is needed to filter it fully at the nyquist frequency.
2#define SPEAKER_LOWPASS ((((float)SPEAKER_RATE)/2.0f)/16.0f)

Although there's some soft noise in the background of UniPCemu's recording, could Youtube be filtering that away?

Edit: I've made a little recording of UniPCemu running 8088MPH (compare against the original 8088MPH recording mpg):
https://www.dropbox.com/s/k8dp8ot0nyvw9he/Uni … 088MPH.zip?dl=0

Original 8088 MPH recording for reference: https://www.dropbox.com/s/9ydrycafqdmd332/808 … %20MPH.mpg?dl=0

Sounds pretty close, although the original noise is a bit softer(more white-noise instead of heavy vibe that's in UniPCemu) it seems?

I wouldn't say Youtube is an authoritative reference point for how RealSound is supposed to be. Who knows what was being used to run the game?

If you have an older machine, I'd try Links there. Otherwise, see if someone has a decent microphone they can use to record gameplay sounds on their own retro machine. Of course, you have to remember that this is not necessarily the "correct" way for PC speaker audio to sound - you'd be modeling (somewhat) the sound of one particular machine.

Listening to UniPCemu recordings and 8088MPH.MPG, it seems that the original recording has more noise, but UniPCemu has some kind of vibe instead of the noise? Does this imply that there's a problem with my filter? Or does it imply the PIT is producing an signal with errors?

My PIT emulation:

1//Render 1.19MHz samples for the time that has passed!
2	length = i/MHZ14_RATE; //How many ticks to tick?
3	i -= length*MHZ14_RATE; //Rest the amount of ticks!
4	time_ticktiming = i; //Save the new count!
5
6	if (length) //Anything to tick at all?
7	{
8		for (channel=0;channel<3;channel++)
9		{
10			mode = PITchannels[channel].mode; //Current mode!
11			for (tickcounter = length;tickcounter;--tickcounter) //Tick all needed!
12			{
13				switch (mode) //What mode are we rendering?
14				{
15				case 0: //Interrupt on Terminal Count? Is One-Shot without Gate Input?
16				case 1: //One-shot mode?
17					switch (PITchannels[channel].status) //What status?
18					{
19					case 0: //Output goes low/high?
20						PITchannels[channel].channel_status = mode; //We're high when mode 1, else low with mode 0!
21						PITchannels[channel].reloadlistening = 1; //We're listening to reloads!
22						if (PITchannels[channel].reload)
23						{
24							PITchannels[channel].gatelistening = mode; //We're listening to gate with mode 1!
25							PITchannels[channel].status = 1; //Skip to 1: we're ready to run already!
26							goto mode0_1; //Skip to step 1!
27						}
28						break;
29					case 1: //Wait for next rising edge of gate input?
30						mode0_1:
31						if (!mode) //No wait on mode 0?
32						{
33							PITchannels[channel].status = 2;
34							goto mode0_2;
35						}
36						else if (PITchannels[channel].gatewenthigh) //Mode 1 waits for gate to become high!
37						{
38							PITchannels[channel].gatewenthigh = 0; //Not went high anymore!
39							PITchannels[channel].gatelistening = 0; //We're not listening to gate with mode 1 anymore!
40							PITchannels[channel].status = 2;
41							goto mode0_2;
42						}
43						break;
44					case 2: //Output goes low and we start counting to rise! After timeout we become 4(inactive) with mode 1!
45						mode0_2:
46						if (PITchannels[channel].reload)
47						{
48							PITchannels[channel].reload = 0; //Not reloading anymore!
49							PITchannels[channel].channel_status = 0; //Lower output!
50							reloadticker(channel); //Reload the counter!
51						}
52
53						oldvalue = PITchannels[channel].ticker; //Save old ticker for checking for overflow!
54						if (mode) --PITchannels[channel].ticker; //Mode 1 always ticks?
55						else if ((PCSpeakerPort&1) || (channel<2)) --PITchannels[channel].ticker; //Mode 0 ticks when gate is high! The other channels are tied 1!
56						wrapPITticker(channel); //Wrap us correctly!
57						if ((!PITchannels[channel].ticker) && oldvalue) //Timeout when ticking? We're done!
58						{
59							PITchannels[channel].channel_status = 1; //We're high again!
60						}

61						break;
62					default: //Unsupported! Ignore any input!
63						break;
64					}
65					break;
66				case 2: //Also Rate Generator mode?
67				case 6: //Rate Generator mode?
68					switch (PITchannels[channel].status) //What status?
69					{
70					case 0: //Output going high! See below! Wait for reload register to be written!
71						PITchannels[channel].channel_status = 1; //We're high!
72						PITchannels[channel].status = 1; //Skip to 1: we're ready to run already!
73						PITchannels[channel].reloadlistening = 1; //We're listening to reloads!
74						goto mode2_1; //Skip to step 1!
75						break;
76					case 1: //We're starting the count?
77						mode2_1:
78						if (PITchannels[channel].reload)
79						{
80							reload2:
81							PITchannels[channel].reload = 0; //Not reloading!
82							reloadticker(channel); //Reload the counter!
83							PITchannels[channel].channel_status = 1; //We're high!
84							PITchannels[channel].status = 2; //Start counting!
85							PITchannels[channel].reloadlistening = 0; //We're not listening to reloads anymore!
86							PITchannels[channel].gatelistening = 1; //We're listening to the gate!
87						}
88						break;
89					case 2: //We start counting to rise!!
90						if (PITchannels[channel].gatewenthigh) //Gate went high?
91						{
92							PITchannels[channel].gatewenthigh = 0; //Not anymore!
93							goto reload2; //Reload and execute!
94						}
95						if (((PCSpeakerPort & 1) && (channel==2)) || (channel<2)) //We're high or undefined?
96						{
97							--PITchannels[channel].ticker; //Decrement?
98							switch (PITchannels[channel].ticker) //Two to one? Go low!
99							{
100							case 1:
101								PITchannels[channel].channel_status = 0; //We're going low during this phase!
102								break;
103							case 0:
104								PITchannels[channel].channel_status = 1; //We're going high again during this phase!
105								reloadticker(channel); //Reload the counter!
106								break;
107							default: //No action taken!
108								break;
109							}
110						}
111						else //We're low? Output=High and wait for reload!
112						{
113							PITchannels[channel].channel_status = 1; //We're going high again during this phase!
114						}
115						break;
116					default: //Unsupported! Ignore any input!
117						break;
118					}
119				//mode 2==6 and mode 3==7.
120				case 3: //Square Wave mode?
121				case 7: //Also Square Wave mode?
122					switch (PITchannels[channel].status) //What status?
123					{
124					case 0: //Output going high! See below! Wait for reload register to be written!
125						PITchannels[channel].channel_status = 1; //We're high!
126						PITchannels[channel].reloadlistening = 1; //We're listening to reloads!
127						if (PITchannels[channel].reload)
128						{
129							PITchannels[channel].reload = 0; //Not reloading!
130							reloadticker(channel); //Reload the counter!
131							PITchannels[channel].status = 1; //Next status: we're loaded and ready to run!
132							PITchannels[channel].reloadlistening = 0; //We're not listening to reloads anymore!
133							PITchannels[channel].gatelistening = 1; //We're listening to the gate!
134							goto mode3_1; //Skip to step 1!
135						}
136						break;
137					case 1: //We start counting to rise!!
138						mode3_1:
139						if (PITchannels[channel].gatewenthigh)
140						{
141							PITchannels[channel].gatewenthigh = 0; //Not anymore!
142							PITchannels[channel].reload = 0; //Reloaded!
143							reloadticker(channel); //Gate going high reloads the ticker immediately!
144						}
145						if ((PCSpeakerPort&1) || (channel<2)) //To tick at all? The other channels are tied 1!
146						{
147							PITchannels[channel].ticker -= 2; //Decrement by 2 instead?
148							switch (PITchannels[channel].ticker)
149							{
150							case 0: //Even counts decreased to 0!
151							case 0xFFFF: //Odd counts decreased to -1/0xFFFF.
152								PITchannels[channel].channel_status ^= 1; //We're toggling during this phase!
153								PITchannels[channel].reload = 0; //Reloaded!
154								reloadticker(channel); //Reload the next value to tick!
155								break;
156							default: //No action taken!
157								break;
158							}
159						}
160						break;
161					default: //Unsupported! Ignore any input!
162						break;
163					}
164					break;
165				case 4: //Software Triggered Strobe?
166				case 5: //Hardware Triggered Strobe?
167					switch (PITchannels[channel].status) //What status?
168					{
169					case 0: //Output going high! See below! Wait for reload register to be written!
170						PITchannels[channel].channel_status = 1; //We're high!
171						PITchannels[channel].status = 1; //Skip to 1: we're ready to run already!
172						PITchannels[channel].reloadlistening = 1; //We're listening to reloads!
173						PITchannels[channel].gatelistening = 1; //We're listening to the gate!
174						goto mode4_1; //Skip to step 1!
175						break;
176					case 1: //We're starting the count or waiting for rising gate(mode 5)?
177						mode4_1:
178						if (PITchannels[channel].reload)
179						{
180						pit45_reload: //Reload PIT modes 4&5!
181							if ((mode == 4) || ((PITchannels[channel].gatewenthigh) && (mode == 5))) //Reload when allowed!
182							{
183								PITchannels[channel].gatewenthigh = 0; //Reset gate high flag!
184								PITchannels[channel].reload = 0; //Not reloading!
185								reloadticker(channel); //Reload the counter!
186								PITchannels[channel].status = 2; //Start counting!
187							}
188						}
189						break;
190					case 2: //We start counting to rise!!
191					case 3: //We're counting, but ignored overflow?
192						if (PITchannels[channel].reload || (((mode==5) && PITchannels[channel].gatewenthigh))) //We're reloaded?
193						{
194							goto pit45_reload; //Reload when allowed!
195						}
196						if (((PCSpeakerPort & 1) && (channel == 2)) || (channel<2)) //We're high or undefined?
197						{
198							--PITchannels[channel].ticker; //Decrement?
199							wrapPITticker(channel); //Wrap us correctly!
200							if (!PITchannels[channel].ticker && (PITchannels[channel].status!=3)) //One to zero? Go low when not overflown already!
201							{
202								PITchannels[channel].channel_status = 0; //We're going low during this phase!
203								PITchannels[channel].status = 3; //We're ignoring any further overflows from now on!
204							}
205							else
206							{
207								PITchannels[channel].channel_status = 1; //We're going high again any other phase!
208							}
209						}
210						else //We're low? Output=High and wait for reload!
211						{
212							PITchannels[channel].channel_status = 1; //We're going high again during this phase!
213						}
214						break;
215					}
216					break;
217				default: //Unsupported mode! Ignore any input!
218					break;
219				}
220				currentsample = PITchannels[channel].channel_status; //The current sample we're processing, prefetched!
221				if (channel) //Handle channel 1&2 seperately too!
222				{
223					//Process the rise toggle!
224					if (((PITchannels[channel].lastchannel_status^currentsample)&1) && currentsample) //Raised?
225					{
226						PITchannels[channel].risetoggle ^= 1; //Toggle the bit in our output port!
227					}
228
229					//Now, write the (changed) output to the channel to use!
230					if (channel==2) //PIT2 needs a sound buffer?
231					{
232						//We're ready for the current result!
233						writefifobuffer(PITchannels[channel].rawsignal, currentsample&((PCSpeakerPort & 2) >> 1)); //Add the data to the raw signal! Apply the output mask too!
234					}
235					else //PIT1 is connected to an external ticker!
236					{
237						if ((PITchannels[channel].lastchannel_status^currentsample) & 1) //Changed?
238						{
239							if (PIT1Ticker) //Gotten a handler for it?
240							{
241								PIT1Ticker(currentsample); //Handle this PIT1 tick!
242							}
243						}
244					}
245				}
246				else //PIT0?
247				{
248					if ((PITchannels[channel].lastchannel_status^currentsample) & 1) //Changed?
249					{
250						if (currentsample) //Raised?
251						{
252							raiseirq(0); //Raise IRQ0!
253						}
254						else //Lowered?
255						{
256							lowerirq(0); //Lower IRQ0!
257						}
258					}
259				}
260				PITchannels[channel].lastchannel_status = currentsample; //Save the new status!
261			}
262		}
263	}

The used filter (low-pass and high-pass IIR filters):
https://bitbucket.org/superfury/unipcemu/src/ … ers.c?at=master

Edit: The filter itself might be doubled in frequency, seeing as the input signal from the PIT is scaled to -16384 to +16383 15-bit range instead of full 16-bit range to prevent overflow when filtering.

Edit: Is it just me or is the recording from UniPCemu slower than the MPG recording?

The high-frequency noise in the Links recording is probably aliasing of the PWM carrier, but I can't tell for sure without doing some research and running a spectrogram.

The buzzing (and slowness) in the 8088MPH mod player is almost certainly due to inaccuracies in the timing of your emulated CPU causing samples to be emitted at irregular intervals instead of exactly every 72 PIT cycles. Again I'd need to do some analysis to be completely sure.

The easiest way for you to find out for sure would be to do the experiment I suggested earlier - dump the pre-filtered 1.193MHz speaker data to a file, load it into Cool Edit, resample to 44.1kHz there, listen to the result and compare the resulting spectrogram to that of the actual output from your emulator with its filter in place. Then you'll be able to see exactly what your filter is doing.

reenigne wrote:

The buzzing (and slowness) in the 8088MPH mod player is almost certainly due to inaccuracies in the timing of your emulated CPU causing samples to be emitted at irregular intervals instead of exactly every 72 PIT cycles.

I second that, the mod player is definitely running considerably slower than on the real thing.
As a side-effect, the carrier wave is also much lower, and therefore more apparent. There also seems to be quite some fluctuation in the carrier wave frequency. Which probably indicates that the player does not just run more slowly as a whole, but the timing of individual instructions is probably off by some random factor, causing microscopic speedups and slowdowns in the player's inner loops.

I don't think the 8088 MPH mod player is a good target for developing a PC speaker emulation routine. A prerequisite for the 8088 MPH mod player to produce correct PWM data is that your emulator is cycle-exact.
Most other PWM routines, such as in Links, are timed with the PIT, and are therefore not directly dependent on the speed of each instruction in your emulator. This will at least make the PWM data fire at roughly the correct speed.

The thing with PWM data is that it is speed-dependent of course. Every value you write to the PIT is relative to the targeted sampling rate. If you play these samples too slowly, the resulting amplitude will be too low. Play them too quickly, and you get the problem that you are trying to update the PIT counter before it even reached 0. What happens then, depends on how your emulator handles this. On real hardware, the new value will not get active until the counter has reached 0, so it gets shifted in time. You get a bad case of the jitters.

Yup. Don't try to prove that your PIT is working properly while also trying to filter the output to approximate something real from a speaker.

Well, the strange thing is in the recording of the raw 1.19MHz wave: my sound editor refuses to open it(other recordings at 44.1kHz load without problems), so I can't even verify that(despite 10 minutes of recording taking up over 1GB of uncompressed 16-bit sound data, at 2.38 MB/s.). Maybe the rate is too high? I'm using WavePad(free/demo) to view it(the limit's apparently 196kHz).

superfury wrote:

Well, the strange thing is in the recording of the raw 1.19MHz wave: my sound editor refuses to open it(other recordings at 44.1kHz load without problems), so I can't even verify that(despite 10 minutes of recording taking up over 1GB of uncompressed 16-bit sound data, at 2.38 MB/s.). Maybe the rate is too high? I'm using WavePad(free/demo) to view it(the limit's apparently 196kHz).

Audacity might go higher than that but not up to 1.2 MHz sampling rate.
But you can always convert 119318 Hz wave to 4410 Hz wave as the ratio is almost same. It is an approximation and there might be better ratios.

superfury wrote:

Well, the strange thing is in the recording of the raw 1.19MHz wave: my sound editor refuses to open it(other recordings at 44.1kHz load without problems), so I can't even verify that(despite 10 minutes of recording taking up over 1GB of uncompressed 16-bit sound data, at 2.38 MB/s.). Maybe the rate is too high? I'm using WavePad(free/demo) to view it(the limit's apparently 196kHz).

The 1.19MHz WAV is binary, right? Should be straightforward to whip up a converter for adding all non-zero bits in the sample window.

It's a plain wav file with a mono 16-bit uncompressed stream at 1.19MHz(rounded down to integer Hz). It has the 0s translated to -32768 and 1s translated to 32767. Otherwise, it just adds the required RIFF, Header and Data sections, nothing more(See wave.c).

And about the 8088MPH loop's timing: only one thing has changed recently: the IN/OUT timing is now more accurate(4 vs 8 cycles, depending on chip and byte/word accesses, see my post at vladstamate's thread). Otherwise, it follows the 8086/8088 user manual 100%(Except MUL, which is more accurate).

Jepael wrote:

Audacity might go higher than that but not up to 1.2 MHz sampling rate.

I know Cool Edit Pro can do a 1.193MHz sample rate, so Adobe Audition almost certainly can too. It might be necessary to load raw PCM samples rather than a .wav file.

Failing that, superfury could just put together a really simple command-line resampling utility using SRC or similar.

superfury wrote:

And about the 8088MPH loop's timing: only one thing has changed recently: the IN/OUT timing is now more accurate(4 vs 8 cycles, depending on chip and byte/word accesses, see my post at vladstamate's thread). Otherwise, it follows the 8086/8088 user manual 100%(Except MUL, which is more accurate).

So how many cycles does the mod player take per sample at the moment on your emulator?

Btw, the 5160 motherboard (and probably the 5150 too) inserts a cycle of wait state for any port access, so an IN or OUT instruction takes 5 cycles (10 for a word) as well as the 4 or 8 cycles to fetch the instruction itself. Though it sounds like you have a much greater error than 1 cycle in 288 at the moment.

reenigne wrote:

Though it sounds like you have a much greater error than 1 cycle in 288 at the moment.

You make a good point here... We *know* that the innerloop is 288 cycles (give or take 1 cycle every now and then, as we saw on the spectrum analysis).
There is exactly one out-instruction to port 0x42 in every loop.
So if superfury were to measure the number of emulated cycles between these out-instructions, he'd see exactly how far his emulation is off.
It could be a rough target for fine-tuning the emulation core. When you can get the loop to run at 288 cycles, it's accurate enough for the mod player/PWM data, even though it may not be cycle-exact for every individual instruction.

I'll add logging of the CPU cycles taken on instructions in the loop later. As I said, currently most timing(except the variable range unknown timings like (I)MUL/(I)DIV) are the timings from the 8086/8088 user manual(can't remember the exact name, user manual by Intel afaik). It contains a big multipage table at the end with the used timings and started with ModR/M timings afaik(with memory timings after each instruction's variants as far as I remember).

Edit: A quick search on Google later, I've seemed to find the used manual(or one if it's revisions): Intel 8086 Family User's Manual October 1979

https://edge.edx.org/c4x/BITSPilani/EEE231/as … s_Manual_1_.pdf

The innerloop doesn't use any muls or divs. It's mostly loads, stores and additions.

superfury wrote:

As I said, currently most timing(except the variable range unknown timings like (I)MUL/(I)DIV) are the timings from the 8086/8088 user manual(can't remember the exact name, user manual by Intel afaik). It contains a big multipage table at the end with the used timings and started with ModR/M timings afaik(with memory timings after each instruction's variants as far as I remember).

That's not the whole story, though, or there would be lots of cycle-exact 8088/8086 emulators. If I understand correctly, this table contains best-case timings - i.e. doesn't include the cycles that the EU spends waiting for the BIU. Though that suggests that your emulator should be faster than a real CPU rather than slower.

Well, those timings are not all UniPCemu uses: it also applies MMU Read/Write cycles, prefetch cycles, modr/m calculations etc. This combines into one big formula(addition). That is the timing spent on the current instruction. Finally, the value is copied, the memory cycles substracted to obtain 'busy'(non-bus) cycles. These are divided by 4 to obtain the amount of prefetch bytes to fetch from memory.

Furthermore, the renderer(CGA on VGA) keeps the CPU in semi-busy state(hardware-induced HLT) to apply CGA WaitState memory.

1 if ((CPU[activeCPU].cycles_OP|CPU[activeCPU].cycles_HWOP|CPU[activeCPU].cycles_Exception) && CPU_useCycles) //cycles entered by the instruction?
2			{
3				CPU[activeCPU].cycles = CPU[activeCPU].cycles_OP+CPU[activeCPU].cycles_HWOP+CPU[activeCPU].cycles_Prefix + CPU[activeCPU].cycles_Exception + CPU[activeCPU].cycles_Prefetch + CPU[activeCPU].cycles_MMUR + CPU[activeCPU].cycles_MMUW; //Use the cycles as specified by the instruction!
4			}
5			else //Automatic cycles placeholder?
6			{
7			#endif
8				CPU[activeCPU].cycles = (CPU_databussize>=1)?9:8; //Use 9 with 8088MPH CPU(8088 CPU), normal 8 with 8086.
9			#ifdef CPU_USECYCLES
10			

1 void CPU_fillPIQ() //Fill the PIQ until it's full!
2{
3	if (CPU[activeCPU].PIQ==0) return; //Not gotten a PIQ? Abort!
4	byte oldMMUCycles;
5	oldMMUCycles = CPU[activeCPU].cycles_MMUR; //Save the MMU cycles!
6	CPU[activeCPU].cycles_MMUR = 0; //Counting raw time spent retrieving memory!
7	writefifobuffer(CPU[activeCPU].PIQ, MMU_rb(CPU_SEGMENT_CS, CPU[activeCPU].registers->CS, CPU[activeCPU].PIQ_EIP++, 1)); //Add the next byte from memory into the buffer!
8	CPU[activeCPU].cycles_Prefetch += CPU[activeCPU].cycles_MMUR; //Apply the memory cycles to prefetching!
9	//Next data! Take 4 cycles on 8088, 2 on 8086 when loading words/4 on 8086 when loading a single byte.
10	CPU[activeCPU].cycles_MMUR = oldMMUCycles; //Restore the MMU cycles!
11}
12
13void CPU_tickPrefetch()
14{
15	if (!CPU[activeCPU].PIQ) return; //Disable invalid PIQ!
16	byte cycles;
17	cycles = CPU[activeCPU].cycles; //How many cycles have been spent on the instruction?
18	cycles -= CPU[activeCPU].cycles_MMUR; //Don't count memory access cycles!
19	cycles -= CPU[activeCPU].cycles_MMUW; //Don't count memory access cycles!
20	cycles -= CPU[activeCPU].cycles_Prefetch; //Don't count memory access cycles by prefetching required data!
21	//Now we have the amount of cycles we're idling.
22	if (EMULATED_CPU<CPU_80286) //Old CPU?
23	{
24		for (;(cycles >= 4) && fifobuffer_freesize(CPU[activeCPU].PIQ);) //Prefetch left to fill?
25		{
26			CPU_fillPIQ(); //Add a byte to the prefetch!
27			cycles -= 4; //This takes four cycles to transfer!
28		}
29	}
30	else //286+
31	{
32		for (;(cycles >= 3) && fifobuffer_freesize(CPU[activeCPU].PIQ);) //Prefetch left to fill?
33		{
34			CPU_fillPIQ(); //Add a byte to the prefetch!
35			cycles -= 3; //This takes four cycles to transfer!
36		}
37	}
38}

superfury wrote:

Well, those timings are not all UniPCemu uses: it also applies MMU Read/Write cycles, prefetch cycles, modr/m calculations etc. This combines into one big formula(addition).

I think this is wrong. The BIU cycles aren't added to the EU cycles - the EU and the BIU operate concurrently. Sometimes the EU has to wait for the BIU (when it the EU needs to do a bus access and the BIU is busy doing a prefetch) and sometimes the BIU has to wait for the EU (when the prefetch queue fills up during a long-running instruction, or when prefetch is suspending pending a jump). So that explains why your emulator is running slow.

Then we reach the next problem: is it possible to apply the BIU/EU split while keeping the current jumptable-based emulation? Currently each step counts timings(prefetch adding to cycles_Prefetch, memory accesses adding to MMUR/W(same with I/O), misc adding to the other timings(HW for hardware interrupts). The BIU(Prefetching, memory/io(MMUR/W) is already added like a wait state of 4/8 cycles) currently substracts(ignores) timings made Then that remaining BIU timing(timing not spend on bus transactions) is spent on filling the prefetch queue(4 cycles per prefetch, like byte memory accesses). Thus BIU fetches to/from memory are counted serially, while prefetching for next instructions are done in parallel(in the calculated remaining time not using the BIU).

So if an CPU instruction of 16(.cycles) cycles spends 4 cycles on memory transactions(reading opcodes, memory i/o, i/o ports), 12(.cycles) cycles are then spent to fetch 3 bytes into the prefetch queue. Thus this does happen in parallel. Although memory/bus accesses stall the CPU(.cycles), the CPU will have to wait for the transaction to complete, thus it's correct to count those non-prefetch bus cycles as EU cycles?

superfury wrote:

Then we reach the next problem: is it possible to apply the BIU/EU split while keeping the current jumptable-based emulation?

No, not really. I tried hard to achieve that. Since I already had a working emulator I hoped I can reuse as much as possible when I started to write my cycle based emulator. But once I did the BIU/EU split there as no way I could keep a jump-table because an instruction execution had to be broken in parts. Somehow I had to find a way to return early from an instruction execution if for example either the prefetch buffer was empty or I had to issue some memory reads. I could not do that cleanly. So in the end I had to rewrite all the instruction emulation from scratch with the idea of doing at the cycle base and not at instruction execution base.

For example a simple instruction like MOV AX, [DI+4] has to issue 3 reads from prefetch (a byte at a time) and 2 bytes from memory (also a byte at a time for an 8088). Only when those reads are done can we execute the instruction, however some part of it is executed in the beginning, like the decoding, decoding the RM, EA calculation, and in the middle to request the memory reads once the EA has done its calculation etc.

Not only that but that instruction (and any other) can take variable number of cycles depending on the preceding instruction. Why? Because what is in the prefetch buffer is different (could be nothing or it could be full) depending on what happened before. So any instruction can really have a variable number of cycles.

Take a look at my emulator to see what I am doing.