Jump to content
IGNORED

Quantizator


ilmenit

Recommended Posts

Can't the movie be streamed from a hard disk? Modern interfaces are providing 65kb/s - almost as fast as the A8 can read from RAM.

 

Possibly, but the raster program eats a lot CPU, so there wouldn't be much left over for disk handling. You could probably do a movie that covers a small part of the screen at least. Is there any disk hardware that can memory map its own 16K-32K buffer into system RAM space? If you could tightly control the timing of when the drive fills this buffer, then we could get full screen.

Link to comment
Share on other sites

All I/O is by the CPU (no DMA devices), so you can put the data anywhere.

 

The IDE types can do adhoc I/O so you don't get overrun problems like with SIO.

 

I can give it a try. Which of Altirra's disk emulations would you recommend? I found the MyIDE docs which look simple enough.

Link to comment
Share on other sites

Can't the movie be streamed from a hard disk? Modern interfaces are providing 65kb/s - almost as fast as the A8 can read from RAM.

 

Possibly, but the raster program eats a lot CPU, so there wouldn't be much left over for disk handling. You could probably do a movie that covers a small part of the screen at least. Is there any disk hardware that can memory map its own 16K-32K buffer into system RAM space? If you could tightly control the timing of when the drive fills this buffer, then we could get full screen.

 

The overheads seem very light with - for example - SpartaDOS X, and for the most part the disk handler is doing burst I/O, reading the IDE data register directly into the target area of RAM. Also, PIO tends not to mess up critical interrupts the way serial IO does, if that helps.

Link to comment
Share on other sites

Some hacks to improve borders:

  • Skip COLBAK init to improve top border.
  • Use all four missiles with PF3 (fifth player) for side borders, disable GRACTL missile DMA, set GRAFM to $FF. This allows using /noborder mode in RastaConverter so all four players can be used for detail.

leenorris.xex

 

GitHub

Edited by Xuel
  • Like 1
Link to comment
Share on other sites

I dug some more into the Diablo sprite stripe problem, and it looks like RastaConverter has uncovered sprite handling bugs in all emulators.

 

There are two bugs in current versions of Altirra. One is that it doesn't properly handle a sprite that starts in horizontal blank and is retriggered again in the visible region on top of that image. That's not too bad to fix.

 

The other problem is nastier and has to do with what is actually displayed when a sprite is retriggered, particularly in quad width as RastaConverter uses. This is the bug that nobody appears to get right. It's best shown with a test program, which tests timed changes to the sprite registers (the sections are HPOSP0, GRAFP0, and SIZEP0):

 

Altirra 2.0:

post-16457-0-01568200-1337150541_thumb.png

 

Atari800 2.2.0:

post-16457-0-61925800-1337150547_thumb.png

 

Atari++ 1.6.0:

post-16457-0-39142100-1337150561_thumb.png

 

From what I can tell, RastaConverter simulates what I implemented, which is to reload the sprite's shift register whenever the position counter matches. Atari800 and Atari++ are drawing both sprite images in full. Neither behavior is correct. Based on tests I've done on the real hardware, this is what should happen:

 

post-16457-0-83761600-1337150566_thumb.png

 

Basically, the contents of the sprite data latch should be ORed into the shift register in its current state at the point of the retrigger. This mostly resembles and overlap of the images, but for double or quad width sprites there is jitter depending on the difference in LSBs of the positions. Ordinarily you'd have to work really hard to find a program affected by this. That is, unless someone would be crazy enough to write a generator that happens to try millions of iterations of random raster programs. :D

 

In order to support this in RastaConverter, its inner raster program loop would need to be modified to remember the previous sprite positions so that on a retrigger it could determine how much, if any, of the previous image remains in the sprite's shift register. After that, there is the usual quandary of producing executables which are correct according to real hardware behavior, but don't work correctly on emulators. I hope to at least rectify this soon for at least one of them.

 

I have also noticed an oddity in the position comparator behavior where the deadline for a new sprite image seems to be one cycle off from where I would expect, but I haven't been able to nail down the exact behavior.

  • Like 6
Link to comment
Share on other sites

There are more hardware freaks than software freaks in the A8 scene. I wonder why no one is bulding a combinated controller that works like a RAMdisk and can be loaded from a streaming media....

As the controller "knows" which RAM bank isn't used on the A8, it can be filled in that time.

At the end one could watch full movies on the A8 ;)

  • Like 1
Link to comment
Share on other sites

Emkay, here is your picture with the border hacks applied:

 

post-21021-0-60026700-1337153392_thumb.png

flugput.xex

 

Notice that the antenna in the top left suffers from not init'ing COLBAK. I am thinking about more reordering hacks to push the COLBAK init forward into the first line instead of not doing it at all.

  • Like 1
Link to comment
Share on other sites

Some hacks to improve borders:

  • Skip COLBAK init to improve top border.
  • Use all four missiles with PF3 (fifth player) for side borders, disable GRACTL missile DMA, set GRAFM to $FF. This allows using /noborder mode in RastaConverter so all four players can be used for detail.

leenorris.xex

 

Do you modify the source of RastaConverter too? I'm planning to do some changes now and would like to work on the newest version.

I have to read about how setting GRAFM=$FF and no missile DMA covers other players.

How skipping the COLBAK init can improve the top border?

 

leenorris.xex - Nice :) It may be worth to try to do transitions from one frame to the next using the /continue option. In theory it could minimize raster program differences caused by random initialization and animation could be smoother. Maybe another parameter /transform (instead of /continue) should be added to change probability of mutations or use different mutations.

Link to comment
Share on other sites

I dug some more into the Diablo sprite stripe problem, and it looks like RastaConverter has uncovered sprite handling bugs in all emulators.

 

Indeed. Proper sprite repositioning was the hardest thing to do in the RastaConverter and debugging it ate a lot of time.

I will try to find and send you my tests files - there were differences on all the emulators and the real Atari.

Damn, I thought that I have done it properly :|

Link to comment
Share on other sites

There is a discrepancy between antic_cycles table definition in RastaConverter and what Altira Hardware Reference Manual states at page 48 (second graph). There are 13 free cycles between Display List DMA and the first occurrence of Playfield DMA implemented in RastaConverter, while the manual shows 12. Which one is accurate?

Link to comment
Share on other sites

Some hacks to improve borders:

  • Skip COLBAK init to improve top border.
  • Use all four missiles with PF3 (fifth player) for side borders, disable GRACTL missile DMA, set GRAFM to $FF. This allows using /noborder mode in RastaConverter so all four players can be used for detail.

leenorris.xex

 

Do you modify the source of RastaConverter too? I'm planning to do some changes now and would like to work on the newest version.

I have to read about how setting GRAFM=$FF and no missile DMA covers other players.

How skipping the COLBAK init can improve the top border?

 

 

No, the only modification I made was to add a /max_evals flag. (And I'm not sure I did it right since I don't know if 999,999,999 always fits in an unsigned.)

 

I implemented the missile borders in movie.asq. See also PRIOR and GRAFM in phaeron's manual.

 

You have to enable extended PAL height in Altirra to see the top-border artifacts caused by initializing COLBAK too soon. I implemented the top-border fixes as post-processing filters in the Makefile.

 

perl -ne 'print if /Init/ .. /ldy/; print if /line0/ .. /line160/' \
$*.out.png.rp.ini $*.out.png.rp \
| perl -e '@l=<>;splice@l,25,0,splice(@l,7,2),splice@l,23,1;print@l' \
| perl -pe '0 if 1 .. s/COLBAK/HITCLR/' \

 

The first perl hack strips out the sync stuff from the rp.ini. I moved all the sync to movie.asq. The second perl hack shuffles the STA COLBAK as late as possible, but it was still visible. So the third perl hack disables the STA COLBAK altogether. I don't like this because it can really mess up some pictures that don't change COLBAK for a long time. I was going to experiment with a more complicated filter that can look for useless instructions in the first line that it can overwrite with the COLBAK init, or do some other sort of instruction shuffling.

 

leenorris.xex - Nice :) It may be worth to try to do transitions from one frame to the next using the /continue option. In theory it could minimize raster program differences caused by random initialization and animation could be smoother. Maybe another parameter /transform (instead of /continue) should be added to change probability of mutations or use different mutations.

 

Cool idea! I'll try with /continue. So, with /transform it would basically be like giving RastaConverter a strong hint about where to start but still giving it freedom to make some significant changes as though you were starting from scratch? Very nice. Maybe it would make sense to use /transform for P and B-frames and start from scratch or bump the mutation probability way up for I-frames?

Edited by Xuel
Link to comment
Share on other sites

By the way, is it possible to add an "only list really interesting threads"-button somewhere on the forum (f.e. at the main page)? Threads like these show me that it's still worth it to spend time to visit the forum, but if I only visit the AA forum 4 times a year, it's really easy to miss it.

Link to comment
Share on other sites

There is a discrepancy between antic_cycles table definition in RastaConverter and what Altira Hardware Reference Manual states at page 48 (second graph). There are 13 free cycles between Display List DMA and the first occurrence of Playfield DMA implemented in RastaConverter, while the manual shows 12. Which one is accurate?

 

Well, I wrote the latter, but I'm pretty sure 12 is the correct number. My Acid800 test suite has a test that checks the DMA pattern, and I also have a cycle dump from a hardware analyzer that shows 12 unused cycles after the two LMS address load cycles and before the first playfield DMA cycle.

  • Like 1
Link to comment
Share on other sites

Thinking of detail enhancements.

Is there any chance to add some "intelligent" dithering to the converter?

At least some "line depending" ditherer, not dithering in pixels, would help. Which means, if "no" dither is chosen, 2 lines could build a resulting colour there, to reduce the horizontal lines.

 

I've tried to enhance the details in the Doom Picture, by doing some line draw here and there.... lighten up some regions and darken lines... to trigger the converter...

 

 

post-2756-0-10534900-1337282294_thumb.png

 

dumm.xex

 

 

Link to comment
Share on other sites

I found that I can "fix" the top border by simply patching rasta.cpp so that it never mutates the COLBAK initial register value away from zero. No need for additional instruction shuffling because Rasta will naturally figure it out from there.

 

This zip file contains a recompiled version of Rasta-opthack5 with this border fix. It also includes a patched version of no_name.asq that adds the missile borders on the left and right of the image. Although counter-intuitive, this lets you use the /noborder mode to use all four players for detail while still getting a nice border. You can unzip this over your existing rasta work area at your own risk.

 

RastaConverterBorder.zip

 

Here is Emkay's dumm.xex with borders. It doesn't include the new top-border fix, but rather my old top-border fix that corrupts some of the top lines.

 

dummborder.xex

 

ilmenit, do you plan on putting your code into a revision control repository, e.g. github? You could then field pull requests as you see fit. And, BTW, thanks for making this code available to all of us!

  • Like 1
Link to comment
Share on other sites

You're always at a bit of a disadvantage, trying to convert from another 8-bit machine like the C64 with its' very specific pallete and manner in which it displays images,, because you not only have to deal with a manner in which it's able to create images the Atari may not be able to, but you also don't gain any of the specific advantages the A8 has. That's part of the reason most people have been converting from higher-color images from 16 and 32 bit platforms. You get images of good saturation with "machine colors" the convertor is likely to pick up on well that take advantage of the A8's comparatively large pallete.

 

I did try a conversion of the Amiga Turrican title graphic, when the first build of the Rastar engine was out and got something that started to look surprisingly like the C64 screen,,,but didn't finish it as a much improved version of the engine had been uploaded by then and me being the ever-excitable blah that I am..yeah, new toy, have to try it. :)

Edited by AtariNerd
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...