1NG

Cool! Which editor for the PC is this? Is the output Basic (for LOAD-command) or ATASCII text (for ENTER-command)?

Nice tutorials! After understanding Basic there are a lot of tricks possible. Some programs are very short (See the NOMAM Basic Ten Liners http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=313429) Not very readable due to the small number of lines restriction - Not a good example how to style a program source code at all, but with some elegant tricks for the advanced programmer. In fact, some things are not very easy to understand, but a challange :-) In Turbo Basic XL you can use procedures and -- for a separating line. This is a good way to code readable Basic. And it is faster then Atari Basic. I recomment using Turbo Basic XL for programming.

Good work! My source is OK now too.

Now I ran into a problem with mads: One file of my source code doesn´t compile any more after upgrading to a new version (see above: upgrade needed for .segment) I striped the problem down to this: SHEARED_SCROLL = 0 org $2400 main: jmp main .if SHEARED_SCROLL ScrollLineOffsetFractAdd_ .rept 85 dta <(((#*25*256)/1000 + 64)*2/1) .endr ScrollLineOffsetFixAdd_ .rept 85 dta >(((#*25*256)/1000 + 64)*2/1) .endr .else ScrollLineOffsetFractAdd_ .rept 85 dta <(80) .endr ScrollLineOffsetFixAdd_ .rept 85 dta >(80) .endr .endif ; ----- start address ------------------------------------------ run main The MADS console output is 0,stop with output files of 0-size length

I just tried the cool feature .segment, but it didn´t work as expected (Message: "Value out of Range" for each .endseg) Until I used the newest version So everything is just fine! BTW: I saw the size of the mads.exe in the three last versions and it was 214016 bytes each. Why is it exactly 209 KB?

The problem with the "hairstyle" drawn lines (instead of a face) can only be in lines 60 to 80. It has to be the Plot or DRAWTO with a wrong second parameter (Y-coordinate). This schould be FY and LY in line 80 and nothing else. A typo in the data lines would not have caused a complete failure like shown above If you would like to get the face finally just look at that lines ...

There is aother though I got when I saw a video about media achaeology which concentrates on old media and representing it. the old computers are not collected to get all of them but stored if a special interesting thing is achieved for the first or only time. After that step there ist often another step and so on. Often it has to do with analogue and digital kind of work together. Sound is analogue but is coded digitally e.g.. One thing that is often looked at are the new possibilities that are given. If I look at the Atari 800 and put a new Device on it it enhances the old technique but the old technique still remains the same. That can be classified in categories like internal / external hardware (2nd Pokey / Sio2SD) or technique possible at that age ore later (same her, but a lot other examples existing: 2nd Pokey / Sio2SD) Some features of the VBXE were possible at that time but not all. Memory was possible, That much colors not. Examples like Battle Zone had also a hardware extension to the 6502. So the VBXE - Has to be programmed on the 6502 like in the past - Has memory like possible in the past (but for much money) - Has advanced video capabilities and a fast blitter. Compare the 7800 console graphics or the ST shifter. But they are from 1984/85 (not 1979). It is beyond that time. - It not much of a collectable in historic manner but in means of media archaeology. It uses the old technique to - VBXE is a great video enhancer for TFT-Displays I would like to have Battle Zone done with the VBXE even if it is not original Hardware. Everybody can decide for themselve But now: If someone uses the Internet to swap software that would not be the same as a copy party like in the 1980s where discs were copied.(Internet is not that new but only available for all since the mid 1990s) Draw your line ...

As I had some experience at the 10 Lines Code Competition at the NOMAM a few days ago I have a very short solution to clear memory at the top end of the memory (e.g. for PM in graphics 5): 9GR.8 The game is in graphics 5 and if a graphics 8 is set before that, it cleares the memory of 8KB. The GR.5 after that uses less memory and leaves enough KB with zeroes for e.g. PM. Only in this special case 5 characters are enough for a memory clear! This doesn´t work for highres games of course ...

I know it is not what you need, but I wanted to check for a range in zero page because of of the rmt used range. And this method checks for any boundary, not only page boundaries, so the use is quiet different. At the end of my zero page variables is the following code: ;safty for Raster Music Tracker zero page RMT_ZP .if RMT_ZP>203 RMT_Zeropage overlapping!!! .endif It generates an error if the zero page usage extends free space given if using rmt Same Test for overlapping different code blocks ProgramMemory1End .if ProgramMemory1End>antic Program memory overlapping with Antic program!!! .endif Maybe a diffent modulo statement can check for some other usefull cases too.

The concept of the tomek card is cool. I do a game for 130xe with or without VBXE. I still have no VBXE but Altirra works well emulating it. If it emulates tomek too, then a version for it is also thinkable. I like the Idea of a tomek chip inside a cartridge. I agree to some point that original hardware is the one and only true platform. And if there are to many extensions available then nobody will be able to play a game on his hardware. Unfortunatly it is not possible to support all hardware for graphics, sound and i/o with some kind of drivers. There is not enough memory and cpu power to do that (Even no Driver API). Every piece in a game is usually optimized for the used hardware. And if drivers would exist, then the speed of the hardware would differ. So? Tomek is OK for me, because it can be used as a separate hardware. VBXE is still a good hardware though. My problem with VBXE is mainly the poor availibility and that only one core is available which supports functionality of a (very fast) blitter. (BTW: How is a core written?) My other idea before reading about tomek was a complete hardware for graphics, sound and i/o. Programmable core, sprites, extended memory, digitized sound and enhanced i/o (ethernet, midi, hdmi). This would be a new defined platform which takes standard hardware to a new defined level. games can support that easier. But that would end up like an Amiga with better graphics and sound but poor cpu. I like the old games and would like to preserve the style of them. Using sio2sd is no problem for most people (atari computer stays untouched). Enhanced Memory as no problem too. Enhanced graphics is different and should not be too much. Enhanced sound is good as well, but same problem. Enhanced i/o like ethernet and hdmi ist fantastic in my opinion since this would give better multi player games in old and fun style. And playing multiplayer games is a lot of extra fun! Having hdmi solves the problem for the actual monitors to have a good picture without washed out colors, flickering, wrong aspect ratio and other effects. As a programmer I can not make a game that needs 100 people with different tasks and tools. Atari is a good platform to do a lot of things by one person or a small team. Not an easy task to set the Atari++ platform right. My thought is: Enhanced graphics? yes, but not to much. Simple digitized sound? yes. And the previously mentioned ethernet port and hdmi out. That all together in a cartridge would be perfect!

As far as I read here there are still a few boards available, so I want to get one. (I am lucky that I havn´t sold it 27 years ago, it is still MY computer. I would not sell it for 500€)

I voted for one. I would love to use my good old 800 instead of the xl.

Aua! I am out here.

Some calculation helper.... We have 160x240 pixel. So in no way we could have more than 160x240 colours (38400) on the screen. This is also limited by the FIXED palette of 128 colours and the available colour switches per scanline. The only REAL problem is the calculation of the available colours per scanline with that. This limitation and the fact that an image has to be "an image" , limits the colour count even more. Mostly a "real" colour picture ends up in less than 60 colours , and it is FULL ALIKE whether the picture originates from real colours or from a 512 colour picture. And btw. one of my self written tools back in the 80s was a picture converter.... So what is the complexity here? Low, because of the few colors? My guess is, that it is very expensive to calculate: Maximum: 160x240 pixels in a line with 128 colors per pixel possible. This means that only 2 by the power of (160x240*7) different pictures can exist on a Atari 8 Bit But that is a number with over 80.000 digits! http://www.wolframal...i=2^(160*240*7) Good news: Even, if you don´t count mirrored and inverted etc that is way to much to see them all. Bad news: To much to calculate them all. (Of course this maximum is not possible, because not every color is possible at every pixel. But only the bits of a normal picture without raster program have are 8500 Bytes (with PM) with 2^(8500* posibilities 2^((40+5)*, a number with 108 digits. Per line.) Limited real: Looking at the raster program: A typical rp-line has 7 changes of 128 colors but on different positions. With nops ld_ sta_ it has about 20 commands a line. ld_ hat 3, st_ 3 and nop is only one command. 7 commands in 20 places but every ld_ can have 128 different values to load (even some more if used for PM Positions), every sta has a color register or PM Position as parameter. About 10^51 possible raster programs per line. Still way way to much to do them brute force. And they are influenced by the previous line, which has not been taken into account here. This is combinated with the posiibilities from the bitmap and PM (108 digits number from above) I am not a mathematician, so something can be missed here. But the big numbers don´t lie: A lot of complexity here! Much more than it seems on a short look.

Ofcourse the bird is possible in G2F. Show it or it didn´t happen. Wow! But how can that be used by a painter? I would like to see a handmade picture with 23 colors per line, made by G2F. On Sat Aug 4, 2012 11:45 AM you wrote 13. Now 16, so it is getting better every day! :-) But fortunately the FAQ tells the facts."How many different colors in line can we have?" I understand that now the problem Quantizator as painting program is solved. Now the colors are adressed: In the FAQ are some examples about that. No, because if you don´t want random, that is not a solution. Or have something changed here? You need to tell exact how it has acted. (And you can´t). But if you can not, how can it create automated solutions (without errors)? 5.1 works fine for me. Maybe you have testet more and can share experience here. Can you provide a complete example? (Can simply be a bug.) This is not only a try to make Quantizator look bad, or is it? (Everytime another thing is bad.) Take it, leave it or improve it.

Short: Hand Painting & G2F -> few colors per line using simple rasters, Quantizator -> lots of colors using complex rasters There are two different applications for different needs. Try to paint the bird obove by Hand -> impossible with G2F. Try to get a G2F-Painted cool Picture to be found by Quantizator -> (nearly) impossible What you want is a painter? Take G2F that is a good solution for that. You can´t have the full colors without complex rasters which have complex side effects which can not be visualized for the artist. What you want is maximum colors? Take Quantizator and do not try to paint over the result. No. Assuming rasters are the same is not correct here. There are other rasters for other needs. I have one for my own needs, and it is different to G2F or Quantizator. You don´t want a "random program" to help you (because the result will be random), but you don´t have the time to wait for the brute force method (because you die before it is ready) You can´t get a painting program with Quantizator rasters, because they are the result of the random process. Quantizator rasters are not uniform, and that gives more colors and positions but more complexity. Live with G2F and fewer colors, painter, and you will be happier. G2Fs restricted raster mode is understandable by the artist. And the paintings are not bad at all. The 4 (5) bitmap colors are shown on the left border. Stock management uses a similar technique: chaotic or dynamic stock. Put pieces optimal in different places (chaotic) uses the space very well, but is not easy to handle from a person, because pieces are spreaded all over the stock. The other technique uses the same pieces always in same locations but wastes space. This can be handled by a person. -> Like much colors, but not understandable for the painter or less colors and easy to handle. BTW: The color problem is way complexer then the example above, because usable areas overlap. But maybe it is an example to understand.

AFAIK the paintings in the compo are NOT simply converted from a picture. They have to be handmade. The video also shows the steps of work. Quantizator is not a painting program. It does not fit to the problem. Isn´t it better to use G2F to do it by hand? It is exact as you requested and can do wonderful pictures. I think that all pictures in the compo have to come around the limitations. Quantizator as a painter? The Gui is not designed for that. If a new program uses the cool "graphics mode" of Quantizator and would try to allow manual painting it would still be very difficult, because a new pixel at any point often needs a change that has effect on other pixels. And there is not only one solutioin for even changing only one pixel. What solution should be choosen? Would you like to get a drop down menu with 20 solutions for that and choose one by looking at the result? And after choosing a pixel the next pixel can destroy the previous one in all possible solutions if you have bad luck. Maybe it is possible to paint a (translucent) green and red over the picture. Where green is painted the pixel get higher priority and less priority if it is "overpainted" with translucend red. Then a slightly directing of the automatic optimization is possible. But it will remain "random". Maybe the red/green overlay could be given as an option and has to be painted before the optimization process. Again it shows that the preparation process of the picture and the calculation parameters can have very strong influence on the result. Only a thought, don´t thinkabout it: A fix random generator start for the complete picture can be given (not easy for multi threaded apps). That means only that the next calculation with identical parameters get the same result. The solution stays random of course. But how much random is the picture anyway? There can be found some good calling parameters that generate nearly the same result every time.Given the fact that it is impossible to calculate the "best picture" (BTW: How does someones eye define that without the slightest subjetivity?) in a short time, quatizator make a very good job.

Here are just some thoughts about a constant amount of colors per row (to prevent something else): Based picture is posted here some posts before in true color. Resulting picture from that in all Atari colors with dithering would be This is not possible as there are to many colors per line. A diagram for the colors of each line shows 6 to 16 Atari colors per line. (first line is the amount of colors of the first line of the atari picture and so on) Using 4 colors per line looks like this: it has lots of errors This will stay so for 9 or any other low number of colors. A drawback is allways, that colors change from top to bottom because they are not get choosen for that line. Ithink the approach of calculating a "best fit" is a good approach. Some criteria for best fit are not easy to calculate. I think that looking at the pictures above and of course the thread at all is very interesting. And there are a lot of ideas presented here. Quantizator has some kind of complexity that will allow users getting experts after using it heavily. I like that.

The FAQ is a good Idea! No need to read the complete thread here and it shows how complex graphics can be. But it also includes a lot of knowledge transfer for the interested user. Well done!

OK, so progress is going on! Fine! VBXE for ALL. I only thought, that I would be near top of the list too, because my VBXE VGA/XE/PAL was "nearly shipping" since january. I hope the next 10 won´t take another 9 months ... This will give grand grand grand sons before the 8-Bit Community got it´s VBXEs :-) (which is also a good thing of course) greetings 1NG

I just tested it and it works were you want! look here: org $90 cx .ds 1 cy .ds 1 client_handle .ds 1 org $2400 create_button client_handle, #16, #20, #48, button1_text create_button client_handle, #32, #20, #48, button2_text button1_text dta d'Hallo' .db 0 button2_text dta d'Hallo' .db 0 create_button .proc(.byte parent .byte cx .byte cy .byte width .word lab0+1).var clc and cx adc cy sta width lab0 ora $0000 rts width dta $00 parent dta $00 .endp wich gets to the code mads 1.9.2 build 21 (21 Jan 11) Source: C:\c\wudsnprojects161\gedplus2\proc.asm 1 2 org $90 3 = 0090 cx .ds 1 4 = 0091 cy .ds 1 5 = 0092 client_handle .ds 1 6 org $2400 7 8 create_button client_handle, #16, #20, #48, button1_text 8 MVA CLIENT_HANDLE CREATE_BUTTON.PARENT\ MVA #16 CX\ MVA #20 CY\ MVA #48 CREATE_BUTTON.WIDTH\ MWA BUTTON1_TEXT CREATE_BUTTON.LAB0+1\ JSR CREATE_BUTTON 8 FFFF> 2400-245A> A5 92 + MVA CLIENT_HANDLE CREATE_BUTTON.PARENT 8 2405 A9 10 85 90 MVA #16 CX 8 2409 A9 14 85 91 MVA #20 CY 8 240D A9 30 8D 59 24 MVA #48 CREATE_BUTTON.WIDTH 8 2412 AD 42 24 8D 57 24 + MWA BUTTON1_TEXT CREATE_BUTTON.LAB0+1 8 241E 20 4E 24 JSR CREATE_BUTTON 9 create_button client_handle, #32, #20, #48, button2_text 9 MVA CLIENT_HANDLE CREATE_BUTTON.PARENT\ MVA #32 CX\ MVA #20 CY\ MVA #48 CREATE_BUTTON.WIDTH\ MWA BUTTON2_TEXT CREATE_BUTTON.LAB0+1\ JSR CREATE_BUTTON 9 2421 A5 92 8D 5A 24 MVA CLIENT_HANDLE CREATE_BUTTON.PARENT 9 2426 A9 20 85 90 MVA #32 CX 9 242A A9 14 85 91 MVA #20 CY 9 242E A9 30 8D 59 24 MVA #48 CREATE_BUTTON.WIDTH 9 2433 AD 48 24 8D 57 24 + MWA BUTTON2_TEXT CREATE_BUTTON.LAB0+1 9 243F 20 4E 24 JSR CREATE_BUTTON 10 11 12 13 14 2442 28 61 6C 6C 6F button1_text dta d'Hallo' 15 2447 00 .db 0 16 2448 28 61 6C 6C 6F button2_text dta d'Hallo' 17 244D 00 .db 0 18 19 20 244E create_button .proc(.byte parent .byte cx .byte cy .byte width .word lab0+1).var 21 244E 18 clc 22 244F 25 90 and cx 23 2451 65 91 adc cy 24 2453 8D 59 24 sta width 25 2456 05 00 lab0 ora $0000 26 2458 60 rts 27 28 2459 00 width dta $00 29 245A 00 parent dta $00 30 31 .endp That is the same MVA #xx yy as in your code. If yy is in ram it works too. Look the cx above. You don´t need a software stack for that. I like that very much! proc.asm

There are also other possibilities in Mads: create_window(window_title_flag, #88, #70, #144, #60) create_button(client_handle, #16, #20, #48, button1_text) Is that pretty? And where your libraries are something like create_window .proc (.byte object_flags .byte cx .byte cy .byte width, .byte height) .var ... rts .endp create_button .proc(.byte parent, .byte cx, .byte cy, .byte width, .word ax) .var ... rts .endp The generated code is the same. No overhead. And there is more: You can change the program directly via parameter without an extra location by defining the destination of the parameter as location in the executing code (eg.in "MYLABEL AND #00" destination is the 00 as MYLABEL+1) Maybe you can use it. Anyway: Mads is very cool! And good job! I like that planning of a long life product is top priority (and not only a "demo"). I like to watch the project here and I CAN WAIT for a final result, knowing it gets better because of that.

I fiddled a bit with it and it worked! Thank you! allegro-4.4.2-msvc-8.0.exe/7z (http://77.55.66.239/...4.2-msvc-8.0.7z) does it if allegro-4.4.2-monolith-mt is used (lib renamed to alleg.lib + put in lib directory and the dll copied in the debug folder.)

Good work! I tried to compile that and need a little help: Include is only "include", Lib is only "lib" and two libraries are refrenced: alleg.lib;freeimage.lib BTW: That is different from RastaConverter (alleg42.dll, freeimage.dll) freeimage OK. Got it from http://freeimage.sourceforge.net/ and put the dll and lib into a lib folder. the .h in the include folder But allegro is not that easy: After I tried some binaries, i downloaded source packages an tried to compile them but they all had other problems. And the docs were allways not correct. Building with cmake doesn´t work either. Even cmake-gui always produced defect project files. As far as I see compiling will go in the direction of copying files into default VS folder . That explaines why there are no includes-paths for allegro in the vcxproj-file. So none of the four possible ways worked for me here and I need a little help. I would appreciate any hint on how to get the source compiled with VS C++ ...

Great pictures! Wow! Awesome. BTW: Did you went to holiday because all your computers were busy rendering pictures?