On Sat, Oct 4, 2008 at 1:47 PM, Mark Marshall <[EMAIL PROTECTED]> wrote: > Thanks for the comments. > > Timothy Normand Miller wrote: >> >> Readdressing the little-endian thing, were you saying that the way >> glyph bits are stored in the VGA font is big-endian? If so, then that >> was my mistake. > > Yes, from my reading of several different books on the VGA, the fonts are > stored with the MSB of each octet as the left most pixel. I change my mind > every day about whether this is the right way around or not, but that is > only a philosophical issue now. > >> >> Read on... > >>> ; HERE! >>> > let G_VID_SCREEN_WIDTH = 0x100 >>> > let G_VID_GLYPH_HEIGHT_M1 = 0x101 >> >> Are these addresses in scratch memory? > > Yes, it was my intention that these would be in scratch memory. I'm not > sure how we're going to allocate things there yet. They could also be > passed in registers, but I can see no advantage in that.
This is an extremely embedded application. The ONLY reason to generalize anything at all is for our sake as developers. Hard code as much as you want. > >>> >>> move ((123000000)/65536)+1, r6 >>> shiftu r6, 16, r6 >>> add r6, -11072, r6 ; ((123000000)%65536) >> >> We're going to have to get help from Petter about how to do this >> properly. Also, what is the meaning of the 123000000 that you're >> trying to store in r6? > > Petter's a new feature to make this easier, thanks Petter. I'm loading a > large number with zeros on the left into the pixel address so that in the > simulator I can see easily that I am incrementing the pixel address by the > amount I thought I should be. This 'frame' is only for testing. Makes sense. >> >>> move 0x12, r7 >>> move 0x34, r8 >>> noop >>> jump draw_glyph, r9 >>> noop >>> noop >>> jump 510 >> >> What code is going to be fixed at 510? > > In the simulator, jumping to address 510 stops the simulation. I didn't know that. :) >> >>> ; >>> ; R2 is the mask that we will use below, we might as well >>> ; load that up now in the delay slot after the memory read. >> >> q2? > > One of the biggest crimes in software is when the comments get out of step > with the code. I'm sorry, I'll try to not let it happen again. ;-). Somehow, I don't think you're going to get any flak for this. :) >> >> Very sweet! > > Thanks, I really enjoy this sort of coding, and there's very little need > for it any more. At work, I'm quite against anyone ever checking in any > assembler, it can be very hard for the non-author to debug. I like working at this end of computer technology. There will always be need for this, but it's very niche. At the same time, it's extremely fundamental, which makes it all the more interesting. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
