Dave <[EMAIL PROTECTED]> wrote: >> Downgrading for the SAM is complicated, because it has 7-bit colour. 2 >> bits for each of RGB, and the Spectrum handed down its 'half-brightness' >> bit. > >I knew there was a reason I shouldnt go down this road! >[rr][gg][bb][x] is the layout?
All the right bits, but not in the right order... 76543210 -GRBxgrb where r,g,b are one bit of each colour; R,G,B are two bits of each colour, and x is half a bit of all three colours. [...] >shortcut? It isnt so noticeable on the sprite engine I have already. If I >limit the projection size to 64x64 it speeds up disproportionatly to the >performance figures projected by the 94x94 and 128x128 figures. If this is >the case it would be easier to create a Space Hulk type game because it >would run at the same speed as a 3d game in 128x128 even if we projected 4 >live action views. Is this because of the way SAM >handles screen memory? Not such as I'd expect the results you describe. (Silly question: you're not waiting for VBL between drawing frames are you? If one routine takes slightly more than 1/50 of a second, where the others are taking slightly less than 1/50th s, then it will appear to be running at half the speed. But you'd probably thought of that.) Memory accesses to all parts of Sam's memory[1], screen or not, run at the same speed - viz. not as fast as you expect. Every access is rounded up to the next multiple of 4 tstates, unless the display raster is somewhere within the screen memory in which case all accesses are rounded up to the next multiple of 8 tstates. Broadly the effect of all this is that you can define a pseudo clock cycle which is worth 4 tstates out of screen memory and 8 tstates in screen memory, and define all the instruction times in terms of that. Most instructions will then execute in an invariant number of pseudoclocks, even though the number of tstates they take actually varies. However just to confuse matters there are a few instructions which take longer than 1 pseudoclock but don't require the processor to access memory after the fetch, and so they don't get delayed as much by the 8 tstate rounding on screen. INC HL is an example of this; it always always takes 8 states to execute, which means it appears to "gain" a pseudoclock when the raster is in screen memory. [1] except the ROM and external expansion memory. >> >7) Finally, is there a decent GUI project for the SAM? >> >> Ages ago Steve Taylor wrote a MODE 3 one, but it never caught on cos it > >> cost too much and was fiddly to convert existing software. And it's word >> processor was apparantly too slow for real typists. [...] >> You might try hacking >> SAMmines by Mnemotech/Andrew Collier, and I like the GI_monitor one, though >> you can't redefine windows' size and position! > >I looked at this on your suggestion and I have to agree. Heck, don't bother hacking it - I'll give you the source! Give me a few days to sort something out and I'll upload it to my webpage. Not sure how useful it'll be though, most of that was written *many* years ago, and it probably isn't very well structured or flexible. These days I'd do things a lot differently now that I have some idea how windowing systems actually work... Andrew -- --- Andrew Collier ---- ---- http://mnemotech.ucam.org/ --- -- r<2+ T<4* cSEL dMS hEn/CB<BL A4 S+*<++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4
