wraggster
November 20th, 2011, 23:40
via http://dsx86.patrickaalto.com/DSblog.html
Sverx has again been working on improving the screen scaling algorithms for DSx86. This time he figured out a smart new way to take advantage of the NDS hardware scaling and blending features in the Jitter mode. The new and improved Jitter mode in this version is just as fast as the plain Scale mode (as it is handled completely in hardware), but it also produces a result that is very close to the software-based Smooth scaling algorithm (in all the low-resolution modes)! Big thanks again to Sverx for his ingenious new scaling method!
DS2x86 progress
I have not made huge progress with DS2x86 during the past week, as I have been busy with some work-related things, including a business trip. I have however managed to get the text mode screen handling moved from the MIPS side to the ARM side. The strange palette problem I mentioned in the previous blog post was actually not related to palette handling, instead, I found an interesting feature in the FPGA code that the original DSTwo graphics transfer code uses. When sending the video data (with command 0xC1), the MIPS side code in the cmd_line_interrupt() routine in game.c module has the following code:
case 0xc1://VIDEO 512*n
isc1cmd = cmd_buf[7] & (( 1 << enable_fix_video_bit) | ( 1 << enable_fix_video_rgb_bit));
case 0xc2://AUDIO 512*n
//*(fpgaport*)write_addr_cmp_addr = (0x400-0x380) ;
SET_ADDR_GROUP(GPIO_ADDR_GROUP1);
*(fpgaport*)(cpld_base_addr + cpld_base_step) = (0x400-0x380) ; //(0x400-0x300) ;
SET_ADDR_DEFT();
*(fpgaport*)cpld_ctr_addr = (1<<fpga_mode_bit) | (1<<fifo_clear_bit) | isc1cmd;
*(fpgaport*)cpld_ctr_addr = (1<<fpga_mode_bit) | isc1cmd;
In the routine MP4_init_module() at the end of the same source file, where the transfer buffers and commands are prepared, is the following code:
buf_st_temp.nds_cmd=(((1 <<enable_fix_video_bit ) |(1 <<enable_fix_video_rgb_bit ))<<24) | (buf_video_up_0<<16) | (VIDEO_UP <<8) | 0xc1;
buf_st_temp.type= 0;
pmain_buf->buf_st_list[buf_video_up_0] = buf_st_temp;
The transfer system on the NDS side sends the highest byte of the nds_cmd field of the buffer struct as the cmd_buf[7] content when requesting the video data, and thus the command 0xC1 always has those enable_fix_video_bit and enable_fix_video_rgb_bit bits set. My understanding is that when those bits are set, the FPGA code always turns on the highest bit of every 16-bit halfword in the transfer buffer (while sending it via FIFO to the NDS side). This creates 16-bit ARGB values with the alpha bit set on-the-fly for the 16-bit color values that the DSTwo SDK normally uses. But, when sending graphics data in some other format, you need to NOT set those bits on! In my case when sending the text mode data (which on the x86 is formatted as an 8-bit character followed by an 8-bit attribute byte), the attribute byte always had the highest bit set, which caused the background color to use the light colors. This caused the DOS background to be gray when it should have been black, so I first thought I had a problem with the palette. As I don't plan to send any 16-bit color values in DS2x86, I simply commented out those two bits, thus forcing the MIPS side to always send the graphics data as-is.
Currently I am working on the CGA graphics mode data transfer. This is rather similar to the text mode (on the MIPS side), it can simply send 32KB from the emulated x86 segment address 0xB800. The NDS side just needs to handle the received data differently. After I get this working, the next mode will be the MCGA graphics mode. In that mode I need to send 64KB from the x86 segment address 0xA000, plus additional 512 bytes (or 768 bytes if I move the 24-bit palette -> 16-bit palette conversion to the NDS side) for the palette.
The remaining graphics modes (EGA and Mode-X modes) are somewhat more difficult, as sending the whole graphics memory area would be 256KB, which is more data than I want (or probably even can) send per frame. I think I need to limit the data to be sent to 256x192 (or 320x200) bytes, but as that won't be enough for the high-resolution modes like 640x480 16-color VGA mode, I still need to figure out a smarter way to handle this. Only after these changes I can then start working on the audio stuff.
http://dsx86.patrickaalto.com/DSdown.html
Sverx has again been working on improving the screen scaling algorithms for DSx86. This time he figured out a smart new way to take advantage of the NDS hardware scaling and blending features in the Jitter mode. The new and improved Jitter mode in this version is just as fast as the plain Scale mode (as it is handled completely in hardware), but it also produces a result that is very close to the software-based Smooth scaling algorithm (in all the low-resolution modes)! Big thanks again to Sverx for his ingenious new scaling method!
DS2x86 progress
I have not made huge progress with DS2x86 during the past week, as I have been busy with some work-related things, including a business trip. I have however managed to get the text mode screen handling moved from the MIPS side to the ARM side. The strange palette problem I mentioned in the previous blog post was actually not related to palette handling, instead, I found an interesting feature in the FPGA code that the original DSTwo graphics transfer code uses. When sending the video data (with command 0xC1), the MIPS side code in the cmd_line_interrupt() routine in game.c module has the following code:
case 0xc1://VIDEO 512*n
isc1cmd = cmd_buf[7] & (( 1 << enable_fix_video_bit) | ( 1 << enable_fix_video_rgb_bit));
case 0xc2://AUDIO 512*n
//*(fpgaport*)write_addr_cmp_addr = (0x400-0x380) ;
SET_ADDR_GROUP(GPIO_ADDR_GROUP1);
*(fpgaport*)(cpld_base_addr + cpld_base_step) = (0x400-0x380) ; //(0x400-0x300) ;
SET_ADDR_DEFT();
*(fpgaport*)cpld_ctr_addr = (1<<fpga_mode_bit) | (1<<fifo_clear_bit) | isc1cmd;
*(fpgaport*)cpld_ctr_addr = (1<<fpga_mode_bit) | isc1cmd;
In the routine MP4_init_module() at the end of the same source file, where the transfer buffers and commands are prepared, is the following code:
buf_st_temp.nds_cmd=(((1 <<enable_fix_video_bit ) |(1 <<enable_fix_video_rgb_bit ))<<24) | (buf_video_up_0<<16) | (VIDEO_UP <<8) | 0xc1;
buf_st_temp.type= 0;
pmain_buf->buf_st_list[buf_video_up_0] = buf_st_temp;
The transfer system on the NDS side sends the highest byte of the nds_cmd field of the buffer struct as the cmd_buf[7] content when requesting the video data, and thus the command 0xC1 always has those enable_fix_video_bit and enable_fix_video_rgb_bit bits set. My understanding is that when those bits are set, the FPGA code always turns on the highest bit of every 16-bit halfword in the transfer buffer (while sending it via FIFO to the NDS side). This creates 16-bit ARGB values with the alpha bit set on-the-fly for the 16-bit color values that the DSTwo SDK normally uses. But, when sending graphics data in some other format, you need to NOT set those bits on! In my case when sending the text mode data (which on the x86 is formatted as an 8-bit character followed by an 8-bit attribute byte), the attribute byte always had the highest bit set, which caused the background color to use the light colors. This caused the DOS background to be gray when it should have been black, so I first thought I had a problem with the palette. As I don't plan to send any 16-bit color values in DS2x86, I simply commented out those two bits, thus forcing the MIPS side to always send the graphics data as-is.
Currently I am working on the CGA graphics mode data transfer. This is rather similar to the text mode (on the MIPS side), it can simply send 32KB from the emulated x86 segment address 0xB800. The NDS side just needs to handle the received data differently. After I get this working, the next mode will be the MCGA graphics mode. In that mode I need to send 64KB from the x86 segment address 0xA000, plus additional 512 bytes (or 768 bytes if I move the 24-bit palette -> 16-bit palette conversion to the NDS side) for the palette.
The remaining graphics modes (EGA and Mode-X modes) are somewhat more difficult, as sending the whole graphics memory area would be 256KB, which is more data than I want (or probably even can) send per frame. I think I need to limit the data to be sent to 256x192 (or 320x200) bytes, but as that won't be enough for the high-resolution modes like 640x480 16-color VGA mode, I still need to figure out a smarter way to handle this. Only after these changes I can then start working on the audio stuff.
http://dsx86.patrickaalto.com/DSdown.html