1NG

IMHO highspeed sio is <20klb/s, Ide up to 80kb/s in a special mode. Original floppy speed is extreme slow: How long does it take to load a normal 40kb game or to copy a 170kb disk? Not 1 or 4 seconds which would be 40kb/s. Size of ATR is limited to 16mb, but that should be enough. We need the complete set of pictures to plan how much kb each picture can have. After that the best graphics that meet the specs can be done in an appropriate way. Can somebody provide us a full set of pictures?

w1k-lounge is unbelievable good!

That is interesting: How big are they and how fast is "filling from outside"? I thought that is impossible on our 6502 even from ram to ram, because it would mean less than 2 cpu cycles per byte for load and store and update the addresses. How does it work? Wait: Bank switching is that fast! So if a memory has enough 16 k pages to blend in normal memory and every picture has 16 kb that will work perfectly even with RastaConverter! I don´t know any memory extension greater that 2M but if we convert a movie with 24 frames/s and 600 seconds time it leads to only 14400 pages of 16k wich is below 256MB memory. Is there anything like that available? (-> The community has to do the conversion of 14400 pics together with RastaConverter - We can do that! But I would like a project like that where a complete movie is converted with a lot of cpu power in more time than it takes to calculate a blue ray just to get a movie running in 160x200 (or 160x152 for 21:10 ratio) I would spend my whole free time in that! - The result would have been possible in the 80s - wow! That is that kind of spare time project I like best )

xex size is 22KB. -> 1MB is 44 pics only. How much pics/second are needed in Space Ace? The RastaConverter pics are great of course, but they can not be loaded fast enough. IMHO loading speed is about 40KB per second. This leads to 4 KB per picture for a framerate of 10 pictures/second And the cpu is used nearly 100% while displaying the actual picture so there is not much power left to unzip the next picture in time. I think it needs a different mode with even then lots of tricks to get it running on 8 Bit Atari. There is some research to be done ... Saving only differences between pictures will save memory as well as crunching. The format of RastaConverter does not take that in account by now. The RP RasterProgram is very different between two (similar) pictures because of the random and independend calculation. Maybe some day it evolves to a RastaMovieConverter ... It is very good for the title screen though. And it brings a lot of new thoughts ... Good!

The new version shows what is possible in speed. It geneates usable pictures a lot faster. It is very good for the old-style computer graphics pictures and not so good on the natural ones with to much colors. Maybe that improves if ilmenits holiday (without internet) is over in a few days. And it looks like the team work here is leading to a wonderful program. Great! BTW: The sources doesn´t compile on my computer with VS C++ 2005 or 2008. It seems that the including paths are not right. And if I change them the platform is unknown. Has anyone a complete source which compiles out of the box?

The base picture contain 51 atari colors. The achieved pic above is impressive for an automatically generated pic! There is still some distortion though. The theoretical best picture with atari colors looks like that: For comparison: a)And a flickering CIN-Picture of that: the colors are a bit washed out. (CIN has only 4 shades and limited color intensity) b)The best 4 color pic looks like that: You see good colors but due to dithering a lot loss of sharpness. Maybe it is impossible to get a better picture with a raster program, but I totally agree that it is a fun toy/tool

BTW: rp = raster program And for all people that don´t know computers very well (One argument by Apple is to not have to) Easiest way to look into a file: Use F3 on Total Commander. If it contains LDA or STA it is the right one :-) sorry, could not resist.

The output is asssembler source code. The batch in the generator folder makes a xex of that.

Maybe the result is OK anyway and only the desktop is screwed. Have you tested the result? Maybe there is a simple solution and the source can be patched. But I think it is OK if it only runs in True Color Mode.

The palette is wrong. I looks like red and green is switched (RGB <-> BGR) This is caused by: A) The picture being "different" from others (size, pixel-format or something) B) the palette used for Atari is false, currupt or inaccessible - If the same picture works on a different computer it then A) is not the case. I would try another palette as option. Maybe they aren´t accessible on the computer or corrupt. Look if they are available. - If the same picture doesn´t work on any computer try converting to a different format (JPG->PNG / PNG->BMP / BMP->PNG / GIF->PNG) (but never to JPG or GIF or quality loss can happen). Or try to crop a pixel in width. If it works I am interested in the cause. If not please attach the picture and the "test.bat" that starts rastaconverter.

That is awesome! I had some ideas after looking at the old source but was´nt able to write you before you did it? Great! Have a nice holyday!

You are correct! My fault, excuses to you. And thanks, because I have already seen very interesting stuff! The antic2cpu and vice versa is also part of the atari800 emulator - Of course, it has to emulate it.

Thank you, but as far as I understand the aproaches and the sources are very different: Quantizator works different than RastaConverter. And version numbers are totally different, too I think that RastaConverter is younger and looks better . (Because ilmenit has a lot of experience and the result is getting better each new generation) I can´t wait to have a look at the source of the new generation and to learn from that!

That is why the assembler code looks kind of "unsorted" with unessecary loads etc. I like that! Question: Change Value: STA +-1, +-16? LDA, LDX and LDY +-1 / +-16 is OK STA,STX,STY +-1 is OK Do you meant both or just LDA, LDX, LDY ? Thank you for sharing that information! I would like to take a look at the source code, too. I am interested in how the 57 cycles are mapped to the 160 pixels. I know how it is done on a Atari ST with 48 colors per line and I know the superb documentation of altirra about the DMA-cycles. I was just fiddling with a small program to figure out that timing when this great RastaConverter came out.

Since Yesterday I tested some things and discovered that the picture is getting better by time constantly. It takes it´s time but after 4 hours I got a picture with only 10.5 Norm. Distance. I thought that optimizing complex functions would usually mean to be stuck in local minima. (Which is the case here also I think) But going from about 20 at half an hour calculating down to 10.5 constantly in a couple of extra hours is surprising. (it does about 800.000 calculations per hour -> near 20 Million Evaluations per day) output.xex cin-Picture (GraphicsTileMaster): 4-Color Picture (GraphicsTileMaster): It is obvious that the first picture is far better! - CIN flickers but does not use 100% CPU time - The 4 color pic is unbelievable good for only 4 colors but not compared to GED- (calculating the optimal 4 colors does take a couple minutes too) RastaConverter is very good work. I see a lot of pictures coming ...

Yes RTFM - I did that, but I was to excited to read it carefully I am programming in c#, which has an easy parallel for and parallel foreach since .Net 4.0. And it works without gpu, but only with cpu-speed and that few cores. it has nearly no disadvantages even on only one CPU-core. Speedup is about factor 3 to 4 on my quadcore and was achieved very easily. What is the optimal picture? Optimal can be, if the eye recognizes the least possble differences for the graphics mode used. That can not be achieved by calculating all possible solutions - Simply because there are to many. Choose 4 colors out of the possible 128 colors per line and combine them with the 5 available colors of player-missile graphics and place them at the best possible positions. Limitations are: PM is only 8 pixels horizontal, but can have different width of one pixel at the screen PM can be in front or behind the normal color which has different possibilities: a) smaller independent pixel or b) bigger area (width) of the color because a big block of the color is placed behind the 3 foreground colors. Every block has to be positioned on the right place. Then dither the colors in an optimal way (not simple to do that afterwards or before the color choosing. Afterwards it affects the next line and previous calculating leads to more colors at all) And that all has to melt down in an assemply-program that can be executed on the atari syncronized with the beam. After all pixels, colors and PM-places are choosen the visible difference has to be calculated to analyze the solution. And there is always something extra This means, that it is not easy to get a program like RastaConverter wich does pictures in a forseeable time. This means great work so far!

I just tested it and it is great! As you may know I work on similar things my hole life. From basic via assembler, C, C++ and now in C#. I am very interested in the technique you are using now: What means that technical stuff while the calculations are running? PushBach2Prev Copy2NextLine SwapWithPrevL Is this Color changing or pixel? I have no clue. Add Instr Remove Instr Swap Instr This looks like organizing the color changes in the dli Change Target Change Value Chg Val To Col What are these for? Norm. Distance looks like the Distance per Pixel (momalized), right? Last Best is the number of the calculation with the lowest distance yet Solutions: 1 seems to be constant

Great work! I was thinking about the drawing order: On the one hand it is good to see the moved window drawn first before the "old" one disapears on the last position because the directory is shown early and can be read while the rest of the drawing is rendered. On the other hand it looks unnaturally because something has to disapear before it apears again to look natural. Beeing there twice and erasing the false twin has something unnatural. If it is possible to change the order easily I would like to see a prototype with changed drawing order just to feel out the difference. But don´t waste to much time on it if it is not easy to do. It is good like it is.

Often Life is unpredictable. And: Curses on anybody who delays the VBXE production!

I think smooth means here: With a lot of frames per second and constant speed. All frames (50/60) per second is the best of course, but what about the speed: 1 line per frame or 2 or 4? everything uneven like 3.3 will look unsmooth without further processing - which is not possible on A8 like in modern TVs. So pressing the mousebutton on the arrow-up or -down maybe can scoll smooth, but in a window it has no hardware assistance like scrollregisters. Without that registers everything is done by the 6502 alone. That is usually done by moving a part from the screen and painting the new visible part. Speed then is gained from copying and drawing speed. I think copying speed is fast on byte aligned windows (as mentioned in the discussion). Drawing the new part depends on the graphics that is shown. Showing text with the great fonts shown earlier can only be fast up/down if it is scolled a complete textlineheight at a time. Therefore the windows height also have to be a multiple of a texts height. This is part of the application design I think. Or did you mean with "offtopic" scolling the text fullscreen without the topic of the GUI multiwindow system? That is easiliy possible via hardwarescrolling for a few pages if the text is rendered in memory first (at any fontsize).

Very cool work! I like the GUI very much and I think I understand why you are doing that fascinating stuff :-) I did something like that but with easier conditions: I've done a XWindows-like Gui in graphics mode under DOS in c++. And I did a multitasking system on a 6809 in Assembler in 1989. The 6809 has a register to set the zero page to a 256 byte aligned address. So every task had it´s own zero page. After doing the kernel I did the priority of the tasks like this: In an (timer-)interrupt every task can be switched a) if its time was up during normal looping b) if it has consumed a lot of time without looping c) it signaled that it does not need further time a) is for programs, that are doing things like looking for user events periodically in a loop while doing something b) is for copying data, drawing rectangles etc. this is not done in an event loop and needs to be done as quickly as possible c) is for a program that has nothing to do yet. a) a "Main Program" with interactions b) drawing windows c) Background Task. E.g. printer task, but nothing to print the differnce is only the time a process/task has at one time slice a) about 20ms before the next task is running b) about 100ms before the next task is running c) 0ms before the next task is running, change immediately technically it is done by looking in the main-loop if a program has run 20ms or does not run anymore. Then the actual task is hold and the next task is started. If a program has to do a lot of work (without event polling) (or hangs) it will be hold after 100ms. switching was done by manipulating the stack. The saved stack was restored and the program jumped back to it´s last execution line. This was done for a maintenance system which acted as a master and asked a lot of sensors via a telephone-chip and ordinary telephone cable. It had 4 fixed tasks running at the same time and programming them was not very special. They shared the hole ROM-memory for the programs and had it´s own stack and zero page. Main memory was always shared by all tasks. The User could navigate in the LCD-Display while sensors where polled and lists where printed at the same time! The 4th task checked some system states an produced messages if something was going on. It was fun for me in the past doing that kind of programming! This is not a complicated approach. Programs can be debugged quiet well (which is very important). But I think a good API is the key to acceptance. As far as I understand there is no program running under the GUI that is not designed for it. Maybe a full screen mode is possible while running tasks in the Background. While I am typing this I think that a good name for the GUI would be quiet useful. -> Quius :-) If not, maybe the text-editor for the OS can get that name :-) Or Quit Useful Operating System Quos. If it has a name (or a project name) then it is concrete instead of the more common "the GUI" which stands for other GUIs as well. Is there a name for it (What is the name of/in the source file?) As I read a few posts I understood the API is similar to existing ones, so some programs will work without changes and others with a few. That is interesting! I would like to know more about the API.

I tried only Altirra 1.9, wich was fine with mc14_d6.xex. It crashes at 7000 and continuing brings the attached screen: Stars are moving and charcter on top changes on stick movement. I hope that helps a little bit. BTW: My VBXE is coming soon ...

For 8 Bit I am using: Altirra as emulator and Wudsn as IDE with MADS Assembler. That works very well. You have a good editor, a fast macro-assembler with lots of capabilities and a superb emulator with good debugging features! You will love it!

Where is programming information available for the VBXE? I can´t find any Information or examples that are well documented. What kind of documentation do you use? BTW: I love moon cresta! The mc15_x does not work here, but version m14_x does.

Ah "Source line breakpoints"! Thanks for the second best chrismas present this year! (And a lot of other stuff in the 2.0 Version. Yeah!)