Xuel

You could change this line in no_name.asq: mva #$ff sizem to this: mva #$00 sizem again i have border.. I think you are swapping "border" and "no border". You have no border in that picture. border = two black bars on left and right side of picture made from MISSILES which cover COLBAK and PLAYERS. To get a border change #$00 back to #$ff.

On my real 800 (NTSC, OS B, GTIA, 48K) this says, "Sorry, Emulator" On my 800XL it says, "OK, Atari" The test program sets PORTB to disable the ROM and install its own NMI and IRQ vectors. That doesn't work on an 800.

Can you try using Beta4?

You could change this line in no_name.asq: mva #$ff sizem to this: mva #$00 sizem

Glad you got it working! Full screen at 25fps requires about 500kB/sec, but PBI memory mapping should be able to come to the rescue.

Hmm... What symptoms did you see? The only settings that I could find that don't work are: - 16K - 5200 - NTSC Otherwise, it seems to work with any other settings. If you enable basic the bottom of the screen is garbled, but it still plays. Burst settings don't apply to the image loader -- it's always 0-cycles to load the next block.

About a day on 3 cores with the case fans on full blast. Wife asked, "Why is your computer so loud now?" 200000 evaluations per frame, 2092 frames. I'll give dither_val a try! I really like the results of ciede but, man, it is slow. The IM clip may have been a bad choice to really show off RastaConverter since the film uses heavy filtering which squelches everything but blues and oranges, so it tends to look like B&W plus highlights of color. Nonetheless, RastaConverter is awesome.

Just for fun, here's another video that abuses the fact that block loads are instantaneous in Altirra and AtariWin800. (Haven't tested Atari800) - Video: Fullscreen 160x240, 4++ bpp - Audio: 4-bit 15.6kHz - Length: 1m23s - Uncompressed size: 46MB - Link: im.zip Next step is getting this working on real hardware using my Beaglebone. Need to buy some level shifters...

I realized my fork doesn't have all the Beta4 changes since ilmenit still hasn't pushed all of them to github yet. EDIT: I had posted that the summing and comparing of distances were still floating point, but like phaeron said, it's integer math. You could speed up the initial distance computations and dithering but those don't take too much time.

I merged ilmenit's latest changes into my fork. I added you as a collaborator if you'd like to upload another Beaglebone build. I also just received my own Beaglebone in the mail from Amazon a few hours ago and I just got your build running on it. I'm getting around 220 evaluations per second with only USB power. Amazing little device.

Nice work! I've added your build to the downloads page. I don't have a BeagleBone but I might be interested in getting one. I want to try hooking up a microcontroller board to the Atari's PBI connector to try my hand at making some kind of "new equipment" device, for example, as emkay alluded to, a huge bank-switching memory expansion for RastaMovie . I've read that Beaglebone will die if you hook 5v devices to its GPIO pins without level shifters. The Fez Panda II is 5V tolerant but has a lot less ram and cpu horsepower. Full screen movies would require ~500KB/s throughput (25fps * ~20KB per frame).

Oops! I swapped the src and dst coordinates in my simple reimplementation of allegro's stretch_blit() function. I committed a fix here. BTW, the issue only affected the output pictures. The .pmg, .mic and .rp files should have been fine. That's cool that you got it working on Beagebone! What kind of evaluation rates are you seeing? I get around 3200 with allegro and 4200 without on my Phenom II X4 3.4Ghz desktop machine in windows and a little higher than that in Linux.

The beauty of github is that forks have all the features as the mainline. So, you have several options to get my optional-allegro fork: Click on the "ZIP" button here Click on "Download as .zip" here. get clone git@github.com:lybrown/RastaConverter.git I'm thinking of refactoring the code a little before merging back into the mainline so that the pieces that ilmenit mentioned are more modularized. No worries. Your fork is private to you. You can keep it or delete it by going to it's page, clicking on "Admin" and then "Delete this repository". You couldn't affect my repository or ilmenit's unless we were to add you as a collaborator.

Apologies. I just realized that I put the Allegro windows executable up instead of the non-Allegro one. I've corrected it here.

Perhaps it'd be nice to have a non-gui version, too, in the future, which then can easily be run on headless machines. One might even strip out all FreeImage code and only support PPM files (portable pixmaps) and BMPs, which are trivial to read without an image library. Having Allegro and FreeImage is nice, but not strictly necessary to do the conversion of images. I was thinking the same thing! I created a fork that makes Allegro optional. Executables here. I made the default /max_evals=5000 when Allegro is disabled. ilmenit, I hesitate to merge this into the mainline since it mucks up the code quite a bit. Ideas?

I added my latest Windows and Linux x64 builds to the downloads area. Can you provide a Beaglebone ARM build?

Thanks! I pushed a bunch of commits. I tried to recreate the commit history leading up to Rasta-opthack5. I'll add branches from other folks soon.

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!

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. 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?

Emkay, here is your picture with the border hacks applied: 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.

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

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

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.

Yea, the borders were very messed up there. Release early, release often! The frames have to fit into 16K banks, so that's why the bottoms have to be cut off. Here's a new version with cleaned up borders. I also reran RastaConverter with 3M evaluations per frame instead of only 100K. As AtariNerd says, I saw what Crest did with NUFLI and NuvieMaker (examples) and thought it would be the next logical step for RastaConverter. Now we just need a really huge memory expansion. Is there anything over 1088K? homer2.xex RastaMovie-0.2.zip On Github: https://github.com/lybrown/RastaMovie

I present RastaMovie-0.1. Requires 1088K. homer.xex RastaMovie-0.1.zip