Do you know if we're allowed to require BIOS calls to change between text and graphics modes, or do we have to expect the hardware to always work right when you bang on it directly? The reason I ask is that if we can rely on the BIOS, we don't have to try to squeeze all conversion programs into the one memory block; we can have the BIOS load a different program for each mode.
On 5/30/05, Patrick McNamara <[EMAIL PROTECTED]> wrote: > So after more discussion with Timothy, I have done some more work on the > program to convert a text screen for the card. > > Here are the bounds I was working in for this program: > > Load/Store architecture > Each non memory access takes 5 100MHz clocks What do you mean by "non memory access"? Are you talking about the fetch-decode-load-compute-store cycle of instruction execution? BTW, since the memory is dual-ported, we can do some overlap. Most instructions have two source registers, and those can be loaded together. Insert an additional cycle if either register is indirect. Compute isn't something we can do anything to optimize. The store cycle, however, can be done at the same time as the next instruction fetch. So, here's what we have. - Register Store + Instruction Fetch - Register Load + Register Load - Indirect register load + indirect register load (optional) - Compute - Register load for indirect register store (optional) That means that typical arithmetic instructions will take 3 to 5 cycles. Branch instructions would also take 3 to 5. The memory access instructions will take unpredictable lengths of time if output fifos fill or input fifos are empty, but they too will take 3 to 5. > Existence of a load block that take 20 + n clocks where n is the number > of 32bit words. Would we really be better off with this than split request and load instructions? Keep in mind that both register file ports are occupied by the processor, meaning that we can't "background" load them. For reads, it means we can't insert useful stuff between the requests and the fetches. Now, for writes, it would definitely help, because you can do N writes in 5+N cycles, which is nice. If we want to be really clever, we could do N writes in 5+ceil(N/2) cycles, but I don't want to push our luck with the complexity. If we can keep requests down to 2 cycles, then we'd be able to do 10 requests in that 20-clock period. We might also be able to keep the load instruction down to 2 cycles. Of course, loop instruction overhead makes a lot of difference too. We should probably combine the compare and branch instructions into one. > Existence of a store block that takes 5 + n clocks where n is the number > of 32bit words. > Indirect register access > No load immediate instruction > > Given those parameters, here is what I got: > > 136 instructions > 73 registers - this includes some "constant" registers needed due to the > missing load immediate and scratch space used for the character blit > ---------- > 209 words - still under half the available space > > Now for the performance: > > I unrolled part of the blit loop since it is by far the most executed > section. The end result is 13.1Hz screen update for 80x50 and 13.8Hz > screen update for 80x25. The lack in refresh increase between 50 line > and 25 line is due to the fact that 25 line text uses and 8x16 font > where 80x50 uses 8x8 so the blit code does almost the same amount of work. > > Without a block store instruction, and assuming that writes are buffered > and only take 5 clocks, then screen updates drop to around 11.8Hz for > 80x50. I haven't finished the analysis of removing the block read > instruction, but I think the effect is negligible though slower. > > Patrick M > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
