copied from my table:
Screen5Regs:
db 6 ; Set screen 5 plus disable horizontal retrace int.
db 2 + 32 ; Disable screen (!64), vblank int (!32), 16x16 sprites unmagnified (2)
db $1F ; Select page 0
db $80 ; Reg 3 unused in Sc5-8
db 0 ; Reg 4 unused in Sc5-8
db $ef ; Reg 5 low bits sprite attr table
db $0f ; Reg 6 low bits sprite pattern table
db 0 ; black background (col=0)
db 8 ; reg 8 (64k VRAM mode)
db $80 ; reg 9 NTSC + 212 lines
db 0 ; colour table hi bits (>16kb)
db 0 ; sprite attr table hi bits (>32kb)

Ok, it works!
The problem was, that I set register 2 to #00 instead of #1f. I thought the bit 0-4 are not used in screen 6, but if I didn't set them to 1, the VDP repeated the screen data every 40*24 bytes.
Thanx a lot for your help! Now I can start with some tests (but not today...).
Have a nice evening!

Hm, I couldn't stop. Logical Copy made it to about 2500 4x8 blocks (this is the average size of a char in SymbOS) in one second (I hope I didn't make a mistake). This is about 1,7 times faster than on the CPC! I hope the final routine won't be much slower, but as the Z80 and the VDP can work parallel I don't see a big problem here.

Hehe. When you're on a roll, it's hard to stop.

That's about 40k/s. Sounds about right. The parallel processing should be helpful indeed. Even with those small copies you can set up the next character while the vdp copies one.

Well, you are looking proportional chr painting routine surely thinking in that is a way to set a sort of FONT SIZE, and to allow to the GUI to use several sizes of fonts.

Is a lot of problems with that, but most of all is the speed!

and the ALIASSING problems that comes from working with low resolution screen modes. Looking ugly in anything that isn't just scale 1x1.


Because that is better to set several fonts with several sizes on HD and loading it on demand. That is just a adm. system to do... and not doing nasty scale conversions.

And for anything like truetype is ALLWAYS good to work on RAM... because the same routine works in every hardware.... just cpu-ram interaction

what i means... to work in ram in a pattern buffer allwos you to draw a real true type format. Including to apply a sort of anti-aliassing is easy in that way. (note: the anti-aliassing slows the thing 6 times) using an algorith like unfocusing-selectively

Prodatron, check your mail...

Another question: When I read the information about the sprite attributes, it seems, that the X-pos of a sprite can't be >255, as it is stored in only one byte. Does it mean, that in screen 6 (512x212) sprites can only be placed in the left half of the screen?

If I'm not wrong in this modes the horizontal sprite resolution is two pixels.

Indeed, in 512-wide modes, sprites can only be on even X-coordinates.

yes, the sprite's screen is always 256width.

Ah, ok, so the sprites will also stay with a ratio of 1:1? Meaning, that a pixel pixel is like 2 screen pixels?
Hope that it will be ok for a mouse pointer in mode 6.

yes, it is correct

in screen 5 / 8 is 1:1 ratio

in screen 6 / 7 is 2:1 ratio

Quote:

Hm, I couldn't stop. Logical Copy made it to about 2500 4x8 blocks (this is the average size of a char in SymbOS) in one second (I hope I didn't make a mistake). This is about 1,7 times faster than on the CPC! I hope the final routine won't be much slower, but as the Z80 and the VDP can work parallel I don't see a big problem here.

A fast copy of 8x8 consume about 702 z80 cycles, so you can do a lot of things while you are waiting vdp command ending. Unique problem for real pararell process is non end of command feature in v9938. I was thinking in this trouble long time ago, and unique solution allowing this can be using line interrupt to generate interrupts to measure time waste in the 8x8 copy. I know that is a nasty solution, but this workaround could save a lot of time and free z80 to realize other tasks.

Again a quick question:
Currently I am loading and executing the binary with a basic program (autoexec.bas). The binary would be limited to less than 32K I think.
Someone already wrote in another thread, that I can move the basic memory to #c000 and do bankswitching for page 2 (#8000-#bfff). In this case I could load several 16K binaries in the extended memory before executing the code.
So how can I move the basic memory to #c000 (while the basic program is running)?