Ah crap!CunningFellow wrote:OH - bugger
We have both been forgetting something in out recent code.
Tile rows >1 are not the same as tile row 0
We need to add something to ZH to get them.
We are ONE clock down again.
80x28 1bpp tile mode possible?(For terminal emulator)
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
Uze,
Well with the extra clock gained from the "not MUL 16" we are back to "attribute pixel off by one" but have it working at least.
The sparse attribute thing can still work in 3 or 4 clocks. It could make the foreground colour any of 256, but not touch the background colour.
It will also be computationally expensive to change attributes.
Well with the extra clock gained from the "not MUL 16" we are back to "attribute pixel off by one" but have it working at least.
The sparse attribute thing can still work in 3 or 4 clocks. It could make the foreground colour any of 256, but not touch the background colour.
It will also be computationally expensive to change attributes.
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
How does the space attribute thing works?
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
Just trying to look at it now.
You have an MSB or LSB set in the VRAM.
If the bit is set, then it pulls the next attribute value from a 255 byte heap of attributes. You can only have 254 attribute changes per screen.
When you are setting an attribute bit - it is expensive. You have traverse the screen and list and move/shuffle to add them in the middle. However ALL simple forms of compression are expensive to add things in the middle really.
So for our 4 free clocks we have
BRCS +.2 ; Skip the DEC if the attribute bit is set
DEC XL ; undo the X+ fro the previous read if the attribute has not changed
LD Rx, X+ ; read the current attribute byte into the colour register and inc X
xxxxx
It will also have the off-by-one-pixel-colour problem for the last pixel.
You have an MSB or LSB set in the VRAM.
If the bit is set, then it pulls the next attribute value from a 255 byte heap of attributes. You can only have 254 attribute changes per screen.
When you are setting an attribute bit - it is expensive. You have traverse the screen and list and move/shuffle to add them in the middle. However ALL simple forms of compression are expensive to add things in the middle really.
So for our 4 free clocks we have
BRCS +.2 ; Skip the DEC if the attribute bit is set
DEC XL ; undo the X+ fro the previous read if the attribute has not changed
LD Rx, X+ ; read the current attribute byte into the colour register and inc X
xxxxx
It will also have the off-by-one-pixel-colour problem for the last pixel.
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
The reason for doing it the above way
Read the RAM every time and undo the increment on X is because you can't skip the LD as a 2 clock instruction without upsetting timing.
but you CAN do a DEC in one clock and skip it.
It just means the list of sparse attribute changes HAS to start at 256 byte boundary AND it can only be 255 long so XL does not wrap and change XH
Read the RAM every time and undo the increment on X is because you can't skip the LD as a 2 clock instruction without upsetting timing.
but you CAN do a DEC in one clock and skip it.
It just means the list of sparse attribute changes HAS to start at 256 byte boundary AND it can only be 255 long so XL does not wrap and change XH
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
well - actually - you could make it MORE than 255 attribute changes per screen AND speed up the search through the compressed data.
You could break the screen into sections and have up to 255 attribute changes per section.
If you just did it the simplest way you could have up to a maximum of 36 attribute changes PER line with a 1K attribute heap. You just have to break up the lines to make sure that you don't hit a 256 byte boundary mid line.
It's going to be some convoluted code to make sure it all works OK. But that is hard stuff for us to do in the background. User code never needs to see how tricky it is.
You could break the screen into sections and have up to 255 attribute changes per section.
If you just did it the simplest way you could have up to a maximum of 36 attribute changes PER line with a 1K attribute heap. You just have to break up the lines to make sure that you don't hit a 256 byte boundary mid line.
It's going to be some convoluted code to make sure it all works OK. But that is hard stuff for us to do in the background. User code never needs to see how tricky it is.
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
Ah ok, I get the idea. A limited amount of attributes changes globally. So If I understand you code, if I only want to set the attribute color for vram[10]="attrib color", I still need to set vram[11] =global color? We need to bytes for each color change? Wow, it going to get complex fast. And I worry about the cost in term CPU, just doing a full traversal of vram will take several scanlines. But again there's not much other practical way to do attributes it seems. And attributes should not be used that much anyway. Lee, how do you see this?
Btw, CunningFellow, can you post the latest spreadsheet with the inner loop? I'm wondering where you get the carry from for the
The mul?
Btw, CunningFellow, can you post the latest spreadsheet with the inner loop? I'm wondering where you get the carry from for the
Code: Select all
BRCS +.2 ; Skip the DEC if the attribute bit is set
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
Perhaps it's a brain fart since it seems too good to be true, can you find the flaw in the following? I realized that there can be up to 16 ins the main loop. That's 16*2*8 bytes tile. Yeah 256 bytes. With a codetile table set at zero:
Code: Select all
ZL=tile row
--main loop--
out portc, r18
ld ZH,X+
out portc, r19
nop
nop
out portc, r18
nop
nop
out portc, r19
nop
nop
out portc, r18
nop
nop
out portc, r19
ijmp
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
The scanline does not care how the attributes are layed out. AS LONG as it does not cross a 256 byte boundary in the middle of the scan line. The preamble juts sets where to start at the beginning of the scan line and the pixel out code runs with it.uze6666 wrote:<SNIP> I worry about the cost in term CPU, just doing a full traversal of vram will take several scanlines. But again there's not much other practical way to do attributes it seems. And attributes should not be used that much anyway.
This means you could break up your 1024 bytes of attribute HEAP into 28 smaller 36 byte hunks. Each scanline could have UP TO 36 attribute changes. Then when you needed to change an attribute you would at max need to traverse 80 bytes of VRAM and move 36 bytes of attribute heap.
Uze. Only problem with only load ZH thing is that the code tiles will be scattered all over FLASH and will collide with the BOOT_LOADER I think. EDIT: No we only have 128 tiles - so the bootloader is safe.
Edit again: No I think it will collide. the PC is 16 bit indexed so the top of 64K is 0x7FFF
Last edited by CunningFellow on Sun Feb 08, 2015 9:23 pm, edited 1 time in total.
Re: 80x28 1bpp tile mode possible?(For terminal emulator)
Awesome! Now what to do with...8 free cycles!?!Uze. Only problem with only load ZH thing is that the code tiles will be scattered all over FLASH and will collide with the BOOT_LOADER I think. EDIT: No we only have 128 tiles - so the bootloader is safe.