MEtalGuy66 Posted January 1, 2010 Share Posted January 1, 2010 Happy New Year! Heres a short slide-show for 130XE users.. (15 frames). 130XE Slide Show.zip Boot this ATR, go to BASIC, and run "D:MAIN.BAS"... Try this demo on a real 130XE with a REAL (commodore/magnavox) monitor using CHROMA/LUMA inputs.. Turn the brightness down and the contrast up.. This demo does not work without separate ANTIC/CPU access to extended RAM... It also doesnt look right on scan-doublers, or anything that doesnt do a true 1:1 frame-rate with the ATARI.. It DOES WORK with PAL and NTSC, and most video capture cards work fine with it.. It also works excellent in Atari800Win in either PAL or NTSC mode.. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted January 1, 2010 Share Posted January 1, 2010 Very nice! Does it run on a Falcon? Quote Link to comment Share on other sites More sharing options...
Marius Posted January 1, 2010 Share Posted January 1, 2010 Hey MetalGuy Why do you use 3.2 version of SpartaDOS ... In my opinion 3.3B is better (with HighSpeed Sio) or 3.3A in case of emulator (or if you want MyIDE) Greetz Marius Quote Link to comment Share on other sites More sharing options...
Marius Posted January 1, 2010 Share Posted January 1, 2010 By the way: Great demo! I really like the effect on the screen with the Windows Logo. The Atari Screens are great too. Cool stuff, thanks for uploading and creating it. Marius Quote Link to comment Share on other sites More sharing options...
Mathy Posted January 1, 2010 Share Posted January 1, 2010 Hello Ken Should work on my 1MB+ XEGS too. Great demo! (Only used Atari800Mac to check it out) Happy MMX to you too. greetings Mathy Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted January 1, 2010 Author Share Posted January 1, 2010 Hello Ken Should work on my 1MB+ XEGS too. Great demo! (Only used Atari800Mac to check it out) Happy MMX to you too. greetings Mathy I'd be interested in knowing what it does on various machines.. It definitely will not work correctly on any machine that does not have true separate antic and cpu access to extended ram (bits 4 & 5 of PORTB have to be like a stock 130xe). The "effects" on all the slides are the same.. Its 320x200x8 colors via per-scanline switching of color reg. 2 between red, green, and blue. And per-scanline bitmap data switching between extended banks 0,1, and 2.. Kewl thing about this system is that ALL of your base ram is free for your own programming.. All of the bitmap data and display list data is stored in extended ram banks 0-3.. The only thing that resides in base ram is a DLI routine which occupies the first 63bytes of page 6. And of course, in the case of this demo, the BASIC program that loads everything.. Heres how to make the .8C8 picture files I used.. Load up photoshop and open a 320x200 picture using standard 24bit RGB color setting.. Draw your picture using the folllowing colors: 000000=black FFFFFF=white FF0000=red 00FF00=green 0000FF=blue FFFF00=yellow 00FFFF=cyan FF00FF=magenta Or set up an indexed color pallete of these exact colors, and have photoshop convert an existing image to them.. One you have a 320 x 200 image in these colors, save it back as an normal RGB color .BMP or .PSD image. 1) reload the image and make sure it's in normal RGB color mode.. 2) Now go to the "channels" pane and dupilcate the RED channel. Delete the original RED, GREEN, and BLUE channels.. 3) copy whats left in the picture into the copy buffer.. 4) Open a new 320x200 image, this time select "bitmap" instead of RGB color.. and paste the copy buffer into this image.. 5) Save this image as RED.BMP (select WINDOWS, 1-bit BMP, and check the "flip row order" box). Repeat steps 1-5 for the Green and Blue components of the image.. You should end up with three separate 1-bit .BMP image files.. Load all three of them into a good Hex editor.. On each file, delete the first 62 bytes (the .bmp header).. Delete the last 2 bytes (padding bytes that photoshop seems to add.) Your file size should be exactly 8000 bytes per file now.. Invert the bits on all three files.. Now paste the Green file onto the end of the red file.. and then paste the blue file onto the end of that.. You should now have a 24000 byte file.. Save it as PICTURE.8C8, and copy it into the demo .ATR disk image.. Modify the BASIC program (lines 2000-2090 handle the file loading) by replacing the filename on one of the lines with "D:PICTURE.8C8". Run the program and see how it looks... I know this is a big pain in the ass... Maybe I'll make a quick routine that just loads standard 4bit .BMP files, and discards the 4th bit... Then you could just use Windows PAINT and save normal "16 color BMP files" (using only the 8 "primary" colors, of course).. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 1, 2010 Share Posted January 1, 2010 Wow, It does not work on Altirra?? Does look nice on Atari800win Plus tho..Nice slide show! Quote Link to comment Share on other sites More sharing options...
+wood_jl Posted January 1, 2010 Share Posted January 1, 2010 Wow! Thanks for sharing! This inspired me to dig out my 130XE and Ebay-sourced "combination S-video and composite cable" which I had never tried. Bravo. Quote Link to comment Share on other sites More sharing options...
+Stephen Posted January 1, 2010 Share Posted January 1, 2010 Nice mg - Atari800Win decided to display them properly today. If I can get my spare monitor cable working today I'll get to try them on 2 different CRTs. Stephen Anderson Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted January 2, 2010 Share Posted January 2, 2010 Well, since I converted hundreds of GIF images into Colorview RGB format in the 90s, I found out that RGB mode 8 (or Gr.8 RGB mode) and RGB mode 9 (or Gr. 9 RGB mode) does not work very well on PAL Ataris. In Gr.8 you never get 8 different colours on a PAL machine and in Gr. 9 you get nowhere near 4096 colours on a PAL machine... When viewing your slideshow I could see this again - attached you find some PCX pictures (done with the emulator and OlivierP palette - for PAL machines) of Gr. 8 RGB pics (Wire 1, Wire 2, Atari 1, Atari 2), Gr. 9 RGB pics (Jaguar and Budgirls) and of Gr. 15 RGB pics (Colpal and Gamgfx). As you can see, Gr.8 and Gr. 9 RGB modes don`t look good on PAL Ataris, whereas Gr. 15 looks fine... Besides, there is a RLE-compressed version of RGB-pictures (introduced by Clay Halliwell with "Colourviewsquash", also supported by Jeff Potter`s "Jview") which can save up to 70% of disk-space. Not sure how good the RLE compression works in Gr. 8, but in Gr. 15 it gave very good compression results (the source for the RLE compression is also available). Attached the sources for the RLE compressed RGB pics here (RGBTools.Zip), maybe you want to use it in the future - packing/depacking is quite fast and there are already two programs that support RLE-compressed RGB pics (they always have the header RGB1 in the file): Coloursquashview by Clay Halliwell and The Projector by Jaroslaw Kucisz... Greetings, Andreas Koch. Quote Link to comment Share on other sites More sharing options...
Ralphy Rocket Posted January 2, 2010 Share Posted January 2, 2010 Here! Here! Happy New Year! Nice!!!!! Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 2, 2010 Share Posted January 2, 2010 It'll always look "worse" in PAL since you only have ~ 16 cycles per second vs 20 for NTSC. I've worked out a new approach to doing these pics in the 80 pixel modes, no idea if it'll look any better as I've not tried it out yet. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted January 2, 2010 Share Posted January 2, 2010 Now working in Altirra thanks to a certain Phaeron and his lightning updates.. http://www.virtualdub.org/beta/Altirra-1.5-test16.zip Quote Link to comment Share on other sites More sharing options...
miker Posted January 2, 2010 Share Posted January 2, 2010 Nice one. But I don't see any point to make it use 130XE ram extension. The main program can be modified to load whole 24000 bytes to memory just above the BASIC-program, and then modify the DLI.OBJ to change address 560 ($230) instead of 54017 ($D301). It should work, I think. Quote Link to comment Share on other sites More sharing options...
miker Posted January 2, 2010 Share Posted January 2, 2010 (edited) OK, ignore my last post... Did some tests under Turbo BASIC: The pic-RGB-parts can be loaded from $4000, $6000 and $8000 addresses. The main program should be compiled though (to make free space from $4000 on). I don't attach anything here cause I failed to initialize DL-interrupt properly after these mods. Just my thinking... Edited January 2, 2010 by miker Quote Link to comment Share on other sites More sharing options...
Rybags Posted January 2, 2010 Share Posted January 2, 2010 Alternatively, a screen image could go under Basic at $A000-BFFF and the DLI could just swap out Basic to enable it's display. Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted January 2, 2010 Author Share Posted January 2, 2010 (edited) OK, ignore my last post... Did some tests under Turbo BASIC: The pic-RGB-parts can be loaded from $4000, $6000 and $8000 addresses. The main program should be compiled though (to make free space from $4000 on). I don't attach anything here cause I failed to initialize DL-interrupt properly after these mods. Just my thinking... The point is that after you load 24k of bitmap data, youve got precious little space left for a BASIC program.. Using extended ram for the bitmaps and Display list makes for plenty of free ram for basic, but you have to turn off ANTIC if you want to make changes to the bitmap data.. I just did it this way for this DEMO because its easy for people to "play with" in BASIC.. You are right though.. For the best use of this system, it would be much better to do the opposite.. Stick all 3 bitmaps, and the display list in base ram, and then write your main program (assembly language) to run "banked" in extended ram.. "shadow" the DLI routine at some adress in all extended ram banks so that it will alwayse be available no matter what bank is currently selected.. This way, you could actually make realtime changes to the display.. Keep in mind though that this would also require 3 separate custom display lists, with an LMS at every single scan line. So your base ram memory has to be managed "just right".. This is why this system is not very practical for large applications on a 64k machine.. Using 130xe separate antic/cpu access though.. as long as we write code that can be run in 16k banks, we can "have our cake and eat it too." so to speak.... Edited January 2, 2010 by MEtalGuy66 Quote Link to comment Share on other sites More sharing options...
miker Posted January 2, 2010 Share Posted January 2, 2010 Yeah, but my point of changing this procedure is that: 1. I don't have any stock 130XE right now 2. My Atari (yeah - 130XE, but with 1MB not compatible with 130XE-mode anymore) sits right next to PC, so it's utterly ill action to run the demo on emu then. Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted January 2, 2010 Share Posted January 2, 2010 (edited) Nice one. But I don't see any point to make it use 130XE ram extension. The main program can be modified to load whole 24000 bytes to memory just above the BASIC-program, and then modify the DLI.OBJ to change address 560 ($230) instead of 54017 ($D301). It should work, I think. Well, thats what "Coloursquashview" by Clay Haliwell does - it is written in Atari Basic, works on a 64k A8 machine and loads+displays (RLE-compressed) RGB mode 8/9/15 pictures (in standard 80/160/320 x 192 resolution), it even supports multiple drives and subdirs... you can find a sample disk with this viewer in my attachments above (one in RGB_tools.Zip and another one in RGB_src.zip). The only difference is, that the RGB pics are not one big 24,000 bytes file but rather the three separate R,G,B files (with 62 sectors each) RLE-compressed into one file (most of the time shorter than 186 sectors). Maybe Ken is able to split up his 24k pics into three separate pics again and use "Colourviewsquash" to RLE-compress them into one shorter file. Then he could use Coloursquashview or the Graphics Projector to display his pics on a 64k machine. It could be the case though, that Coloursquashview or The Graphics Projector use RAM under the OS and thus do not work with Sparta-DOS, I have not tested this, since I never use Sparta. Last not least, the RGB viewer programs display the pics in yyy x 192 resolution, but it should be possible to alter/patch at least Colourviewsquash (an Atari Basic program!) to display yyy x 200 pixels instead (or the other way around, re-size the 320x200 pics into 320x192 pics)... In short: - split up the single 24k file into three separate pics (eventually downsize to 320x192 resolution), with extenders .R, .G, .B - use Colourviewsquash to RLE compress these pics into one file, with extender .RGB - then use Coloursquashview or the Graphics Projector to view them on a 64k machine (eventually patch Coloursquashview to display 320x200 instead of 320x192) For GIF87a pictures the conversion process is easier, since there is a converter named JVIEW.COM by Jeff Potter available which can convert GIF into uncompressed R,G,B pictures or into RLE-compressed RGB pictures at once with all three gfx-modes 8/9/15 supported; there are even various dithering modes for Gr. 8 and Gr. 15 available, as well as zoom-options vertically/horizontally if the GIF is bigger than the standard Gr. 8/9/15 resolution (the program Jview therefore requires 64k RAM - RAM under the OS and thus will not work with disk-versions of SpartaDOS)... Greetings, Andreas Koch. P.S.: Attached two images with graphic viewers + converters here, side a contains JVIEW10.COM, side b contains Colourviewsquash (Atari Basic!), Coloursquashview (Atari Basic!) and some RGB loader in TB XL plus many other gfx converters... Edited January 2, 2010 by CharlieChaplin Quote Link to comment Share on other sites More sharing options...
MEtalGuy66 Posted January 3, 2010 Author Share Posted January 3, 2010 (edited) Yeah, but my point of changing this procedure is that: 1. I don't have any stock 130XE right now 2. My Atari (yeah - 130XE, but with 1MB not compatible with 130XE-mode anymore) sits right next to PC, so it's utterly ill action to run the demo on emu then. MIKER: Yep. 1024k is not even close to being worth sacrificing spearate antic/cpu access.. at a minimum, you should install a switch which "gives back" bit5 of PORTB for this purpose. Andreas: This is the year 2010.. we have totaly ease of use of 16meg ATR images.. who in the hell wants to add compression to an already overly complex method of displaying images? Let's be realistic.. Back in the floppy disk days when you could only fit a few 24k image files on a disk, that may have been nice.. But nowadayze, I wont be bothering with any sort of compression.. I will recode my DLI routine to run from an adress above $7FFF (and leave PORTB alone) and I will create the custom display lists to LMS the data correctly from three consecutive bitmaps in base ram ($2000,$4000,$6000 per Miker's suggestions).. But all of the demos I write are gonna run in banked extended ram, and use a service routine (also aove $7FFF) to manipulate the display.. This way, I can write some nice apps/demos that actually change the display in realtime without disrupting ANTIC's access to the bitmap data And yeah, you are gonna have to have separate antic/cpu access to extended ram in order to run them.. Edited January 3, 2010 by MEtalGuy66 Quote Link to comment Share on other sites More sharing options...
Fres Posted January 4, 2010 Share Posted January 4, 2010 Cool! Nice work, mg. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.