|  Post Your Message | |
| |
| | Previous Messages | Posted By
IstvanV
on 2011-05-07
17:46:04
|  Re: Bitmap colors'reversed nibbles
With the default vertical scroll, the DMA lines are 3, 4, 11, 12, 19, 20, and so on. Line 4 is the first raster line of the first character.
Here is a simplified description of how the DMA logic works:
- if the lower 3 bits of $FF06 and (latched) $FF1D are equal anywhere between a few characters before the beginning of the horizontal window for fetching video data, and the end of it, then the first (luminance) DMA will occur in the current line (it may be started mid-line, in that case not all characters will be updated, and the first 3 bytes read will be "garbage" from the data bus). The new attributes will only have a visible effect in the next line
- if the same $FF06 / $FF1D equality happens just before the end of a line, then the second (color) DMA will be done in the next line
- it is possible to enable both DMAs at the same line. In this case, attribute data is read from the "luminance" memory, and is stored/interpreted as both types of data
|
|
Posted By
Luca
on 2011-05-07
17:11:28
 | Re: Bitmap colors'reversed nibbles
Does it mean that the very first DMA cycles occur in line 02 and 03, next are 10 and 11, next are 18 and 19 and so on?
|
|
Posted By
IstvanV
on 2011-05-07
06:28:39
| Re: Bitmap colors'reversed nibbles
It is not necessary to read the memory 4 times for the two colors. The TED reads both (luminance and color) bytes only once, and then buffers them internally for the whole row of characters. Basically, for reading video data, these are the memory operations that occur (there can be only two per character in a single line, and to have two, DMA/halting the CPU is needed):
- bitmap bytes are read in every line from 0 to 203
- luminance (or color in character modes) is read in the last raster line of the previous character (first DMA)
- color (character code in character modes) is read in the first line of a character (second DMA)
I assumed the 1551 is slow simply because of slow ROM code - especially in the drive, as making the Plus/4 CPU 10 times faster does not seem to accelerate the loading, while it does for IEC level emulation - but there might be some other reason as well. With disk turbos, it can be much faster.
|
|
Posted By
MMS
on 2011-05-07
06:00:28
 | Re: Bitmap colors'reversed nibbles
off:
Well, Istvan you know the +4 much better than me, but let me add two comments:
1) c64 can use 3 different colors per char. +4 has two dma, and the cpu is faster. So... (ok i understand that luminance has to be read separately too, but thats why they not store all the comlete color1 at one place, the second color at a second place). The machine has to read the memory 4 times for two colors, while with the above only two times. So even 4 independent color theoretically possible in same bandwidth.
2) standardization in an arhitecture is a key for easy programming. When they made the black color to be handled differently, they generated a "special case", though they could add 7 more dark greys, and made shade of white more "whitish".
3) oh,that bloody flash bit... It caused so many limitation here and there,just to save 2kb Rom on inverz charset.
4) as i know, the 1541 shift register hw bug caused this operation done by sw, told to made data transfer ~4x slower on the same serial bus. Then a question:if it is right, why 1551 is only 5x faster,despite paralell interface? An other hidden bug maybe? 
|
|
Posted By
Gaia
on 2011-05-07
02:02:23
| Re: Bitmap colors'reversed nibbles
The slow 1541 speed IS a bug: the original intention was to utilize one of the shift registers in one the VIA chips of the drive to read one byte at once from the disk's surface. It was discovered by C= engineers in literally the very last moment, so they had to rewrite the entire transfer protocol using SW bitbanging.
See:
http://www.softwolves.com/arkiv/cbm-hackers/11/11260.html
|
|
Posted By
Degauss
on 2011-05-06
17:55:33
| Re: Bitmap colors'reversed nibbles
I don't really know, but i bet theres two reasons for the flipped nybbles. In first place, i'm sure they wanted to have luminance and color seperated from each other. When you want to do that in hardware, i guess it was easier to employ that criss-cross-scheme: You would only have to OR the nybbles, no (probably more "expensive") shifting would be required...
|
|
Posted By
Luca
on 2011-05-05
17:52:53
| Re: Bitmap colors'reversed nibbles
Yeah but: why invert the nibbles of fixed colours between luminance and color?
|
|
Posted By
IstvanV
on 2011-05-05
17:28:07
| Re: Bitmap colors'reversed nibbles
The slower speed of 1541 on C64/Plus/4 is not really a bug, it is more of a result of limitations of the CBM serial bus protocol and the C64 hardware. To read the character codes and attributes from memory, the VIC-II needs to halt the CPU for 43 cycles at the first raster line of each row of characters. With the original, faster mode of the 1541, the kernal would not be able to read the data sent by the drive reliably, due to the slowdown resulting from the CPU being halted by the VIC-II. On the Plus/4, there are actually two DMA lines per character, since there is no separate color RAM which could be read by the video chip at the same time as the main memory, using a wider data bus. However, if you blank the screen during disk I/O, the slightly faster "VIC-20" mode of the drive will also work on the Plus/4.
The 8 shades of black is probably just a result of trying to keep the video hardware simple, i.e. 3 bits for luminance and 4 bits for color, rather than interpreting the redundant black colors in a special way.
There are two "fixed" colors in multicolor bitmap mode because the limited memory bandwidth (2 bytes per character line) of the machine does not allow for more separate colors per character than what is already available in hires mode. It could have been solved e.g. by having four DMA lines per character, but that would have made the TED too complex, in addition to more CPU slowdown.
There is one graphics limitation, however, that I think could have been avoided easily: in multicolor text mode, it would have been a better idea to use the flash (7) bit for selecting the use of high resolution or multicolor per character, since the flashing does not work in multicolor anyway. With the use of bit 3 (which made sense on the C64, where the color RAM is 4 bits wide only), half of the palette is lost.
Of course, since the flashing is not very useful, it might have been even better to have more colors instead of it, for example one bit to select low/high saturation.
|
|
Posted By
MMS
on 2011-05-05
14:53:01
| Re: Bitmap colors'reversed nibbles
Haha, really strange!
In fact it is exactly described in the Plus/4 Programmers Reference Guide on P.223
It is visible I have never programmed 320x200 gfx in assembly
Reason: initial design/concept mistake, not corrected afterwards.
(similar to C64 + 1541 speed issue due to HW bug, 80% speed decrease, we see normal now)
-Why we have only one shade for black, and not 8, like the other colors?
-Why we have two fixed colors in multicolor for the whole screen?
-Why only 2 sound channels not eg. 3 or 4? (could make C64 music transfer much easier).
2 independent volume registers with 4-4 bits for each channel would be a dream for any tracker
Few concept failures. nothing fatal, just little annoying, seeing the lost chances.
The fixed +4 programs built into BOM and too high starting price became fatal.
(And the missing numeric keyboard, made impossible to sell +4 as a professional computer.)
|
|
Posted By
Luca
on 2011-05-04
07:58:51
| Bitmap colors'reversed nibbles
After a quarter of century, only now I realized that color and luminance values in bitmaps are nibble-reversed each other: let's have #$12 in the area $1C00-$1FE7; hence, filling the area $1800-$1BE7 with, i.e., #$07, we'll assign luminance 0 to color 2 and luminance 7 to color 1! :o
Why this? Is there a reason for that?
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
