Page 4 of 7

Posted: Tue Jul 24, 2012 11:48 am
by antime
You could try adapting the double interrupt technique used on the C64. Basically you arrange for an interrupt to trigger while the CPU is executing instructions of a known, minimal latency, and then compensate for the single instruction jitter by cycle counting and polling.

Posted: Tue Jul 24, 2012 1:30 pm
by bgvanbur
Chilly Willy wrote:To give you an idea of how sensitive this is, the loop in work ram starts the DMA 6 pixels earlier than the same code in rom.
This makes me wonder about the sensitivities of using Word RAM for VDP DMA.

Posted: Tue Jul 24, 2012 3:02 pm
by TmEE co.(TM)
Regarding Stef's idea about Z doing things, well it won't work because bus is locked and when Z accesses 68K side during DMA it will also be halted like 68K, until DMA ends.

Posted: Tue Jul 24, 2012 7:12 pm
by Chilly Willy
antime wrote:You could try adapting the double interrupt technique used on the C64. Basically you arrange for an interrupt to trigger while the CPU is executing instructions of a known, minimal latency, and then compensate for the single instruction jitter by cycle counting and polling.
Those work because the CPU clock is locked to the VDP clock AND you have access to a cycle accurate raster position. The raster position on the Genesis doesn't have the lsb, so you'll never be more accurate than 2 pixels. It doesn't help that the minimum clock cycles for instructions on the 68000 is 4, most are 8 to 14 cycles, and there are NO odd cycle instructions.

bgvanbur wrote:
Chilly Willy wrote:To give you an idea of how sensitive this is, the loop in work ram starts the DMA 6 pixels earlier than the same code in rom.
This makes me wonder about the sensitivities of using Word RAM for VDP DMA.
It shouldn't be a problem - any latency should just shift the image right a pixel - hopefully it's consistent and not intermittent, which would cause jitter. That is one reason I want to make a demo checking how it works from word ram... just to be sure.

Posted: Tue Jul 24, 2012 8:45 pm
by antime
Chilly Willy wrote:Those work because the CPU clock is locked to the VDP clock AND you have access to a cycle accurate raster position. The raster position on the Genesis doesn't have the lsb, so you'll never be more accurate than 2 pixels.
The synchronization is done based on the vertical count. The horizontal position is based purely on cycle counting.
It doesn't help that the minimum clock cycles for instructions on the 68000 is 4, most are 8 to 14 cycles, and there are NO odd cycle instructions.
Repeating the jitter correction for two consecutive lines would give a 2 cycle accuracy. If the cycle count/line isn't constant and predictable then the scheme obviously does not work.

Posted: Tue Jul 24, 2012 9:31 pm
by Chilly Willy
It helps that this mode has a two-pixel width (160 wide display instead of 320). I'm still trying various things, but this looks like one of those things that's non-trivial to solve. The current method used looks like the most straightforward for certain.

Posted: Wed Jul 25, 2012 7:12 am
by Chilly Willy
Well, I got H32 mode stable... just comment out one of the NOPs after the 13 word stores. That's it.

However, there's a BIG problem with H32 mode and DMA color: 161 wide shears to the left, and 162 wide shears to the right. Apparently it's 161.5 wide!

So I don't think H32 and DMA color is going to be useful. :(

EDIT: Well, I suppose you COULD draw the buffer such that every other line was 161 and the other lines were 162. That should average out to rectangular, but every other line will be a half pixel off from the others. Not to mention that makes calculating the offset to draw to a bit harder, but it SHOULD work.

EDIT 2: Well, finally got some free time and tried the 161/162 trick and found something interesting... it IS 161. For some reason, if I save the BMP as 161 wide and convert it, it's not converting right. Maybe BMPs pad for odd widths... when I save as 162 and then only write 161 pixels per line, it looks perfect on the screen. Go figure... :lol:

Anywho, I'll post a demo in a bit when I clean things up a little... need to adjust the display a little as it doesn't start at the same place as H40 mode, so I need a bit of padding to start to center the image.

EDIT 3: Here's the demo. Images are 161x224 with a visible width of 128. The converter takes a 162x224 BMP and outputs a 161x224 binary.

http://www.mediafire.com/?88jfs5ztav8k9a8

Posted: Thu Jul 26, 2012 2:50 am
by sega16
Good news everyone I have finished my own converter. I call it Image to direct color and back again meaning that it can take a image in major formats (I tested it with png and jpg) and convert it to direct image and then convert the direct color image back to an image readable. It supports floyd steinburg dithering so the images look good and no more messing around with plugins it is a one click solution. Here is the format for using the program

Code: Select all

directconvert -m input output
for -m you can use -i2 -i3
-i2 means that it will convert the image to direct color with BGR 233
-i3 means that the image will be converted to a direct color image using the standard sega genesis palette format
-o means that it will convert both types of direct color image back to a normal image reable by a image editor
-o will automatically determine which type of direct color image it is based on filesize
Note the direct color images generated by this program have a 4 byte header
Width height are both stored in 2 byte big endian
-t will generate a BGR233 to sega genesis table NOTE: when using this mode leave output blank
Here is a sample image from the converter
Original:
Image
Sega genesis palette
Image
BGR 233
Image
As you can see BGR 233 loses 1 bit of blue but takes up half the memory
You can read more about this on my website
http://geekwithcomputer.com/directcolor.html
And download the program and source here:
http://geekwithcomputer.com/direct_colo ... er_v_2.zip
Please tell me what you think about it and I do hope you like it.

Posted: Thu Jul 26, 2012 3:07 am
by Chilly Willy
Nifty! Can't wait to try it. Oh - your website is really awesome, but it's spelled A W E S O M E. :D

EDIT: To compile in linux, use this line:

Code: Select all

g++ -o directconvert main.cpp -lpthread -lX11 -lpng -lz -lstdc++
CImg is in the Ubuntu repo, so you can install it with Synaptic or "apt-get install cimg-dev". Which brings me to a bug... in main.cpp, you have:

Code: Select all

#include "Cimg.h"
when it should be

Code: Select all

#include "CImg.h"
That doesn't matter in Windows, but does in every other OS. You also put "Written by sega" when you probably meant "sega16". :wink: :lol:

Posted: Thu Jul 26, 2012 3:30 am
by sega16
I fixed my site I remember looking at the logo and thinking something is not right I guess that was it.The online text generator I used had some odd glitch were even if I right click enable check spelling in the text box were the text is to be entered it did not show the red line under the misspelled word. I have never had that happen before I think it has to do with the website and not with firefox.
Edit: fixed program I can not believe all the typos that are slipping by my head.

Posted: Thu Jul 26, 2012 3:36 am
by Chilly Willy
sega16 wrote:I fixed my site I remember looking at the logo and thinking something is not right I guess that was it.The online text generator I used had some odd glitch were even if I right click enable check spelling in the text box were the text is to be entered it did not show the red line under the misspelled word. I have never had that happen before I think it has to do with the website and not with firefox.
Probably. My problem is I sometimes don't hit the keys hard enough to register, then I'll hit return before noticing I missed the letter. It's especially bad with keys I need to hit with the left pinky or ring finger.

Posted: Thu Jul 26, 2012 3:44 am
by sega16
Wow I never even thought about that happening but I am sure it has happened to me before and I did not even realize it. Is the program working on Ubuntu? I have heard reports of MVSC acting different than GCC although I don't think that the difference applies to my program.

Posted: Thu Jul 26, 2012 4:06 am
by Chilly Willy
Seems to work fine. I get the preview window with what looks like the converted image, and the save file has the data. Converting back gives a png with the preview image, so so far, so good!

Nice work... the images look good.

Posted: Thu Jul 26, 2012 4:10 am
by sega16
Glad you like it and yes the preview window is the converted image.

Posted: Thu Jul 26, 2012 4:49 am
by Chilly Willy
Here's a demo of a few 160x224 scifi images run thru the converter... very good. I don't think I could do better with GIMP and that ximagic plugin.

http://www.mediafire.com/?7jv67j62k4xxjw0